Toast notifications without the spam

Toasts are the easiest notification pattern to over-use. Every successful action gets a toast. Every save. Every minor side effect. By the end of a session the user has dismissed thirty of them and started ignoring everything in the corner of the screen.

A good toast policy is mostly about restraint. Here's the framework.

When to toast

• Async actions the user might not see complete. "Export started", "Invite sent." The user kicked something off and walked away mentally; the toast is the confirmation.
• Side effects of an action. "Pinned to top." "Removed from board." Confirms a small action whose result isn't visible in the current viewport.
• Soft errors with a recovery path. "Couldn't save, retry?" The toast becomes interactive.

When not to toast

• Synchronous actions whose result is visible. If the user clicked delete and the row disappears, you don't need a toast saying "deleted." The disappearance is the toast.
• Anything destructive or critical. If the user needs to know about it, it needs more weight than a 4-second corner notification. Use a banner or a modal.
• System-level events that didn't come from a user action. "New version available" doesn't belong in a toast. It belongs in a top banner or a soft prompt the user can engage with on their own time.

The three placement rules

1. 01Bottom-right or top-right, not center. Center toasts feel like modals and break flow.
2. 02Stack down, not up. New toasts appear below the previous; older ones expire from the top. Visitors track time as down-the-page; reversing that confuses them.
3. 03Maximum three visible at once. Past three, you have a notification center problem, not a toast problem. Collapse older toasts into a tray.

Timing

Default to 4 seconds. Errors get 6. Toasts with an action button get 8, the user needs time to read and decide. Critical messages should not be timed at all; they stay until dismissed, or they're not actually a toast.

Banners and inline notices

Banners are persistent, they live at the top of the page until dismissed. Use them for system status, account warnings, and version notices. Inline notices are contextual, they sit next to the thing they describe. Use them for form-level validation and per-section warnings.

Build one

The toast-stack, banner-alert, and inline-notice entries have the anatomy and tuned prompts. Choose one pattern per notification class, don't mix toasts and banners for the same kind of message.