Toast notification

Problem Context

• A user action succeeds, is queued, or changes low-risk state while the user can keep working.
• A background process such as export, sync, upload, invitation, or archive needs short status feedback.
• The message can be understood quickly and does not need multiple controls, long instructions, or blocking recovery.
• The product has a plan for durable access when the message includes a job, receipt, audit event, undo action, or later result.

Selection Rules

• Choose a toast for short non-blocking confirmation, progress handoff, background-job status, or low-risk warning that does not require users to stop the current task.
• Use a persistent inline notification, error state, dialog, banner, or notification center when the message is critical, long, legally important, requires repair, or must remain available.
• Use undo only when the toast action can restore the exact prior state; otherwise label the action as View, Retry, Open jobs, or another truthful next step.
• Keep toast copy specific enough to name the object or process, such as Export started for April invoices, rather than Done or Success.
• Limit each toast to one primary action and move multi-step workflows into a page, panel, dialog, or notification center.
• Cap the visible stack and place newer messages consistently so users are not forced to manage a wall of notifications.
• Provide close behavior for visible toasts and respect reduced-motion or timing needs when animating entry and exit.
• Preserve important expired toast messages in history when users may need to reference or act on them later.

Required States

• Idle state with no visible toast and a reachable status or history region when applicable.
• New toast state that announces the message without stealing focus from the current task.
• Stacked state with newest and older messages ordered predictably and capped.
• Actionable toast state with one short action and enough persistence to activate it.
• Dismissed state after the user closes one toast.
• Expired state after time-based dismissal, with durable history for messages that remain relevant.
• Escalated state where critical or long feedback is routed to persistent UI instead of a toast.

Interaction Contract

• A toast appears because a specific action or system event occurred, not as the only visible structure for the task itself.
• The current page remains operable while the toast is visible.
• The toast does not move keyboard focus unless it contains an action that intentionally receives focus and remains available long enough to use.
• Users can dismiss a visible toast without losing the underlying task state.
• If a toast auto-dismisses, the product either makes the message safely disposable or stores it in a place users can revisit.
• New toasts do not overwrite earlier actionable or important messages without preserving their outcome.
• Critical failures, long instructions, and multi-step recovery are escalated out of the toast layer.

Implementation Checklist

• Classify each candidate message by consequence, required action, and whether users may need to revisit it.
• Use a single notification region per viewport and choose placement that does not cover navigation, form submits, chat input, or primary task controls.
• Write a short title or message that names the object, action, and result.
• Use role status for neutral or success updates and alert only for urgent warnings that still do not need persistent recovery.
• Keep an optional action short, object-scoped, and limited to one command.
• Set sensible duration rules by severity and action presence; actionable toasts should persist until dismissed or acted on.
• Queue or cap simultaneous messages, and send older important items to history instead of hiding them silently.
• Make close controls keyboard reachable and give them accessible names that include the toast subject.
• Test with keyboard, screen reader announcements, zoom, reduced motion, slow reading, and repeated background events.

Common Generated-UI Mistakes

• Using a toast as the only feedback for payment, save, permission, upload, or security failures.
• Showing repeated autosave confirmations so frequently that users ignore every status message.
• Packing long explanations, links, forms, or multiple buttons into a tiny transient surface.
• Stacking messages until they cover primary actions or content.
• Using vague copy such as Done, Failed, or Updated without naming the affected object.
• Auto-dismissing an Undo action before users can perceive and activate it.
• Moving focus to every toast and disrupting keyboard or screen reader workflows.

Critique Questions

• Is this message disposable after a few seconds, or does the user need to revisit it?
• What object, job, or action changed, and does the toast name it?
• Would losing the toast make the current state unsafe, ambiguous, unpaid, unsaved, or unrecoverable?
• Is one concise action enough, or does this need a persistent surface?
• Can keyboard and assistive technology users perceive, dismiss, and act on the toast without a timing trap?
• What happens when several events fire in a row?