How do you design good onboarding?

In short

Alita Kendrick of NN/g defines onboarding as flows that sit alongside the app’s normal interface and get the user used to the app. That includes setup and instructions. Existing users can see onboarding too, when a new feature appears.

Kendrick’s recommendation may come as a surprise: where possible, skip onboarding. Onboarding costs attention and effort, and memory is limited. In my view, that effort should go into a simpler interface first.

What I see most often in audits: instead of improving a confusing screen, the team puts an intro tour in front of it. The tour ends; the screen stays the same. According to Kendrick, instructions shouldn’t be used to patch bad design.

When to use it

According to Kendrick, most mobile apps don’t need onboarding, because users learn the app by using it. She names situations where onboarding can help:

• The app needs information to start. Opening an account or verifying your identity in a banking app are examples.
• The product depends on the user’s situation. A diet app asks for your current weight before you start.
• The main feature is new or unfamiliar. Kendrick’s example is mobile check deposit. When it was new, it was an alternative to depositing at an ATM.

In these cases, pause before adding onboarding:

• You haven’t tested the screen with users yet. Kendrick wants you to test the app without onboarding first. Add the flow only when the test shows a real problem. How I set up the test is in the usability testing guide.
• You want to explain an element everyone knows. Page Laubheimer of NN/g advises against explaining the obvious, such as the gear icon for settings.
• The real goal is to market new features. Kendrick recommends leaving feature promotion out of the first launch. In her view, such promotional screens belong on the app store page. In the app, show the feature at the moment it is useful.

Types of onboarding

Laubheimer splits help into two kinds. “Push” help comes at app launch or at any moment, detached from context. “Pull” help appears when the app recognises the moment the user needs it. The types below sit between these two poles.

Intro tour

These are cards that appear one after another at first launch. NN/g calls this form a “deck-of-cards” tutorial. Each card explains a feature, and at the end the user goes into the app.

In Kendrick’s NN/g study, one group of participants read these tours and the other skipped them. Those who had read the tour weren’t more successful at the tasks. That group even found the tasks harder.

Laubheimer explains this with the “paradox of the active user”: users want to get started right away and skip the tour. And information without context isn’t remembered when it is needed.

Sometimes a tour still fits. In Laubheimer’s research, intro flows helped introduce a novel interaction paradigm such as augmented reality. Showing an unfamiliar interaction up front makes sense to me there.

Learn while using

A tip appears as soon as the user reaches a feature, right next to that feature. Laubheimer calls this contextual help. Tooltips that appear on hover and so-called coach marks belong to this group.

Aurora Harley of NN/g sets clear rules for coach marks. Each tip should explain a single interaction, and the tips should come one at a time when they are useful. Avoid chains of tips that open one after another.

Harley also warns: users can mistake a tip for a clickable part of the interface. That is why the tip has to stand apart visually from the app’s elements.

Start with an empty state

In a new account, the list, dashboard or favourites are empty. Kate Kaplan of NN/g wants this area not to stay completely empty. A totally blank screen makes users wonder whether the system works at all.

According to Kaplan, a good empty state first says how the system stands. Then it explains what goes in this area and links directly to the task that fills it.

Kaplan writes that this approach usually works better than tours forced at first launch. The empty state helps when the user reaches that area. So it is pull help.

Dos and don’ts

Most of the points below come from NN/g’s articles on onboarding, coach marks and empty states. Some come from mistakes I see again and again in audits.

Live example: one app, three onboardings

Imagine a made-up expense app called Piggy Bank. Below, the same app starts with three different onboardings. Choose a type and try the flow with Next and Skip.

After all three runs, ask yourself: with which type do you remember where to set the budget limit? In the intro tour, the information came before you had even seen the app. With the empty state, it was right in that area.

Notice in the demo too that Skip does something different in each type. In the tour, the skipped information doesn’t come back. With the tip, the help link stays. With the empty state, there is nothing to skip.

The difference between mobile and desktop

On a phone the screen is small and attention is often interrupted. According to Harley, mobile users are short on time. That makes them even less willing to read instructions than web users.

So on phones I keep it short. A tip is one sentence and doesn’t cover the element it points to. For the rest of the screen, read the mobile app design guide.

On desktop the screen is wide and applications are often more complex. Kaplan’s article on empty states is also about complex applications. The dashboard, notifications and favourites are empty on day one, and each area can guide with its own empty state.

Laubheimer shows two examples from desktop design tools. In one, a tip appears only when it relates to the user’s current task. In the other, details open only when the user asks for them. Laubheimer calls this progressive disclosure.

Because desktop has a mouse, it is tempting to show tips on hover. For me that is never the only way. There is no hover on touchscreens or with the keyboard.

A note on accessibility

Onboarding often opens as an overlay or dialog. In accessibility reviews, the problems I see with these overlays are mainly about focus and announcements. I look at these WCAG 2.2 criteria first.

• 2.4.3 Focus Order (level A). According to the W3C, when a modal dialog is open, focus stays in the dialog and content outside it doesn’t receive focus. When the dialog closes, focus returns to the element that opened it, or to the one directly after.
• 2.2.2 Pause, Stop, Hide (level A). Motion that starts by itself, lasts longer than five seconds and appears alongside other content must be pausable by the user. If tour cards advance by themselves and these conditions apply, they fail the criterion.
• 4.1.3 Status Messages (level AA). Messages such as “Step 2 / 3” or “Tips closed” must reach the screen reader without the focus being moved.

That is why the step information in the demo is announced in an aria-live region. After Skip, focus isn’t lost but jumps to the Start over button. The buttons for choosing the type report their state with aria-pressed.

All the criteria are in the WCAG guide. How I review a flow step by step is described in the accessibility audit guide.

A note on implementation

Below is plain HTML for an empty state and a tip connected to its field. Underneath is a small script that opens the tour once and brings it back from the settings.

<!-- Empty state: a real heading and a link to the task that fills the area. -->
<section class="empty-state" aria-labelledby="empty-title">
  <h2 id="empty-title">No expenses yet</h2>
  <p>Add your first expense and this month's total will appear here.</p>
  <a class="btn btn--primary" href="/expenses/new">Add your first expense</a>
</section>

<!-- Tip: next to the field, connected to the field. -->
<label for="category">Category</label>
<select id="category" aria-describedby="tip-category">...</select>
<p id="tip-category" class="tip">You can change the category later too.</p>

<script>
  // The tour opens once by itself and can be reopened from settings at any time.
  if (!user.tourSeen) openTour();
  settings.querySelector('#show-tour').addEventListener('click', openTour);
</script>

The empty state’s heading is a real heading element, and the button a real link. That way screen reader users find the empty state too when they navigate by headings.

The tip is connected to the field with aria-describedby. When the user reaches the field, the screen reader reads the tip along with it. A separate dialog for the visual tip isn’t needed.

I put the “Show tour again” option in an easy-to-find place, in the settings or the help menu. Laubheimer tells how, in a bike app, he found no way to reopen the tour after it ended. That is why it matters that closed help can come back.

I prefer to store whether the tour has been seen in the user’s account. Information stored in the browser shows the same person the tour again on another device. If you want me to build the flow from design to code, that falls under the Design & Ship Sprint.

Checklist

Before an onboarding flow goes live, I go through this list. If you want me to review your app’s first launch: the UX audit covers these points.

• I tested the app without onboarding first.
• I can say in one sentence why each step is there.
• At first launch, only what is needed to get started is asked for.
• Every step that asks for data gives the reason.
• Skip is visible and works at every step.
• A closed tour or tip can be opened again.
• Tips appear one at a time and next to the element in question.
• A tip doesn’t look like a clickable part of the interface.
• Every empty screen says what it is and what the first step is.
• No card advances by itself.
• When a dialog opens, focus moves into it and returns when it closes.
• When the step changes, the screen reader hears it.

My note

I look at onboarding at the end of the design work, not at the start. First I test the screens without a flow. Where the user gets stuck, I improve that first.

If a spot remains that I can’t improve, I put a tip or an empty state there. I usually use a full-screen flow only for required steps such as opening an account.

Think of a banking app. Asking for identity verification at first launch is one of the legitimate cases Kendrick names. But if promotional cards go into the same flow, the user reaches their real task later. I separate those cards and move them into the empty state of the matching screen or into a tip.

When the screen matches the mental model in the user’s head, there is little to explain. If you keep having to make the onboarding longer, the interface doesn’t explain itself. You can see that quickly with a heuristic evaluation.