How many clicks should it take to find what you're looking for

Nearly every site brief carries the same line: "everything should be findable in two or three clicks." The team delivers it literally — five items in the top menu, three in each submenu, the number checks out. And the visitor still can't find pricing, still calls to ask "where's your pricing page," even though it's sitting right there as the third menu item.
The count was never the problem. This isn't a guess — a 2003 study tracked 44 users across 620 tasks and more than 8,000 clicks, and what it found runs against what most people assume.
Where the "three clicks" rule came from, and why it doesn't hold
The study started with a simple question: after how many clicks does a user give up? There was no fixed number. Successful tasks ranged from 2 to 25 clicks, and 80% of successful tasks took up to 15 clicks, not three. The most telling part: the click-count distribution for successful and unsuccessful attempts was nearly identical. Dissatisfaction ran between 46% and 61%, but that swing tracked the task itself, not the path length. The researchers' own conclusion is blunt: the three-click rule has no scientific basis.
The rule still gets repeated in client meetings anyway, because it's easy to remember and easy to measure — you can just count. But measurable isn't the same as correct. Squeezing a menu down to fit "three clicks" by merging sections that don't belong together doesn't fix anything; it hides the problem behind a tidier number.
The real problem is findability, not click count
Visitors don't count clicks. At every step they're answering one question: "is this taking me where I need to go?" If the answer isn't obvious, they leave — after the third click or the fifteenth, it makes no difference. So the real issue isn't depth, it's recognition: whether someone can tell which item is the right one at each step. And that almost always traces back to one thing — the label was written in the company's own vocabulary, not the customer's.
Menu labels are the customer's words, not your internal terms
Nielsen Norman Group's menu-design guidance says this plainly: link labels should use clear, specific, familiar wording — menus are not the place for invented terms, internal jargon, or abstract high-level categorization. In practice that gap looks like this: internally the offering is called "Integrated Digital Solutions," while the customer's actual search is "make my site faster." Without a bridge between those two phrasings, the visitor doesn't recognize themselves in your menu, even when the right service is sitting right there.
The five-person test
You don't need a tool to check this, just five people:
- Write each menu item's label on its own card.
- Give five people who don't work for the company a real task — "find the price on this site."
- Watch which card they reach for first. Don't prompt them.
- If someone second-guesses their first pick, that label isn't working — replace it with the phrase the tester actually used out loud.
Three examples across sectors
Internal jargon rarely stands out to the people who use it every day. Three cases:
- A clinic's menu says "Our Services," but the patient is looking for "which doctor, which day" — "Doctors and Office Hours" says the same thing in the patient's own words.
- An online store has a "Catalogue" section, but a shopper on their phone types "socks" into search — the search bar does the real work, so the section itself can just say "Products."
- An agency site labels a section "Portfolio," while a prospect wants to "see a similar project" — "Our Work" points at the same page in more familiar terms.
None of these are design failures. They're word choices, and fixing them costs five minutes of honest self-review, not a budget line.
How much depth is reasonable
Once the labels are right, the second question is depth. The same source draws a clear line here too: cascading dropdown menus get frustrating past two tiers, and going deeper than that is generally discouraged. A wide mega menu, by contrast, can surface two or three tiers at once, because the visitor sees the whole structure in one glance instead of opening a new panel at every step. Front-loading the key word in a label — "Pricing and plans" rather than "Plans, pricing and terms" — also helps the eye scan faster.
Navigation on mobile: one thumb, one hand
Most visitors open the menu on a phone, holding it in one hand and scrolling with a thumb, not on a desktop. That has two practical consequences. First, the hamburger icon needs the word "Menu" next to it — the icon alone means nothing to a meaningful share of visitors, especially an older audience. Second, the first three or four visible items should cover the most common needs (usually services, pricing, contact); everything else can sit under "More," because the further down the thumb has to travel, the less likely the tap. On a deep page, a short breadcrumb trail — "Home / Services / UX design" — lets someone step back up a level without hitting the browser's back button.
How to test navigation before rebuilding anything
The five-person test is a good start, but before a bigger change there's one more worth running: the first-click test. Give someone the task, show only the first screenshot of the page — no clicking through — and ask where they'd tap. If the share of correct answers is low, the problem isn't further down the site, it's that very first decision point. It's a test you can run in a single day, without redesigning anything or hiring a designer.
Visitors don't count clicks — they walk away the moment they stop recognizing the next step.
Navigation architecture isn't something you set once and forget. As the product list grows and new services get added, the old labels need to be re-tested. Sections added one at a time over the years each made sense on their own, but looked at together they've usually stopped adding up to a structure anyone can follow. That's exactly what our UX/UI design work, which rebuilds the visitor's path from scratch, is for — starting from what the customer is looking for at each step, not from a click count.