figma guide
Designing inline alerts and banners in Figma: patterns, tone, and handoff
Design persistent inline alerts and page banners in Figma with tone variants, action slots, dismiss rules, and Dev Mode specs—separate from toasts and modals.
- Published
- Updated
- Jun 09, 2026
- Read time
- 8 min
- Level
- Beginner
Quick answer
Inline alerts and banners in Figma are persistent message components that stay visible until the user dismisses them or resolves the issue. Unlike toasts, they do not auto-dismiss. Build inline alerts for contextual warnings inside a form or section; build page banners for account status, maintenance, or policy notices below the nav. Publish components with variants for tone=info | success | warning | error, layout=inline | banner, and dismissible=true | false. Document focus order, role (role="alert" vs role="status"), and persistence rules in Dev Mode. Pair with modals for blocking flows, forms, and the Figma guides hub.
Who this is for
- Product designers shipping billing warnings, feature deprecations, and form-level validation summaries.
- Design system teams separating toast (transient) from alert (persistent) primitives.
- Engineers implementing ARIA live regions, dismissible banners, and sticky notice bars.
Alert vs banner vs toast vs modal
| Pattern | Persistence | Scope | Blocks work? | Best for |
|---|---|---|---|---|
| Inline alert | Until resolved/dismissed | Section or form | No | Field errors, section warnings |
| Page banner | Until dismissed or expiry | Full page width | No | Trial ending, maintenance |
| Toast | Auto-dismiss | Global overlay | No | ”Saved”, undo |
| Modal | Until explicit action | Viewport | Yes | Destructive confirm, auth |
Verdict: if the message must stay visible while the user continues working, use an inline alert or banner—not a toast. If the user cannot proceed, use a modal.
Component anatomy: inline alert
| Part | Purpose | Spec tip |
|---|---|---|
| Container | Tone background + border | Left border 4px or full fill |
| Leading icon | Tone indicator | 20px; required for warning/error |
| Title (optional) | Short headline | Bold; one line |
| Message | Primary copy | 1–3 lines; links allowed |
| Actions | Text buttons or links | 1–2 max |
| Dismiss | Icon × | Only when dismissible=true |
Alert / Inline
├── Variant: tone=info | success | warning | error
├── Property: hasTitle=true | false
├── Property: dismissible=true | false
├── Property: hasActions=true | false
├── Layer: Container (horizontal auto layout, padding 12px 16px)
│ ├── Icon
│ ├── Content stack (vertical auto layout)
│ │ ├── Title (optional)
│ │ └── Message
│ ├── Actions (horizontal auto layout)
│ └── Dismiss button (optional)Bind colors to semantic tokens—alert/warning/bg, alert/warning/border, alert/warning/text. Run contrast checks on every tone.
Component anatomy: page banner
| Part | Purpose | Spec tip |
|---|---|---|
| Container | Full-width bar | Below nav; min-height 48px |
| Message | Primary copy | Center or left align—pick one system-wide |
| Actions | Primary + secondary | ”Upgrade” + “Learn more” |
| Dismiss | Optional | Account notices often dismissible |
Banner / Page
├── Variant: tone=info | warning | promo
├── Property: dismissible=true | false
├── Layer: Container (horizontal auto layout, space-between, padding 12px 24px)
│ ├── Message group (icon + text)
│ ├── Actions
│ └── Dismiss (optional)Banners span the content width or full viewport—document which. Show banner + navigation on one artboard so engineers know z-index and push behavior (content shifts down vs overlays).
Tone mapping
| Tone | Typical use | Dismissible? | ARIA role |
|---|---|---|---|
| Info | Tips, new features | Often yes | status |
| Success | Completed setup step | Yes | status |
| Warning | Trial ending, limits | Sometimes | alert if urgent |
| Error | Payment failed, sync broken | Rarely until fixed | alert |
Preview tones in dark mode—warning yellows often fail contrast on dark surfaces.
Placement patterns
| Placement | Component | Example |
|---|---|---|
| Below global nav | Page banner | ”Scheduled maintenance Saturday” |
| Above form | Inline alert | ”Verify email to publish” |
| Inside card | Inline alert | ”Storage 90% full” |
| Between sections | Inline alert | Deprecation notice |
| Sticky bottom | Banner (mobile) | Cookie / consent (if not modal) |
Do not stack more than two persistent alerts visible at once—combine copy or prioritize in spec.
Inline alerts with forms
Form-level alerts summarize issues; field-level errors stay on inputs.
| Level | Component | Copy pattern |
|---|---|---|
| Field error | Input state=error + helper text | ”Enter a valid email” |
| Form summary | Inline alert tone=error | ”Fix 3 errors below” |
| Section warning | Inline alert tone=warning | ”Changes affect billing” |
Link to form input states and tooltips for field-level hints—alerts are for page or section scope.
Actions and links in alerts
| Action type | Usage | Spec |
|---|---|---|
| Text button | Primary fix | ”Update payment” |
| Secondary link | Learn more | Opens docs in new tab |
| Dismiss only | Informational | No action required |
Keep one primary action per alert. If two equal actions are needed, consider a modal instead.
Dismiss behavior
Document these rules in Dev Mode:
| Alert type | Dismissible? | On dismiss |
|---|---|---|
| Info / promo | Yes | Hide until next session or never show again |
| Warning (billing) | Sometimes | Snooze 7 days—note logic |
| Error (payment failed) | No | Must resolve |
| Success | Yes | Auto-hide optional after 10s |
If dismissible, include × button with aria-label="Dismiss alert". Store “don’t show again” in settings—not only local dismiss.
Layout with auto layout
- Inline alert: horizontal auto layout,
align=center, gap 12px; content stack grows. - Banner: space-between; message left, actions right; wrap on mobile.
- Responsive: on narrow screens, stack actions below message—design
breakpoint=smvariant. - Icons: fixed 20×20; do not shrink.
Use layout grids on banner artboards aligned to page grid. For responsive frames, show banner text truncation with … and full message in title attribute—note in spec.
Accessibility checklist
role="alert"for urgent errors;role="status"for informational updates.- Do not rely on color alone—icon + text required for warning/error.
- Focus management: dismiss button is keyboard reachable; focus does not trap.
- Links in message are real
<a>elements with visible focus ring. - Contrast on tone backgrounds meets WCAG AA—verify with a11y plugins.
- Screen reader: title + message read together; actions announced after.
Common use cases
Trial ending (banner)
tone=warning, dismissible. Message: “4 days left in trial.” Actions: “Upgrade” (primary), “Compare plans” (link).
Payment failed (inline alert)
tone=error, not dismissible. Inside billing settings card. CTA: “Update payment method.”
Feature deprecation (inline alert)
tone=info, dismissible. Above affected section. Link to migration docs.
Maintenance window (page banner)
tone=info, full width below nav. Not dismissible until event passes.
Cross-link badges when status chips accompany banner messages.
Prototyping limits
Figma cannot persist “dismissed” state across sessions. For reviews:
- Show visible and dismissed frames side by side.
- Prototype
×click → hidden state frame. - Note: “Engineering: store dismiss in localStorage / user prefs.”
Handoff to engineering
| Deliverable | Where it lives |
|---|---|
| Tone → color tokens | Variant names + token table |
| ARIA role per tone | Component description |
| Dismiss rules | Per variant spec |
| Banner push vs overlay | Artboard note |
| Action routes | Link targets in Dev Mode |
| Mobile wrap behavior | sm variant frame |
Include alerts in your Dev Mode handoff checklist. Publish under Patterns / Alert and Patterns / Banner in your team library.
Comparison: when teams reach for the wrong pattern
| Situation | Wrong choice | Right choice |
|---|---|---|
| Payment failed | Toast (auto-hides) | Inline alert or banner until fixed |
| ”Saved” confirmation | Banner | Toast |
| Delete account confirm | Banner with button | Modal |
| Cookie consent | Tiny toast | Banner or dedicated modal |
| Field “invalid email” | Page banner | Field error state |
Common mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Toast for payment errors | User misses critical info | Persistent alert |
| Banner for every save | Alert fatigue | Toast instead |
| No icon on warning | Color-only signal | Leading icon required |
| Dismiss on blocking error | Issue hidden | dismissible=false |
| 5 stacked banners | Unreadable chrome | Priority + combine |
| Same component for toast and banner | Wrong behavior shipped | Separate primitives |
| Lorem ipsum in alert | Ships to prod | Real copy in library |
| Banner overlays nav without spec | Broken layout | Document push vs overlay |
FAQ
Should inline alerts and banners share one component?
Separate top-level components. Banners are full-width with different layout rules; inline alerts sit in content flow. Share tone tokens and icon set only.
How is this different from the toasts guide?
Toasts cover transient, auto-dismissing notifications. This guide covers persistent messages that stay until resolved or dismissed.
Include alerts in the component library?
Yes. Publish tone variants early so squads stop drawing one-off yellow boxes per feature.
Global banner vs inline alert for billing?
Global banner when every page should surface account risk; inline alert when only billing settings need the message.
Bottom line
Use inline alerts for section-scoped, persistent messages and page banners for full-width notices below the nav. Keep them separate from toasts (transient) and modals (blocking). Publish tone, dismissible, and layout variants with real copy, document ARIA roles, and show banner + nav layout on handoff artboards. Continue with toasts for confirmations, forms for field errors, and the tutorials hub.
§ Keep reading