Notifications tell users that something changed. Five components cover it, from a toast that vanishes in four seconds to a modal that stops the page. The skill is choosing the right one, and as quiet a one as the situation allows.
Use the chooser below, then open the page for the component: Toast, E-Com Toast, Modal, Banner, Inline.
Answer up to three questions. The answer shows the component, why, and a live example you can fire.
Two origins. Task-generated notifications answer something the user just did and belong next to where they are working. System-generated ones come from the application or an administrator, independent of what the user is doing.
| Component | Disruption | Origin | Use when | Statuses |
|---|
Every notification interrupts. Frequent interruptions lower productivity and cause alert fatigue, so keep each one inside the part of the interface and the task where it matters. If the message is not needed, do not send it.
Status colors carry a fixed meaning, and each has one reserved icon. Never pair a status color with another status’s icon. Icons are Material Symbols Outlined, weight 300, filled.
| Status | Icon | Color token | Used for |
|---|
E-Com (E-Com Toast, E-Com Modal) uses the brand’s black and white and no status color; any icon from the gallery may be used. Promotion banners use the brand’s accent color or neutral black and white, also with a free icon.
| Component | Emphasis | Sizes | Layouts |
|---|
Weak is the default. Strong is used sparingly. Status says what the message is (color and icon). Emphasis says how loud it is. Choose the component first, then the status by its meaning, then the emphasis. The status does not decide the emphasis; the consequence does. An Error does not have to be Strong, and a Warning can be Strong if the consequence is serious.
Design guidance given 2026-10-13, not in Figma. Figma defines the tiers but not when to pick which. It agrees with the Banner guidance already here (Strong only for what is urgent, Weaker for general information) and with how Carbon, Adobe Spectrum, SAP Fiori, Material treat routine confirmations. It does not cover Inline: the Inline row is a recommendation.
| Component | Default | Strong only when |
|---|---|---|
| Toast | Weak: normal feedback, “Saved”, “Copied”, “Could not save – try again” | Exceptionally, when the feedback needs extra visual attention. Never for a critical interruption or anything the user must notice or act on: use a Banner, or an Inline notification near the content. |
| Banner | Weak (Weaker for general information and offers) | A critical outage, a blocked main flow, risk of data loss, or anything that needs immediate attention. |
| Inline | Weak | The same as Banner, when it blocks a central flow in that area (recommendation). |
Weak: an ordinary warning or error that can be handled locally, such as a failed action that can be tried again, or something the user must correct. Strong: a critical outage, a blocked main flow, risk of data loss, or anything that needs immediate attention.
If the message must be noticed, must stay, or needs an action, it does not belong in a toast. Show it as a Banner, or near the affected content. For critical or blocking information choose a persistent notification type; do not make a temporary toast louder.
Ask in this order and take the first yes.
A notification that does not go away on its own must always be dismissable. A Modal must support all three ways: ×, ESC and a click outside.
| Method | Toast | E-Com Toast | Inline | Banner | Modal |
|---|
On a Banner, whether the × exists is decided by the administrator or content owner, not by the component.
Fire each component, then three flows where components work together.
Each button fires that component. Banner and Inline appear under the buttons.
Real situations that combine components. Notice that each message uses the quietest component that does the job.