Toasts are bad UX

Original Article ↗ Hacker News Discussion ↗

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.