Onboarding Wizard Design

A senior product marketing director's playbook for designing first-run product onboarding wizards that get users to the ah-ha moment without overwhelming them. Step architecture, progressive disclosure, escape hatches, completion incentives, drop-off measurement. The discipline of building an onboarding sequence the user actually completes.

Most product onboarding wizards fail in one of two ways. They cram every feature into a 12-step intro the user has not earned the patience for. Or they offer a "skip onboarding" button so prominent that users skip into an empty product with no context, and then churn the next day because they never found the value. The activation rate is the metric that matters, and most wizards are optimizing for the wrong thing.

The wizards that work do something different. Each step earns the user one step closer to value. The wizard surfaces the right thing at the right moment, not everything upfront. Skip exists but is balanced against staying engaged. The user reaches the ah-ha moment with a sense that the product respected their time.

The voice is the senior product marketing director who has watched activation rates double when wizards were redesigned and watched them collapse when "more onboarding" was added without discipline. Practical, opinionated about the design choices that distinguish completed wizards from skipped ones, willing to call out when no wizard at all is the right answer.

When to use this skill: scoping a first-run onboarding wizard for the first time, auditing a wizard with poor completion or activation, deciding which features warrant inclusion in onboarding vs deferred to in-product help, or designing the ah-ha moment the wizard is engineering toward.

What this skill covers

This skill spans first-run product onboarding wizards. The growth-tooling distinctions:

• multi-step-form-design is pre-signup data capture (forms before the user has access). This skill is post-signup product onboarding. Different phase, different audience state.
• interactive-product-tour is contextual help WITHIN the product, surfacing across the lifecycle. This skill is the sequential first-run experience.
• chatbot-flow-design is conversational help. This skill is non-conversational sequential setup.
• onboarding-wizard-design (this skill) is the post-signup wizard's structure, ah-ha moment design, progressive disclosure, skip mechanics, drop-off measurement.
• pm-spec-writing is the spec for engineers building the wizard. This skill is about WHAT to build; pm-spec-writing is about communicating it.

The audience: product marketers, growth marketers, in-house product teams designing activation flows, agencies running activation work for SaaS clients.

Out of scope: pre-signup forms (covered by multi-step-form-design); in-product contextual tours (covered by interactive-product-tour); the engineering implementation; specific Userpilot/Userflow/Pendo/Appcues platform configurations (those stay implementation-side).

The wizard decision: when wizards earn vs when contextual help suffices

Before designing the wizard, decide whether a wizard is the right tool.

Wizards earn investment when:

• The product has a meaningful setup step before value emerges. Connect a data source, invite a teammate, configure a workspace. Without setup, the product is empty; the wizard makes setup tractable.
• The ah-ha moment requires multiple actions in sequence. Single-action ah-ha moments (paste a URL, see a result) often work better with contextual prompts than with wizards.
• The audience expects guided onboarding. B2B SaaS with technical setup, enterprise software, configurable products. Some audiences (consumer, frictionless tools) reject wizard friction.
• The team can maintain the wizard. Wizards decay as the product evolves; without maintenance commitment, the wizard becomes a liability.

Wizards do NOT earn investment when:

• The product reaches value immediately. Single-input tools, simple consumer products. A wizard adds friction without lift.
• Contextual help would suffice. Tooltips, in-feature hints, and progressive in-product education sometimes serve better than upfront wizards.
• The audience expects no friction. Some audiences abandon at any wizard; meet them where they are.
• The team cannot maintain the wizard alongside product changes. Stale wizards point to deprecated features; users hit broken steps.

The decision is not "should we have an onboarding wizard"; it is "is the wizard the right tool for this specific product and audience."

Detail in references/wizard-decision-criteria.md.

Tutorial-overload vs skip-friendly-empty vs earned-progressive-disclosure

The keystone framing.

Tutorial-overload. Every feature explained in a 12-step intro before the user has touched the product. Cognitive overload. Users skip if they can; abandon if they cannot. Cost: the wizard's design effort produces a sequence almost nobody completes; activation rate suffers because the user did not reach the value-giving moment.

Skip-friendly-empty. "Skip onboarding" button at every step, so prominent that users always take it. Users skip; arrive at an empty product with no context; churn within hours. Cost: activation rate falls off a cliff because users never set up the basics that make the product functional.

Earned-progressive-disclosure. Each step earns the user one step closer to value. The wizard surfaces the right thing at the right moment, not everything upfront. Skip exists but is friction-balanced against staying engaged (e.g., skip places the user in a partially-set-up state with clear callouts to complete setup later). Cost: design effort is significant; activation rate often climbs significantly as a result.

The litmus test. Watch a new user complete (or skip) the wizard. Did they reach a moment where the product visibly demonstrated value within their first session? If yes, the wizard is earned-progressive-disclosure. If they completed every step but never reached value, tutorial-overload. If they skipped and never returned, skip-friendly-empty.

Step architecture: what belongs in each step, sequence logic

The structure that makes wizards actually work.

The principle. Each step should move the user one step closer to value. Steps that do not should be cut.

Common step patterns.

• Welcome and orientation. Quick context-setting, often skippable. Sets expectations for what the wizard will do.
• Identity and account context. Who are you, what's your role, what brought you here. Often used to personalize subsequent steps.
• Critical setup step. The one thing the product cannot work without (connect data source, invite teammates, set primary use case). This is often where wizards justify their existence.
• First-action step. Get the user to take a meaningful action that produces visible result. The ah-ha moment lives here or right after.
• Configuration deferral. Surface the things that can be set up later but are commonly needed; let the user defer with a clear path back.
• Confirmation and next steps. Recap what was set up; surface what to do next; route to in-product home.

Step coherence test. Each step should answer: did this step move the user closer to value? Steps that exist for completeness or feature-pride should be cut.

Detail in references/step-architecture-patterns.md.

The ah-ha moment design

What the wizard is actually trying to engineer.

The principle. The ah-ha moment is the moment the user feels "oh, this is what the product does for me." The wizard's structure should engineer toward that moment.

Identifying the ah-ha moment.

• It is the visible demonstration of value, not just feature explanation.
• It is action-tied, not knowledge-tied. The user did something and s