Tag Archives: following

How To Improve Your Design Process With Data-Based Personas




How To Improve Your Design Process With Data-Based Personas

Tim Noetzel



Most design and product teams have some type of persona document. Theoretically, personas help us better understand our users and meet their needs. The idea is that codifying what we’ve learned about distinct groups of users helps us make better design decisions. Referring to these documents ourselves and sharing them with non-design team members and external stakeholders should ultimately lead to a user experience more closely aligned with what real users actually need.

In reality, personas rarely prove equal to these expectations. On many teams, persona documents sit abandoned on hard drives, collecting digital dust while designers continue to create products based primarily on whim and intuition.

In contrast, well-researched personas serve as a proxy for the user. They help us check our work and ensure that we’re building things users really need.

In fact, the best personas don’t just describe users; they actually help designers predict their behavior. In her article on persona creation, Laura Klein describes it perfectly:

“If you can create a predictive persona, it means you truly know not just what your users are like, but the exact factors that make it likely that a person will become and remain a happy customer.”

In other words, useful personas actually help design teams make better decisions because they can predict with some accuracy how users will respond to potential product changes.

Obviously, for personas to facilitate these types of predictions, they need to be based on more than intuition and anecdotes. They need to be data-driven.

So, what do data-driven personas look like, and how do you make one?

Start With What You Think You Know

The first step in creating data-driven personas is similar to the typical persona creation process. Write down your team’s hypotheses about what the key user groups are and what’s important to each group.

If your team is like most, some members will disagree with others about which groups are important, the particular makeup and qualities of each persona, and so on. This type of disagreement is healthy, but unlike the usual persona creation process you may be used to, you’re not going to get bogged down here.

Instead of debating the merits of each persona (and the various facets and permutations thereof), the important thing is to be specific about the different hypotheses you and your team have and write them down. You’re going to validate these hypotheses later, so it’s okay if your team disagrees at this stage. You may choose to focus on a few particular personas, but make sure to keep a backlog of other ideas as well.

Hypothetical Personas


First, start by recording all the hypotheses you have about key personas. You’ll refine these through user research in the next step. (Large preview)

I recommend aiming for a short, 1–2 sentence description of each hypothetical persona that details who they are, what root problem they hope to solve by using your product, and any other pertinent details.

You can use the traditional user stories framework for this. If you were creating hypothetical personas for Craigslist, one of these statements might read:

“As a recent college grad, I want to find cheap furniture so I can furnish my new apartment.”

Another might say:

“As a homeowner with an extra bedroom, I want to find a responsible tenant to rent this space to so I can earn some extra income.”

If you have existing data — things like user feedback emails, NPS scores, user interview notes, or analytics data — be sure to go over them and include relevant data points in your notes along with your user stories.

Validate And Refine

The next step is to validate and refine these hypotheses with user interviews. For each of your hypothetical personas, you’ll want to start by interviewing 5 to 10 people who fit that group.

You have three key goals for these interviews. For each group, you need to:

  1. Understand the context in which they need to solve the problem.
  2. Confirm that members of the persona group agree that the problem you recorded is an urgent and painful one that they struggle to solve now.
  3. Identify key predictors of whether a member of this persona is likely to become and remain an active user.

The approach you take to these interviews may vary, but I recommend a hybrid approach between a traditional user interview, which is very non-leading, and a Lean Problem interview, which is deliberately leading.

Start with the traditional user interview approach and ask behavior-based, non-leading questions. In the Craigslist example, we might ask the recent college grad something like:

“Tell me about the last time you purchased furniture. What did you buy? Where did you buy it?”

These types of questions are great for establishing whether the interviewee recently experienced the problem in question, how they solved it, and whether they’re dissatisfied with their current solution.

Once you’ve finished asking these types of questions, move on to the Lean Problem portion of the interview. In this section, you want to tell a story about a time when you experienced the problem — establishing the various issues you struggled with and why it was frustrating — and see how they respond.

You might say something like this:

“When I graduated college, I had to get new furniture because I wasn’t living in the dorm anymore. I spent forever looking at furniture stores, but they were all either ridiculously expensive or big-box stores with super-cheap furniture I knew would break in a few weeks. I really wanted to find good furniture at a reasonable price, but I couldn’t find anything and I eventually just bought the cheap stuff. It inevitably broke, and I had to spend even more money, which I couldn’t really afford. Does any of that resonate with you?”

What you’re looking for here is emphatic agreement. If your interviewee says “yes, that resonates” but doesn’t get much more excited than they were during the rest of the interview, the problem probably wasn’t that painful for them.

Data-Driven Personas Interview Format


You can validate or invalidate your persona hypotheses with a series of quick, 30-minute interviews. (Large preview)

On the other hand, if they get excited, empathize with your story, or give their own anecdote about the problem, you know you’ve found a problem they really care about and need to be solved.

Finally, make sure to ask any demographic questions you didn’t cover earlier, especially those around key attributes you think might be significant predictors of whether somebody will become and remain a user. For example, you might think that recent college grads who get high-paying jobs aren’t likely to become users because they can afford to buy furniture at retail; if so, be sure to ask about income.

You’re looking for predictable patterns. If you bring in 5 members of your persona and 4 of them have the problem you’re trying to solve and desperately want a solution, you’ve probably identified a key persona.

On the other hand, if you’re getting inconsistent results, you likely need to refine your hypothetical persona and repeat this process, using what you learn in your interviews to form new hypotheses to test. If you can’t consistently find users who have the problem you want to solve, it’s going to be nearly impossible to get millions of them to use your product. So don’t skimp on this step.

Create Your Personas

The penultimate step in this process is creating the actual personas themselves. This is where things get interesting. Unlike traditional personas, which are typically static, your data-driven personas will be living, breathing documents.

The goal here is to combine the lessons you learned in the previous step — about who the user is and what they need — with data that shows how well the latest iteration of your product is serving their needs.

At my company Swish, each one of our personas includes two sections with the following data:

Predictive User Data Product Performance Data
Description of the user including predictive demographics. The percentage of our current user base the persona represents.
Quotes from at least 3 actual users that describe the jobs-to-be-done. Latest activation, retention, and referral rates for the persona.
The percentage of the potential user base the persona represents. Current NPS Score for the persona.

If you’re looking for more ideas for data to include, check out Coryndon Luxmoore’s presentation on how his team created data-driven personas at Buildium.

It may take some time for your team to produce all this information, but it’s okay to start with what you have and improve the personas over time. Your personas won’t be sitting on a shelf. Every time you release a new feature or change an existing one, you should measure the results and update your personas accordingly.

Integrate Your Personas Into Your Workflow

Now that you’ve created your personas, it’s time to actually use them in your day-to-day design process. Here are 4 opportunities to use your new data-driven personas:

  1. At Standups
    At Swish, our standups are a bit different. We start these meetings by reviewing the activation, retention, and referral metrics for each persona. This ensures that — as we discuss yesterday’s progress and today’s obstacles — we remain focused on what really matters: how well we’re serving our users.
  2. During Prioritization
    Your data-driven personas are a great way to keep team members honest as you discuss new features and changes. When you know how much of your user base the persona represents and how well you’re serving them, it quickly becomes obvious whether a potential feature could actually make a difference. Suddenly deciding what to work on won’t require hours of debate or horse-trading.
  3. At Design Reviews
    Your data-driven personas are a great way to keep team members honest as you discuss new designs. When team members can creditably represent users with actual quotes from user interviews, their feedback quickly becomes less subjective and more useful.
  4. When Onboarding New Team Members
    New hires inevitably bring a host of implicit biases and assumptions about the user with them when they start. By including your data-driven personas in their onboarding documents, you can get new team members up to speed much more quickly and ensure they understand the hard-earned lessons your team learned along the way.

Keeping Your Personas Up To Date

It’s vitally important to keep your personas up-to-date so your team members can continue to rely on them to guide their design thinking.

As your product improves, it’s simple to update NPS scores and performance data. I recommend doing this monthly at a minimum; if you’re working on an early-stage, rapidly-changing product, you’ll get better mileage by updating these stats weekly instead.

It’s also important to check in with members of your personas periodically to make sure your predictive data stays relevant. As your product evolves and the competitive landscape changes, your users’ views about their problems will change as well. If your growth starts to plateau, another round of interviews may help to unlock insights you didn’t find the first time. Even if everything is going well, try to check in with members of your personas — both current users of your product and some non-users — every 6 to 12 months.

Wrapping Up

Building data-driven personas is a challenging project that takes time and dedication. You won’t uncover the insights you need or build the conviction necessary to unify your team with a week-long throwaway project.

But if you put in the time and effort necessary, the results will speak for themselves. Having the type of clarity that data-driven personas provide makes it far easier to iterate quickly, improve your user experience, and build a product your users love.

Further Reading

If you’re interested in learning more, I highly recommend checking out the linked articles above, as well as the following resources:

Smashing Editorial
(rb, ra, yk, il)


Original source: 

How To Improve Your Design Process With Data-Based Personas

Monthly Web Development Update 3/2018: Service Workers, Building A CDN, And Cheating At Design

Service Worker is probably one of the most misrepresented technologies we currently have. When I hear people talking about it, the topic almost always revolves around serving an app when a user is offline. However, Service Worker can do so much more than that, and every week I come across new articles that show how powerful the technology really is.

This month, for example, we can learn how to use Service Worker for cross-tab messaging and to load off requests into the background with the Background Sync API. I think the toolset we now have in our browsers already allows us to build great experiences regardless of the network state. Now it’s up to us to make the experiences so great that users truly love them. And that’s probably the hardest part.

News

Sketch 49
Sketch 49 has arrived, and with it comes the new Prototyping in Sketch feature which lets you see the entire flow in action. (Image credit)

General

  • Ed Ellson examined Chrome’s Background Sync API and the retry strategy it uses to perform a request. By allowing synchronization in the background after a first attempt has failed, the API helps us improve the browsing experience for users who go offline or are on unstable connections.

UI/UX

Cheating At Design
Use color and weight to create visual hierarchy instead of size is only one of the seven practical tips for cheating at design that Adam Wathan and Steve Schoger share. (Image credit)

Security

  • With GraphQL you can query exactly what you want whenever you want. This is amazing for working with an API but also has complex security implications. Instead of asking for legitimate, useful data, a malicious actor could submit an expensive, nested query to overload your server, database, network, or all of these. To prevent this from happening, Max Stoiber shows us how we can secure the GraphQL API in our projects.

Privacy

  • WebKit is introducing the Storage Access API. The new API targets one of the major issues with Safari’s Intelligent Tracking Protection (ITP): Identifying users who are logged in to a first-party service but view content of it embedded on a third party (YouTube videos on a blog, for example). The Storage Access API allows third-party embeds to request access to their first-party cookies when the user interacts with them. A good solution to protect user privacy by default and allow exceptions on request.

Web Performance

  • Janos Pasztor built his own Content Delivery Network because he thinks it can be a better solution than using existing third parties. The code for the CDN of his personal website is now available on Github. A nice web performance article that looks at common solutions from a different angle.
  • A year after Facebook’s announcement to broadly use Cache-Control: Immutable, Paul Calvano examined how widespread its usage is on the web — apart from the few big players. Interesting research and it’s still sad to see that this useful performance tool is used so little. At Colloq, we use it quite a lot, which saves us a lot of traffic and load on our servers and enables us to serve a lot of pages nearly instantly to recurring users.
Global stats of a self-built CDN
Global stats for the custom CDN that Janos Pasztor built. (Image credit)

HTML & SVG

JavaScript

CSS

Accessibility

Accessibility Checklist
The Accessibility Checklist helps build accessibility into your process no matter your role or stage in a project. (Image credit)

Work & Life

  • This week I read an article by Alex Duloz, and his words still stick with me: “When we develop a new application, when we post content on the Internet, whatever we do that people will have access to, we should consider just for a minute if our contribution adds up to the level of dumbness kids/teenagers are exposed to. If it does, we should refrain from going live.” The truth is, most of us, including me, don’t consider this before posting on the Internet. We create funny things, share funny pictures and try to get fame with silly posts. But in reality, we shape society with this. Let’s try to provide more useful resources and make the consumption of this more enjoyable so young people can profit from our knowledge and not only view things we think are funny. “We should always consider how teenagers will use what we release.”
  • The MIT OpenCourseWare released a lot of free audio and video lectures. This is amazing news and makes great content available to broader masses.
  • Jake Knapp says great work requires idealism and cynicism and has strong arguments to back up this theory. An article worth reading.
  • There’s an important article on how unhappiness has grown in America’s population since around the year 2000. It reveals that while income inequality might play a role, the more important aspect is that young people who use a lot of digital media are unhappier than those who use it only up to an hour a day. Interestingly, people who don’t use digital media at all, are unhappy, too, so the outcome of this could be that we should try to use digital media only moderately — at least in our private lives. I bet it’ll make a big difference.
  • Following the theory of Michael Bradley, projects don’t necessarily need a roadmap for success. Instead, he suggests to create a moral compass that points out why the project exists and what its purpose is.

Going Beyond…

We hope you enjoyed this Web Development Update. The next one is scheduled for April 13th. Stay tuned.

Excerpt from – 

Monthly Web Development Update 3/2018: Service Workers, Building A CDN, And Cheating At Design

How To Make A WordPress Plugin Extensible

Have you ever used a plugin and wished it did something a bit differently? Perhaps you needed something unique that was beyond the scope of the settings page of the plugin.

I have personally encountered this, and I’m betting you have, too. If you’re a WordPress plugin developer, most likely some of your users have also encountered this while using your plugin.

Here’s a typical scenario: You’ve finally found that plugin that does everything you need — except for one tiny important thing. There is no setting or option to enable that tiny thing, so you browse the documentation and find that you can’t do anything about it. You request the feature in the WordPress plugin’s support forum — but no dice. In the end, you uninstall it and continue your search.

Imagine if you were the developer of this plugin. What would you do if a user asked for some particular functionality?

The ideal thing would be to implement it. But if the feature was for a very special use case, then adding it would be impractical. It wouldn’t be good to have a plugin setting that only 0.1% of your users would have a use for.

You’d only want to implement features that affect the majority of your users. In reality, 80% of users use 20% of the features (the 80/20 rule). So, make sure that any new feature is highly requested, and that 80% of your users would benefit from it, before implementing it. If you created a setting for every feature that is requested, then your plugin would become complicated and bloated — and nobody wants that.

Your best bet is to make the plugin extensible, code-wise, so that other people can enhance or modify it for their own needs.

In this article, you’ll learn about why making your plugin extensible is a good idea. I’ll also share a few tips of how I’ve learned to do this.

What Makes A Plugin Extensible?

In a nutshell, an extensible plugin means that it adheres to the “O” part of the SOLID principles of object-oriented programming — namely, the open/closed principle.

If you’re unfamiliar with the open/closed principle, it basically means that other people shouldn’t have to edit your code in order to modify something.

Applying this principle to a WordPress plugin, it would mean that a plugin is extensible if it has provisions in it that enable other people to modify its behavior. It’s just like how WordPress allows people to “hook” into different areas of WordPress, but at the level of the plugin.

A Typical Example Of A Plugin

Let’s see how we can create an extensible plugin, starting with a sample plugin that isn’t.

Suppose we have a plugin that generates a sidebar widget that displays the titles of the three latest posts. At the heart of the plugin is a function that simply wraps the titles of those three posts in list tags:


function get_some_post_titles() 
  $args = array(
      'posts_per_page' => 3,
  );

  $posts = get_posts( $args );

  $output = '
    '; foreach ( $posts as $post ) $output .= '
  • ' . $post->post_title . '
  • '; $output .= '
'; return $output; }

While this code works and gets the job done, it isn’t quite extensible.

Why? Because the function is set in its own ways, there’s no way to change its behavior without modifying the code directly.

What if a user wanted to display more than three posts, or perhaps include links with the posts’ titles? There’s no way to do that with the code above. The user is stuck with how the plugin works and can nothing to change it.

Including A Hundred Settings Isn’t The Answer

There are a number of ways to enhance the plugin above to allow users to customize it.

One such way would be to add a lot of options in the settings, but even that might not satisfy all of the possibilities users would want from the plugin.

What if the user wanted to do any of the following (scenarios we’ll revisit later):

  • display WooCommerce products or posts from a particular category;
  • display the items in a carousel provided by another plugin, instead of as a simple list;
  • perform a custom database query, and then use those query’s posts in the list.

If we added a hundred settings to our widget, then we would be able to cover the use cases above. But what if one of these scenarios changes, and now the user wants to display only WooCommerce products that are currently in stock? The widget would need even more settings to accommodate this. Pretty soon, we’d have a gazillion settings.

Also, a plugin with a huge list of settings isn’t exactly user-friendly. Steer away from this route if possible.

So, how would we go about solving this problem? We’d make the plugin extensible.

Adding Our Own Hooks To Make It Extensible

By studying the plugin’s code above, we see a few operations that the main function performs:

  • It gets posts using get_posts.
  • It generates a list of post titles.
  • It returns the generated list.

If other people were to modify this plugin’s behavior, their work would mostly likely involve these three operations. To make our plugin extensible, we would have to add hooks around these to open them up for other developers.

In general, these are good areas to add hooks to a plugin:

  • around and within the major processes,
  • when building output HTML,
  • for altering post or database queries,
  • before returning values from a function.

A Typical Example Of An Extensible Plugin

Taking these rules of thumb, we can add the following filters to make our plugin extensible:

  • add myplugin_get_posts_args for modifying the arguments of get_posts,
  • add myplugin_get_posts for overriding the results of get_posts,
  • add myplugin_list_item for customizing the generation of a list entry,
  • add myplugin_get_some_post_titles for overriding the returned generated list.

Here’s the code again with all of the hooks added in:


function get_some_post_titles() 
  $args = array(
      'posts_per_page' => 3,
  );

  // Let other people modify the arguments.
  $posts = get_posts( apply_filters( 'myplugin_get_posts_args', $args ) );

  // Let other people modify the post array, which will be used for display.
  $posts = apply_filters( 'myplugin_get_posts', $posts, $args );

  $output = '
    '; foreach ( $posts as $post ) // Let other people modify the list entry. $output .= '
  • ' . apply_filters( 'myplugin_list_item', $post->post_title, $post ) . '
  • '; $output .= '
'; // Let other people modify our output list. return apply_filters( 'myplugin_get_some_post_titles', $output, $args ); }

You can also get the code above in the GitHub archive.

I’m adding a lot of hooks here, which might seem impractical because the sample code is quite simple and small, but it illustrates my point: By adding just four hooks, other developers can now customize the plugin’s behavior in all sorts of ways.

Namespacing And Context For Hooks

Before proceeding, note two important things about the hooks we’ve implemented:

  • We’re namespacing the hooks with myplugin_.
    This ensures that the hook’s name doesn’t conflict with some other plugin’s hook. This is just good practice, because if another hook with the same name is called, it could lead to unwanted effects.
  • We’re also passing a reference to $args in all of the hooks for context.
    I do this so that if others use this filter to change something in the flow of the code, they can use that $args parameter as a reference to get an idea of why the hook was called, so that they can perform their adjustments accordingly.

The Effects Of Our Hooks

Remember the unique scenarios I talked about earlier? Let’s revisit those and see how our hooks have made them possible:

  • If the user wants to display WooCommerce products or posts from a particular category, then either they can use the filter myplugin_get_posts_args to add their own arguments for when the plugin queries posts, or they can use myplugin_get_posts to completely override the posts with their own list.
  • If the user wants to display the items in a carousel provided by another plugin, instead of as a simple list, then they can override the entire output of the function with myplugin_get_some_post_titles, and instead output a carousel from there.
  • If the user wants to perform a custom database query and then use that query’s posts in the list, then, similar to the first scenario, they can use myplugin_get_posts to use their own database query and change the post array.

Much better!

A Quick Example Of How To Use Our Filters

Developers can use add_filter to hook into our filters above (or use add_action for actions).

Taking our first scenario above, a developer can just do the following to display WooCommerce products using the myplugin_get_posts_args filter that we created:

add_filter( 'myplugin_get_posts_args', 'show_only_woocommerce_products' );
function show_only_woocommerce_products( $args ) 
   $args['post_type'] = 'product';
   return $args;

We Can Also Use Action Hooks

Aside from using apply_filters, we can also use do_action to make our code extensible. The difference between the two is that the first allows others to change a variable, while the latter allows others to execute additional functionality in various parts of our code.

When using actions, we’re essentially exposing the plugin’s flow to other developers and letting them perform other things in tandem.

It might not be useful in our example (because we are only displaying a shortcode), but it would be helpful in others. For example, given an extensible backup plugin, we could create a plugin that also uploads the backup file to a third-party service such as Dropbox.

“Great! But Why Should I Care About Making My Plugin Extensible?”

Well, if you’re still not sold on the idea, here are a few thoughts on why allowing other people to modify your plugin’s behavior is a good idea.

It Opens Up the Plugin to More Customization Possibilities

Everyone has different needs. And there’s a big chance your plugin won’t satisfy all of them, nor can you anticipate them. Opening up your plugin to allow for modifications to key areas of your plugin’s behavior can do wonders.

It Allows People to Introduce Modifications Without Touching the Plugin’s Code

Other developers won’t be forced to change your plugin’s files directly. This is a huge benefit because directly modifying a plugin’s file is generally bad practice. If the plugin gets updated, then all of your modifications will be wiped.

If we add our own hooks for other people to use, then the plugin’s modifications can be put in an external location — say, in another plugin. Done this way, the original plugin won’t be touched at all, and it can be freely updated without breaking anything, and all of the modifications in the other plugin would remain intact.

Conclusion

Extensible plugins are really awesome and give us room for a lot of customization possibilities. If you make your plugin extensible, your users and other developers will love you for it.

Take a look at plugins such as WooCommerce, Easy Digital Downloads and ACF. These plugins are extensible, and you can easily tell because numerous other plugins in WordPress’ plugins directory add functionality to them. They also provide a wide array of action and filter hooks that modify various aspects of the plugins. The rules of thumb I’ve enumerated above have come up in my study of them.

Here are a few takeaways to make your plugin extensible:

  • Follow the open/closed principle. Other people shouldn’t have to edit your code in order to modify something.
  • To make your plugin extensible, add hooks in these places:
    • around and within major processes,
    • when building the output HTML,
    • for altering post or database queries,
    • before returning values from a function.
  • Namespace your hooks’ names with the name of your plugin to prevent naming conflicts.
  • Try passing other variables that are related to the hook, so that other people get some context of what’s happening in the hook.
  • Don’t forget to document your plugin’s hooks, so that other people can learn of them.

Further Reading

Here are some resources if you want to learn more about extending plugins:

Smashing Editorial
(mc, ra, al, yk, il)

Original post:  

How To Make A WordPress Plugin Extensible

A Comprehensive Guide To User Testing

(This is a sponsored article.) With a prototype of your design built, it’s important to start testing it to see if the assumptions you have made are correct. In this article, the seventh in my ongoing series exploring the user experience design process, I’ll explore the importance of user testing.
As I explored in my earlier article on research, where I explored the research landscape, there are many different types of research methods you can use, and there are a variety of different user tests you can run, including:

Link:  

A Comprehensive Guide To User Testing

How To Streamline WordPress Multisite Migrations With MU-Migration

Migrating a standalone WordPress site to a site network (or “multisite”) environment is a tedious and tricky endeavor, the opposite is also true. The WordPress Importer works reasonably well for smaller, simpler sites, but leaves room for improvement. It exports content, but not site configuration data such as Widget and Customizer configurations, plugins, and site settings. The Importer also struggles to handle a large amount of content. In this article, you’ll learn how to streamline this type of migration by using MU-Migration, a WP-CLI plugin.

Link: 

How To Streamline WordPress Multisite Migrations With MU-Migration

How To Make A Drag-and-Drop File Uploader With Vanilla JavaScript

It’s a known fact that file selection inputs are difficult to style the way developers want to, so many simply hide it and create a button that opens the file selection dialog instead. Nowadays, though, we have an even fancier way of handling file selection: drag and drop.
Technically, this was already possible because most (if not all) implementations of the file selection input allowed you to drag files over it to select them, but this requires you to actually show the file element.

Read this article:  

How To Make A Drag-and-Drop File Uploader With Vanilla JavaScript

“Maybe Later” – A New Interaction Model for Ecommerce Entrance Popups

I’d guess that over half of the e-commerce stores I visit use entrance popups to advertise their current deal. Most often it’s a discount.

What is an Entrance Popup and What’s Wrong With Them?

They are as they sound. A popup that appears as soon as you arrive on the site. They’re definitely the most interruptive of all popups because you’ve not even had a chance to look around.

I get why they are used though because they work really well at one thing – letting you know that an offer exists, and what it is. And given high levels of competition for online dollars, it makes sense why they would be so prolific.

The intrusion isn’t the only point of frustration. There’s also the scenario where you arrive on a site, see an offer appear, you find it interesting and potentially very valuable (who doesn’t want 50% off?), but you want to do some actual looking around – the shopping part – before thinking about the offer. And when you’re forced to close the popup in order to continue, it’s frustrating because you want the offer! You just don’t want it right now.

So, given the fact that they are so common, and they’re not going anywhere anytime soon, and they create these points of frustration, I’ve been working on developing a few alternative ways to solve the same problem.

The one I want to share with you today is called “Maybe Later”.

“Maybe Later” is a Solution to Increase Engagement and Reduce Frustration

As you saw in the header image, instead of the now classic YES/NO popup – the one that gets abused by shady marketers (Technology isn’t the Problem, We Are.) – “Maybe Later” includes a third option called, you guessed it!

The middle option gives some control back to the shopper.

It’s more than just a third button, here’s how it works (I’ll refer to the sketch opposite):

  1. The popup appears when you enter the site. You can choose “No” to get rid of it, “Yes” to take advantage of it, or “Maybe Later” to register your interest but get it out of your way.
  2. When you click “Maybe Later” a cookie is set to log your interest.
  3. Now while you are browsing the rest of the site, a Sticky Bar – targeted at the cookie that was set – appears at the bottom (or top) of the page, with a more subtle reminder of the offer, so that you know it there and ready if you decide to take advantage of it.
  4. If you decide against the offer, you can click “No thanks” on the Sticky Bar, the cookie is deleted, and the offer is hidden for good.

The core purpose of this idea is to put the control back with the shopper while creating an effective method for the retailer to engage with you, with your permission.


Follow our Product Awareness Month journey >> click here to launch a popup with a subscribe form (it uses our on-click trigger feature).


Visual Hierarchy on Popup Buttons

When you have more than a single button, it’s important to establish visual design cues to indicate how the hierarchical dominance plays out. For you as a marketer, the most important of the three buttons is YES, MAYBE LATER is second, and NO is the least.

You can create a better user experience for your visitors by using the correct visual hierarchy and affordance when it comes to button design. In the image below, there is a progression of visual dominance from left to right (which is the correct direction – in Western society). Left is considered a backward step (in online interaction design terms), and right is a progression to the goal.

From left to right we see:

  • The NO button: is designed as a ghost button which has the least affordance and weight of the three.
  • The MAYBE LATER button: gains some solidity by increasing the opacity
  • The YES button: has a fully opaque design represented by the primary call to action colour of the theme.

You can achieve a similar level of dominance by making the secondary action a link instead of a button, which is a great visual hierarchy design technique. What I don’t like is when people do this, but they make the “No thanks” link really tiny. If you’re going to provide an option, do it with a little dignity and make it easy to see and click.

See the “Maybe Later” Popup-to-Sticky-Bar Model in Action

Alrighty, demo time! I have a few instructions for you to follow to see it in action. I didn’t load the popup on this page as it’s supposed to be an entrance popup and I needed to set the scene first. But I’ll use some trickery to make it happen for you.

Follow these instructions and you’ll see “Maybe Later” in action:

Please note: this is desktop only. Reason being is that Google dislikes entrance popups on mobile. Sticky Bars are the Google-friendly way to present promos on mobile, so they work, but the combo isn’t appropriate.

  1. Visit this page (opens in new window).
  2. Click the “Maybe Later” button and the popup will close.
  3. Refresh that page and you’ll see a Sticky Bar with the same offer appear at the bottom.
  4. Come back to this page.
  5. Refresh this page and you’ll see the Sticky Bar here too.
  6. Click “No thanks” to get rid of it when you’ve had enough :D

Here’s the entrance Popup you will see:

Maybe Later - A New  interaction model for ecommerce entrance popups

And the Sticky Bar you will see following that:

How to Use “Maybe Later” on Your Website

If you’d like to give it a try, follow the instructions below in your Unbounce account. (You should sign up for Unbounce if you haven’t already: you get Landing Pages, Popups, and Sticky Bars all in the same builder).

You can also see what Popups and Sticky Bars look like on your website by entering your URL on our new Live Preview Tool.

“Maybe Later” Setup Instructions

Caveat: This is not an official Unbounce feature, and as such is not technically supported. But it is damn cool. And if enough people scream really hard, maybe I’ll be able to persuade the product team to add it to the list. And please talk to a developer before trying this in a production environment.

Step 1: Create a Popup in Unbounce

Step 2: Add “Maybe Later” Script to the Popup

In the “Javascripts” window located in the bottom-left.

Add the following script “Before the body end tag”, replacing “lp-pom-button-50” with the id of your “Maybe Later” button, and unbounce.com with your own domain.

document.getElementById("lp-pom-button-50").onclick = function() 
parent.postMessage(JSON.stringify('later'), 'https://unbounce.com');

Step 3: Set URL Targeting on Popup

Set up the URL targeting for where you want the popup to appear. I chose the post you’re reading right now (with a ?demo extension so it would only fire when I sent you to that URL).

Step 4: Set Cookie Targeting on Popup

Set up the cookie targeting to “Not show” when the “Maybe Later” cookie is present. The cookie is set when the button is clicked. (You’ll see how in step 9).

Step 5: Create a Sticky Bar in Unbounce

Step 6: Add “Maybe Later” Script to the Sticky Bar

Add the following script “Before the body end tag”, replacing “lp-pom-button-45” with the id of your “No Thanks” button, and unbounce.com with your own domain.

document.getElementById("lp-pom-button-45").onclick = function() 
parent.postMessage(JSON.stringify('laterForget'), 'https://unbounce.com');

Step 7: Set URL Targeting on Sticky Bar

Set up the URL targeting for where you want the Sticky Bar to appear. This might be every page on your e-commerce site, or in my case just this post and another for testing.

Step 8: Set Cookie Targeting on Sticky Bar

Set the Trigger to “Arrival”, Frequency to “Every Visit”, and Cookie Targeting to show when the cookie we’re using is set. (You’ll see how it’s set in the next step).

Step 9: Add “Maybe Later” Code to Your Website

This is some code that allows the Popup and Sticky Bar to “talk” to its host page and set/delete the cookie.

// On receiving message from the popup set a cookie
window.onload = function() 
function receiveMessage(e) 
var eventData = JSON.parse(e.data);
// Check for the later message
if (eventData === 'later') 
document.cookie = "mlshowSticky=true; expires=Thu, 11 May 2019 12:00:00 UTC; path=/";

if (eventData === 'laterForget') 
document.cookie = "mlshowSticky=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";

}
// Listen for the message from the host page
window.addEventListener('message', receiveMessage);
}

Step 10: Enjoy Being Awesome

That’s all, folks!


What Do You Think?

I’d love to know what you think about this idea in the comments, so please jump in with your thoughts and ideas.

Later (maybe),
Oli

p.s. Don’t forget to see what Popups and Sticky Bars look like on your website with the new Live Preview Tool

View original: 

“Maybe Later” – A New Interaction Model for Ecommerce Entrance Popups

Maximizing The Design Sprint

Following a summer of Wonder Woman, Spiderman, and other superhero blockbusters, it’s natural to fantasize about having a superpower of your own. Luckily for designers, innovators, and customer-centric thinkers, a design sprint allows you to see into the future to learn in just five days what customers think about your finished product.
As a UX consultant and in-house design strategist, I have facilitated dozens upon dozens of design workshops (ranging from rapid prototyping sessions to, of course, sprints).

View post: 

Maximizing The Design Sprint

Don’t Settle. Build the Marketing Campaigns of Your Dreams Without a Line of Code

Conquer technical limitations with Zapier and Unbounce

Hi, I’m Corey. Are you an idealistic marketer, like me?

That is—do you plan your marketing campaigns by pretending technical limitations aren’t a thing and just map out the ideal experience you want for your prospects from first impression to final conversion? Like this:

A photo of my actual campaign flow on the whiteboard.

If your whiteboard looks this optimistic, read on. We’ll nerd out together.

After us idealistic marketers are done dreaming about our perfect campaign structure from start to finish, the harsh reality sets in: technical limitations are definitely a thing. When the time comes to figure out how to actually do something a little crazy, like augment lead data or enrich it with extra data pulled from ‘the internet’, things get much trickier. But if you’re dedicated to the campaign you mapped out, you really want to make it happen.

Often, you’ll ask a developer for help and hear, “Sure it’s possible. I’ll just need two weeks to code it up. Log a request and we’ll prioritize it against all the other requests for my genius.”

We both know you’re not logging that request, because it’s not getting prioritized.

Eventually, you run a campaign that looks exactly like what you’ve done before, or what everyone else is doing, because it’s relatively easy for us—lowly marketers—to pull off by ourselves.

It’s infuriating.

Can’t we Execute More Sophisticated Marketing?

Is it too much to ask that we can create whatever the hell we dream up, so we can push the industry forward? To deliver the experience we think could make a difference to our prospects—one they might even enjoy?

Not if we need to rely on devs to help build our lead management or the integrations component of our campaigns for us, unfortunately.

However, I’ve found that more and more often I don’t need to have these futile conversations with developers. Modern martech has brought us tools to help, and the tool that comes up most often for me is Zapier.

Your Marketing on Zapier

Have you ever punched above your weight at work and solved a problem that that you’re totally unqualified to solve? It. feels. so. satisfying. You feel way smarter than you actually are.

I got that feeling when I used Zapier with Unbounce for the first time. I still get that feeling today. If you dream big enough, and can connect the right tools together, you can pull off campaign workflows that feel almost impossible.

Exactly how I felt having used Zapier for the first time.

Most recently, I tried to execute the campaign in the whiteboard photo above (the one above the Dragonball Z meme). The campaign—called Conversion Quest—challenges PPC marketers working in agencies to double the conversion rate of one of their client’s landing pages in 30 days.

When planning this campaign, I wanted to have a prospect fill out the form on a landing page with the current date (when they were “starting their quest”), and their current conversion rate. From there, they’d receive an email confirming their personalized quest goal and deadline by which they’d ideally complete the challenge (The email was to automatically pull in someone’s target conversion rate and their custom due date a month out).

Of course, when I’d planned this flow, there was no technical way to magically include a doubled conversion rate and custom due date directly in each prospect’s followup message. That is until my colleague reminded me of Zapier Formatter, which allows you to manipulate your lead data before it goes into your marketing automation platform (or CRM, or Email Marketing Service, or wherever other tool you can think of). Just 30 minutes later (and without approaching our dev team), I had augmented data going into our marketing automation platform.

Now Conversion Quest runs with custom info in the followup, all thanks to a quick Zap (a preconfigured integration template connecting two or more apps).

Here’s an example of the message I send in that campaign:

Here’s a sample of the email I manipulated data with via Zapier to personalize.

Now, are you going to need to use Zapier so you can build Conversion Quest?

No (that’s my great idea)… But my bet is you’ve got amazing campaign ideas for which Zaps could help you create a consistent (better!) experience for your leads, and help you stop relying on developers. As a bonus, Unbounce now has Integrations Powered by Zapier available right in the builder, so you can do this super quickly, without ever leaving Unbounce.

Here’s just a sampling of the Zaps available right in Unbounce. There are 60+ right in app, and with a Premium Zapier account you can access over 900!

Let’s dig into the versatility for a second.

Leveling up your marketing (without a line of code)

You could use Unbounce’s Integrations Powered by Zapier if…

1. You need to connect a client’s hodgepodge of tools

In this case, you’re a marketing agency that needs to build high-converting lead gen landing pages, overlays or sticky bars that connect to anything and everything your clients use, which could include:

  • Hatchbuck
  • Base
  • Follow Up Boss
  • Agile CRM
  • Pipedrive
  • Salesforce
  • HubSpot CRM
  • Capsule CRM
  • PipelineDeals

A few quick Zaps can connect your lead data to all of the above.

2. You want to use an existing CRM or marketing automation platform, with custom landing pages/Unbounce

If you’re using a tool that requires you to use rigid forms or landing pages, but you’d rather have custom landing pages that look great, convert like crazy and give you more control over the experience, you’d simply Zap together your landing page builder with tools/platforms like:

  • GoToWebinar
  • Marketo
  • Salesforce
  • Pardot
  • MailChimp
3. Your CMS or Marketing Automation tool doesn’t enrich your data for you

With Integrations Powered by Zapier, if you collect a lead in Unbounce, Zapier can enrich the lead’s profile with extra data (using, for example, the lead scoring Zap) en route to wherever you’re storing your leads.

4. Your sales team would like to be notified immediately when a super qualified lead comes in…but they never check their email

For this, you can try sending notifications via the following Zaps:

  • SMS integration
  • Slack
  • Twitter
  • LinkedIn
5. You’d like to route leads to specific salespeople in your CRM depending on the info a prospect submits in a form

Joe Savich from Altos gave this a try in Unbounce, and had high praise for this email parser Zap:

“It’s pretty nice. The integration powered by Zapier was super easy to setup…I was able to create a lead notification with a condition that, depending on which custom field was chosen, would send that lead to the appropriate sales team. My client thinks I am a magician! I could see this being used a lot going forward.”

Overall, of all the feature releases in my 4 ½ years at Unbounce, Integrations Powered by Zapier is my all time favourite. Zaps from right inside our builder empower marketers to do things you shouldn’t be able to do, without developers. And they make you feel really smart.

If you’re committed to driving our industry forward with some next-level marketing (that may look impossible at first glance), I’d urge you to try zapping some connections together and getting creative. You might surprise yourself, or better yet your boss or clients.

Continue reading: 

Don’t Settle. Build the Marketing Campaigns of Your Dreams Without a Line of Code

5 Real-Life Popup A/B Tests That Will Help Boost Your Conversion Rate (Based on Actual Case Studies)

5 tests

Do you think your popups are converting at their highest potential? I’m guessing that unless you’ve been testing them to figure out what makes your audience tick, then probably not. Luckily, you can figure that out by, well,..testing of course :). And if you’re wondering what to assess first, I have some suggestions. As Head of Customer Success at WisePops, an intelligent popup builder, I’ve reviewed hundreds of A/B tests. Based on this experience, I’ll share 5 popup A/B tests which can make a difference for your future and existing campaigns (spoiler: one of our customers almost tripled the number…

The post 5 Real-Life Popup A/B Tests That Will Help Boost Your Conversion Rate (Based on Actual Case Studies) appeared first on The Daily Egg.

More:

5 Real-Life Popup A/B Tests That Will Help Boost Your Conversion Rate (Based on Actual Case Studies)