Bottom navigation

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?