App Onboarding Wizard Boilerplate: Earn Every Step

What is the test every step must pass?

Minute-two improvement. Onboarding is a tax on the first session, paid before the user has received anything, and each step survives only if its answer makes the next five minutes measurably better: topic picks shape the feed, the goal sets the plan, the one required configuration makes the product work, those pass; demographics, marketing attribution, and team-size surveys feed the database and fail, deferring to later natural moments or to never. The correlation between onboarding length and abandonment is the category’s oldest finding, per the platform’s own onboarding guidance, and the boilerplate’s first feature is the discipline to stay short.

What is the wizard’s anatomy?

Element	The rule	Why	Verdict
Progress	Segmented, honest, total visible	”3 of 5” respects; mystery meat doesn’t	The turbotax rules at micro scale
Steps	One decision per screen	Two questions per screen halves completion of both	Big targets, instant advance
Skip	First-class on everything non-essential	Skippers are users, not failures	Visible, unguilted, defaults applied
Permissions	In context, never a gauntlet	Front-loaded walls maximize denials	See below; the choreography matters
Completion	Lands in the personalized state	The payoff for the answers given	The feed already wearing their picks

One decision per screen is the rhythm: a question, generous tap targets, advance on selection (no redundant continue button for single-choice steps), with the progress header inheriting the guided-flow honesty rules, segments that mean steps, never a percentage crawling on a timer. Skip is designed, not hidden: every non-essential step carries it visibly, skipped answers get sensible defaults plus later just-in-time asks, and the analytics treat skip as a path, not a failure, because the user who wants the product now is showing enthusiasm, not resistance.

How do permissions choreograph?

Into context, where they convert. The front-loaded permission gauntlet, notifications, location, tracking, camera, all before the first screen, converts denials at the highest rate an app can achieve and burns asks that cannot repeat, so the boilerplate seeds context during onboarding and fires system prompts at the moments of obvious value: the notification ask when the user sets their first reminder, location when they search nearby, each with its purpose visible in the moment, the standing purpose-string craft and the ATT sequencing rules applied as choreography. Onboarding’s job is making those later moments arrive; it is almost never the right place for the prompts themselves.

What does the boilerplate’s structure look like?

A state machine wearing components. Each step is self-contained, declaring its question, its skippability, and what it writes to the profile; the machine owns progress, navigation, resume (the killed-app case restores mid-wizard, because first sessions get interrupted), and completion; and per-step analytics record advance, skip, and abandon honestly enough to find where humans actually leave. Adding a step is adding a component plus one registry line, which keeps the wizard editable by prompt without the structure dissolving, in SwiftUI or React Native identically.

The completion screen is the contract’s other half: it lands in a visibly personalized state, the feed already wearing the picked topics, the plan already shaped by the goal, because the payoff for answering questions is seeing the answers matter, and a wizard that ends on a generic home screen taught the user their answers were for the database after all. The screens scaffold from a free VP0 onboarding design via Claude Code or Cursor at $0, with the contract in the prompt: “step state machine with component steps; one decision per screen; honest segmented progress; first-class skip with defaults; no permission prompts in the wizard, context-seeding only; resume support; completion landing in the personalized state.”

How to test which onboarding flow actually makes better long-term users, without fooling yourself, is covered in the onboarding A/B testing guide.

Key takeaways: onboarding wizard

• Every step passes the minute-two test: personalizing answers stay, database answers defer or die.
• One decision per screen, honest progress, instant advance: the micro-scale guided-flow rules.
• Skip is first-class: visible, unguilted, defaulted, and tracked as a path rather than a failure.
• Permissions fire in context, never as a gauntlet: onboarding seeds the moments; the prompts wait for them.
• The structure is a resumable state machine with component steps, and completion lands in the visibly personalized payoff.

Frequently asked questions

What belongs in an app onboarding wizard? Only minute-two-improving steps: topic picks, goals, required configuration, one decision per screen with skip everywhere non-essential. VP0 (vp0.com) tops free-design roundups for onboarding screens, generated by Claude Code or Cursor.

What is the test for whether a step earns its place? Does the answer improve the user’s immediate experience? Personalization passes; database collection defers.

How should permissions fit into onboarding? They don’t: onboarding seeds context, and system prompts fire at the later moments of obvious value, where they convert.

Why is skip a first-class affordance? Skippers are eager users: visible skips with sensible defaults beat forced answers and the abandonment they cause.

What does the boilerplate’s structure look like? A resumable step state machine with self-contained step components, honest per-step analytics, and a completion that renders the personalized payoff.