Review before submit

Problem Context

• The user has answered several questions across one or more pages and the next action has legal, financial, account, eligibility, publication, payment, or service-routing consequences.
• Users may need to spot typos, wrong addresses, stale evidence, skipped optional answers, or conditional answers that no longer apply.
• The product can pre-populate previous answer pages and preserve state while users move between review and editing.
• A later confirmation page will provide receipt, reference number, next steps, or status after the irreversible or high-friction action is complete.

Selection Rules

• Choose review before submit when users need to verify multiple captured answers immediately before committing a transaction.
• Use multi-step form for collecting and saving the answers that lead to review, not as a substitute for the final check gate.
• Use complete complex form when users are actively editing many related settings on one surface and need review before save inside that editor.
• Use error summary when the user needs to recover from validation errors, not when all valid answers need a final confirmation before submit.
• Use confirmation page only after submit, when the task should show receipt, reference number, and next steps instead of pre-submit Change links.
• Group answers into sections that match the journey or user mental model, and omit irrelevant conditional branches.
• Show skipped optional answers as Not provided when the absence itself needs review or can affect the outcome.
• Use Change links for individual answers or coherent sections; each link must return users to the correct answer with previous values pre-filled.
• After a changed answer creates new required questions or invalidates downstream answers, resolve that dependency before returning to review.
• Use a submit button label that states the action and consequence, not generic Continue.

Required States

• Initial review state with grouped captured answers, relevant sections, and explicit submit action.
• Answer changed state where the user returns to the owning question with the old value pre-populated.
• Return-to-review state after a changed answer saves without repeating unrelated pages.
• Skipped optional answer state shown as Not provided when meaningful.
• Stale dependent answer state after an upstream change invalidates a downstream answer.
• New dependent question state before returning to review when a change requires extra information.
• Validation blocking state when review cannot submit because a required answer is missing or stale.
• Submit-ready state after all shown answers are current and required declarations are satisfied.
• Submitted handoff state that routes to a confirmation page rather than keeping pre-submit Change links active.

Interaction Contract

• Review loads only after required upstream answers are saved or clearly marks missing required sections.
• Each Change action stores return context so saving the edited answer returns to review, not the next ordinary journey page.
• Edited pages show previous values exactly as last saved unless the answer was invalidated by a dependency rule.
• Changing an upstream answer recomputes later relevance and marks affected answers stale, removed, or newly required before submit.
• The review page excludes branches that do not apply, unless showing Not provided helps users verify an optional skipped answer.
• The primary action commits the transaction only after current answers, stale dependencies, and required declarations pass.
• After commit, the user lands on a confirmation page with receipt and next steps; review Change links are no longer the main recovery path.

Implementation Checklist

• Inventory every answer, section heading, display label, stored value, edit route, dependency rule, optional-answer display rule, and final submit consequence.
• Build summary rows from canonical saved answers rather than reformatting ad hoc page text.
• Add Change links with specific accessible text and return-to-review context for each row or section.
• Pre-populate edit pages from saved data and preserve all unrelated answers after edit, validation, browser Back, and server errors.
• Recompute conditional branches after every changed answer and ask newly required questions before returning to review.
• Mark stale sections clearly and block submit until the affected answers are reviewed or corrected.
• Use final action copy that names the consequence, such as Send application, Pay now, Publish listing, or Update account.
• Route successful submit to a confirmation page with reference, receipt, status, or next steps.
• Test keyboard order, screen reader context for repeated Change links, mobile summary wrapping, long addresses, hidden conditional answers, skipped optional answers, browser Back, edit return, stale answers, and double-submit prevention.

Common Generated-UI Mistakes

• Using a review page that contains no captured answers.
• Labelling the final commit button Continue.
• Sending users through every later page after they change one answer.
• Showing irrelevant conditional sections that the user never answered.
• Hiding skipped optional answers even when Not provided affects the outcome.
• Keeping stale downstream answers after an upstream answer changes.
• Putting repeated Change links in a table without accessible context.
• Treating a post-submit confirmation page as if it were the review step.

Critique Questions

• What exactly changes in the system when the user presses the final button?
• Can users see every relevant answer and tell which section each answer belongs to?
• Does each Change link return to the owning question with the current answer pre-populated?
• After saving a changed answer, does the service return to review without repeating unrelated pages?
• Which downstream answers become stale or irrelevant after each possible change?
• Does the page clearly separate pre-submit review from post-submit confirmation?