In a design system's feedback components, when should a message be a toast, a banner or an inline alert?
answer
- how long does it matter
- where is the cause
- confirm your own action briefly
- a state of the whole service
- nothing critical in a toast
basics
~20 sA toast briefly confirms a low-stakes result of the user's own action; a banner states a condition affecting the whole screen or account and stays until resolved; an inline alert sits next to the content it concerns.
solid answer
~50 sThe choice turns on **scope** and **lifetime**. A **toast** is a brief, non-blocking confirmation of something the user just did — 'Added to My List' — that is safe to miss, so it never carries critical information or the only way to act. A **banner** sits at the top of the screen or app and describes a condition that affects everything there — 'Your payment failed; update your card to keep watching' — and it stays until the condition is resolved or the user dismisses it. An **inline alert** sits beside the thing it is about — '4K is not available on this device' under a quality setting — and lives as long as that content does. Interruptive messages that need a decision belong in a dialog, and form errors belong to the form's own pattern.
go deeper
Recall the three components by scope and lifetime: toast for a brief confirmation, banner for a standing condition, inline alert beside its cause.
Explain why a toast must be safe to miss and never the only path to an action, and when a banner should return after dismissal.
Show you can move misplaced messages to the right component across a product, starting with anything critical that currently lives in a toast.
Decide how the system governs which teams may raise banners, since one shared top-of-screen slot is contested by every product area.
## Three components, one question Every feedback message answers two questions: **what does it concern** (one action, one piece of content, or the whole screen or account) and **how long does it matter** (a moment, or until something changes). The three standard components map onto those answers. | Component | Concerns | Lifetime | Position | Example on a streaming service | |---|---|---|---|---| | **Toast** | A result of the user's own recent action | Seconds; dismisses itself or on demand | Floating, consistent screen position | 'Added to My List' | | **Banner** | A condition affecting the whole screen, account or service | Until resolved; dismissible unless it states a condition that still applies | Top of the screen or app shell | 'Payment failed — update your card to keep watching' | | **Inline alert** | One section, item or setting | As long as that content is shown | Next to the content it concerns | '4K is not available on this device' under playback quality | ## The toast: brief and safe to miss A **toast** (often called a snackbar) confirms that something happened. Its defining trait is that it goes away, which is also its limit: - It is **non-blocking** and never takes focus, so it does not interrupt what the user is doing. - It is **safe to miss**: users who look away, who read slowly, who use a magnifier or who are watching a film may never see it. - Therefore it never carries **critical information**, and never the **only** path to an action. An 'Undo' in a toast is fine when the same action exists elsewhere. - It confirms the user's own action; system-initiated news the user must act on is usually not a toast. ## The banner: a standing condition A **banner** describes a state that persists: a failed payment, a service disruption in the user's region, an expiring free trial, the app being offline. It stays visible across the screens it affects and disappears when the condition does. A banner that the user may dismiss should not return every time the screen loads unless the condition has changed; a banner about something the user must fix — the failed payment — stays until it is fixed. ## The inline alert: next to its cause An **inline alert** is attached to one piece of content. Because it sits beside its cause, it needs no explanation of where the problem is. It is the right choice when only part of the screen is affected: a title unavailable in the viewer's region, a download that failed on one episode, a subtitle track that could not load. Form validation messages are a specialised case owned by the form pattern. ## A decision list for the spec 1. Does the user need to decide something before continuing? Not this family — use a dialog. 2. Does the message concern one item or section? Use an **inline alert** beside it. 3. Does it describe a condition of the whole screen, account or service that lasts? Use a **banner**. 4. Is it a brief confirmation of the user's own action that is safe to miss? Use a **toast**. 5. If you are unsure whether it is safe to miss, it is not — choose a banner or inline alert. ## The same rules on TV and web A **video-streaming service** shows this family on both a web player and a television app. On the web, a toast appears in a corner while the user browses. On a television, viewed from across the room and driven by a remote's directional pad, text must be larger, messages must stay clear of the area where subtitles and playback controls appear, and focus cannot easily reach a floating toast without pulling it away from playback — one more reason a toast there must be safe to ignore. The categories do not change between platforms; their sizing, placement and timing do. ## Common mistakes - A failed payment shown as a toast that vanishes while the user is watching. - A banner used for 'Saved' confirmations, so the top of the screen fills with stale news. - An inline alert placed far from its cause, so users cannot tell what it refers to. - Colour as the only difference between an informational and an error message.
- Can a toast carry an action such as 'Undo'?Yes, if the action is a convenience and the same result is reachable elsewhere, for example removing the title from My List again. A toast must not be the only way to act, because it disappears and may never be seen or reached by keyboard, remote or screen-reader users in time.
- When should a dismissed banner come back?When the condition it describes changes or recurs, not on every screen load. A dismissed trial-ending notice may return near the deadline; a failed-payment banner should not be dismissible at all until the card is updated, because it describes a problem the user must fix.
saying these in an interview costs you the question
- A toast is fine for a failed payment because users see it immediately.
- Banners are just bigger toasts and can confirm every save.
- Anything important should be a toast so it does not clutter the screen.
- An inline alert can sit anywhere on the screen as long as it is red.
- A toast should move focus to itself so screen-reader users hear it.