A video-streaming app on TV and web fires toasts for downloads, profile changes and a failed payment at once; how should the design system stack, queue or escalate them?
answer
- one region, a visible limit
- queue, then collapse duplicates
- timers start when shown
- critical escapes the toast
- keep clear of playback
basics
~20 sRoute every toast through one region with a small visible limit, queue the rest and collapse duplicates, start each timer only when shown, and escalate the failed payment out of toasts into a persistent banner.
solid answer
~40 sFirst, **escalate**: a failed payment is critical and lasting, so it is not a toast at all but a **banner** that stays until the card is updated. The rest go through **one toast region** per screen, owned by a single manager rather than each feature, with a small **visible limit** — often one on television, a few on the web. Extra toasts **queue** in order, with a priority so an error-level toast is not stuck behind five confirmations, and **duplicates collapse** — 'Three episodes downloaded' instead of three toasts. Each toast's timer starts when it becomes visible, announcements are queued the same way so a screen reader is not flooded, and the region stays clear of subtitles and playback controls.
go deeper
Recall that toasts share one region with a visible limit and that critical messages never go in a toast.
Explain queue order, priority, collapsing duplicates and why each timer starts only when its toast is shown.
Diagnose a burst problem from logs and screen-reader testing, then move stray feature toasts onto the shared manager and escalate critical ones.
Decide how the system arbitrates the shared feedback surfaces between product areas, and which toasts are deferred during playback.
## The failure this prevents When every feature raises toasts independently, bursts happen: a season finishes downloading, a profile setting syncs, a payment fails — at the same second. Without rules, toasts overlap, cover the player's controls, vanish before anyone reads them, and a screen reader reads five messages in a row, the important one lost in the middle. **Stacking and queueing** rules turn that burst into something a person can follow. ## Step one: escalate what is not a toast Before stacking anything, check that each message belongs in a toast. A **toast** is a brief, safe-to-miss confirmation. The failed payment is neither brief in consequence nor safe to miss: it becomes a **banner** at the top of the app, stays until the card is updated, and is announced assertively once. Only the remaining, low-stakes messages enter the toast queue. ## Step two: one region, one manager - The design system provides **one toast region** per screen, in a consistent position, and **one manager** that every feature calls. Features request a toast; they never draw their own. - The manager enforces a **visible limit**: commonly one toast at a time on a television, a small number on the web. - New toasts appear in a consistent order — for example, newest nearest the edge — so the stack does not reshuffle under the user's eyes. ## Step three: queue with priority and collapsing 1. Toasts beyond the visible limit wait in a **queue**, first in, first out. 2. A **priority** lets an error-level toast jump ahead of routine confirmations, so it is not delayed behind them. 3. **Duplicates collapse**: identical or same-kind messages merge into one with a count — 'Three episodes downloaded' — instead of three. 4. **Stale toasts drop**: a queued 'Downloading…' toast is discarded if 'Download complete' arrives before it is shown. 5. Each toast's **timer starts when it becomes visible**, not when it was requested, so queued messages are not silently expired. ## Step four: queue the announcements too What a screen reader hears must follow the same discipline. Announcements come from the manager in the same order as the visible toasts, politely for routine messages, and collapsed messages are announced once with their count. A burst of five polite announcements is still a burst; the collapsing rule is what keeps it short. ## Television versus web | Concern | Web player | Television app | |---|---|---| | Visible limit | A few toasts stacked | Usually one at a time | | Placement | Corner away from the player controls | Inside the screen's safe area, clear of subtitles and the playback bar | | Actions in toasts | Allowed, reachable by keyboard | Avoided; focus stays with playback | | Duration | Reading-time convention | Longer, read from across the room | | During full-screen playback | Toasts may be deferred or minimised | Non-urgent toasts deferred until playback pauses | Deferring non-urgent toasts during full-screen playback is a product choice worth writing into the spec: a 'Profile updated' message over the climax of a film helps nobody. ## Diagnosing an existing burst problem - Log every toast request with its source, severity and time for a week, and find the bursts. - Look for **features drawing their own toasts** outside the manager — the usual cause of overlap. - Look for **critical messages in toasts**; each is a bug to escalate. - Test with a screen reader during a burst and count what is heard. ## What the spec should contain - One region and one manager per screen, and a rule that features never draw toasts themselves. - Visible limits per platform, queue order, priority rules and the collapsing rule. - The escalation rule: anything critical or lasting is a banner or inline alert, never a toast. - Placement rules that keep toasts clear of playback controls and subtitles. - Deferral rules for full-screen playback, stating which severities may still appear. ## Why this is a system concern, not a feature concern No single feature team can solve a burst, because each sees only its own messages. The download team's toast is reasonable, the profile team's toast is reasonable, and together with the payment message they overwhelm the viewer. Only a shared component with a shared queue sees the whole picture, which is why stacking and queueing rules belong in the design system's feedback specification and its toast manager, and why a review of a new feature asks which messages it raises and at what severity.
- Should an error-level toast replace the toast currently on screen, or wait its turn?Jump the queue but do not yank the current toast mid-read: let it finish or shorten its remaining time, then show the error next. If the error truly cannot wait, it probably is not a toast — escalate it to an inline alert or banner where it can persist.
- Why must features call a shared toast manager instead of rendering toasts themselves?Limits, queueing, collapsing, placement and announcement order only work if one place sees every request. A feature that draws its own toast bypasses all of them and is the usual cause of overlapping toasts and flooded screen readers.
saying these in an interview costs you the question
- Showing every toast at once is fine because each disappears on its own.
- A failed payment can be a toast if its colour is red enough.
- Each feature should render its own toasts in its own corner.
- Queued toasts can start their timers when requested, to keep the queue short.
- Screen-reader announcements need no queueing because they are polite.