Toasts are bad UX
Developers and UX practitioners are questioning the widespread use of “toasts” – small, temporary popup notifications – as a way to provide user feedback. Critics argue that toasts are often misplaced, too brief, inaccessible, and redundant when better inline or contextual cues could convey success, errors, or undo options more clearly, especially on large screens or for disabled users. Others counter that, when reserved for asynchronous or off-screen events and paired with persistent logs or inline indicators, toasts remain a valuable, consistent pattern—highlighting that good or bad outcomes depend more on implementation and context than on the component itself.
Scope of the Debate
- Most agree the YouTube/Gmail examples are poor, but they disagree whether “toasts are bad UX” in general or just often misused.
- Some see toasts as a useful standard pattern; others consider them a crutch for weak state management and lazy design.
When Toasts Are Considered Appropriate
- For events unrelated to the current UI region: background jobs, server-side async work, long-running imports, hardware events, off-screen changes.
- As a non-blocking alternative to modal dialogs for “not critical but useful” information.
- As a complement to inline feedback, not the only feedback.
- In mobile UIs where screens are small and the toast is usually within the visual field.
Common Criticisms
- Distance from interaction: on large/wide screens, notifications can appear far from where the user is looking, so they’re missed or distracting.
- Ephemerality: auto-hiding messages are hard to read in time, impossible to re-check, and bad for accessibility; users feel they’re “racing a clock.”
- Obstruction: many implementations cover controls or content, sometimes grabbing focus or mouse events.
- Overuse and spam: constant “success” toasts train users to ignore them, so important messages get lost (alarm fatigue / banner blindness).
Accessibility & Neurodiversity
- People using screen magnifiers or with limited visual fields often never see toasts.
- Timed toasts conflict with accessibility guidelines unless configurable or backed by another persistent channel (e.g., log, ARIA live regions).
- ND users describe peripheral popups as strong, unwanted context switches.
Alternatives & Improvements
- Inline indicators near the control: spinners that become checkmarks or errors; disabled controls while processing.
- Local confirmations that replace or appear adjacent to deleted/changed items.
- Persistent status bars, notification trays, or action logs with history and timestamps.
- “Undo” buttons are widely valued, but many argue they should be persistent and discoverable, not buried in a vanishing toast.
Pragmatic / Engineering View
- Toasts are attractive because a single global mechanism centralizes error/success handling and reduces per-component code.
- Several argue that this is optimizing for developer time over user experience, but note most teams are resource-constrained.