Onboarding flows people actually finish: what to cut and what to keep

The cheapest onboarding test I know needs no tooling. Hand your phone to someone who has never seen the app, say nothing, and watch their thumb. On most first-run flows it drifts toward the top right corner within a few seconds, looking for the word Skip. That small movement tells you more than a dashboard: the person came to do something, and you are standing in the doorway talking.

I spent years designing first-run experiences before I started writing about them full time, and the flows that failed rarely failed because of bad illustration or clumsy copy. They failed for three structural reasons, almost always the same three. The good news is that the fixes are known patterns, cheap to try, and easy to measure if you count the right things.

Why people leave before they start

Too many screens before anything happens

The classic welcome carousel has four or five slides: a promise, three features, a call to action. People swipe through it at the speed of their thumb and remember none of it, because nothing on those slides is theirs yet. Each extra screen is one more point where someone can close the app and not come back. Apple's Human Interface Guidelines on onboarding ask for a brief experience that doesn't make people memorize or provide a lot of information, and they suggest deferring further questions until a situation actually requires them. That advice is old, and most of the flows I review still ignore it.

Permission prompts at launch

A system permission alert is a one-shot request on iOS. If the person taps Don't Allow, your app cannot show that alert again; the only way back is a trip into Settings that very few people make. Android is a little more forgiving but not much. Since Android 11, if someone denies the same permission more than once, the system treats it as a permanent denial and stops showing the dialog. Android 13 added a runtime permission for notifications, so the notification prompt is now also something you can waste. Asking for location, contacts and notifications in the first ten seconds spends your only good chance at a moment when the person has no idea why you need any of it.

Sign-up before value

A login wall before the first useful screen asks for trust the app has not earned. People who arrived from an ad or a store search are curious, not committed. Apple's App Review Guidelines say that if your app doesn't include significant account-based features, you should let people use it without a login. They also require in-app account deletion for any app that offers account creation, which is worth knowing before you make an account mandatory for everyone.

Four patterns that keep people

Progressive onboarding

Instead of front-loading every lesson, teach each thing at the moment someone needs it. The first time a person reaches the filter bar, a short tip next to the filter icon explains it. The first time they long-press a card, the menu itself does the teaching. One tip at a time, placed near the control it describes, dismissed for good once read. Apple's guidelines describe the same idea as an alternative to a separate flow: a short description the first time someone uses a feature, plus a visual cue toward the next step. It matches what I have seen in usability sessions too. People remember what they just did, not what they were told.

Empty states that teach

The empty screen a new user lands on is the most underused space in most apps. An empty expense list that says "No expenses yet" wastes it. One that says "Add the last thing you paid for" with the amount field already focused turns the first visit into the first entry. A good empty state does three things: says what will live here, offers one action that creates it, and shows a hint of what the screen looks like once it's full. Some apps add a sample item the person can edit or delete. That works well for project and note apps, less well for anything financial, where fake data makes people nervous.

Deferred account creation

Let people do the core task first, locally, and ask for an account when it protects something they already care about. "Create an account to keep this list on your other devices" is an easy yes after someone has built the list. The same request on the first screen is a hard maybe. This pattern has an engineering cost that designers should raise early: local data has to merge into the new account without loss, and someone has to decide what happens if the person signs in to an existing account that already has data. Settle that in the first sprint, not the last.

Permission priming

Priming means showing your own short explanation right before the system alert, at the moment the person reaches the feature that needs it. Tap "Find stores near me", see one sentence about why the app needs location, then see the system alert. Apple's guidelines are specific about this screen: one button only, labeled something like "Continue" or "Next" rather than "Allow", and no cancel or close option that skips the alert. Android's own guidance describes a similar educational screen, shown when shouldShowRequestPermissionRationale() returns true, which is the platform telling you the person declined once and might need a reason.

Priming is not a trick for raising opt-in rates. If you cannot write an honest one-sentence reason, the screen exposes that, which is useful information in itself.

Some requests can disappear entirely. Both platforms offer a system photo picker that hands your app only the photos the person selects, with no library permission at all. On iOS, provisional notification authorization lets you deliver notifications quietly to Notification Center, where the person decides to keep them or turn them off after seeing a real one.

Audit your own flow in an afternoon

You can run this on your own app with a test device, a notebook and two hours.

1. Delete the app (or start a fresh simulator), turn on screen recording, and install the current release build. Debug builds often skip steps that real users see.
2. Count every screen and every tap from the launch screen to the first useful result. Write both numbers at the top of the page. "Useful" means the person has done the thing the app exists for: a logged run, a saved recipe, a first transfer.
3. Label each screen with one word: teaches, asks or does. Most flows have far more of the first two than the third.
4. For every "asks" screen, name the feature that needs the answer. Move the question to that feature. If no feature needs it yet, delete the question.
5. For every "teaches" screen, check whether an empty state or a one-time tip near the relevant control could carry the same message.
6. Say no to everything: deny each permission, skip sign-up, dismiss every sheet. Does the app still work? Apple's guidelines ask for alternatives where possible, such as typing an address when someone declines location.
7. Force-quit the app halfway through onboarding and reopen it. A flow that restarts from the first slide punishes people for being interrupted by a phone call.
8. Finally, give the phone to someone new, stay quiet, and note every hesitation longer than a couple of seconds.

The output of this audit is a short list: screens to delete, questions to move, and lessons to turn into empty states or tips. In my experience it fits on one page, and the first two lists are always the longest.

What to measure

Overall onboarding completion is a weak number on its own, because it hides where people leave. Track completion per step instead: log an event when each onboarding screen appears and when it's completed, with the step's position and name. The biggest drop between two adjacent steps is where your next design hour should go.

Three more numbers are worth having:

• Time to first value: the minutes (or taps) between first launch and the first meaningful action. Pick one action that defines it and keep the definition stable.
• Grant rate per permission, by where it was asked: if you move the location request from launch to the store finder, compare the two placements directly.
• Account creation after value versus before: if you defer sign-up, count how many people create an account once they have something worth saving.

Keep these events free of personal data; step names and counts are enough. And be patient with small numbers. An app with a few hundred installs a week needs a while before a difference of a few percentage points means anything, so change one thing at a time and give each change long enough to settle.

Where onboarding really starts

The first-run flow is the second half of a promise that began on the store page. If the screenshots promise a budget in two minutes and the app opens with five slides about features, people feel the gap at once. Store listings and screenshots are covered in our app marketing and ASO track, and they are worth reading next to your onboarding, not after it.

The other half of the problem sits even earlier. If you cannot say in one sentence what the app does for this particular person, no carousel will say it for you; the positioning work described in finding the angle before you promote an app is the same work an onboarding flow depends on. More interface pieces live in the app design track.

For now, pick the one screen in your flow that asks for something before giving anything back, and move it to the moment it's needed. Then hand the phone to the next new person and watch where their thumb goes.