UX Patterns Guide
Back to compare picker

Review before submit vs Multi-step form vs Complete complex form vs Error summary

Use review before submit when users need one final, editable check of captured answers before the irreversible submit action; use multi-step form for the journey, complete complex form for editable sectioned settings, and error summary for validation recovery.

Review before submit live exampleMulti-step form live exampleComplete complex form live exampleError summary live example
Learn the decision

Match the interaction to the person's task

Use review before submit when users need one final, editable check of captured answers before the irreversible submit action; use multi-step form for the journey, complete complex form for editable sectioned settings, and error summary for validation recovery.

Review before submit

Use it when: A user has provided multiple answers and should verify them before a consequential submit action.

Make this state clear: Initial review state with grouped captured answers, relevant sections, and explicit submit action.

Observe the result: A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.

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 →

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 →

Error summary

Use it when: Form submission can produce one or more errors.

Make this state clear: Failed-submit state with summary visible near the form heading.

Observe the result: After failed submit, focus or reading order makes the summary discoverable before users scan the form.

Study the full pattern →

Practice the judgment: Imagine this situation: Change links return users to an earlier page and then force them through the whole transaction again. 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 Review before submitMulti-step formComplete complex formError summary
UI or UX UI + UX - Final editable answer summary before committing a transactionUI + UX - Multi-page transaction with saved step stateUI + UX - Sectioned enterprise configuration formUI + UX - Form recovery summary
UI guidance Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.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 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 top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.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 complete complex form when users must edit many related product settings together and need to inspect dependencies across sections before saving.Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.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 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.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI Change links lack context, so assistive technology users hear a list of identical Change links.A five-screen flow shows all steps as complete after users only viewed them.A long settings page saves invalid combinations because validation checks each field in isolation and ignores dependencies between threshold, approvers, and escalation owner.Summary and field messages visually disconnected or contradictory.
Good UX A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.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 jumps from Review back to Rules, changes a dependency, and sees Review marked stale until the affected sections pass validation again.After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again.A user clicks Save, sees three generic errors somewhere in the page, and must scan many controls to discover which section owns each problem.Only showing errors below the fold.
Best fit A user has provided multiple answers and should verify them before a consequential submit action.A transaction spans several ordered pages or sections.A product configuration has many related fields across named sections.Form submission can produce one or more errors.
Avoid when The task is a single low-risk field with clear inline validation and an obvious submit action.The fields are short, related, and easier to scan together on one page.The form is a short related set of fields that fits a simple single-page form.The message is a system failure, permission problem, or outage rather than a validation issue.
Required state Initial review state with grouped captured answers, relevant sections, and explicit submit action.Current step state with heading, saved context, local answer controls, Back, and Continue.Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.Failed-submit state with summary visible near the form heading.
Accessibility burden Use headings that make the review task explicit, such as Check your answers before sending your application.Use a clear page heading on every step and keep it synchronized with route and progress context.Use semantic headings, fieldsets, legends, and persistent labels so each section and field group has a programmatic name.Use a heading and alert behavior that makes the summary discoverable.
Common misuse Labelling the final commit button Continue.Using a multi-step form to hide a short related form that users should review on one page.Splitting tightly related settings across pages so dependencies are invisible during editing.Replacing field-level messages with only a top-level summary.

Review before submit

UI or UX
UI + UX - Final editable answer summary before committing a transaction
UI guidance
Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action.
UX guidance
Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed.
Good UI
A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address.
Bad UI
Change links lack context, so assistive technology users hear a list of identical Change links.
Good UX
A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved.
Bad UX
A user selects Change address, edits one field, then has to repeat every later page before finding the review page again.
Best fit
A user has provided multiple answers and should verify them before a consequential submit action.
Avoid when
The task is a single low-risk field with clear inline validation and an obvious submit action.
Required state
Initial review state with grouped captured answers, relevant sections, and explicit submit action.
Accessibility burden
Use headings that make the review task explicit, such as Check your answers before sending your application.
Common misuse
Labelling the final commit button Continue.

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.

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.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Summary and field messages visually disconnected or contradictory.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
The message is a system failure, permission problem, or outage rather than a validation issue.
Required state
Failed-submit state with summary visible near the form heading.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Replacing field-level messages with only a top-level summary.
Decision rules
  • Prefer review before submit when answers have already been collected and the next action will send, apply, pay, publish, or otherwise commit the transaction.
  • Prefer multi-step form for the sequence that collects and saves answers before the review page; the review page is a gate inside that journey, not the whole journey lifecycle.
  • Prefer complete complex form when users need to edit many related settings on one sectioned surface before saving, rather than reviewing captured answers from previous pages.
  • Prefer error summary when validation has failed and users need links to errors; it does not replace a final review of valid captured answers.
  • A review page must show only relevant captured answers, grouped under meaningful section headings, with skipped optional answers shown explicitly as not provided when that matters.
  • Each editable answer or section needs a Change link that returns to the owning question with values pre-populated, then returns users to review without repeating unrelated pages.
  • The submit button must state the committed action, such as Send claim, Pay now, or Change tax details, rather than generic Continue.
  • If a changed answer creates new required questions, ask those questions before returning to review and mark affected answers as needing review.
  • Do not use review before submit for a low-risk single field where inline validation and one clear submit action are enough.
  • Do not use a post-submit confirmation page as a review page; after commit, users need receipt, reference, and next steps, not pre-submit edit affordances.
Inspect live examples
Review before submitMulti-step formComplete complex formError summary
Failure modes
  • A final page says Review but contains only a generic warning and no captured answers to inspect.
  • Change links return users to an earlier page and then force them through the whole transaction again.
  • The submit button says Continue, so users do not realize the next action commits the transaction.
  • The page shows irrelevant skipped branches or hidden conditional answers, making users review information that does not apply.
  • The page appears after submission, so Change links imply edits are still possible when the data is already committed.
  • A changed answer does not invalidate dependent answers before final submit.

Saved items