Product Design
Onboarding gets treated as a design exercise — pick a nice illustration style, write some friendly copy — when it's really a sequencing problem. The order you ask for things, and how quickly you get to something the user actually cares about, matters more than how polished any individual screen looks.
This matters more than it seems, because onboarding is the one part of the product every single user experiences, without exception — you can build a great feature that half your users never find, but every user who installs the app goes through onboarding. A small improvement there compounds across your entire user base in a way that a niche feature improvement never does.
Every screen between install and the moment a user experiences your product's actual value is a chance to lose them. A long welcome carousel explaining features nobody's used yet is friction, not education — most users learn a feature better by touching it than by reading a slide about it. Where possible, let people reach a real, working version of the core action before asking them to sign up, set preferences, or watch an intro.
System permission prompts (camera, location, notifications, tracking) are one-shot on iOS in a meaningful sense — if a user declines, you generally can't re-trigger the native dialog; you have to send them to Settings, which almost nobody does. A "priming" screen that explains why you're about to ask, shown right before the system prompt, meaningfully improves the accept rate compared to firing the system dialog cold on first launch.
Where the product allows it, let people explore before forcing an account. When an account genuinely is required for the core loop to work — most social or transactional products — explain why right before you ask, rather than presenting sign-up as the very first screen with no context.
A handful of onboarding questions (two to four, not ten) can meaningfully improve relevance if the app actually uses the answers visibly and quickly — a personalized home screen, a tailored recommendation. Questions that don't visibly change anything downstream just read as friction, and should always have a skip option so an impatient user isn't blocked from proceeding.
A brand-new account with a genuinely blank screen — no data, no content, no example — reads as broken, even when it's working correctly. Sample content, a clear first action, or a short guided task in that empty state does more for first-session retention than almost any other single change.
The most common mistake in onboarding work is redesigning based on a guess about where people drop off. Instrument each onboarding step as its own event, look at the actual funnel, and find the specific screen where the drop happens before changing anything. It's common for the real problem to be a single confusing step rather than the whole flow — and redesigning the wrong ten screens wastes a sprint that fixing the one real problem wouldn't have.
Some users want to move fast and skip every optional step; others read every word before proceeding, worried about getting a setting wrong. Good onboarding design serves both without penalizing either — a visible, honest skip option (not a hidden tiny link in the corner) respects the first group, while sensible defaults and the ability to change any onboarding choice later in Settings reassures the second group that nothing they pick during setup is a permanent, high-stakes decision.
The first-session flow gets most of the design attention, but a returning user who hasn't come back in a while needs a different, lighter kind of re-onboarding — a reminder of what changed, not the full introduction again. Treating "day one" and "day seven, after a gap" as the same problem is a common miss; a returning user already knows the basics and just needs to be reoriented quickly, not walked through the product from scratch.
Once you're instrumented, resist the urge to ship a full onboarding redesign in one shot and hope it helped. Where you have the traffic to support it, an A/B test of a single change — reordering two steps, adding a priming screen before one specific permission — isolates what actually moved the funnel from what just happened to coincide with a broader release. At lower traffic volumes where a formal test isn't statistically meaningful, at least change one variable at a time and watch the same funnel step before and after, rather than redesigning everything simultaneously and losing the ability to tell what worked.
Good onboarding isn't about making every screen prettier. It's about removing screens, reordering the ones that remain, and using real data instead of intuition to find out which one is actually costing you users.
More from the journal
App Store
Apple rejects a meaningful share of first-time submissions, and it's rarely the exotic reasons founders worry about. Here's what actually trips people up, and how to submit clean.
Launch
Launch day is the easy part. The work that determines whether it goes well happens weeks earlier — here's the sequence we actually follow.
Engineering
Cross-platform frameworks have closed most of the historical gap with native — but not all of it. Here's the actual decision framework, not a philosophy war.