UX Patterns Guide
UI + UX Navigation And Wayfinding established

Bottom navigation

Keep three to five top-level destinations persistently available at the bottom of compact mobile screens, with clear labels, icons, selected state, and preserved state inside each section.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A compact mobile app has three to five high-frequency top-level destinations.
  • Users need frequent switching between major sections.
  • Each section benefits from a persistent selected state and retained local state.

Avoid when

  • There are fewer than three or more than five primary destinations.
  • The items are commands, filters, or one-off actions rather than destinations.
  • The product has deep hierarchy that needs a drawer, side navigation, or breadcrumbs.
  • The layout is tablet, desktop, or wide enough that a rail or persistent side navigation is more ergonomic.

Problem it prevents

Mobile users need one-tap access to a small set of primary app destinations without stretching to a top menu or losing section context.

Pattern anatomy

What a strong implementation has to make clear

User need

A compact mobile app has a small number of high-frequency primary sections.

Pattern promise

Keep three to five top-level destinations persistently available at the bottom of compact mobile screens, with clear labels, icons, selected state, and preserved state inside each section.

Required state

Default state with all primary destinations visible.

Recovery path

Using bottom navigation for unrelated actions.

Access contract

Every icon must have a visible label or accessible name.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Five labeled destinations stay fixed at the bottom with Home selected, Alerts showing a small badge, and no action button mixed into the bar.
  • Selected state uses shape, weight, and text color instead of relying on color alone.
  • Switching from Home to Saved and back preserves each section's scroll count and draft state.
  • A badge invites users to check Alerts without changing what the Alerts destination does.
Weak implementation

Vague, hidden, hard to recover from

  • Six tiny icon-only items and a center plus button compete for space.
  • The active destination is unclear and labels truncate into guesses.
  • Tapping Search clears the Home feed position and opens a one-off command instead of a destination.
  • A create action in the middle of the bar surprises users who expect destination switching.
UI guidance
  • Render three to five bottom destinations with stable touch targets, labels or accessible names, reinforcing icons, selected state, optional badges, and safe-area spacing.
  • Keep the bar visually attached to the app shell rather than to one section's content, and avoid mixing in commands or deep hierarchy links.
UX guidance
  • Support rapid switching between top-level mobile sections while preserving each section's local navigation, scroll, filters, and drafts.
  • Adapt the same destination model to rail or drawer navigation when window width or destination count makes the bottom bar cramped.
Implementation contract

What the implementation must handle

States

  • Default state with all primary destinations visible.
  • Selected destination state exposed visually and programmatically.
  • Destination changed state with content updated and previous section state preserved.
  • Badge or notification state that does not steal focus or shift the bar.

Interaction

  • Activating an item switches to its top-level destination rather than performing a transient command.
  • The selected item remains visible and stable while users navigate inside that section.
  • Each destination has a predictable label, accessible name, and selected/current state.
  • Switching destinations does not clear scroll position, filters, drafts, or nested navigation unless the user explicitly resets them.

Accessibility

  • Every icon must have a visible label or accessible name.
  • The active destination must not be conveyed by color alone.
  • Expose the selected or current destination programmatically.
  • Badges need accessible text when they convey meaningful counts or status.

Review

  • Are these items truly top-level destinations users revisit often, or are they actions competing for bottom reach?
  • Will the selected state and labels still be understandable at the narrowest supported width?
  • What section state must be preserved when users switch away and come back?
Interactive lab

Inspect the states before you copy the pattern

Switch top-level destinations

Check whether the active destination and destination content stay in sync.

Bottom navigation
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Default state with all primary destinations visible.

Keyboard / Access

External keyboard focus moves through destinations in visual order.

Avoid Generating

Putting too many destinations into the bar.
Evidence trail

Source-backed claims behind this guidance

Material Design Bottom Navigation

Material Design - checked

Material documents bottom navigation as a mobile bar for three to five primary destinations, with selected state and destination-only behavior.

Android NavigationUI Bottom Navigation

Google - checked

Android NavigationUI documents wiring bottom navigation items to destinations, automatic selected-state updates, and item-state preservation.

Full agent/debug reference

Problem Context

  • A compact mobile app has a small number of high-frequency primary sections.
  • Users switch between sections repeatedly while holding the device one-handed.
  • Each destination may have its own nested navigation, scroll position, filters, or draft state that should survive destination switches.

Selection Rules

  • Choose bottom navigation for three to five top-level mobile destinations of similar importance.
  • Keep destinations at the same hierarchy level and make each item navigate to a stable app section.
  • Use visible labels or very familiar labels plus accessible names; do not rely on ambiguous icons alone.
  • Preserve each destination's nested navigation, scroll position, filters, and drafts when users switch away and return.
  • Adapt to a navigation rail or drawer on wider screens or when the destination count exceeds what the bottom bar can hold.
  • Use a toolbar, floating action button, menu, or local button for commands instead of putting actions in the navigation bar.

Required States

  • Default state with all primary destinations visible.
  • Selected destination state exposed visually and programmatically.
  • Destination changed state with content updated and previous section state preserved.
  • Badge or notification state that does not steal focus or shift the bar.
  • Overflow or more-destinations decision state where the design changes to rail, drawer, or a More destination instead of cramming items.
  • Full-screen or modal task state where hiding the bar is deliberate and reversible.

Interaction Contract

  • Activating an item switches to its top-level destination rather than performing a transient command.
  • The selected item remains visible and stable while users navigate inside that section.
  • Each destination has a predictable label, accessible name, and selected/current state.
  • Switching destinations does not clear scroll position, filters, drafts, or nested navigation unless the user explicitly resets them.
  • Badges communicate status without changing the destination's function.

Implementation Checklist

  • Limit the bar to three to five primary destinations for compact mobile layouts.
  • Give every destination a text label or accessible name, plus an icon that reinforces the label.
  • Expose the active destination with aria-current="page" or the platform equivalent selected state.
  • Keep the bar outside the routed content area so it can persist while destinations change.
  • Store per-destination navigation and UI state when users switch sections.
  • Respect bottom safe areas, system gestures, and touch target sizing.
  • Move extra destinations to rail, drawer, More, or another primary navigation model instead of shrinking labels.

Common Generated-UI Mistakes

  • Putting too many destinations into the bar.
  • Mixing navigation destinations with commands such as create, delete, filter, or submit.
  • Using icon-only labels for unfamiliar sections.
  • Resetting scroll, filters, or draft state every time users switch destinations.
  • Using bottom navigation for deep child pages instead of top-level app areas.
  • Combining it with another competing primary navigation model on a narrow screen.

Critique Questions

  • Are these items truly top-level destinations users revisit often, or are they actions competing for bottom reach?
  • Will the selected state and labels still be understandable at the narrowest supported width?
  • What section state must be preserved when users switch away and come back?
Accessibility
  • Every icon must have a visible label or accessible name.
  • The active destination must not be conveyed by color alone.
  • Expose the selected or current destination programmatically.
  • Badges need accessible text when they convey meaningful counts or status.
Keyboard Behavior
  • External keyboard focus moves through destinations in visual order.
  • Activation switches destination and keeps focus behavior predictable.
  • The selected destination remains identifiable when focused, hovered, or activated.
  • If the bar is hidden for an immersive task, keyboard users must have a clear way to leave the task and restore navigation.
Variants
  • Labeled bottom navigation
  • Mobile tab bar
  • Badged destination
  • More destination
  • Adaptive navigation bar to rail

Verification

Last verified: