Patterns Ux
Hick's Law: Why More Nav Items Slow Users Down
Reading level
The nav that grew too helpful
A SaaS product's top navigation started with 4 items. Over three years, the product grew. The nav grew with it — to 5, then 7, then 9 items. Each addition made sense in isolation: "We added reporting, we need a Reports link." "We launched integrations, we need an Integrations link." Nobody ever removed anything.
User research revealed something counterintuitive: the 9-item nav had a lower click-through rate than the old 4-item nav, even for features users needed frequently. More choices — more time spent deciding. More time deciding — more users who just didn't click.
Hick's Law: RT = b·log₂(n + 1). Reaction time scales logarithmically with the number of choices. A nav with 9 items isn't 2.25× harder to scan than a nav with 4 — it's harder by log₂(10)/log₂(5), or about 1.43× — and that's before accounting for the additional visual scanning time, which is additive.
Hick's Law applies cleanly to flat navigation lists. It breaks down for hierarchical structures (mega-menus, dropdowns) because categorization can reduce the effective n from total items to items per visible group. A mega-menu with 5 categories of 4 items each presents n=5 at first glance, not n=20 — assuming the categories are well-matched to the user's mental model.
When to cut, when to group
The audit method: Take every item in your navigation and classify it by last-month click volume. Items that appear in the top 20% of clicks should be top-level. Everything else is a candidate for grouping or removal.
A common finding: 3–4 items handle 80% of nav clicks. The remaining 5–6 items split the other 20%. Those tail items are still needed — but they don't deserve equal visual weight and decision cost as the top-4.
// Navigation hierarchy signal: n items at this level
// Hick's law cost grows with n
// Grouping strategy: reduce visible n via categories
// ❌ Flat 9-item nav — n=9, RT penalty applies to all choices
['Dashboard', 'Reports', 'Campaigns', 'Audience',
'Integrations', 'Templates', 'Settings', 'Help', 'Billing']
// ✅ Grouped to 4+1 — primary n=5 at top level
['Dashboard', 'Campaigns', 'Audience', 'Reports', '⋯ More']
// "More" expands: Templates, Integrations, Billing, Help, Settings
// Power users learn to go directly; casual users use top-4The "More" overflow pattern reduces cognitive decision cost for the 80% use case while preserving discoverability for the 20%.
Hick's Law and Miller's 7±2 are separate but compounding. Miller constrains working memory (how many things you can hold in mind at once); Hick constrains decision time (how long choosing takes). A 9-item nav both slows the choice (Hick) and may overflow working memory during scanning (Miller). Keeping primary nav items to 5–6 addresses both constraints simultaneously.
Contextual navigation is often better than global navigation for complex apps. Surfacing relevant sub-items based on current page/context reduces effective n without requiring the user to learn a hierarchy. The tradeoff: contextual nav requires more work to implement and test across states.
The nav that grew to match the org chart
A SaaS product had a top navigation with 11 items after three years of feature expansion. Each item had been added when a feature team launched: Campaigns, Audiences, Reports, Integrations, Templates, Analytics, Billing, Settings, Help, API Docs, and What's New. The pattern was consistent — each team wanted visible top-level access for their feature. Nobody ever removed anything because removing an item felt like deprioritising a team's work.
User testing revealed the hidden cost. Session recordings showed users hovering over the navigation for 4–6 seconds before clicking, frequently pausing mid-nav to scan back to the left. Heat maps showed near-equal hover density across all 11 items even for features users never used — the visual weight of a 11-item nav forced users to evaluate every item on every visit. Time-on-nav correlated with early session churn: sessions where users spent over 3 seconds on the nav in the first 30 seconds had a 34% higher churn rate.
The org-chart nav is a predictable failure mode in product companies. Each team's feature deserves top-level placement from the team's perspective. The user's perspective is different: they have a task, they want the fastest path to it, and every additional item increases their decision cost. The product team's job is to reconcile these two views — and the correct answer is almost always to reduce visible items based on usage data, not perceived importance.
Grouping by user mental model, not product taxonomy
The team ran a card-sorting exercise with 12 existing users and 8 prospective users. The results were clear: users grouped the 11 items into four natural categories — "Do my work" (Campaigns, Audiences, Templates), "See results" (Reports, Analytics), "Manage my account" (Billing, Settings, API Docs), and "Get help" (Help, What's New, Integrations). The 11-item flat nav became 4 top-level items with grouped dropdowns.
An A/B test over three weeks measured time-to-first-click on target navigation items. The 4-item grouped nav was 58% faster on first-visit sessions and 31% faster on return sessions. Churn correlated with time-on-nav dropped from 34% to 18%. The key finding from user interviews: users described the old nav as "exhausting" and the new nav as "obvious" — even though all 11 features were still accessible, just one click deeper.
The card-sorting insight is transferable. Users do not organise navigation items the way product teams do. Product teams organise by feature ownership; users organise by their intent and workflow. The gap between these two mental models is where navigation friction lives. Closing it requires listening to users rather than defaulting to the org chart, and accepting that secondary placement does not mean deprioritisation — it means appropriate placement.
Pattern at a glance
<!-- ❌ 11-item flat nav: Hick's Law cost paid on every interaction -->
<nav aria-label="Main">
<ul>
<li><a href="/campaigns">Campaigns</a></li>
<li><a href="/audiences">Audiences</a></li>
<li><a href="/reports">Reports</a></li>
<li><a href="/analytics">Analytics</a></li>
<li><a href="/integrations">Integrations</a></li>
<li><a href="/templates">Templates</a></li>
<li><a href="/settings">Settings</a></li>
<li><a href="/billing">Billing</a></li>
<li><a href="/api">API Docs</a></li>
<li><a href="/help">Help</a></li>
<li><a href="/whats-new">What's New</a></li>
</ul>
</nav><!-- ✅ 4 top-level items: n=4 decision cost. Sub-items on expand -->
<nav aria-label="Main">
<ul>
<li>
<a href="/campaigns">Work</a>
<ul class="dropdown">
<li><a href="/campaigns">Campaigns</a></li>
<li><a href="/audiences">Audiences</a></li>
<li><a href="/templates">Templates</a></li>
</ul>
</li>
<li>
<a href="/reports">Results</a>
<ul class="dropdown">
<li><a href="/reports">Reports</a></li>
<li><a href="/analytics">Analytics</a></li>
</ul>
</li>
<li><a href="/settings">Account</a></li>
<li><a href="/help">Help</a></li>
</ul>
</nav>Try it: find a target item faster
Both versions contain the same navigation items. The "Long" nav shows all 9 items flat. The "Short" nav groups them into 5 primary + 1 overflow. Try to find "Billing" in both — notice the scan time difference even though you know what you're looking for.
The demo measures time-to-click across 5 navigation targets in each mode. The grouped nav is consistently 25–40% faster on first-time scans — the Hick's Law prediction holds even in a demo setting where users are primed to expect a task.
Pay attention to where your eyes go in the long nav. You're likely serially scanning every item — even the ones you recognize as wrong — before landing on the target. In the short nav, most eye movements are saccades to the category that matches your goal, not serial scans.
Showing: Short — 5 + overflow
Implementation depth
Hick's Law gives a quantitative prediction: RT = b · log₂(n + 1) where b is an empirically measured constant (~150ms for visual scanning tasks) and n is the number of equally probable choices. For an 11-item nav, predicted scan time is 150 · log₂(12) ≈ 537ms. For a 4-item nav: 150 · log₂(5) ≈ 348ms. That 189ms difference compounds across every navigation action in a session. For a user who navigates 20 times per session, the 11-item nav costs ~3.8 seconds more per session in decision time alone.
// Hick's Law decision time estimate (b = 150ms empirical)
function hicksRT(n, b = 150) {
return b * Math.log2(n + 1);
}
hicksRT(11); // 537ms — 11-item flat nav
hicksRT(4); // 348ms — 4-item grouped nav
hicksRT(5); // 387ms — 5-item + overflow pattern
// Decision time saved per navigation action: ~189ms
// Across 20 nav actions per session: ~3.8s saved per sessionNavigation architecture pitfalls:
- Groupings that match the org chart, not user intent — the most common failure mode. "Our data team owns Analytics and Reports" is not a user-facing category. "See how things are performing" is. Card sorting with 20 users before grouping items is the minimum viable validation.
- Dropdown hover delay — navigation dropdowns must use a 100–200ms hover delay before opening to prevent accidental trigger when the cursor passes over the nav item. CSS-only dropdowns on
:hoverwith no delay cause constant unintended openings. - Keyboard accessibility of grouped nav — dropdown items must be reachable via keyboard (
Taband arrow keys). Usearia-haspopup="true",aria-expanded, and ensure focus management opens/closes dropdowns correctly. An inaccessible grouped nav trades accessibility for visual simplicity. - Progressive disclosure vs burial — moving items to a dropdown must be validated against actual usage data. If an item moves to secondary and usage drops 80%, you have buried it, not organised it. Monitor click volume on secondary items after any navigation restructure.
References
Remember
Key takeaways
-
Every item you add to a nav increases the decision cost for all items. Trim ruthlessly — items that get under 5% of clicks should be in a secondary menu, not at the top level.Hick's Law: RT = b·log₂(n + 1). Flat nav growth is always a performance regression. Use analytics to identify the 20% of items that handle 80% of clicks — those deserve top-level placement.Mega-menus and overflow patterns work by reducing effective n from total items to items per category. This only holds when categories match the user's mental model — otherwise the scan becomes 2-level and slower, not faster.
-
Audit your nav by click volume, not feature importance. Frequently-clicked items should be easy to reach; rarely-used items should be discoverable but not demanding equal attention.Hick's Law and Miller's 7±2 compound: a long nav both slows decisions (Hick) and overflows working memory during scanning (Miller). The optimal range for top-level nav items is 4–6.Contextual navigation (surfacing sub-items based on current page) is the architectural solution to Hick's Law in complex apps. It reduces effective n to context-relevant items — but requires significant state modeling to implement correctly across all page states.
Keep going
Finish this takeaway, then continue the track — Casey saved your spot locally.
Sign in with email to sync progress across devices (beta).
Inside the Casebook
New cases every few weeks — patterns from production UI engineering. Double opt-in, easy unsubscribe.
No spam. Unsubscribe anytime. Emails sent via Buttondown.
RSS feed