Use success toasts for completed, non-blocking actions.
Feedback
Choosing the right component to communicate status, outcomes, and loading states to the user.
Decision guide
The right feedback pattern depends on two things: whether the user needs to act on the information, and whether the flow needs to be blocked until they do.
ScenarioComponentWhy
Action succeeded (save, send, copy)ToastNon-blocking. Disappears automatically. No decision needed from the user.
Action failed, user can retryToast (error)Surface the error with an optional retry action. Still non-blocking.
Destructive action needs confirmationModalBlocks the flow intentionally. User must confirm or cancel before anything changes.
Short background task in progressSpinnerInline or overlay. Use when the wait is under ~3 seconds and no partial progress is available.
Long task with measurable progressProgress barShow a percentage or step counter. A spinner alone is inadequate when the user must wait more than a few seconds.
Persistent inline statusBadgeAttach to an object that has a state (draft, live, archived). Stays visible with the content.
Page-level warning or announcementBannerFixed at the top of the page. For system-wide notices (maintenance, account issues). Should be dismissible unless it describes a blocking condition.
Empty state (no data yet)Inline messageNot a Toast, not a Modal. A short message with a call to action placed where the content would normally appear.
Toast guidelines
Toasts are for transient confirmation. They inform without interrupting. The user does not have to close them — they disappear on their own.
RuleGuidance
Duration4–6 seconds for short messages. 8 seconds if an action (undo, retry) is included.
Copy lengthOne sentence. If the feedback needs more explanation, it belongs in a modal or inline alert.
StackingShow one at a time. Queue new toasts rather than stacking. Stacks over 2 are disorienting.
PositionBottom-right on desktop. Bottom-center on mobile. Avoid top placement — it conflicts with navigation.
VariantsUse
success for completed actions, error for recoverable failures, info for neutral updates. Do not use warning in a toast — warnings need attention and should persist.Modal vs Toast
The single most common feedback mistake is using a modal where a toast is sufficient, or using a toast when the stakes require a modal. The distinction is whether the user must make a decision.
Use a Toast whenUse a Modal when
The action is already doneThe action is about to happen and cannot be undone
No response is neededA confirm or cancel decision is needed
The user can continue workingThe user must stop and address the situation
The message fits in one sentenceThe situation requires explanation or additional context
Spinner guidelines
A spinner communicates that something is happening. It says nothing about how long it will take or how much has been completed. Use it for short waits only.
RuleGuidance
Delay before showingWait at least 200–300ms before showing a spinner. Instant appearance for fast responses adds visual noise.
Replace button labelWhen a button triggers an async action, replace its label with a spinner and disable it. Keep the button's width stable.
Full-page overlayUse only when the entire interface is blocked. Avoid if only one section is loading — use a local spinner instead.
Accessible labelAlways include an
aria-label like "Loading" or a visually hidden text node. A spinner alone is invisible to screen readers.Do and don't
Do
Use danger toasts with retry for recoverable failures.
Use modal when confirmation is required before destructive actions.
Give spinners an accessible label that explains what is loading.
Don't
Use modal for simple success confirmations.
Use toast for irreversible confirmation decisions.
Use spinner alone for long-running measurable tasks.
Stack several toasts for the same single user action.