Wizards and Steppers: Long Tasks in Steps Without Losing the User

When to use a wizard or stepper for long tasks, how many steps make sense, how to show progress, and how to review answers before confirming.

info Quick Definition
A wizard is a step-by-step process that asks for information in a fixed order, and a stepper is the visual indicator that shows where the user is within it. Both split a long task into manageable parts, as long as each step makes sense on its own.

What are they, and how do they differ?

A wizard is the whole flow: a sequence of screens that guides the user from start to finish, sometimes inside a modal. A stepper is only the progress indicator that accompanies the flow, showing completed, current, and upcoming steps. A wizard may or may not have a stepper, and a stepper can appear in flows that are not wizards, such as a checkout process.

Nielsen Norman Group (NN/g) defines a wizard as a step-by-step process that lets users enter information in a prescribed order, and recommends not letting users skip steps. That distinguishes it from a long form, where you can almost always go back to any field.

Why does this matter for a junior designer?

Because almost every product has a long task someone has to complete: opening an account, setting up a store, booking a trip with several options. A forty-field form on one screen is intimidating; split into five steps with a clear order, the task feels more manageable.

But the pattern is also misused. A wizard for a task repeated every day becomes a nuisance. Knowing when it works and when it does not is the difference between a guided task and an obstacle course.

What does NN/g recommend?

NN/g (Raluca Budiu, 2017) recommends wizards for novice users or infrequent processes, such as initial setup. If the user repeats the process, offer a faster alternative. Some recommendations from its article:

  • Show the full sequence and highlight the current step, so users know where they are and how much is left.
  • Label buttons precisely. Instead of generic “Next” and “Previous”, name the step the user is heading to.
  • Allow leaving midway and saving progress to resume later, without re-entering everything.
  • Make each step self-sufficient, without depending on information stored elsewhere in the app.
  • Place help beside the wizard, not over it, and reuse previous selections as defaults the next time.

NN/g also lists the disadvantages: more clicks and higher interaction cost if repeated, difficulty comparing information across steps, poor tolerance for interruptions, blocking the rest of the application when the wizard is modal, and less control for expert users. For the cost concept, the article on interaction cost explains why each step adds up.

How many steps should there be?

There is no universal number, but some guidance helps. Carbon, IBM’s design system, recommends its progress indicator for linear processes of three or more steps. It does not recommend it with fewer than three steps, when steps can be completed in any order, or when the number of steps changes with conditional logic.

None of the cited sources sets a maximum. The practical rule is that each step has a reason to exist. If two steps can be merged without the user getting lost, merge them. If a step is so long that users abandon halfway, split it.

How is progress shown?

Carbon defines visible states for each step: completed, current, not started, error, and disabled. In the error state you should explain what went wrong and how to fix it, and when possible validate that a step is complete before letting users continue.

For labels, Carbon recommends one or two words that state what the user will do in that step, for example verb plus noun, such as “Define endpoints”, or a single universally understood word, such as “Cart” or “Payment”. Avoid vague labels like “Processing”.

Carbon also notes that, by default, the indicator is non-interactive and only shows progress; an interactive version lets users navigate to any step. It also warns about disabled steps: they are not focusable and screen readers do not read them, so do not keep information there that users need. Decide as well whether users can go back without losing what they already entered.

How do you review everything before confirming?

GOV.UK recommends showing a single “Check answers” page right before the confirmation screen for small or medium transactions. For large transactions with several sections, you can add a check answers page at the end of each section, which can help when different people complete each section. GOV.UK asks you to test this approach with users before adopting it.

Each section gets a “Change” link that leads to the relevant question, with answers already filled in. After the user clicks “Continue”, GOV.UK recommends returning them to the check answers page without repeating the rest of the process. If the change requires new questions, those are asked before returning. Optional questions left unanswered are shown as “Not provided”.

To validate each step without interrupting, the article on form validation timing explains when to show an error.

When is a wizard the WRONG choice?

  • With fewer than three steps. A two-step indicator adds noise. A short form works better.
  • When the order is free. If users can fill in information in any order, a wizard takes away control for no reason.
  • With expert users or frequent processes. The cost of going through every screen becomes a daily annoyance.
  • When the number of steps depends on conditional logic. According to Carbon, the indicator is not suitable in that case. If each answer changes how many screens follow, a page with sections is often better.

If the flow has sections but is not linear, the article on UI flow chunking describes how to organize information into blocks without imposing an order.

Example

Illustrative example: setting up a business on a payments platform. There are four steps: account holder details, business details, bank account, and verification.

  • Stepper: four states, labeled “Holder”, “Business”, “Account”, and “Verification”. The current step is highlighted.
  • Exit: the user can save and return. If they close the browser at step two, they resume there.
  • Review: before submitting, a page summarizes the four sections, with a “Change” link next to each. When the IBAN is changed, the app returns to the review without repeating the other steps.
  • Error: if the bank account is invalid, the step explains the problem and how to fix it instead of just marking the error.

A single-page form would have looked shorter, but it would have mixed four different tasks, and the user would not know when it ends.

For payments, the article on checkout UX expands on the trust and friction decisions in that part of the journey.

Common mistakes

  • Using a wizard for a task the user repeats every day.
  • Using generic “Next” and “Previous” labels without context.
  • Not allowing a long process to be saved and resumed.
  • Building steps that depend on information from elsewhere in the app.
  • Showing a stepper whose steps change with the answers, without notice.
  • Forgetting the review page before confirming.

Sources

Frequently asked questions

What is a wizard in UX?
It is a step-by-step process that lets users enter information in a prescribed order, with each step usually a screen, sometimes inside a modal. Nielsen Norman Group recommends it mainly for novice users or infrequent processes.
What is a stepper?
It is a visual progress indicator that shows the steps of a linear task, with completed, current, and upcoming steps. Carbon, IBM’s design system, calls it a progress indicator and recommends it for linear processes of three or more steps.
How many steps should a wizard have?
There is no universal limit. Carbon does not recommend a progress indicator with fewer than three steps, and neither NN/g nor GOV.UK sets a maximum. What matters is that each step can be completed on its own, without depending on information from elsewhere in the app.
How do you review answers before confirming?
With a review page that summarizes all answers and lets the user change them. GOV.UK recommends a single page right before the confirmation screen for small or medium transactions, and a review at the end of each section for very large ones, testing it with users first.
When is a wizard the wrong choice?
With expert users or very frequent processes, where interaction cost grows. Carbon also advises against the progress indicator when steps can be completed in any order, when there are fewer than three steps, or when the number of steps changes with conditional logic.