User Onboarding Checklist – Designing the New User Experience (NUX)

Author: Dan Zambonini

 

In this post we’ll take a look at the design decisions behind the Bipsync new user experience, along with a summary checklist that you can use to plan your own onboarding process.

What is New User Experience (NUX)?

I use the terms User Onboarding and New User Experience interchangeably to describe the same concept: the flows, words, interactions and design elements that are developed to help new users:

• Activate – Go through the steps to get started, e.g. register, install, import.
• Educate – Learn how to use the app features.
• Convert – Engage and convert into a regular or paying customer.

That last point — the NUX should result in a converted user — is the ultimate goal and the quantifiable measure of the onboarding process.

NUX design is not a single task or set of instructions. It is best approached holistically, taking into account every interaction you have with the user, and how your product’s relationship with them changes over time.

What are your magic moments?

If we work backwards from the goal of onboarding — to convert a new user into a long-term customer — we need to get a better understanding of what causes that to happen. Usually it’s when a person extracts significant-enough value from the product; they experience the benefits it provides that outweigh the time, hassle and cost to use it.

Startups that build Minimum Viable Products have known this for years. You can get away with a clunky, basic experience as long as the core value of the product is accessible and provides people with a net gain in their work or life.

The parts of your app that deliver these value-demonstrating “magic moments” are critical parts of your onboarding plan, but they can be tricky to identify. Smaller consumer apps may only perform a single task with an obvious benefit, but larger enterprise software can offer a broad spectrum of feature and benefits, which must be distilled to one or two eureka moments to plan a focused new user experience.

If you try to guess what the magic moments are, you may get them wrong. That’s what happened to us when we started to plan the Bipsync NUX. We spent a long time talking to our existing beta users before we realized that the magic moments we had guessed were actually in a secondary or tertiary phase of product usage that only applied to longer-term users. We needed to find out what the original mental-click was that made people commit to using the product.

Luckily, after sitting through multiple demonstrations to potential customers and in-person testing with new users, we found common product moments where their eyes would light up and they would become animated and enthusiastic.

What do your magic moments depend on?

Once you’ve identified your magic moments, you need to take another step backwards and work out what the exact tasks and features are that will lead a new user to experience those moments.

In our case, the two magic moments were:

• Using the audience-specific tagging system that kept itself automatically organized.
• Using the collaboration features — sharing, locking, and subscriptions — that made the team knowledge base a living, useful resource.

Those moments relied on a few specific tasks: creating and tagging a note, setting up a team, sharing notes, and subscribing to relevant tags.

Armed with your list of magic moments and the product tasks required to experience them, it’s time to start implementing your NUX.

Pre-app NUX

First contact

A person will start to form expectations about your product from the first time they read or hear about you, and those expectations will depend on the language you’ve used. If you’re a “team communication app”, that implies a slightly different set of features and benefits from a “messaging app”, even though both descriptions could equally apply to the same product.

Of course, it’s important that your marketing communications are clear about what your product is and who it’s targeted at, but you should also try to craft the language to start guiding readers towards your magic moments. You want them to proactively explore the features you’ve set expectations about after they sign up, so that they reach those critical conversion moments faster.

There are many external places that first contact with people can occur. Try to optimize as many as possible for your magic moments and the features that those moments depend on — in press releases, search ads, your social media posts, and your website page <title>s — i.e. the text that appears in external search results.

Website and sign up

Your website is your biggest opportunity to set expectations about your product, and likely the “closest” in terms of time between reading and using, so don’t waste it. Massage those headlines and paragraphs, and choose your images carefully to subtly remind people what they should be doing after they sign up.

The sign-up flow is also in-play. For example, in the Bipsync sign up form, we display “Why?” tooltip links next to the fields that explain why we’re asking for each piece of information. We don’t ask for any unusual information, so these tooltips weren’t really necessary. They were included purely to remind the user about the collaboration features that we want them to look for.

You may also want to use other parts of your sign-up flow to onboard the user, so long as it doesn’t distract from the core flow of the sign up process or become annoying.

For example, you’ll sometimes have a roadblock page in the flow that thanks people for signing up and asks them to check for a verification email before they can continue. There’s no further action to take on this page, so you could use the opportunity to quietly point out that you have a mobile app that they could download while they wait for the email, or some other task that helps to activate their account. Similarly, mobile app loading screens and even log in pages can present minor opportunities for short bursts of user education.

I’m not yet convinced about the effectiveness of these intermediary onboarding opportunities, but it might be something you want to test. My current opinion is that I want to get people to the magic moments as quickly as possible, and any minor “optimizations” that may annoy or distract them in that critical sign up and sign in flow should be eliminated — especially as the user has no reason to trust you yet.

In fact, the quicker that you can get through the sign up process the better. We’re hoping to change to a lazy registration process soon — one where the user doesn’t need to verify an email address to access the system for the first time.

If you can’t remove or delay signup there may be other ways you can reduce the amount of information you need to ask for, or automate their profile setup, for example using browser information like timezone and location, a service like Gravatar, or social logins provided by the likes of Facebook, Twitter and LinkedIn.

In-app NUX

Core User Experience

Much like Adam Sandler movies, the best kind of onboarding is no onboarding at all.

To minimize the amount of user education needed and reduce the friction to reach the magic moments, make the default app experience as intuitive as possible. Consider every detail of your interface, including the language and nomenclature you’re using. Is it clear, relevant to the target audience, and consistent throughout the app?

The absolute best way to improve your base usability level is to user test — to watch new users as they attempt to navigate your interface and complete tasks. Test, test, and then test again. Stop reading this now and find someone to use your product as you watch. It’s like having bad sex — incredibly disappointing, but you’ll still be glad you did it.

Once you’re happy with the usability, create the default states for new users. How does the product look and feel when a new user logs in? What default content do they have? What’s the default profile photo? Are there any tags, notifications or projects waiting for them to demonstrate how they work? You can even use the default content as a mini tutorial, to explain itself.

After you’ve defined your default states, delete all the content. Everything. Wipe every bit of user generated data from your app, so that you can work on the empty states — how the app components look and behave when they’re empty. Remove dead ends where possible — don’t just tell someone that a list is empty, but tell them how to add an item, or even let them click the empty area to add the first item. If some buttons/features don’t work when a component is empty because they depend on content, disable them.

First Use NUX

Next, it’s time to design a flow of educational content designed specifically for when new users access the app for the first time. Popular approaches include:

• A self-contained set of images and text that acts like a separate instruction booklet for how to use the app, often displayed in a paginated modal over the app interface. This can include screenshots, illustrations, animations, and other creative elements, but is rarely interactive other than stepping through the pages.
• A single, static, illustrated overlay that points to important parts of the interface with small descriptions about functionality. This sometimes has a hand-drawn aesthetic on a greyed-out overlay to help exaggerate the contrast between the interface and the instructions.
• A setup wizard that activates the user by importing content, setting up the user profile, and performing other tasks that help to personalize the first use, to demonstrate how content that the user recognizes fits into the new experience.
• An integrated, contextual tour that guides the user step-by-step through the interface components, teaching them how to use features by using them.

Each method has advantages and disadvantages, not least in development time to implement. We chose the fourth option — the contextualized tour — as our app interface has many components, and we felt that the guided tour helped the user to recognize and understand the core features faster.

When we tried to squeeze in all of the tasks we needed to reach the magic moments, we found that the initial tour was far too long. New users will lose interest and won’t remember what they’ve learned if you ask them to sit through five minutes or more of a guided exercise.

Instead, we decided to split the first-use tour into two smaller tours. The first, that launches automatically after you sign in for the first time, is a simple guide to creating, organizing and browsing notes. We then wait a few minutes to give the user time to finish the tour and experiment with the interface, to reinforce the learning from the first tour. Then, we add an in-app notification to non-invasively tell them that a second tour is available. Clicking the notification launches the second tour, that guides the user through team setup and the collaboration features. BOOM*. Hello, magic moments. (*FYI, that was an ironic BOOM. I’m British, I don’t BOOM.)

Talking of BOOM, you need to decide what tone to take in your new user experience; where you’ll sit on the line between silliness and stuffiness. We try to keep our app and marketing language simple, neutral and professional. However, we decided that the tour needed to be a little less formal to help the user through a potentially confusing and overwhelming experience. The tour is the only place you’ll see us use an exclamation mark in the app, along with other informal elements like an animated thumbs-up icon and slightly exaggerated language.

There are other ways to motivate users and retain interest throughout onboarding, such as profile progress meters with scores to improve for people who are competitive. These gamification-like elements didn’t sit well with our application, so we decided against them.

Onboarding tours shouldn’t necessarily follow the same path for every user. Your app might offer different plans with variations in features, multiple user roles, or different routes into the system — for example, registered on the website versus invited to a team. Each of these users might have different expectations or magic moments that you want to guide them through, so building a tour that can be personalized for different use cases in sensible if you can. Our tours are defined in flexible configuration files, which give us the option to add or remove steps depending on the user’s context.

It’s also important that you user test your onboarding tour, like you did your app interface. The graphical design of our tour changed dramatically after a number of insightful user tests. For example, after spending days planning and designing the first tour, we sat a user down to test it. She signed up, logged in, and immediately closed the very first step of the tour without reading it.

It turns out that we had designed a first step modal that looked so much like a warning / pop-up that users regularly see, that the natural reaction was to quickly click the big close button in the top right of the modal. This was absolutely invaluable feedback from a few seconds of user testing.

Responsive / Continued Onboarding

After the initial introduction, there are many ways you can continue the onboarding process that are responsive to the users progress and needs. Some of the tactics we use include:

• Progress-based inline cues. We display contextual tips inside features depending on how often people have used the feature or more generally how many times they’ve used the app. We have a configurable system for displaying these tips to users. For example, we might display a simple instruction inside a menu until they’ve used it three times, or in another section we might wait until the user has used the system 10 times and then show them a power-user tip inside an advanced feature.

• Progress-based highlighting. Similarly to tips, we can use a combination of feature usage data along with overall system experience to visually highlight a useful but unused feature after a person has been using the system for a while.

• Progress-based personalized email. Unlike many apps, we don’t send a welcome email immediately after the user registers. Instead, we let them use and explore the system features. The next day, we send a personalized welcome email that highlights useful features that they haven’t discovered yet, based on their usage data. We feel this is more likely to invite people back than a generic email with the same old top-level features listed that they already know about.

• Optional advanced tours. As we now have a framework that allows us to easily build product tours, we intend to create a series of optional tours that can be accessed from inside the app that introduce advanced feature sets. It’s a shame to only use tours for the benefit of new users to get them to conversion moments. We want to present additional user education opportunities for our regular users too.

With all of these options available for onboarding users, it’s also important not to patronize or irritate people with constant unwanted offers for help. If possible, include options to unsubscribe from future emails and toggle onboarding features off in the interface.

Summary / User onboarding checklist

• Discover and define your magic moments — the in-app experiences most likely to convert users.
• Define the list of the features and tasks required to reach the magic moments.
• Set “First Contact” expectations for magic moments: in ads, social media, etc.
• Set expectations for magic moments on your website, reinforce during sign-up.
• Consider interstitial education opportunities: mobile app loading screen, log in UI.
• Automate user signup where sensible, e.g. use browser geolocation, social login.
• User test and improve app usability to reduce onboarding required.
• Set default states for new users: default content, profile photo, tags, etc.
• Optimize empty states. Remove dead ends, disable features that aren’t accessible.
• Design and implement a first use tour of in-app tasks required for magic moments. Consider language, motivation techniques, and best pattern for your app, e.g. instruction booklet, illustrated overlay, setup wizard, contextual tour.
• Personalize the tour depending on the user context: payment plan, role, etc.
• User test the first use tour.
• Create ongoing N-th use tours.
• Create inline cues that are driven by minimum or maximum app and feature usage.
• Create user lifecycle emails, potentially personalized and driven by feature usage.
• Offer methods for a user to opt-out of future onboarding messages.