Use a toast notification for brief non-blocking feedback; use error state for recoverable failures, undo for reversible completed actions, and treat toast-only critical errors as a failure of persistence and recovery.
Use a toast notification for brief non-blocking feedback; use error state for recoverable failures, undo for reversible completed actions, and treat toast-only critical errors as a failure of persistence and recovery.
Practice the judgment: Imagine this situation: A save success toast appears for every keystroke and overwhelms the page with repeated confirmations. 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 | Toast notification | Toast-only critical error | Error state | Undo |
|---|---|---|---|---|
| UI or UX | UI + UX - Transient non-modal status message | UI + UX - Transient critical-feedback anti-pattern | UI + UX - Recoverable failure surface | UX - Post-action recovery behavior |
| UI guidance | 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. | Replace a lone disappearing toast with a persistent failure region attached to the affected task, using a heading that names the failed payment, save, upload, permission, or destructive action. | Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions. | Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region. |
| UX guidance | Escalate to inline, section, dialog, notification center, undo, or error-state treatment when the message requires repair, proof, long reading time, several actions, or reliable recovery. | Protect users from losing the only explanation for a high-consequence failure by keeping the problem, affected object, and next action available after the notification times out. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. |
| Good UI | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. | A failed invoice payment leaves a persistent alert inside the invoice panel with Retry payment, Update card, and Contact billing actions. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button. |
| Bad UI | Five unrelated toasts pile up over the Save and Continue controls. | The user misses the only error message and repeats the failed action. | Tiny transient toast for a blocking failure. | Undo action disappears before users can activate it. |
| Good UX | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. | After the notification disappears, users can still see that the invoice is unpaid, why payment failed, and which recovery actions are available. | User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state. | Undo restores the deleted task to the list and reports Quarterly report restored. |
| Bad UX | Every autosave tick triggers a toast, training users to ignore real status changes. | Users have to guess whether the payment, save, delete, or upload succeeded after the toast timed out. | Clearing work after save failure. | The UI promises undo for a side effect that has already notified external recipients. |
| Best fit | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. | Use this anti-pattern entry to identify and replace transient-only handling of payment, save, permission, account, upload, deletion, and security failures. | A system or task failure blocks expected content or action. | The action is common and mistakes are likely. |
| Avoid when | The message is the only recovery path for a blocking or high-consequence failure. | A toast supplements a persistent error state, inline validation message, undo affordance, or notification center item that users can revisit. | Nothing exists yet and the state is expected. | Recovery would restore only part of the user's lost work. |
| Required state | Stacked state with newest and older messages ordered predictably and capped. | Pre-action state that shows what the user is attempting and what will be affected. | Normal expected state before failure. | Normal state before the user action. |
| Accessibility burden | Keep close and action controls keyboard reachable, clearly named, and stable while focused. | Place persistent error text and recovery controls in the reading order near the affected task. | Use appropriate alert or status semantics for newly appearing critical errors. | Make the undo control keyboard reachable and programmatically identifiable. |
| Common misuse | Using a toast as the only feedback for payment, save, permission, upload, or security failures. | Using a disappearing snackbar as the only feedback for failed save, failed delete, failed permission change, failed upload, or failed authentication. | Using a transient toast for critical errors. | Restoring only part of the prior state while implying full recovery. |