Do onboarding tours and coach marks actually work? What the evidence says, and what to do instead

Mostly, no. Feature tours and coach-mark walkthroughs get dismissed within seconds, and when researchers have measured them, people who sat through a tutorial did no better at the explained tasks than people who skipped it.

What works is smaller and later: teach only what users could not guess, show it next to the thing it explains when they need it, and never block the screen. Permission prompts follow the same rule. Ask when the feature needs it, not on launch.

What the research says

Nielsen Norman Group tested deck-of-cards tutorials (the swipe-through screens many apps show on first launch) with 70 iOS users across four apps. Task success was essentially the same whether people read the tutorial or skipped it, and completion times were similar. The uncomfortable part: people who read the tutorial rated the tasks as harder. Explaining a simple app makes it look complicated.

NN/g's follow-up on tutorials versus contextual help sums up the problem with upfront tours: they interrupt people who are trying to do something else, they aren't memorable, and they don't improve task performance. Their recommendation is "pull" help that appears when the user's behaviour signals a need, rather than "push" help that fires on a schedule.

None of this is new. It's the paradox of the active user, described by John Carroll and Mary Beth Rosson at IBM in the 1980s: people dive straight into their task, even when a bit of upfront learning would save them time. You design for that, not against it.

Apple's own onboarding guidelines land in the same place. They say people "grasp and retain information better when they can actually perform the task", suggest context-specific tips instead of a single onboarding flow, and ask that any separate tutorial be optional, not shown again once skipped, and easy to find later in help or settings.

What practitioners are seeing

The Reddit threads on this read like a support group. A recent r/UI_Design post about Revolut's auto-playing feature tour drew dozens of replies, and nearly all of them said the same thing: they start tapping around trying to make it stop. The sharpest criticism was about content, not animation: the tour tells you the Add money button adds money, while a term some users genuinely didn't know (UPI) got a caption that explained nothing. Some said they'd close the app rather than wait.

In a thread titled Enough with the tooltips, designers describe product partners pushing auto-open walkthroughs on project after project. One says they tested one to settle the argument: by their recollection around 85% closed it immediately, and only a small share of those who stayed finished every step. One team's anecdote, not a study, but it fits the NN/g findings. The same thread draws a useful line: coach marks that pop up unasked are the problem; an on-demand tooltip that defines an unfamiliar term is fine.

Why feature tours fail

Three reasons, and most bad tours have all of them.

They restate what's already on screen. If the button says "Send", a coach mark saying "Tap here to send" is noise. Worse, it teaches people that your overlays are skippable, so they skip the one that mattered.

They block the UI. A dimmed screen with a spotlight stops people doing the thing they opened the app for, so they tap wildly to escape before reading step one.

They teach before there's a task. Six steps on first launch means six things to remember for a moment that hasn't happened yet. By the time the user needs step four, it's gone.

A tour is also often a patch for a confusing screen. As NN/g's mobile onboarding analysis puts it, instructional onboarding should not be used to supplement poor design.

When a tutorial is worth it

Tours earn their place when you're teaching something a reasonable person could not work out from the screen:

• Gestures with no visible cue. Swipe to archive, long-press for more actions, pull to refresh in an unusual place.
• Capabilities nobody would guess. One developer in the Revolut thread defended a single screen that tells people they can log an expense by speaking it aloud. Nobody discovers that by looking at a button.
• New mental models. A product built around a concept users haven't met before (say, splitting a budget into envelopes) may need a sentence or two up front.
• Setup that has to happen first. Linking a bank account, choosing a language, picking a region. NN/g lists required user information and heavily personalised functionality as the legitimate reasons for onboarding.

Even then: short, skippable, and doing over reading.

Better patterns than a tour

A learn-by-doing first run. Instead of describing the core action, let people do it with light guidance. A founder on r/UI_Design replaced three preference screens (pick topics, pick a style, turn on notifications) with a flow where new users react to a few real posts, then inferred their interests from that. Commenters pushed back on one detail worth copying: if you infer choices, make them visible and easy to undo. Apple's guidance says the same thing from the other side: postpone nonessential setup and ship reasonable defaults.

Empty states that teach. An empty inbox or project list appears exactly when the user needs to know what goes there, and one clear action ("Create your first invoice") beats any carousel.

Just-in-time hints. One short message, anchored to the control, shown the first time it becomes relevant, dismissed with one tap and never shown again. If you're using tooltips for this, the timing and touch rules in our guides on tooltip delay and tooltips on mobile apply.

Progressive disclosure. Show the basic version first and reveal advanced options as people reach for them, so there's less to explain at once (more on this in minimizing cognitive load).

On-demand help. A "What's this?" link or a searchable help centre. Help the user pulls in is help they read.

Hidden gestures: visible path first, hint second

A long r/UXDesign thread on hidden gestures (a long-press on a photo that reveals download and like actions) reached a fairly clear consensus. A gesture is fine as a shortcut, as long as the same action is available somewhere visible, the way a right-click menu on desktop duplicates things you can do elsewhere. If the gesture is the only way to reach an action, you need to teach it, and a first-use hint is the least annoying way. Several people pointed out that older users rarely think to long-press at all.

So the rule is: put the action in a visible place (an overflow menu, a detail screen), then add the gesture as a speed-up, then hint at it once, in context. For more on this on touch devices, see alternatives to hover interaction on touchscreens.

Permission requests: ask in context, after value

Permission prompts are onboarding's other bad habit, and every platform owner says not to stack them on launch. Apple's privacy guidelines say to avoid requesting permission at launch unless the app can't function without it, and ideally to wait until people use the feature that needs access. Apple's developer docs for notifications give a concrete example: a task app should ask after the person schedules their first task, not on first launch. They also note the system only shows the prompt once; later requests don't prompt the person again. Android's notification permission guidance suggests letting users get familiar with the app first and asking when they tap an alert bell, follow an account or place an order.

On the web, web.dev calls showing the permission dialog on landing "the worst thing you can do" and recommends a "double permission" pattern: your own in-page prompt first, the browser prompt only if the user says yes, so a reflexive "Block" doesn't lock you out.

The r/UXDesign discussion on asking for notifications during onboarding says the same in fewer words: give value before you ask for something, tell people why they'd want the notifications, and don't offer only "Later" as the escape hatch. One commenter called a Later-only prompt a dark pattern and said they uninstall on sight. Another made the practical point: people deny on impulse, and then it's harder to switch on when they actually want it.

Two details that trip teams up:

• Explain the benefit, not the feature. NN/g's permission request article recommends priming screens that describe what the user gets, in plain language, and clear recovery steps (with a link to settings) when someone has said no.
• If you show a custom screen before an iOS system alert, follow Apple's rules for it. For protected resources like camera, location and contacts, Apple says that screen should have a single button labelled something like "Continue" or "Next" that opens the system alert, with no separate cancel option and no button titled "Allow" that could be confused with the real one.

On iOS, provisional authorization lets you deliver notifications quietly to Notification Centre so people decide after seeing what you send.

How to tell if your onboarding is working

Tour completion is a vanity metric. Measure what the onboarding was supposed to cause:

• Activation: the share of new users who complete the core action (first invoice sent, first expense logged) within their first session or week.
• Task success on the features the tour covers, compared between people who saw it and people who didn't. An A/B test is ideal.
• Permission grant rate by prompt placement, and the share of denied users who later enable it.
• Funnel drop-off per onboarding step. A founder in this r/userexperience thread described using product analytics to see exactly which step people bail on, which is the fastest way to win an argument about a five-screen welcome flow.

If you want a second pair of eyes on a first-run flow, our free UX audit will flag blocking overlays and launch-time prompts along with everything else.

Tour or no tour: a checklist

1. Could a clearer label, a visible control or a better default remove the need to explain it?
2. Would a typical user work it out from the screen? If yes, cut the step.
3. Is it needed before the user can do anything? If not, turn it into a one-time hint shown when it becomes relevant.
4. Can users learn it by doing the real action? Prefer that to reading.
5. Does it block the interface? It shouldn't.
6. Can it be skipped, and found again later in help or settings?
7. Are permission prompts tied to the feature that needs them, with the benefit explained first?
8. Are you measuring activation and task success, not tour completion?

Most tours won't survive question two. That's the point.