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.
What this source can teach
Use this source to compare a documented solution with the task and states in your own product.
- Start with the original. Open the source and find the guidance or example relevant to your task.
- Trace the connection. Use the claim notes below to see how this site applies the source to specific patterns.
- Check the setting. Compare the source's platform, people, and constraints with your own decision.
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. |
Comparisons supported by this source
- Alert vs inline message vs toast notification vs confirmation dialog
Carbon distinguishes inline, toast, actionable, callout, banner, notification panel, and modal notification surfaces by placement, duration, and interaction.
- Empty state vs no-results recovery vs error state
Carbon distinguishes inline, toast, actionable, and modal notification treatments for messages near affected content.
- Inline message vs toast notification vs error state vs inline validation
Carbon distinguishes inline notifications from toast and modal variants and places inline notifications in task flows near related content.
- Notification center vs toast notification vs alert vs inline message
Carbon notification usage recommends a notification center when users need to revisit and act on notifications after transient surfaces disappear.
- Success confirmation vs toast notification vs notification banner vs alert
Carbon defines success notification status as confirmation that a task completed as expected and distinguishes inline and toast variants by context.
- Toast notification vs toast-only critical error vs error state vs undo
Carbon distinguishes toast, inline, actionable, and callout notification variants, including toast timing, short content, dismissal, and alternate access when more time is needed.
- Toast-only critical error vs error state
Carbon documents time-based toast behavior, persistent inline behavior, actionable notification alternatives, and the need for users to access messages after auto-dismiss when more time is needed.
- Toast-only success for completed transaction vs confirmation page vs success confirmation vs toast notification
Supports distinguishing transient toast notifications from persistent or actionable notification treatments.
Evidence Role
This source is treated as pattern-library evidence. Its value comes from the specific claims and setting described above.
Publisher: IBM Carbon Design System. Last checked: .