Designing tooltips and popovers in Figma: placement, triggers, and handoff

Quick answer

Tooltips in Figma are small, non-interactive labels; popovers are larger panels that may contain links, buttons, or form fields. Build both as published components with variants for placement=top | bottom | start | end and optional arrow. Document open delay (300–500ms for tooltips), dismiss rules (hover vs click), and focus management for popovers in Dev Mode—not only a floating screenshot. Tooltips must not hide essential information; popovers that trap focus need specs aligned with modal patterns. Pair with badges that truncate, icon buttons in nav, and the Figma guides hub.

---

Who this is for

• Product designers adding contextual help, truncated-label hints, and compact action panels.
• Design system contributors defining overlay primitives once for web and desktop.
• Engineers implementing Radix Tooltip, Floating UI, or MUI Popover who need placement and timing rules.

---

Tooltip vs popover: choose the right overlay

Pattern	Content	Interaction	Best for
Tooltip	Short text (≤ 80 chars)	Hover/focus; no clicks inside	Icon labels, truncated text, keyboard hints
Popover	Rich text, links, small forms	Click or hover to open; interactive inside	Filters, emoji pickers, profile mini-cards
Hover card	Preview (user, link)	Hover with delay	Social previews, mention cards
Coach mark	Onboarding callout	Programmatic, often with backdrop	First-run tours (spec separately)

Verdict: if the overlay needs a button or link, it is a popover—not a tooltip. Accessibility tools flag interactive content inside tooltips as failures.

---

Tooltip component anatomy

Part	Purpose	Spec tip
Container	Background + padding	Max width 240–280px
Label	Plain text only	No headings inside tooltips
Arrow	Points to trigger	Optional; document when omitted
Shadow	Elevation	Use elevation tokens

Tooltip / Base
├── Variant: placement=top | bottom | start | end
├── Property: hasArrow=true | false
├── Layer: Container (auto layout, padding 8px 12px)
│   └── Label (text/body-sm, on-inverse text token)
└── Layer: Arrow (vector or component)

Bind fill to surface/tooltip and text to text/on-tooltip from your semantic color system.

---

Popover component anatomy

Part	Purpose	Spec tip
Container	Panel surface	Min width 200px; max ~360px for forms
Header	Title + close (optional)	Use for titled popovers only
Body	Content stack	Vertical auto layout
Footer	Actions (optional)	Primary/secondary buttons
Arrow	Optional anchor	Same placement rules as tooltip

Popover / Base
├── Variant: placement=bottom-start | bottom-end | ...
├── Property: hasHeader=true | false
├── Layer: Container (vertical auto layout)
│   ├── Header row (title + close icon button)
│   ├── Body slot (instance swap)
│   └── Footer actions (horizontal auto layout)
└── Layer: Arrow

Reuse close icon button and button row patterns from modals at smaller scale.

---

Placement and collision rules

Document these in the component description—engineers port them to Floating UI or Popper:

Rule	Tooltip	Popover
Default placement	Top for icon buttons	Bottom-start for menus
Flip on overflow	Yes—show bottom if top clipped	Yes
Shift along axis	Keep 8px viewport margin	Same
Arrow alignment	Center on trigger when possible	Align to trigger edge for wide triggers
Offset from trigger	4–8px	8px

Design four placement variants as separate component variants or a dedicated “spec artboard” showing top/bottom/start/end with the same trigger width.

---

Triggers and timing

Trigger	Tooltip	Popover
Hover	Standard; 300–500ms open delay	Optional; longer delay to avoid accidental open
Focus	Required for keyboard	Open on focus for icon triggers
Click	Avoid for pure tooltips	Standard for menus and pickers
Dismiss	Pointer leave + blur	Click outside, Escape, close button

Do not prototype tooltips that only appear on click unless the spec explicitly says click-triggered (rare).

For mobile, note that hover tooltips often fail—use visible labels or popovers on tap instead. Reference mobile frame safe areas when overlays sit near screen edges.

---

Accessibility checklist

• Tooltip content must be available to screen readers via aria-describedby or visible text elsewhere—designers note the association in Dev Mode.
• Focus tooltips open on keyboard focus, not hover only.
• Popover focus trap: first focusable element inside on open; return focus to trigger on close—mirror modal focus rules.
• Contrast: tooltip background vs text must pass WCAG—check with accessibility plugins.
• No essential info tooltip-only: if compliance or checkout depends on it, show the text inline or in a popover.

Keyboard: document Escape closes popover; Tab cycles inside trapped popovers only.

---

Layout with auto layout

1. Tooltip container: horizontal or vertical auto layout, hug contents, padding token space/2 × space/3.
2. Popover body: vertical stack, gap 12px; form fields use form components at full width.
3. Trigger + overlay artboard: place trigger and tooltip as siblings in a spec frame—do not group overlay inside trigger (breaks Dev Mode hierarchy notes).

Use auto layout patterns for popover footers: primary action on the inline end, 8px gap.

---

Common use cases

Icon button with tooltip

Trigger: 32–40px icon button. Tooltip: 1–3 words (Settings, Delete row). Placement: top for toolbar icons, end for sidebar icons near the left edge.

Truncated table cell

Show ellipsis in cell; tooltip on hover with full string. Link to table row patterns and badge truncation.

Filter popover

Trigger: filter button with active count badge. Popover: checkbox list + Apply/Clear footer. Document Apply vs instant apply behavior.

Date picker / combobox panel

Popover contains calendar or listbox—cross-link dropdown menu anatomy for list items inside the panel.

---

Prototyping limits

Figma prototypes simulate hover poorly on touch devices and do not enforce focus traps. For stakeholder demos:

1. Use two frames: closed and open state.
2. Wire hover or click to open overlay frame.
3. Add a note on the artboard: “Engineering: use portal, focus trap, delay 400ms.”

For motion, keep overlays instant or fade 150ms—see animation in prototypes for what Figma can and cannot preview.

---

Handoff to engineering

Deliverable	Where it lives
Placement enum	Variant names or spec table
Open/close delay	Component description
Interactive vs read-only	“Tooltip: no focusable children” note
z-index / portal	“Render in document portal” note
Arrow dimensions	Fixed size in px or token

Include overlay specs in your Dev Mode handoff checklist. Token export for tooltip surfaces via dev handoff plugins when needed.

---

Comparison: design all states vs engineer defaults

Approach	Best for	Risk
Design open + closed only	Most tooltips	Engineer picks flip logic
Design 4 placements	High-traffic icons	More maintenance
Design popover + form inside	Complex filters	Must spec validation timing

Verdict: tooltips need one open state + placement notes; popovers need header, body, footer variants and focus documentation.

---

Common mistakes

Mistake	Consequence	Fix
Paragraph in tooltip	Unreadable; a11y fail	Use popover or inline help
Links inside tooltip	Not keyboard accessible	Popover component
No focus path	Keyboard users miss help	Focus-triggered spec
Tooltip on disabled control	Should describe why disabled	Wrap in span; tooltip on wrapper
Giant drop shadow	Visual noise	Elevation token shadow/sm
Detached overlays per screen	Inconsistent padding	Library components

---

FAQ

Should the arrow be a separate component?

Optional. Many code libraries draw arrows in CSS. If you include one, use a small component with placement variants rotated 0°/90°/180°/270°.

How do tooltips relate to modals?

Modals block the page and require explicit dismiss; tooltips are ephemeral. Popovers sit between—interactive but local. Use the modal guide when the overlay needs a scrim or blocks background interaction.

One library file for tooltip and popover?

Same file, separate component sets, shared elevation and radius tokens from effects and layout grids.

Do dark mode tooltips need a separate component?

Use variable modes on fill and text—one set, two mode values. Preview with dark mode token workflow.

---

Bottom line

Treat tooltips as short, non-interactive hints with placement, delay, and focus specs. Treat popovers as small panels with optional header, body, footer, and focus trap rules. Never put essential actions or links in tooltips—upgrade to a popover. Publish both from your library with token-backed surfaces and document timing in Dev Mode. Continue with modals for blocking flows, dropdown panels, and the tutorials hub.