Use a confirmation page as the final endpoint after a transaction; use success confirmation for durable proof inside an ongoing task, review before submit before commit, and notification banner for previous-page outcomes while the journey continues.
Use a confirmation page as the final endpoint after a transaction; use success confirmation for durable proof inside an ongoing task, review before submit before commit, and notification banner for previous-page outcomes while the journey continues.
Practice the judgment: Imagine this situation: A confirmation page still shows Change links from review, implying submitted answers can be edited directly. 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 →| Dimension | Confirmation page | Success confirmation | Review before submit | Notification banner |
|---|---|---|---|---|
| UI or UX | UI + UX - Final endpoint page after a transaction is complete | UI + UX - Durable in-context proof that an action completed | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Page-flow service notification before the H1 |
| UI guidance | Render a full page after commit with a prominent completion panel, a page heading that names what finished, a reference or receipt when users need one, and a clear section for what happens next. | Render success confirmation near the action result or affected object with a success label, object-specific message, reference or timestamp when useful, and one next step such as View receipt, Continue review, or Copy reference. | 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 one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content. |
| UX guidance | Use a confirmation page when the transaction or service journey has ended and users need durable proof, reassurance, next-step timing, or a record they can bookmark, print, quote, or revisit. | Use success confirmation when users need confidence that a just-finished action has really completed and can identify what changed before continuing. | 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. | Reserve the pattern for service-wide problems, personal deadlines or obligations elsewhere in the service, and outcomes from a previous page when the journey continues rather than ends. |
| Good UI | A grant application page says Application complete, shows reference APP-48291, lists what happens next within 5 working days, and offers Save record, Track application, and feedback links. | After evidence upload, a success panel beside the evidence checklist says Evidence uploaded, shows receipt EV-2048, timestamp, and View receipt. | 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 case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status. |
| Bad UI | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. | A file-upload receipt appears only in a disappearing toast even though the user must quote it later. | Change links lack context, so assistive technology users hear a list of identical Change links. | A success toast appears in the corner after redirect and disappears before the user can verify which evidence was uploaded. |
| Good UX | A user copies the reference, saves the receipt, follows Track application, and later returns from a bookmark to the same confirmation details or a helpful tracking fallback. | Users can copy the receipt reference, open the confirmed record, then see the success message collapse into normal completed state. | 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 lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey. |
| Bad UX | Users submit twice because refresh or Back replays the final action instead of returning to the receipt. | The UI says Saved before the network request finishes and later silently reverts the draft. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record. |
| Best fit | A transaction or service journey has ended and users need durable proof plus next-step information. | A user action has completed and users need proof, object identity, or next-step orientation. | A user has provided multiple answers and should verify them before a consequential submit action. | A service problem, deadline, overdue action, or elsewhere-in-service event affects the user's next interpretation of the page. |
| Avoid when | The user remains inside an ongoing task and only needs local proof near the changed object. | The success is obvious, low consequence, and safe to communicate as a brief toast. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The message is a submitted-form validation error or field correction. |
| Required state | Submitted state immediately after authoritative commit routes to the confirmation page. | Confirmed success state with object identity, reference or timestamp, and changed status. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Neutral Important state for service problem, deadline, overdue action, or elsewhere-in-service information. |
| Accessibility burden | Keep interactive controls out of low-contrast panel treatments unless focus and text contrast are explicitly verified. | Keep confirmation actions keyboard reachable and labelled with the affected object or reference. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice. |
| Common misuse | Showing a toast or local success strip as the only proof of a completed transaction. | Showing success before the operation is actually committed. | Labelling the final commit button Continue. | Using a notification banner for field validation errors instead of an error summary and field-level messages. |