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

Prefer review before submit when answers have already been collected and the next action will send, apply, pay, publish, or otherwise commit the transaction.

Review before submit live example Multi-step form live example Complete complex form live example Error summary live example

Decision dimensions

Dimension	Review before submit	Multi-step form	Complete complex form	Error summary
UI or UX	UI + UX - Final editable answer summary before committing a transaction	UI + UX - Multi-page transaction with saved step state	UI + UX - Sectioned enterprise configuration form	UI + 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.	Help users recover from one or more submitted-form errors without scanning the entire page.
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	A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or change links.	A five-screen flow shows all steps as complete after users only viewed them.	A single grid shows Nm, Rule, Appr, Esc, Mail, JSON, Mode, and Owner fields with no labels, fieldsets, section status, or error ownership.	Red banner saying fix errors with no 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.	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 raises a spend threshold, validates the form, is moved to the Approvals section, adds a second approver and escalation owner, reviews the complete policy, and saves without re-entering earlier values.	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 user changes an early answer and the form silently submits later answers that no longer apply.	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.	A single local field issue can be corrected before submit without page-level orientation.
Required state	Initial review state with grouped captured answers, relevant sections, and explicit submit action.	Not-started state with clear start point and expectation of the steps or sections ahead.	Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.	Neutral form before submit with no summary.
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	Using a review page that contains no captured answers.	Using a multi-step form to hide a short related form that users should review on one page.	Calling a dense settings table a complex form without section status, labels, or validation ownership.	Showing a red banner or toast with no links to the invalid answers.

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: A final page says Check your answers but shows only a paragraph and a Continue button with no answers, section headings, or 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: Using a review page that contains no captured answers.

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.

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 single grid shows Nm, Rule, Appr, Esc, Mail, JSON, Mode, and Owner fields with no labels, fieldsets, section status, or error ownership.
Good UX: A user raises a spend threshold, validates the form, is moved to the Approvals section, adds a second approver and escalation owner, reviews the complete policy, and saves without re-entering earlier values.
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: Calling a dense settings table a complex form without section status, labels, or validation ownership.

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: Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI: Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI: Red banner saying fix errors with no links.
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: A single local field issue can be corrected before submit without page-level orientation.
Required state: Neutral form before submit with no summary.
Accessibility burden: Use a heading and alert behavior that makes the summary discoverable.
Common misuse: Showing a red banner or toast with no links to the invalid answers.

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 submit Multi-step form Complete complex form Error 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.