How to Design Navigation

Navigation is one of the most consequential design decisions in any product. Users who can't find what they're looking for don't search — they leave.

Most navigation problems start with information architecture, not visual design. Fix the structure first, then design the UI.

Navigation patterns — and when to use each

Top navigation bar: Best for sites and apps with a moderate number of primary sections (4-8) and relatively flat information architecture. Works well on desktop where horizontal space is available. Common for marketing sites, e-commerce, and productivity tools.

Limitations: doesn't scale beyond ~6 primary items without becoming cluttered. More than that, and you either need to introduce mega-menus (expensive to build and cognitively demanding) or trim the navigation.

Sidebar navigation: Best for apps with many sections, complex information hierarchies, or tools where context-switching between areas is frequent. Sidebars can expand to show sub-items without displacing content. Common in SaaS dashboards (Linear, Notion, Figma), admin panels, and developer tools.

Fixed sidebar takes up permanent screen space — it costs you horizontal pixels on every page. Collapsible sidebars let users hide it when they don't need it, which works well for dense applications.

Bottom navigation (mobile): Best for mobile apps where the primary navigation items need to be reachable with one thumb. Show 3-5 primary destinations. More than 5 items requires an overflow menu, which defeats the purpose.

Bottom nav is dominant for native iOS and Android apps. On mobile web, it's used but less consistently — many web products still use a hamburger menu even when bottom nav would serve users better.

Hamburger menu: A hidden navigation accessed by a menu icon. Use it for secondary or rarely-needed items, not primary destinations. Hiding primary navigation behind a hamburger increases the number of taps to reach content and reduces discoverability.

The burger is not a solution to too many navigation items — it's a deferral of the information architecture problem. If you have 12 top-level nav items, hiding them in a hamburger menu doesn't fix the fact that you have 12 top-level nav items.

Information architecture's role

Navigation is the UI. Information architecture is the structure underneath. If the IA is wrong, no amount of navigation UI improvement will fix it.

Before designing navigation, answer these questions:

• What are the 4-6 primary destinations users need to reach?
• How do those destinations group logically?
• What is the hierarchy of content within each section?

Use Whimsical to map your IA as a tree diagram. Start with your top-level categories, then branch into sub-levels. The diagram makes hierarchy problems visible — you can see at a glance when you have too many items at the top level, or when the tree is so deep that users need 4 clicks to find anything.

Map your IA in Whimsical

The depth problem

Navigation can fail by being too deep (too many levels) or too flat (too many items at one level).

Too deep: Three or more levels of navigation means users need to remember their path and navigate back through multiple levels to change direction. Two levels is almost always enough for most products.

Too flat: 10+ items at the top level overwhelms users with choices. Hick's Law — the time to make a decision increases with the number of choices — applies directly here.

The target: 4-6 primary categories at the top level, with clear sub-structure within each. If you can't get there, you either have a categorization problem (items don't naturally group) or a scope problem (the product does too many things and needs rethinking).

Mobile navigation decisions

Mobile navigation is a triage decision. You have limited screen real estate and limited interaction surface. Pick 3-5 primary destinations for the bottom bar. Move everything else to a secondary menu, profile section, or settings.

The items in your bottom nav should be the things users visit most frequently. This is a data decision — if you have analytics, look at page views by section. If you're designing from scratch, prioritize by core user goals.

Don't replicate your desktop nav on mobile. A sidebar that works on desktop doesn't automatically translate to mobile. Design mobile navigation separately, starting from user goals rather than the desktop structure.

Naming navigation items

Navigation item names should match the user's mental model, not the internal product structure or engineering terminology.

Test your navigation labels before building. Give 5 users a list of tasks ("Find your billing history," "Invite a team member") and ask them to click the navigation item they'd expect to find it under. If they consistently choose the wrong label, the label is wrong.

Common naming mistakes:

• Too abstract: "Hub," "Studio," "Center" — users don't know what these contain
• Too branded: Internal product names that aren't self-explanatory to new users
• Ambiguous: "Resources" could mean documentation, templates, or support — be specific

When in doubt, use the simplest, most literal label. "Billing" beats "Account" if billing is the primary reason people visit that section.

Breadcrumbs

Breadcrumbs show users their location within a hierarchy: Home > Products > Electronics > Headphones.

Use breadcrumbs when:

• Your information architecture is 3+ levels deep
• Users frequently navigate between content at different levels
• Users might land deep in your hierarchy from search (SEO-driven pages)

Don't use breadcrumbs as a substitute for clear primary navigation. If users consistently need breadcrumbs to orient themselves, your navigation structure needs rethinking.

On mobile, breadcrumbs are often impractical due to space constraints. Consider showing only the parent level ("← Electronics") rather than the full path.

Progressive disclosure in navigation

Not all navigation items need to be visible at all times. Reveal deeper navigation when users enter a relevant section.

A sidebar that expands sub-items only when a top-level section is active is a form of progressive disclosure. Users see what's relevant to where they are, without all sub-levels competing for attention simultaneously.

This works well in applications with deep hierarchies. The Notion sidebar is a good example — sub-pages appear only under the parent page when it's expanded.

The rule: don't show navigation items users haven't needed yet. Show them when the context makes them relevant.

Design your navigation in Figma

Navigation design is mostly information architecture and naming decisions. The visual execution matters, but getting the structure right first will have more impact than any UI refinement.