UI Design · Systems
Toasts, Banners and Alerts: Designing a Notification System With Rules
Most apps grow their notification surfaces one ad-hoc component at a time. The result is four different ways to say the same thing, chosen by whoever built the feature that week.
Four surfaces, one recurring question: which one now?
Toasts, banners, inline field alerts and modals all interrupt the user to say something. Without a rule for which surface handles which situation, teams default to whichever component is easiest to import, and the app ends up training users to ignore all of them equally.
The fix isn't a better toast component. It's a decision table: severity and persistence determine the surface, not habit or convenience.
Matching surface to severity
Toast: confirms, doesn't block
For success confirmations on actions the user just took — "Saved," "Invite sent." Auto-dismisses, never requires a response, never carries anything the user must act on.
Inline alert: lives with the context
Field-level or section-level problems belong next to what caused them, not floating at a screen edge disconnected from the thing that's wrong.
Banner: persistent, page-level state
"You're viewing a read-only snapshot," "Trial ends in 3 days" — conditions that are true for the whole session, not a one-off event. Stays until the condition changes, not on a timer.
Modal: requires a decision
Reserved for the smallest possible set: destructive confirmations and blocking errors that make continuing pointless. Every other case that reaches for a modal is usually a banner or inline alert in disguise.
Never stack more than one toast
Queue them and show one at a time, or collapse into a counter ("3 items updated"). A stack of toasts sliding in over each other is unreadable and looks like a bug.
Severity gets a consistent color and icon
Success, warning, error and neutral info each get one color mapped through the same token used everywhere else in the product — never a one-off shade picked for this component alone.
Errors don't auto-dismiss
A success toast can vanish after a few seconds because there's nothing left to do. An error toast that vanishes the same way can disappear before the user has read it, taking the only explanation of what went wrong with it. Errors stay until dismissed, or move to a surface — inline, banner — that doesn't have a timer at all.
The takeaway
Toast for confirmation, inline for field-level context, banner for persistent state, modal only for decisions that block progress. Pick the surface by severity and persistence, not convenience — and reserve auto-dismiss for messages that genuinely need no response.
Let's talk about your product