Auto-dismissing toasts cannot carry must-read information
Aliases: snackbar · transient toast · lightweight notice
What it is
A toast is a short, non-focus-stealing status message, usually anchored at a screen edge, that the system dismisses on a timer. What separates it from a banner or a dialog is not tone of voice but who ends the reading: a toast closes itself; the reader is never asked to confirm “I saw that.” It therefore fits only information whose absence would not change the next move—“Saved,” “Copied,” “Added to favorites.” Passwords, permission changes, irreversible failures, and validation that must be fixed now do not belong on a toast. Putting must-read content there hands a critical fact to a race against attention.
Why it happens
While someone is in a primary task, a brief edge message first lands in peripheral vision. Understanding it requires a gaze shift; if that shift happens after the message is gone, nothing entered working memory. A toast also has no stable layout slot, so there is no place to re-read. Recall depends on that one glance. The test for must-read is whether missing it would send the next action the wrong way. Missing “copied” at worst means pasting again. Missing a submit failure lets someone leave believing the work succeeded. Auto-dismiss splits “the system considers this delivered” from “the person actually read it,” and the second often fails.
Studying it
Dual-task setups measure miss rates: the primary task is filling a form or scanning a list; the secondary is later reporting what the notice said and meant.
Independent variables: whether the message requires a follow-up action, whether it appears during typing, toast position (top / bottom / near the control), visual load of the primary task. Dependent variables: detection, content recall, and whether the next step contradicts the message (for example closing the page after a failure).
Laboratory participants who know “a notice will appear” over-detect. A closer product test embeds the toast in a real submit flow and asks “did the save succeed?” rather than “did you see a toast?” Seeing and understanding are not the same measurement.
Where it stops holding
If the same outcome leaves durable evidence elsewhere—a new list row, a button that now reads “Saved,” a mark beside the field—the toast is redundant and a miss is cheap. An undo toast looks must-read, but if history or a trash can still recovers the object, transience is acceptable; it becomes must-read only when undo lives solely on the toast, which is then the wrong surface. Full-screen magnification or speech output may not reach an edge message before the timer fires. On a second display or a mirrored meeting screen, the toast may appear where the user is not looking.
Applying it
- Grade every message by whether missing it changes the next step: confirmations may toast; must-read content belongs beside the field, in an in-page banner, or in a dialog that requires a response.
- Do not put information that cannot be found again on a toast: one-time codes, the full cause of an error, a permission that was withdrawn.
- Keep submit failures, unfinished payments, and overwrite conflicts next to the object until the user handles them or explicitly dismisses.
- Verify by running the main flow with toasts disabled. If the next step would then be wrong, that message should not have been a toast.