Notification & Toast Design

The plain-language idea

There are three common ways to tell a user something happened, and they earn different placement and duration based on how important and how actionable the message is:

• Toast — a small, transient message that floats above the content and auto-dismisses after a few seconds. Right for a low-stakes confirmation of something that already finished ("Copied to clipboard"), where the user doesn't need to act on it.
• Banner — persistent until dismissed or the underlying condition resolves, usually anchored at the top of the page or a section. Right for something ongoing that the user should stay aware of ("You're offline," "Your trial ends in 3 days").
• Inline notification — attached directly to the specific thing it's about, like a validation error under the form field that caused it. The most contextual of the three, and the right choice whenever the message concerns one specific element already on screen.

See it in a real thing: a toast queue that treats actionable messages differently

type Toast = { id: string; message: string; kind: "info" | "error"; durationMs?: number };

function pushToast(toast: Toast) {
  queue.push({
    ...toast,
    // errors and anything requiring a decision get no durationMs — they stay until the user
    // dismisses them. Only low-stakes confirmations auto-dismiss.
    durationMs: toast.kind === "error" ? undefined : 4000,
  });
}

An auto-dismissing toast is the wrong pattern for anything that needs the user to act — "Item deleted. Undo?" that vanishes after four seconds is a race the user can lose. If they're not looking at that exact moment, or need a second longer to read and decide, the option to undo is just gone, with no way back. Anything with a real decision attached (undo, retry, an error requiring acknowledgment) shouldn't have a timer at all; it should sit until the user dismisses it.

What people usually miss

Watch out

• Auto-dismiss is wrong for anything needing a decision, not just "undo." The same reasoning applies to any toast offering an action — retry, view details, confirm — the timer working against the user is the problem, regardless of which specific action is at stake.
• Toast, banner, and inline aren't interchangeable by importance alone — placement matters too. A banner sits at a fixed page/section position because the condition it describes is ongoing; a toast floats and moves because it's transient by nature. Using a toast for a persistent condition like "you're offline" means the message disappears while the condition hasn't.
• Stacking many toasts at once is a real, common failure mode, not a hypothetical — any bulk or rapid-fire action can trigger it, and the fix is collapsing or queueing, not just letting the UI stack indefinitely.
• A toast still needs to be announced to screen reader users (via aria-live), independent of its dismiss timing — getting the auto-dismiss decision right doesn't automatically make the toast accessible; that's a separate requirement.

Why this matters in interviews

"A user says a toast disappeared before they could hit undo" is a real, common bug report, and the strong answer isn't "make the timer longer" — it's recognizing that anything requiring a decision shouldn't auto-dismiss at all, and naming the difference between a toast, a banner, and an inline notification as three genuinely different tools, not three names for the same thing.