UX Patterns Guide
My learning 0 of 20 lessons complete
Start lesson 1 →
Back to compare picker

Complete complex form vs Single-page form vs Multi-step form vs Wizard

Use a complete complex form when a product configuration has many related sections that must stay inspectable together, with section status, cross-section validation, draft preservation, and a review-ready save contract.

Complete complex form live exampleSingle-page form live exampleMulti-step form live exampleWizard live example
Learn the decision

Match the interaction to the person's task

Use a complete complex form when a product configuration has many related sections that must stay inspectable together, with section status, cross-section validation, draft preservation, and a review-ready save contract.

Complete complex form

Use it when: A product configuration has many related fields across named sections.

Make this state clear: Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.

Observe the result: A user jumps from Review back to Rules, changes a dependency, and sees Review marked stale until the affected sections pass validation again.

Study the full pattern →

Single-page form

Use it when: A compact set of related fields should be reviewed together before one submit.

Make this state clear: Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.

Observe the result: A user reviews all contact details before submitting because the fields are short, related, and visible in one scan.

Study the full pattern →

Multi-step form

Use it when: A transaction spans several ordered pages or sections.

Make this state clear: Current step state with heading, saved context, local answer controls, Back, and Continue.

Observe the result: A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.

Study the full pattern →

Wizard

Use it when: A setup, import, object creation, or configuration task has strict sequencing.

Make this state clear: Current guided step with a clear heading, local controls, and step-specific primary action.

Observe the result: 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.

Study the full pattern →

Practice the judgment: Imagine this situation: A wizard is used for ordinary settings editing, adding blocked future steps and cancel behavior when users only needed a sectioned configuration surface. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Complete complex formSingle-page formMulti-step formWizard
UI or UX UI + UX - Sectioned enterprise configuration formUI + UX - Short related multi-field submission pageUI + UX - Multi-page transaction with saved step stateUI + UX - Guided sequential setup assistant
UI guidance Render one coherent form surface with a clear title, section navigation or section headings, current section state, grouped controls, persistent labels, helper text, required indicators, error summary, field-level errors, review or summary state, and one save contract.Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit.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.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 complete complex form when users must edit many related product settings together and need to inspect dependencies across sections before saving.Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.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 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 policy configuration form has Basics, Rules, Approvals, Notifications, and Review sections; Approvals shows an error because the threshold in Rules requires at least two approvers.A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end.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 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 long settings page saves invalid combinations because validation checks each field in isolation and ignores dependencies between threshold, approvers, and escalation owner.A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.A five-screen flow shows all steps as complete after users only viewed them.All steps are visible as visited while hidden required setup is inserted later, so the step count and current heading are dishonest.
Good UX A user jumps from Review back to Rules, changes a dependency, and sees Review marked stale until the affected sections pass validation again.A user reviews all contact details before submitting because the fields are short, related, and visible in one scan.A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.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 Save, sees three generic errors somewhere in the page, and must scan many controls to discover which section owns each problem.A validation failure clears completed fields, forcing the user to re-enter unrelated information.A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again.A user goes Back to change the connector and the wizard silently keeps review answers from the old connector.
Best fit A product configuration has many related fields across named sections.A compact set of related fields should be reviewed together before one submit.A transaction spans several ordered pages or sections.A setup, import, object creation, or configuration task has strict sequencing.
Avoid when The form is a short related set of fields that fits a simple single-page form.The form is long, high-stakes, branched, or too hard to recover from on one page.The fields are short, related, and easier to scan together on one page.The task is a short form that users should scan and submit on one page.
Required state Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.Current step state with heading, saved context, local answer controls, Back, and Continue.Current guided step with a clear heading, local controls, and step-specific primary action.
Accessibility burden Use semantic headings, fieldsets, legends, and persistent labels so each section and field group has a programmatic name.Keep field order in the DOM the same as the visible order.Use a clear page heading on every step and keep it synchronized with route and progress context.Use one clear wizard title and one current step heading; keep browser title, heading, and progress context synchronized.
Common misuse Splitting tightly related settings across pages so dependencies are invisible during editing.Using one page for a long complex application just to avoid designing steps.Using a multi-step form to hide a short related form that users should review on one page.Letting users finish before required tests, previews, or review pass.

Complete complex form

UI or UX
UI + UX - Sectioned enterprise configuration form
UI guidance
Render one coherent form surface with a clear title, section navigation or section headings, current section state, grouped controls, persistent labels, helper text, required indicators, error summary, field-level errors, review or summary state, and one save contract.
UX guidance
Use a complete complex form when users must edit many related product settings together and need to inspect dependencies across sections before saving.
Good UI
A policy configuration form has Basics, Rules, Approvals, Notifications, and Review sections; Approvals shows an error because the threshold in Rules requires at least two approvers.
Bad UI
A long settings page saves invalid combinations because validation checks each field in isolation and ignores dependencies between threshold, approvers, and escalation owner.
Good UX
A user jumps from Review back to Rules, changes a dependency, and sees Review marked stale until the affected sections pass validation again.
Bad UX
A user clicks Save, sees three generic errors somewhere in the page, and must scan many controls to discover which section owns each problem.
Best fit
A product configuration has many related fields across named sections.
Avoid when
The form is a short related set of fields that fits a simple single-page form.
Required state
Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.
Accessibility burden
Use semantic headings, fieldsets, legends, and persistent labels so each section and field group has a programmatic name.
Common misuse
Splitting tightly related settings across pages so dependencies are invisible during editing.

Single-page form

UI or UX
UI + UX - Short related multi-field submission page
UI guidance
Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit.
UX guidance
Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.
Good UI
A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end.
Bad UI
A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.
Good UX
A user reviews all contact details before submitting because the fields are short, related, and visible in one scan.
Bad UX
A validation failure clears completed fields, forcing the user to re-enter unrelated information.
Best fit
A compact set of related fields should be reviewed together before one submit.
Avoid when
The form is long, high-stakes, branched, or too hard to recover from on one page.
Required state
Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.
Accessibility burden
Keep field order in the DOM the same as the visible order.
Common misuse
Using one page for a long complex application just to avoid designing steps.

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 browser refresh on step 3 clears steps 1 and 2, forcing the user to start again.
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
Current step state with heading, saved context, local answer controls, Back, and Continue.
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.

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
All steps are visible as visited while hidden required setup is inserted later, so the step count and current heading are dishonest.
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 goes Back to change the connector and the wizard silently keeps review answers from the old connector.
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
Current guided step with a clear heading, local controls, and step-specific primary action.
Accessibility burden
Use one clear wizard title and one current step heading; keep browser title, heading, and progress context synchronized.
Common misuse
Letting users finish before required tests, previews, or review pass.
Decision rules
  • Prefer a complete complex form when related settings, policies, permissions, or enterprise configuration fields need one inspectable editing surface rather than a short one-page submit or a sequential transaction.
  • Prefer a single-page form when the field set is compact, related, low branching, and can be reviewed comfortably before one submit without section navigation.
  • Prefer a multi-step form when users are completing a long transaction across saved pages and each page has a clear answer-collection role, especially for applications, checkout, compliance, or public-service journeys.
  • Prefer a wizard when the product must guide a setup, import, or creation task through dependent steps with a final finish action, step-specific tests, generated previews, or cancel semantics.
  • A complete complex form should expose section names, section status, current section, validation errors, stale review state, and save readiness without making users infer progress from scroll position.
  • Keep related controls grouped with headings, fieldsets, legends, persistent labels, helper text, and aligned validation messages; do not compress the form into a spreadsheet-like grid of abbreviations.
  • Use cross-section validation when one section changes the requirement or meaning of another section, and preserve all entered values when moving to an error-owning section.
  • Provide an error summary that points to the affected section or field group, then show the field-level error beside the owning input.
  • Mark required or optional fields according to the dominant pattern in that product form; for long product configuration forms, required labels are often clearer when most fields are optional.
  • Do not use a complete complex form when research shows users need one thing per page, heavy branching, mobile-first recovery, or per-answer autosave; use multi-step or single-question pages instead.
  • Use progressive disclosure inside a section only for secondary settings; do not hide required fields, dependencies, section status, or save-blocking errors behind collapsed advanced panels.
  • Before save, offer review or summary behavior for high-risk settings so users can inspect dependencies and section status without leaving the form.
Inspect live examples
Complete complex formSingle-page formMulti-step formWizard
Failure modes
  • A dense grid of unrelated settings is called a complex form but has no section ownership, labels, validation recovery, or review state.
  • The product splits tightly related settings across pages, so users cannot compare a threshold in one section with the approval rule it changes.
  • A wizard is used for ordinary settings editing, adding blocked future steps and cancel behavior when users only needed a sectioned configuration surface.
  • A long public-service form is kept on one page even though one-question pages, branching, and saved answers would reduce errors.
  • Cross-section dependencies fail silently, letting users save a policy where one section contradicts another.
  • Error messages appear only at the top of the form, forcing users to search through many sections without field-level ownership.

Saved items