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
| Pattern | Duration | Interaction | Best for |
|---|---|---|---|
| Toast | Auto-dismiss (3–6s) | Optional action + dismiss | ”Saved”, “Copied”, undo |
| Snackbar | Auto-dismiss or persistent | One text action common | Material-style bottom notices |
| Inline alert | Persistent until resolved | May include links | Form validation, page-level warnings |
| Banner | Persistent | Multiple actions possible | Account 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
| Part | Purpose | Spec tip |
|---|---|---|
| Container | Surface + padding | Min width 280px; max width 420px |
| Leading icon | Tone indicator | 20–24px; optional for neutral |
| Message | Primary text | 1–2 lines; truncate with ellipsis |
| Action | Text button | One action max (Undo, View) |
| Dismiss | Icon 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
| Tone | Typical use | Auto-dismiss | Icon |
|---|---|---|---|
| Success | Saved, sent, completed | 4s | Checkmark |
| Neutral | Generic info | 5s | Optional info |
| Warning | Reversible issue | 6s or persistent | Alert triangle |
| Error | Action failed | Persistent until dismiss | X circle |
| Info | Tips, background sync | 5s | Info 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:
| Rule | Desktop | Mobile |
|---|---|---|
| Default position | Bottom-end, 24px margin | Bottom-center, 16px margin |
| Max visible stack | 3 toasts | 2 toasts |
| Stack direction | Newest on top (upward) | Same |
| Gap between toasts | 8px | 8px |
| z-index | Above modals or below—pick one | Same 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
| Behavior | Spec |
|---|---|
| Auto-dismiss success | 4000ms |
| Auto-dismiss neutral | 5000ms |
| Error toasts | Persistent; require dismiss or action |
| Pause on hover | Pause timer when pointer enters toast |
| Pause on focus | Pause when toast or action has focus |
| Undo action window | Match 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
| Rule | Detail |
|---|---|
| Max actions | One text action per toast |
| Label length | 1–2 words (Undo, Retry, View) |
| Primary vs destructive | Undo is neutral; Delete undo needs warning tone |
| Action closes toast | Document 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 useassertive—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
- Container: horizontal auto layout, align center, gap 12px, padding 12px 16px, corner radius
radius/lg. - Message: fill container width, truncate with ellipsis after two lines—document max lines.
- Action: hug contents, min touch target 44px height on mobile variants.
- 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:
- Create closed and open frames on the same page.
- Wire a button click to navigate to a frame with the toast visible.
- 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
| Deliverable | Where it lives |
|---|---|
| Tone enum | Variant property names |
| Dismiss duration | Component description per tone |
| Stack position | Spec artboard or README frame |
| Portal target | ”Render in #toast-root” note |
| Max stack count | Component 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
| Approach | Blocks page | Best for | Avoid when |
|---|---|---|---|
| Toast | No | Confirmations, undo | Critical errors needing full attention |
| Modal | Yes | Destructive confirm, multi-step fix | ”Saved” feedback |
| Inline alert | No (in context) | Form errors, section warnings | Global background sync status |
| Tooltip | No | Icon hints | Post-submit confirmation |
Verdict: use toasts for outcomes the user already initiated; use modals when they must stop and decide.
Common mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Toast for form errors | User misses field context | Inline alert on the field |
| Multiple action buttons | Cluttered; hard to implement | One action max |
| Success toast for 10s | Blocks stack; annoying | 4s default |
| No persistent error state | User loses failure message | Error tone + dismiss |
| Toast behind modal | Invisible feedback | Document z-index layer |
| Paragraph-length message | Unreadable in 360px | Shorten or use modal |
| Detached toasts per screen | Inconsistent padding | Library 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.
§ Keep reading