The Setup Wizard
A linear multi step flow for configuration that genuinely has to happen before anything works.
The problem it solves
Some products cannot function until several linked decisions are made. Presenting them as one dense settings page causes abandonment and wrong answers.
A dependent setup sequence
Wizards have a bad reputation because they are used where they do not belong. Used correctly, a wizard is the right tool for exactly one situation: configuration that is mandatory, ordered, and where later steps depend on earlier answers. Picking a payroll country before the tax fields. Choosing a database type before the connection form.
The test is whether the user could do this configuration in any order. If they could, it is a settings page, and forcing a sequence onto it adds friction for nothing.
- Show the number of steps and the current position from the first screen.
- One decision per step. A step with six unrelated fields is a settings page in a costume.
- Let people go back without losing input, and save partial progress so a closed tab is not a restart.
- Default every field you can infer, and mark inferred values so the user can see what you assumed.
- End on the result, not on a confirmation. The last screen should be the working product.
That last point separates a wizard that feels like progress from one that feels like paperwork. Ending on Setup complete, with a Go to dashboard button, adds a click and takes away the payoff. Land the user in the configured thing.
Paperwork wizard
- Step 1 of ? with no count shown.
- Nine fields on step two, none of them related.
- Back button clears the form.
- Ends on a Setup complete screen.
Working wizard
- Step 2 of 4, with the remaining steps named.
- One decision per step, with the reason it matters.
- Back preserves everything, and progress survives a closed tab.
- Ends inside the configured workspace with the first item visible.
Worked example
Northpay, payroll setup
Northpay needs country, entity type, pay schedule and bank details before it can run anything, and the tax fields differ by country. Their wizard asks country first, then shows only the fields that country requires. A user in one jurisdiction sees four fields where a user in another sees nine. The same information on a single page would have shown everyone all thirteen.
One thing a wizard must never do is collect what it does not need. Every optional question inside a mandatory flow reads as mandatory, and each one raises the chance the user quits with a half configured account, which is worse than no account.
When it fits
- Configuration that is genuinely required before the product does anything at all.
- Flows where later fields depend on earlier answers, such as tax fields after a country choice.
- Regulated or financial setup where a wrong answer is expensive to unwind.
- Technical setup where the order of operations is real, such as choosing a runtime before its settings.
When it backfires
- When the steps have no real dependency, so a settings page would have let the user work in their own order.
- When optional questions are smuggled into a mandatory flow, making the whole thing feel longer than it is.
- When progress is lost on refresh, so anyone interrupted mid flow starts again or never returns.
- When it ends on a confirmation screen rather than the working product, wasting the momentum it built.
Products using it
Stripe
Account activation is staged by topic, with business type asked before the fields that depend on it.
Xero
Company setup asks country and financial year before showing tax and reporting options tied to that choice.
Vercel
Project creation asks framework first, then presents build settings already filled in for that framework.
The psychology under it
The takeaway
Use a wizard only where later steps depend on earlier answers, and land the last step inside the working product.
Finished the teardown? Bank it and the day counts toward your run.