pattern-library checked
Carbon Design System Notification
Documents inline, toast, actionable, and modal notifications, including guidance for actionable messages, long messages, and notification placement relative to page content.
Pattern Decisions This Source Supports
| Pattern | Supported decision | Required contract | Claim note |
|---|---|---|---|
| Alert | Choose alert when a time-sensitive warning, error, or important status change must be noticed immediately without moving focus. | The alert appears close to the task area whose outcome it affects and before the controls users need next. | Carbon distinguishes notification types by placement, duration, interaction, and whether a message should persist or escalate. |
| Error state | Choose error state when expected content or task progress is blocked by system, network, permission, validation, save, sync, or computation failure. | The error remains visible until resolved, intentionally dismissed, replaced by recovered content, or escalated. | Carbon documents inline, actionable, toast, and modal notification treatment, including when messages need actions or more detail. |
| Inline message | Choose inline message when the message's subject is a visible local object or section and the feedback should stay attached to it. | The message appears in the visual and reading order near the object or section it describes. | Carbon describes inline notifications as task-flow messages, positioned near primary content, with persistence until dismissal or resolution. |
| Notification banner | Choose notification banner when a service message should be seen immediately before the page heading and before users interpret that page. | The banner appears before the page H1 and in the same content width as the heading and body text. | Carbon notification usage distinguishes inline, toast, actionable, banner, panel, and modal notifications by placement, duration, and interaction burden. |
| Notification center | Choose notification center when messages must be revisitable after toast, push, email, or inline surfaces have disappeared. | The entry point opens the notification center without navigating away from the current task unless the product uses a dedicated full page. | Carbon notification usage recommends notification centers when users need to revisit and act on past notifications after transient notifications disappear. |
| Success confirmation | Choose success confirmation when the user needs durable in-context proof that a just-completed action succeeded. | The confirmation appears only after the action is committed enough to be truthful. | Carbon defines success notification status as confirmation that a task completed as expected and distinguishes inline, toast, actionable, and callout variants. |
| Toast notification | Choose a toast for short non-blocking confirmation, progress handoff, background-job status, or low-risk warning that does not require users to stop the current task. | A toast appears because a specific action or system event occurred, not as the only visible structure for the task itself. | Carbon documents toast notification timing, concise content, stacking, dismissal, actionable variants, and alternate access when users need more time. |
| Toast-only critical error | Flag this anti-pattern when a failure blocks progress, affects money or data, changes account or security state, or requires a repair action after the message appears. | The critical error remains visible until it is resolved, intentionally dismissed from a safe persistent surface, replaced by a recovered state, or escalated. | Carbon distinguishes inline, toast, actionable, and callout notifications; toast messages can auto-dismiss, while critical action or longer recovery needs persistent or actionable treatment. |
| Toast-only success for completed transaction | Flag this anti-pattern when a committed or high-consequence transaction is confirmed only by a disappearing toast. | The completed transaction remains provable after the toast expires. | Supports distinguishing transient toast notifications from persistent or actionable notification variants. |
Evidence Role
This source is treated as pattern-library evidence. Use it to validate the decision rules above, not as a visual style reference.
Publisher: IBM Carbon Design System. Last checked: .