UX Encyclopedia

Navigation Patterns

Navigation answers three questions at all times (foundational IA principle): Where am I? What's here? Where can I go? If any is unclear, navigation has failed regardless of aesthetics.

Try it — find “Oat milk” in both menus. The same 16 grocery items, organized broad-and-shallow on the left and deep on the right. Click through each menu; the counters keep score.

Broad · 4 × 4, 2 levels Clicks: 0

Deep · 2 × 2 × 2 × 2, 4 levels Clicks: 0

Task — Find: Oat milk. Open categories until you reach it in each menu.

Choosing a pattern

  • Tab/bottom navigation (mobile): 2–5 flat, equally important top-level areas. Persistent = orientation for free. The default for consumer apps (iOS tab bar; Material navigation bar). Bottom placement also serves the thumb zone on large phones.
  • Navigation rail / sidebar (tablet, desktop, web apps): scales to more items, supports nesting; Material's canonical adaptive path is bottom bar (compact) → rail (medium) → drawer/sidebar (expanded).
  • Hamburger/drawer: hides everything behind a tap — measured costs in discoverability and engagement vs. visible navigation (NN/g: hidden navigation is used less and rated harder). Acceptable for secondary destinations or very broad IAs; don't hide your top 3–5 destinations.
  • Top nav + mega-menu (content-rich websites): mega-menus test well when grouped and scannable (NN/g) — keep groups labeled, avoid hover-only on touch. See accessibility rules below.
  • Hub-and-spoke: a home hub linking task areas (fine for utility suites, settings). Sequential/wizard: for linear tasks — show step count and allow safe back.
  • Search as navigation: mandatory for large content sets; search is a complement, not a substitute, for browsable structure (users mix both — Rosenfeld & Morville's berry-picking/foraging framing).

Tab bars vs. system gesture navigation (mobile specifics)

  • System gestures own the screen edges: Android gesture nav uses left/right edge swipes for back, which collides with edge-swipe-to-open drawers and horizontal carousels near edges — prefer visible buttons or bottom tabs over edge-swipe-dependent nav on Android.
  • Support predictive back (Android 14+): the system previews where back will land; apps that intercept back arbitrarily break it. Same spirit as the older rule — system back must be safe and predictable.
  • Keep the bottom bar for navigation only; don't mix actions into it (both HIG and Material draw this line). iOS 26's Liquid Glass tab bars minimize on scroll but remain reachable — don't hand-roll hiding nav that the user can't summon back with one gesture.
  • Gestures are invisible affordances: any gesture-only route to a destination needs a discoverable visible alternative (see Mobile App Design).

Mega-menu & dropdown accessibility

  • Use the disclosure (show/hide) pattern, not ARIA menu/menubar roles — those roles are for application menus and impose keyboard behavior that breaks link navigation (ARIA Authoring Practices Guide disclosure-navigation example; Adrian Roselli's widely cited guidance).
  • Trigger is a <button aria-expanded> that opens on click/Enter/Space — never hover-only (fails touch and keyboard); if hover-open is kept for mouse users, add a close delay and generous hover paths to prevent accidental dismissal (NN/g on hover misery in mega-menus).
  • Esc closes and returns focus to the trigger; Tab moves through items; the panel must not trap focus; content order in the DOM matches visual order. WCAG 1.4.13 (Content on Hover or Focus) requires hover-triggered panels to be dismissible, hoverable, and persistent.
  • A top-level item that is both a link and a section opener is a known trap — split it (link + separate expand button) or make the panel's first item the section landing page.

Rules that hold across patterns

  • Highlight current location in the nav (you-are-here) + page title match; mark it programmatically with aria-current="page".
  • Breadcrumbs for hierarchies ≥3 levels deep on web (NN/g: cheap, no measured downside). Mark up as a <nav aria-label="Breadcrumb"> with an ordered list; last item gets aria-current="page".
  • Breadcrumb schema: add schema.org BreadcrumbList JSON-LD so crawlers understand hierarchy. Note Google stopped displaying breadcrumb trails in mobile results (Jan 2025, domain-only display) but still supports the markup for desktop display and site understanding — keep it.
  • Labels: front-loaded, specific nouns users say themselves (test with card sorting/tree testing) — never internal org names or clever puns.
  • Depth vs. breadth: prefer moderately broad & shallow over deep tunnels (each level = another decision + page load; classic menu research — Larson & Czerwinski 1998 found breadth generally beats depth within reason).
  • Back must never lose work or behave unpredictably (web back button and Android system back are sacred).
  • Keep global nav consistent on every screen; consistency is what makes it "navigation" rather than links.

Sources

  • Nielsen Norman Group — hamburger/hidden-navigation studies; mega-menu studies; breadcrumb guidelines (nngroup.com).
  • Rosenfeld, L., Morville, P. & Arango, J. (2015). Information Architecture (4th ed.). O'Reilly.
  • Larson, K. & Czerwinski, M. (1998). "Web page design: implications of memory, structure and scent for information retrieval." CHI '98.
  • Apple HIG — Tab bars, Navigation; Material 3 — Navigation bar/rail/ drawer, adaptive canonical layouts; Android developers — predictive back.
  • W3C ARIA Authoring Practices Guide — disclosure navigation menu pattern (w3.org/WAI/ARIA/apg); WCAG 2.2 SC 1.4.13.
  • Google Search Central — breadcrumb structured data; blog post "Simplifying the visible URL element on mobile search results" (2025).
  • Tidwell, J., Brewer, C. & Valencia, A. (2020). Designing Interfaces (3rd ed.). O'Reilly — pattern catalog.
↑↓ to navigate · Enter to open · Esc to close