figma guide

Designing toasts and snackbars in Figma: patterns, timing, and handoff

Design toast and snackbar components in Figma with tone variants, auto-dismiss timing, action slots, stacking rules, and Dev Mode specs so notifications ship correctly.

Published
Updated
Jun 08, 2026
Read time
7 min
Level
Intermediate

Quick answer

Toasts and snackbars in Figma are transient notification components that confirm actions, report errors, or offer a single undo. Build them as published components with variants for tone=neutral | success | warning | error | info, optional leading icon, optional action label, and optional dismiss button. Document auto-dismiss duration (4–6s for success, persistent for errors), stacking position (bottom-center on mobile, bottom-end on desktop), and aria-live behavior in Dev Mode—not only a static frame. Pair with modals for blocking errors, tooltips for inline hints, and the Figma guides hub.


Who this is for

  • Product designers adding save confirmations, undo flows, and inline error feedback.
  • Design system contributors defining one notification primitive instead of five slightly different banners per squad.
  • Engineers implementing Sonner, Radix Toast, MUI Snackbar, or custom portals who need timing and stacking rules.

Toast vs snackbar vs banner: pick the right pattern

PatternDurationInteractionBest for
ToastAuto-dismiss (3–6s)Optional action + dismiss”Saved”, “Copied”, undo
SnackbarAuto-dismiss or persistentOne text action commonMaterial-style bottom notices
Inline alertPersistent until resolvedMay include linksForm validation, page-level warnings
BannerPersistentMultiple actions possibleAccount limits, maintenance

Verdict: if the message auto-disappears and does not block the page, use a toast. If the user must read and act before continuing, use an inline alert or modal—not a toast.


Component anatomy

PartPurposeSpec tip
ContainerSurface + paddingMin width 280px; max width 420px
Leading iconTone indicator20–24px; optional for neutral
MessagePrimary text1–2 lines; truncate with ellipsis
ActionText buttonOne action max (Undo, View)
DismissIcon button ×Optional when auto-dismiss is enough
Toast / Base
├── Variant: tone=neutral | success | warning | error | info
├── Property: hasAction=true | false
├── Property: hasDismiss=true | false
├── Layer: Container (horizontal auto layout, padding 12px 16px)
│   ├── Icon slot (optional)
│   ├── Message (text/body-sm, flex grow)
│   ├── Action button (text variant, nested component)
│   └── Dismiss icon button (optional)

Bind container fill to surface/toast or tone-specific tokens from your semantic color system. Use elevation tokens for shadow/md—toasts float above page content.


Tone mapping

ToneTypical useAuto-dismissIcon
SuccessSaved, sent, completed4sCheckmark
NeutralGeneric info5sOptional info
WarningReversible issue6s or persistentAlert triangle
ErrorAction failedPersistent until dismissX circle
InfoTips, background sync5sInfo circle

Run accessibility contrast checks on every tone. Preview light and dark surfaces with dark mode token tricks.


Placement and stacking

Document these in the component description—engineers port them to a toast viewport:

RuleDesktopMobile
Default positionBottom-end, 24px marginBottom-center, 16px margin
Max visible stack3 toasts2 toasts
Stack directionNewest on top (upward)Same
Gap between toasts8px8px
z-indexAbove modals or below—pick oneSame system-wide

Design a spec artboard showing three stacked toasts with decreasing opacity or offset—optional visual cue for engineers.

Respect mobile safe areas when toasts sit above tab bars or home indicators.


Timing and behavior

BehaviorSpec
Auto-dismiss success4000ms
Auto-dismiss neutral5000ms
Error toastsPersistent; require dismiss or action
Pause on hoverPause timer when pointer enters toast
Pause on focusPause when toast or action has focus
Undo action windowMatch dismiss timer (e.g. 5s undo)

Do not prototype toasts that block interaction unless the spec says so—that is a modal.


Action button rules

RuleDetail
Max actionsOne text action per toast
Label length1–2 words (Undo, Retry, View)
Primary vs destructiveUndo is neutral; Delete undo needs warning tone
Action closes toastDocument whether action dismisses automatically

Reuse text button and icon button components from forms and cards—do not draw one-off action styles per toast.


Accessibility checklist

  • aria-live: success/neutral use polite; errors use assertive—note in Dev Mode.
  • Focus management: toasts should not steal focus on open unless they contain an action; document focus move to action button when present.
  • Color alone: pair error/success tones with icons—do not rely on hue only.
  • Motion: respect prefers-reduced-motion—spec fade-only or no animation.
  • Screen reader text: message must be plain language; avoid “Success!” without context (“Changes saved”).

Keyboard: Escape dismisses focused toast when dismiss button is present; Tab reaches action and dismiss controls.


Layout with auto layout

  1. Container: horizontal auto layout, align center, gap 12px, padding 12px 16px, corner radius radius/lg.
  2. Message: fill container width, truncate with ellipsis after two lines—document max lines.
  3. Action: hug contents, min touch target 44px height on mobile variants.
  4. Stack artboard: vertical auto layout, gap 8px, align end (desktop) or center (mobile).

Use auto layout patterns for consistent spacing. Keep toast width hug contents up to max width, then wrap message.


Common use cases

Save confirmation

Tone: success. Message: “Changes saved.” Auto-dismiss: 4s. No action unless undo is supported.

Undo delete

Tone: neutral. Message: “Item deleted.” Action: Undo. Timer: 5s—action and dismiss share the window.

Network error

Tone: error. Message: “Could not sync. Check your connection.” Action: Retry. Persistent until dismiss.

Copy to clipboard

Tone: success. Message: “Link copied.” Auto-dismiss: 3s. No dismiss button needed.

Cross-link table bulk actions and form submission flows where toasts confirm background operations.


Prototyping limits

Figma prototypes do not auto-dismiss or stack toasts realistically. For stakeholder demos:

  1. Create closed and open frames on the same page.
  2. Wire a button click to navigate to a frame with the toast visible.
  3. Add a note: “Engineering: portal, 4s timer, pause on hover.”

For enter animation, spec slide up + fade 200ms—see animation in prototypes for limits.


Handoff to engineering

DeliverableWhere it lives
Tone enumVariant property names
Dismiss durationComponent description per tone
Stack positionSpec artboard or README frame
Portal target”Render in #toast-root” note
Max stack countComponent description
Action behavior”Undo reverts last delete” note

Include toast specs in your Dev Mode handoff checklist. Export motion tokens via dev handoff plugins when teams share timing variables.


Comparison: toast vs modal vs inline alert

ApproachBlocks pageBest forAvoid when
ToastNoConfirmations, undoCritical errors needing full attention
ModalYesDestructive confirm, multi-step fix”Saved” feedback
Inline alertNo (in context)Form errors, section warningsGlobal background sync status
TooltipNoIcon hintsPost-submit confirmation

Verdict: use toasts for outcomes the user already initiated; use modals when they must stop and decide.


Common mistakes

MistakeConsequenceFix
Toast for form errorsUser misses field contextInline alert on the field
Multiple action buttonsCluttered; hard to implementOne action max
Success toast for 10sBlocks stack; annoying4s default
No persistent error stateUser loses failure messageError tone + dismiss
Toast behind modalInvisible feedbackDocument z-index layer
Paragraph-length messageUnreadable in 360pxShorten or use modal
Detached toasts per screenInconsistent paddingLibrary component

FAQ

Should toasts include a progress bar for auto-dismiss?

Optional. A thin progress bar helps users gauge remaining time—common in video apps. For most SaaS, timer-only is enough; spec if you include it.

How do toasts relate to snackbars?

Material Design uses “snackbar” for bottom transient messages—functionally the same as toasts. Pick one term in your design system and stick to it in Figma component names.

One component for toast and banner?

Separate sets. Banners are full-width, persistent, and often sit below the nav—different layout and behavior than floating toasts.

Do dark mode toasts need separate components?

Use variable modes on fill, text, and icon—one component set, mode values per theme. Preview with dark mode workflow.


Bottom line

Treat toasts as short, non-blocking feedback with tone, timing, stacking, and optional undo action specs. Never use toasts for critical errors that need a modal—or form errors that belong inline. Publish one library component with token-backed surfaces and document aria-live and dismiss rules in Dev Mode. Continue with modals for blocking flows, badges on nav items, and the tutorials hub.

Share on X

§ Keep reading

Related guides.