By Mehdi HassanWhat makes good mobile app onboarding design?
Good mobile app onboarding design gets a new user to their first real result quickly and asks for as little as possible on the way. Everything in the first session either moves the user toward that result or waits. That includes the sign-up form, the permission prompts, the feature tour and the notification opt-in.
The result is what we call the value event: the first moment the app does its job for this person. For a budgeting app it's seeing this month's spending sorted. For a language app it's finishing a first lesson. For a scheduling app it's a booking link that works. Name yours in one sentence before you draw a single screen, because every other decision depends on it. Our guide to finding your aha moment covers how to pick it from user research and usage data.
Onboarding is one stage of the broader process in our mobile app design guide. This article focuses on the two places most apps lose people: tutorials nobody reads and permission prompts that arrive too early.
Why do onboarding carousels and tutorials fail?
Onboarding carousels fail because they explain features before the user has a reason to care. Three or four swipeable slides with an illustration and a headline ask for attention at the exact moment the user wants to try the app. Most people tap Skip or swipe through without reading, so the slides cost time and teach nothing.
They also hide the product. If the first thing a user sees is marketing, the app hasn't proven anything yet, and the store listing already did the selling. Tutorials that point at buttons with coach marks have a similar problem: they teach the interface instead of the outcome, and people forget them as soon as they're dismissed.
There are exceptions. A single welcome screen that sets one expectation ("Connect your bank to see this month's spending") works well, and a short gesture hint is useful when the core interaction isn't discoverable, such as swiping cards. The test is simple: does this screen move the user closer to the value event, or does it only describe it?
Pattern | What it does | Use it when |
|---|---|---|
Carousel tutorial | Explains features on swipeable slides | Rarely; almost never as the first screen |
Value-first flow | Gets the user to one result, then asks for more | Default for most apps |
Personalization questions | Asks 2–4 questions to tailor the first result | The first result depends on goals or level |
Interactive walkthrough | User does the core action with guidance | The core interaction isn't obvious |
Sample data or demo mode | Shows the app working before setup | Real setup takes effort, such as imports or connections |
Deferred sign-up | Lets users try before creating an account | There's value before anything needs saving |
What does a value-first onboarding flow look like?
A value-first onboarding flow starts with the shortest path to the value event and treats every other step as something to earn. It usually has five parts, in this order.
One welcome screen with one promise
State what the user will get in the next minute, in their words, with one button. No carousel.
Only the questions the first result needs
If the first result depends on goals or level, ask two to four quick questions. If it doesn't, ask none. Our guide to onboarding surveys covers which questions are worth the screen.
The core action, with real or sample content
Let the user do the thing: log a workout, scan a receipt, see a sample budget. Empty screens here are a dead end, so fill them or guide the first entry.
The value event, made visible
Show the result clearly and say what it means. This is the screen that should get the most design attention in the whole flow.
Then ask: account, permissions, notifications
Now there's something to save and a reason to come back, so sign-up and opt-ins have context.
Deferred sign-up isn't always possible. Banking, health and anything with sensitive data needs identity up front, and some apps are useless without an account. In those cases, keep the form minimal, offer Sign in with Apple and Google, and show what's coming on the next screen so the form feels like a step toward something.
How should you ask for permissions in a mobile app?
You should ask for each permission at the moment the user tries to do something that needs it, after a short priming screen that explains the benefit. That approach is called permission priming. It protects the system prompt, which is the only prompt that actually grants access.
It matters because the system prompt is a one-shot on iOS. Once someone taps Don't Allow, the app can't show it again; the user has to find the setting in the Settings app. Android lets apps ask again, but if the user declines repeatedly the system stops showing the dialog, and since Android 13 notifications also need a runtime permission. On both platforms, a cold prompt on first launch, before the user knows why the app wants their camera or location, wastes your best chance.
- Ask in context. Request the camera when the user taps Scan, not on launch.
- Prime with the benefit. "Turn on location to see classes within walking distance" beats "We need your location."
- Offer a real way to skip. "Not now" should continue the flow, and the feature should explain itself later.
- Write a clear purpose string. iOS shows your usage description inside the system prompt, so it's copy that needs the same care as a headline.
- Recover gracefully. If access was denied, show what's missing and a button that opens the right settings screen.
When should you ask for push notification permission?
Ask for push notification permission after the user has experienced the value event and has a concrete reason to be reminded: a streak to protect, a delivery to track, a reply they're waiting for. Tie the priming screen to that reason, and let the user choose what they'll be notified about if you can.
iOS also supports provisional authorization, which delivers notifications quietly to Notification Center without asking first. The user then decides from a real notification whether to keep them. It's a good fit for apps whose notifications are useful but not urgent, because people judge an example instead of a promise.
For example, suppose you're redesigning onboarding for a meal-planning app
For example, suppose a meal-planning app opens with four carousel slides, then sign-up, then notification and location prompts, before the user sees a single recipe.
A value-first version would start with one welcome line ("Plan this week's dinners in two minutes"), ask two questions (household size, foods to avoid), and show a full week of dinners straight away. Saving the plan prompts account creation. The notification priming screen appears after the first plan is saved and offers one specific reminder: the shopping list on the day the user picked. Location is requested only if the user taps "Find stores near me."
This is a hypothetical walkthrough, not a measured result. The point is the order: result first, then the asks that the result justifies.
How do you measure whether app onboarding works?
You measure app onboarding by the share of new users who reach the value event, and how long it takes them. Screen-by-screen drop-off shows where people leave; permission grant rates show whether priming works; and day-one and week-one retention show whether the value event was the right one.
Instrument each step of the flow as an event before launch, not after. Watch a handful of real people go through it on their own phones, because recordings show hesitation that analytics can't. Then change one thing at a time. If users are reaching the value event but not coming back, the problem is usually the event itself, not the onboarding screens. A follow-up checklist or progress pattern can help in the days after, which we cover in onboarding checklist design.
Platform conventions matter here too: back behavior inside a multi-step flow, and how sheets and alerts behave, differ between platforms. See iOS vs Android design for the details.
