figma guide
Designing navigation and tabs in Figma: patterns, states, and handoff
Design nav bars, sidebars, and tab bars in Figma with correct states, auto layout, safe areas, and Dev Mode specs engineers can implement without guessing.
- Published
- Updated
- Jun 05, 2026
- Read time
- 6 min
- Level
- Intermediate
Quick answer
Navigation in Figma should be a published component set—top bar, side rail, or bottom tabs—with variants for item state (default, hover, active, disabled) and density (compact vs comfortable). Use auto layout for item rows, bind semantic color tokens for active indicators, and document which item is “current” in Dev Mode descriptions (URL, route id, or section name). On mobile, design inside frames with safe areas and minimum 44px touch targets. Pair with mobile frame presets, interactive component states, and the Figma guides hub.
Who this is for
- Product designers shipping app shells, settings areas, and marketing site headers.
- Design system teams standardizing nav primitives before dozens of feature files diverge.
- Engineers who need clear active-state rules, not screenshots of five similar tab bars.
Choose the right navigation pattern
| Pattern | Best for | Avoid when |
|---|---|---|
| Top app bar | Web apps, Android-style primary actions | More than ~5 primary destinations |
| Side navigation | Dense dashboards, admin tools, docs | Mobile-first products without a collapsed drawer spec |
| Bottom tab bar | iOS/Android primary destinations (3–5) | Desktop-only workflows |
| Segmented control / tabs | Switching views within one screen | Replacing global app navigation |
| Breadcrumbs | Deep hierarchies, enterprise | Flat single-level apps |
Verdict: pick one primary global pattern per platform (web vs mobile) and reuse it—do not redesign navigation per feature squad.
Component anatomy: nav item
| Layer | Role | Handoff note |
|---|---|---|
| Container | Hit area, padding | Min height 44px on touch |
| Icon (optional) | Recognition | Use instance swap property |
| Label | Text | Truncate rules in description |
| Active indicator | Bar, pill, or bold | Token: nav/indicator/active |
| Badge (optional) | Counts | Document max digits (99+) |
Structure as a component set Nav / Item with variants state=default | hover | active | disabled and density=compact | default.
Top navigation bar (web)
- Frame: full width, horizontal auto layout, height 56–64px, padding horizontal 16–24px.
- Left cluster: logo instance + primary links (horizontal auto layout, gap 8–16px).
- Right cluster: search, notifications, avatar—push apart with auto layout space between on the parent or a spacer frame.
- Active link: underline or
text/weight-semibold+ semantic color—never color alone (accessibility plugins).
Sticky header spec
Document in description: position: sticky; top: 0; z-index: nav and whether content scrolls under or below the bar.
Side navigation (dashboard)
| Section | Layout tip |
|---|---|
| Brand / product switcher | Fixed top, 48–56px tall |
| Primary items | Vertical auto layout, gap 4px |
| Secondary (settings, help) | Pin to bottom with spacer flex-grow pattern |
| Collapsed rail | Icon-only variant width ~56px; show tooltips in spec |
Use layout grids on the content area beside the rail—not on the rail itself unless you align icons to an 8pt grid.
Nested items: indent 16px per level; show expand/collapse as a boolean component property, not a detached chevron per row.
Bottom tab bar (mobile)
Design on a 390×844 (or your team standard) frame with safe area padding for home indicator.
| Rule | Value |
|---|---|
| Tab count | 3–5 primary destinations |
| Icon + label | Label optional only if icons are universally understood—document exceptions |
| Active state | Filled icon + label color token |
| FAB overlap | If FAB exists, document center tab or raised FAB z-index |
Prototype tab switches with component properties or separate frames per tab root—link to prototype basics.
Tabs (in-page, not global nav)
Segmented tabs sit below the page title and control panel content on the same route.
Tabs / Segmented
├── Variant: size=sm | md
├── Variant: state=default | hover | active | disabled
├── Slot: panel (swap instance or show/hide via property)| Mistake | Fix |
|---|---|
| Tabs look like bottom nav | Different height, no safe-area inset, label style text/tab |
| 8+ tabs in one row | Scrollable tab row variant or dropdown “More” |
| No empty panel | Design panel=empty and panel=loading |
Pair with sections for flows so each tab maps to a named section in the file.
States and interaction
| State | Visual | Prototype |
|---|---|---|
| Default | Muted label/icon | — |
| Hover | Subtle background (web) | On click → navigate |
| Active / current | Indicator + emphasis | Starting frame for section |
| Disabled | Reduced opacity, no pointer | Omit from prototype hotspots |
| Focus (keyboard) | Visible ring | Describe in Dev Mode; do not hide |
Use interactive components for hover/press on nav items, not on the entire bar.
Responsive behavior
Document breakpoints in a small spec table on the handoff page:
| Viewport | Navigation behavior |
|---|---|
| ≥1024px | Side rail expanded |
| 768–1023px | Side rail collapsed (icons only) |
| <768px | Bottom tabs or hamburger → drawer |
Cross-link responsive design in Figma for constraint vs auto layout decisions on the content frame beside nav.
Comparison: native components vs UI kits
| Approach | Best for | Risk |
|---|---|---|
| Native component set | Long-term product | Upfront build time |
| Kit nav block | MVP speed | Token mismatch with your code |
| Detached frames per screen | Never | Unmaintainable active states |
Verdict: import UI kits as reference, then rebuild one nav set on your semantic tokens.
Handoff checklist
| Deliverable | Where |
|---|---|
| Active item logic | Component description (match route /segment) |
| Icon set | Published library, 24px grid |
| Spacing | Auto layout gaps = spacing tokens |
| Overflow | Truncate vs wrap rules for long product names |
| Z-index | Nav above content, below modals |
Run the same pass as Dev Mode for designers before review.
Common mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Active state only on color | Fails a11y | Indicator + weight or underline |
| Different nav per file | Inconsistent IA | Publish Nav/* from team library (team libraries) |
| 6 bottom tabs | Crowded, rejects App Store patterns | Merge destinations or use “More” |
| No collapsed drawer spec | Broken tablet layout | Ship collapsed variant |
| Prototype without real labels | Engineers guess truncation | Use realistic copy widths |
FAQ
Should logo be part of the nav component?
Yes for product apps; no for white-label systems where marketing owns the header separately.
How do I show “current page” in Figma?
Use the active variant on the correct item instance, and add a description on the nav frame listing the route. Do not rely on prototype highlight color alone.
Tabs vs accordion on mobile?
Tabs for 2–5 peer views of equal weight; accordion for long settings lists—see forms patterns for dense settings.
Do nav items need variants for dark mode?
Yes—bind to dark mode tokens or mode-aware variables on the same component set.
Bottom line
Ship one nav system per platform: component sets for items, clear active treatment, and written routing rules in Dev Mode. Use auto layout for alignment, safe areas on mobile, and keep everything in the team library so active states stay honest across files. Next: forms, modals, and the tutorials hub.
§ Keep reading