| UI or UX | UI + UX - Durable in-context proof that an action completed | UI + UX - Transient non-modal status message | UI + UX - Page-flow service notification before the H1 | UI + UX - Urgent current-task status message |
| UI guidance | 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 toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action. | Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content. | Render an alert as a visible message in the current task area with a clear severity cue, short title, consequence-focused body, and one direct action or safe dismissal when appropriate. |
| UX guidance | Use success confirmation when users need confidence that a just-finished action has really completed and can identify what changed before continuing. | Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task. | Use notification banners sparingly for information users need before interpreting the page but that is not the main task content on that page. | Use alerts when the user must notice a time-sensitive condition that affects their current task, such as session expiry, lost connection, unsaved work risk, failed submission, or a security-sensitive hold. |
| Good UI | After evidence upload, a success panel beside the evidence checklist says Evidence uploaded, shows receipt EV-2048, timestamp, and View receipt. | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. | A case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status. | A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable. |
| Bad UI | A green strip says Done with no object, reference, or next step. | Five unrelated toasts pile up over the Save and Continue controls. | A validation error appears in a notification banner at the top of the page with no links to the invalid fields. | A vague red strip says Warning with no object, consequence, or next step. |
| Good UX | Users can copy the receipt reference, open the confirmed record, then see the success message collapse into normal completed state. | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. | A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey. | Users can renew the session, save a draft, or inspect details without losing typed work. |
| Bad UX | The UI says Saved before the network request finishes and later silently reverts the draft. | Every autosave tick triggers a toast, training users to ignore real status changes. | The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record. | The only warning that unsaved work will be lost disappears after five seconds. |
| Best fit | A user action has completed and users need proof, object identity, or next-step orientation. | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. | A message should be encountered before the page H1 but is not the page's main task content. | A current task has a time-sensitive warning, error, or important status change. |
| Avoid when | The success is obvious, low consequence, and safe to communicate as a brief toast. | The message is the only recovery path for a blocking or high-consequence failure. | The message is a submitted-form validation error or field correction. | The message belongs beside one object, row, field, or local section. |
| Required state | Pre-action state with no success confirmation. | Idle state with no visible toast and a reachable status or history region when applicable. | No-banner state when no service-context notice or previous-page outcome applies. | No-alert state with the task operating normally. |
| Accessibility burden | Expose dynamic success as a status message or equivalent so assistive technologies can announce it without moving focus unnecessarily. | Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement. | Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice. | Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself. |
| Common misuse | Showing success before the operation is actually committed. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Using a notification banner for field validation errors instead of an error summary and field-level messages. | Using a disappearing toast for warnings users must act on before continuing. |