Back to compare picker

Wizard vs Multi-step form vs Step navigation / step indicator vs Process list / step-by-step navigation

Prefer a wizard when users are configuring, creating, importing, or installing something through a guided assistant where later choices depend on earlier selections.

Decision dimensions

Dimension WizardMulti-step formStep navigation / step indicatorProcess list / step-by-step navigation
UI or UX UI + UX - Guided sequential setup assistantUI + UX - Multi-page transaction with saved step stateUI + UX - Linear multistep task progress indicatorUI + UX - End-to-end ordered journey guidance with linked tasks
UI guidance Render a bounded assistant shell with a clear wizard title, current step heading, step list or progress context, step-specific body content, Back, Next or step-specific primary action, Finish, and Cancel or Close.Render each step as a focused page with a clear heading, progress context when useful, Back and Continue controls, local validation, and a final review page before submission.Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states.Present the process as a numbered ordered list of three to ten high-level steps, each with a short parallel action heading and enough supporting text or links to complete that stage.
UX guidance Use a wizard when users must be guided through a dependent setup, creation, import, or configuration task where each step prepares the next one and final finish should be gated.Use a multi-step form when a transaction is too long, conditional, high-stakes, or hard to recover from as one page, and users need manageable saved progress.Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains.Use process lists to help users understand an end-to-end journey that may span guidance pages, transactions, departments, offline actions, or separate sessions.
Good UI A connector setup wizard shows Choose connector, Configure access, Test connection, Review, and Finish in a side step list, with Configure access current and future steps disabled until prerequisites pass.A benefit application has Eligibility, Contact details, Documents, Review, and Submit pages, with the current step named in the heading and completed steps shown from saved data.A five-step application shows Eligibility complete, Contact details current, Documents upcoming, Review upcoming, and Submit upcoming, with the current step emphasized and a matching page heading.A 'Apply for a permit' guide shows numbered steps for Check eligibility, Prepare documents, Submit application, Pay fee, and Track decision, each expanding to relevant links and conditions.
Bad UI A generic Step 1, Step 2, Done strip wraps one text field and a Finish button with no dependency, preview, review, or cancel state.A five-screen flow shows all steps as complete after users only viewed them.A two-page form adds a large stepper that consumes space without explaining meaningful progress.A live form page shows a process list where the Continue button should be, so users leave the transaction to read unrelated guidance.
Good UX A user selects Zendesk, enters a token, runs a connection test, reviews generated sync settings, goes Back, and the token and test state are preserved or clearly invalidated when changed.A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current.A user unsure where to start expands 'Prepare documents' and sees both online upload guidance and an offline identity check requirement before starting the application.
Bad UX A user clicks Finish before the connector was tested and later discovers the integration never ran.A user changes an early answer and the form silently submits later answers that no longer apply.Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite.The process list says 'Complete identity check' but opens another step-by-step page that loops back to the original guide.
Best fit A setup, import, object creation, or configuration task has strict sequencing.A transaction spans several ordered pages or sections.A linear form, application, checkout, or setup flow has three or more meaningful steps.An end-to-end journey spans several pieces of guidance, service links, departments, or channels.
Avoid when The task is a short form that users should scan and submit on one page.The fields are short, related, and easier to scan together on one page.The journey has only one or two screens.The user is inside a live transactional form or wizard.
Required state Not-started state that explains what the wizard will configure and how many major steps follow.Not-started state with clear start point and expectation of the steps or sections ahead.Default state with completed, current, and upcoming steps.Standalone process overview with introduction and ordered high-level steps.
Accessibility burden Use one clear wizard title and one current step heading; keep browser title, heading, and progress context synchronized.Use a clear page heading on every step and keep it synchronized with route and progress context.Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states.Use semantic ordered-list structure so step order is available without relying on visual counters.
Common misuse Using wizard chrome for a short edit form with no dependent sequence.Using a multi-step form to hide a short related form that users should review on one page.Using a step indicator as breadcrumbs, tabs, side navigation, or pagination.Using a process list as a transactional progress indicator.

Wizard

UI or UX
UI + UX - Guided sequential setup assistant
UI guidance
Render a bounded assistant shell with a clear wizard title, current step heading, step list or progress context, step-specific body content, Back, Next or step-specific primary action, Finish, and Cancel or Close.
UX guidance
Use a wizard when users must be guided through a dependent setup, creation, import, or configuration task where each step prepares the next one and final finish should be gated.
Good UI
A connector setup wizard shows Choose connector, Configure access, Test connection, Review, and Finish in a side step list, with Configure access current and future steps disabled until prerequisites pass.
Bad UI
A generic Step 1, Step 2, Done strip wraps one text field and a Finish button with no dependency, preview, review, or cancel state.
Good UX
A user selects Zendesk, enters a token, runs a connection test, reviews generated sync settings, goes Back, and the token and test state are preserved or clearly invalidated when changed.
Bad UX
A user clicks Finish before the connector was tested and later discovers the integration never ran.
Best fit
A setup, import, object creation, or configuration task has strict sequencing.
Avoid when
The task is a short form that users should scan and submit on one page.
Required state
Not-started state that explains what the wizard will configure and how many major steps follow.
Accessibility burden
Use one clear wizard title and one current step heading; keep browser title, heading, and progress context synchronized.
Common misuse
Using wizard chrome for a short edit form with no dependent sequence.

Multi-step form

UI or UX
UI + UX - Multi-page transaction with saved step state
UI guidance
Render each step as a focused page with a clear heading, progress context when useful, Back and Continue controls, local validation, and a final review page before submission.
UX guidance
Use a multi-step form when a transaction is too long, conditional, high-stakes, or hard to recover from as one page, and users need manageable saved progress.
Good UI
A benefit application has Eligibility, Contact details, Documents, Review, and Submit pages, with the current step named in the heading and completed steps shown from saved data.
Bad UI
A five-screen flow shows all steps as complete after users only viewed them.
Good UX
A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.
Bad UX
A user changes an early answer and the form silently submits later answers that no longer apply.
Best fit
A transaction spans several ordered pages or sections.
Avoid when
The fields are short, related, and easier to scan together on one page.
Required state
Not-started state with clear start point and expectation of the steps or sections ahead.
Accessibility burden
Use a clear page heading on every step and keep it synchronized with route and progress context.
Common misuse
Using a multi-step form to hide a short related form that users should review on one page.

Step navigation / step indicator

UI or UX
UI + UX - Linear multistep task progress indicator
UI guidance
Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states.
UX guidance
Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains.
Good UI
A five-step application shows Eligibility complete, Contact details current, Documents upcoming, Review upcoming, and Submit upcoming, with the current step emphasized and a matching page heading.
Bad UI
A two-page form adds a large stepper that consumes space without explaining meaningful progress.
Good UX
After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current.
Bad UX
Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite.
Best fit
A linear form, application, checkout, or setup flow has three or more meaningful steps.
Avoid when
The journey has only one or two screens.
Required state
Default state with completed, current, and upcoming steps.
Accessibility burden
Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states.
Common misuse
Using a step indicator as breadcrumbs, tabs, side navigation, or pagination.

Process list / step-by-step navigation

UI or UX
UI + UX - End-to-end ordered journey guidance with linked tasks
UI guidance
Present the process as a numbered ordered list of three to ten high-level steps, each with a short parallel action heading and enough supporting text or links to complete that stage.
UX guidance
Use process lists to help users understand an end-to-end journey that may span guidance pages, transactions, departments, offline actions, or separate sessions.
Good UI
A 'Apply for a permit' guide shows numbered steps for Check eligibility, Prepare documents, Submit application, Pay fee, and Track decision, each expanding to relevant links and conditions.
Bad UI
A live form page shows a process list where the Continue button should be, so users leave the transaction to read unrelated guidance.
Good UX
A user unsure where to start expands 'Prepare documents' and sees both online upload guidance and an offline identity check requirement before starting the application.
Bad UX
The process list says 'Complete identity check' but opens another step-by-step page that loops back to the original guide.
Best fit
An end-to-end journey spans several pieces of guidance, service links, departments, or channels.
Avoid when
The user is inside a live transactional form or wizard.
Required state
Standalone process overview with introduction and ordered high-level steps.
Accessibility burden
Use semantic ordered-list structure so step order is available without relying on visual counters.
Common misuse
Using a process list as a transactional progress indicator.
Decision rules
  • Prefer a wizard when users are configuring, creating, importing, or installing something through a guided assistant where later choices depend on earlier selections.
  • Prefer a multi-step form when the primary job is collecting submitted answers across saved pages, especially public-service, application, checkout, or compliance transactions.
  • Use step navigation only to communicate progress inside a broader flow; it is not the guided assistant, validation model, cancel contract, or finish action by itself.
  • Use a process list when users need to understand an external process or complete tasks outside one controlled assistant, especially when tasks can be read or completed outside strict sequence.
  • A wizard should have step-specific footer actions such as Back, Next, Test connection, Review, Finish, and Cancel; avoid generic Next-only navigation when step obligations differ.
  • Do not unlock review or finish until prerequisite configuration, tests, generated previews, or validations have passed.
  • Provide a safe cancel or close state for partial setup, and state whether the draft will be saved, paused, or discarded.
  • If users need to jump freely among independent tasks, use task-list or process-list behavior instead of disabling future wizard steps.
  • If the sequence is just a long form with saved answers and review, use multi-step form; reserve wizard framing for guided tool work with stronger sequencing and setup semantics.
  • When an earlier wizard choice changes, clear, recompute, or retest dependent later steps before final finish.
Inspect live examples
Failure modes
  • Wizard chrome wraps a short edit form and adds disabled steps with no real dependency.
  • Finish is available before the generated setup is tested or reviewed.
  • Cancel immediately discards a partially configured setup without warning or draft recovery.
  • A hidden conditional step appears after users already relied on a fixed step count.
  • Step navigation is treated as the whole implementation while validation, draft state, and finish semantics are missing.
  • A process explanation is forced into a blocking wizard even though users only needed to read or complete tasks independently.