Use a banner for product, service, account, or section-level information that belongs at the top of a broader interface; use alert for urgent current-task status, inline message for object-local context, and toast for short disposable feedback.
Use a banner for product, service, account, or section-level information that belongs at the top of a broader interface; use alert for urgent current-task status, inline message for object-local context, and toast for short disposable feedback.
Practice the judgment: Imagine this situation: Three product banners stack above the page heading and push the task out of view. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Banner | Alert | Inline message | Toast notification |
|---|---|---|---|---|
| UI or UX | UI + UX - Top-of-interface broad-scope message | UI + UX - Urgent current-task status message | UI + UX - Contextual in-flow feedback | UI + UX - Transient non-modal status message |
| UI guidance | Render the banner at the top of the interface or content area it governs, below required global chrome and before the page content that should be interpreted with that message. | Render an alert as a visible message in the current task area with a clear severity cue, short title, consequence-focused body, and one direct action or safe dismissal when appropriate. | Render the message inside the same row, card, panel, form section, or task region that it describes, with a clear tone, concise title, body text, and at most one local action or detail disclosure. | Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action. |
| UX guidance | Use banners when users need broad context before continuing across several pages or sections, such as maintenance, service delay, account setup, rollout, policy, or official-site identity information. | Use alerts when the user must notice a time-sensitive condition that affects their current task, such as session expiry, lost connection, unsaved work risk, failed submission, or a security-sensitive hold. | Use inline messages when users need contextual feedback while continuing nearby work, such as a row-level warning, section-level success, local policy note, or task-specific next step. | Escalate to inline, section, dialog, notification center, undo, or error-state treatment when the message requires repair, proof, long reading time, several actions, or reliable recovery. |
| Good UI | A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe. | A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable. | An invoice row shows Missing billing contact directly beneath the affected customer with Add contact as the only action. | Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history. |
| Bad UI | Three unrelated banners stack above the page heading and push the account task below the fold. | Users miss an urgent condition because the message auto-expires or appears far from the affected task. | A section message contains a full support workflow, several links, and unrelated settings controls. | Five unrelated toasts pile up over the Save and Continue controls. |
| Good UX | A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace. | When the connection returns, the alert downgrades to a success status and then can be dismissed safely. | A successful send message remains beside the invoice long enough to copy the generated reference. | A completed archive action shows a short toast and a specific Undo action because the prior state can be restored. |
| Bad UX | A field validation error appears in a banner, forcing users to hunt for the failing input. | The only warning that unsaved work will be lost disappears after five seconds. | The message disappears like a toast even though users still need the invoice reference. | Every autosave tick triggers a toast, training users to ignore real status changes. |
| Best fit | The message applies across several pages, routes, sections, records, or sessions. | A current task has a time-sensitive warning, error, or important status change. | A visible object or section has local status, warning, success, or next-step information. | Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export. |
| Avoid when | The message affects only one field, object, row, panel, or local task section. | The message belongs beside one object, row, field, or local section. | The message is a one-field validation correction. | The message is the only recovery path for a blocking or high-consequence failure. |
| Required state | Informational product or service banner at the top of the related interface. | Advisory or success state that uses calmer status semantics rather than assertive alert semantics. | Informational inline message attached to the relevant object or section. | Stacked state with newest and older messages ordered predictably and capped. |
| Accessibility burden | Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to. | Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself. | Keep the message in the reading order near the context it describes. | Keep close and action controls keyboard reachable, clearly named, and stable while focused. |
| Common misuse | Using a banner for one field error, one row warning, or one card status. | Using a disappearing toast for warnings users must act on before continuing. | Using an inline message for a single field error that should be connected to that input. | Using a toast as the only feedback for payment, save, permission, upload, or security failures. |