Skip to main content

Mobile Navigation Patterns: When to Use Each One

By · · 6 min read

mobileuxnavigation
On this page

Navigation is the skeleton of a mobile app. When it works, nobody notices it; people move between screens without thinking. When it doesn't, users can't find features, get lost in deep stacks of screens, and abandon tasks they came to complete.

The difficulty on mobile is space. You can't show everything at once, so every navigation pattern is a trade-off between visibility and room for content. This guide covers the main patterns, what each is good at, and how to choose.

Start with your information architecture#

Before choosing a pattern, understand the structure of your app:

  • How many top-level destinations are there?
  • How often do people switch between them?
  • How deep does the hierarchy go?
  • Which tasks are most frequent?

The answers usually make the right pattern obvious. Navigation design problems are often information architecture problems in disguise. If you have eleven top-level sections, no navigation pattern will save you; the structure itself needs simplifying.

Bottom tab bar#

The bottom tab bar shows three to five top-level destinations as icons with labels at the bottom of the screen. It's the default on iOS and widely used on Android through the navigation bar component.

Use it when:

  • You have three to five top-level destinations.
  • People switch between those sections frequently.
  • Each section is roughly equal in importance.

Why it works: destinations are always visible, always one tap away, and within comfortable thumb reach on large phones. Users can see the whole shape of the app at a glance.

Rules for tab bars:

  • Always include text labels. Icons alone are ambiguous for anything beyond the most common symbols.
  • Keep the tab bar visible on top-level screens. Hiding it inconsistently confuses users.
  • Preserve each tab's state. If someone scrolls down a feed, switches tabs, and comes back, they should return to where they were.
  • Tapping the active tab should typically scroll to the top or return to the tab's root screen.
  • Don't use tabs for actions like "Create" unless it's the core action of the app, and even then, consider a distinct visual treatment.

The navigation drawer, often opened by a hamburger icon, slides in from the side and lists many destinations.

Use it when:

  • You have more than five destinations.
  • Some destinations are used infrequently, such as settings, help, or account pages.
  • Your app has a clear primary screen that most people use most of the time.

The trade-off: drawers hide navigation. Research and practical experience consistently show that hidden navigation is used less than visible navigation. Features placed in a drawer get less discovery and engagement.

Rules for drawers:

  • Don't hide your most important destinations in a drawer if they could fit in a tab bar.
  • Group items logically with clear section labels.
  • Highlight the current location.
  • Consider combining patterns: a tab bar for primary destinations plus a "More" tab or profile screen for secondary ones.

Top tabs#

Top tabs, sometimes called segmented tabs, sit below the header and switch between related views within a single section — like "All," "Unread," and "Archived" in an inbox.

Use them when:

  • Views are closely related and at the same level.
  • People switch between them while staying in the same context.
  • There are a small number of views, ideally two to five, or a scrollable set for categories.

Rules for top tabs:

  • Don't use top tabs for primary app navigation; that's what the bottom bar is for.
  • Support swiping between tabs where the platform expects it.
  • Keep labels short and parallel in structure.

Stack navigation#

Stack navigation moves people deeper into content: a list leads to a detail page, which leads to a sub-detail page. A back button returns them up the stack.

Rules for stacks:

  • Always provide a clear way back, with the platform's standard back behavior.
  • Show the title of the current screen so people know where they are.
  • Avoid very deep stacks. If people regularly go five or six levels deep, the structure probably needs flattening.
  • Don't break the system back gesture or button. People rely on it heavily.

Modals take over the screen for a focused, self-contained task: composing a message, adding a payment method, completing a multi-step setup.

Use them when:

  • The task is short and has a clear end.
  • You want to prevent distraction until the task is completed or cancelled.

Rules for modals:

  • Provide a clear way to close or cancel.
  • Warn before discarding unsaved input.
  • Don't nest modals inside modals; it disorients people.
  • Return users to exactly where they were when the task finishes.

Gestures#

Gestures — swipe to go back, pull to refresh, swipe to delete — make navigation feel fluid, but they're invisible.

Rules for gestures:

  • Use gestures as shortcuts, not as the only way to do something.
  • Follow platform conventions; don't redefine standard gestures.
  • Provide visual hints for custom gestures, such as partially revealed actions.
  • Avoid conflicting gestures, like a horizontal carousel inside a screen that also uses horizontal swipe to go back.

Search as navigation#

In content-heavy apps — shopping, music, documentation — search is often the fastest navigation path. Make it easy to reach, ideally from a top-level tab or a persistent search field, and support recent searches and suggestions. Search doesn't replace good structure, but it's an essential complement.

Choosing: a quick decision guide#

  • Three to five equally important sections, frequent switching: bottom tab bar.
  • One main screen with many secondary sections: primary screen plus drawer or "More" area.
  • Related views within one section: top tabs.
  • Moving from overview to detail: stack navigation.
  • Focused, short task: modal.
  • Huge content catalog: prominent search alongside a simple structure.

Most real apps combine several patterns. A typical structure is a bottom tab bar for primary destinations, stack navigation within each tab, top tabs for related views, and modals for focused tasks.

Test navigation early#

Navigation problems are cheap to find before visual design and expensive to fix after launch. Two lightweight methods help:

  • Tree testing: give people a text-only version of your structure and ask them to find specific items. It reveals whether your labels and grouping make sense.
  • First-click testing: show a screen and ask where they'd tap to complete a task. If the first click is right, people usually succeed.

Good navigation tells users what the app can do and how to get there. Visible destinations, consistent behavior, clear labels, and a reliable way back build confidence. Hidden, inconsistent, or overloaded navigation erodes it.

Choose patterns based on your structure and your users' most common tasks, follow platform conventions, and test early. Your users should spend their attention on your content, not on figuring out how to reach it.