| 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. | Use notification banners sparingly for information users need before interpreting the page but that is not the main task content on that page. |
| 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 | A submitted application only redirects to a dashboard toast that says Done, with no reference, receipt, or next-step details. | A green strip says Done with no object, reference, or next step. | 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 validation error appears in a notification banner at the top of the page with no links to the invalid fields. |
| 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 | A user closes the page after seeing a transient message and later cannot prove the payment or application happened. | 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 message should be encountered before the page H1 but is not the page's main task content. |
| 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. | Pre-action state with no success confirmation. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | No-banner state when no service-context notice or previous-page outcome applies. |
| Accessibility burden | Use one clear page H1 or panel title that communicates completion without relying on green color alone. | Expose dynamic success as a status message or equivalent so assistive technologies can announce it without moving focus unnecessarily. | 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. | Using a review page that contains no captured answers. | Using a notification banner for field validation errors instead of an error summary and field-level messages. |