# Wizard

Lead people through a long task 1 step at a time, in a fixed order.

- Family: Onboarding and flows
- Kind: Classic pattern
- Maturity: established
- Platforms: web, mobile, desktop
- Updated: 2026-10-12
- Source: https://uxpatterns.ai/patterns/wizard
- Licence: CC BY 4.0 (text and drawings; product screenshots excluded)

## Problem

A task needs a lot of input, and the person does it rarely enough that they do not know the order. Shown as 1 long form it reads as work they have no time for, so many never start. Shown without an order, they answer questions that later turn out not to apply to them.

## Forces

- Too much at once - "how long is this going to take?"
- Later answers depend on earlier ones
- Leaving halfway must not lose the work

## Solution

Split the task into steps, 1 screen each, with 1 question or 1 tightly related group per screen. Make that question the page heading. Put a Back link at the top that returns the previous screen exactly as it was left. Check the answer when the person leaves the step, not only at the end. Save as you go, so closing the tab is not the same as starting again. Show position only when you can state it honestly.

## Anatomy

- **Back link** (A): top left, above the heading. Returns the previous step as it was left. Some people do not trust the browser button.
- **Step heading** (B): the question being asked, not the name of the section. A screen reader then announces it once, not twice.
- **The fields** (C): only what this step needs. Group 2 or 3 fields when they are genuinely 1 thought, such as a full address.
- **Primary action** (D): 1 per screen - "Continue", and "Submit" on the last. No competing button beside it.
- **Position** (E): optional. "Question 3 of 7" only when 7 is true for this person. Leave it out when the flow branches.

## Why it works

People decide whether to begin a task by guessing what it will cost them. One long form shows the whole cost at once, and a good number of people never start. Splitting it lowers the price of the first step and replaces 1 large decision with several small ones, each of which is easy to answer and visibly finished. Making the question the heading means the person reads 1 thing and answers 1 thing. And an honest position indicator removes the worst part of a long flow, which is not its length but not knowing its length.

## Use when

- The task is long, done rarely, and has a natural order.
- Later steps depend on what was answered earlier.
- Finishing matters more than speed - applying, filing, setting something up.

## Avoid when

- The person does this often and knows it by heart. A single dense form is faster for them.
- The parts are independent. Use sections, tabs or a settings page instead.
- There are only 2 short steps. One screen is less work than two.

## Risks

- Cutting the task into so many screens that it feels longer than it is.
- A strip showing every step at once - easily missed, poor on a phone, and wrong as soon as the flow branches.
- Losing what was typed when the person goes back, or closes the tab.
- Checking the answers only at the end, so errors surface far from where they were made.
- Letting Back repeat a one-time action such as a payment.

## Accessibility

- Make the question the page heading, so a screen reader announces it once rather than twice.
- Move focus to that heading when the step changes, or the change is silent.
- Give the Back link real text - "Back" - not only an arrow glyph.
- If you show a position, mark the current step with aria-current="step".
- Never show a step as finished using colour alone.

## Examples

- **Check if you need a UK visa** (Government Digital Service, Oct 2026): opens on a single question - nationality - with 1 Continue button and deliberately no progress indicator, because the answer decides how many questions follow.
- **Register to vote** (Government Digital Service, Oct 2026): the start page states the cost before step 1: "about 5 minutes", and what to have ready. The flow itself is 1 question per screen.

## Related patterns

- Inline validation (combined): /patterns/inline-validation
- Progressive disclosure (alternative): /patterns/progressive-disclosure
- Breadcrumbs (conflicts): /patterns/breadcrumbs
- Tabs (see-also): /patterns/tabs

## References

- van Welie, M. - Wizard, Patterns in Interaction Design (2001)
- Tidwell, J., Brewer, C., Valencia, A. - Designing Interfaces, 3rd ed. (2019)
- Government Digital Service - Question pages, GOV.UK Design System (checked Oct 2026)
- Nielsen Norman Group - Wizards: definition and design recommendations (2019)