November 2026
A 4-Item Nav Menu Cuts Find-a-Page Time 22%
A four-item nav menu claims a 22% cut in find-a-page time, examined through information architecture and decision science for 2025 site builds
Four items. That is the whole navigation. No dropdowns, no mega-menu, no "Resources" catch-all. The claim — a four-item nav menu cuts find-a-page time by 22% — is the kind of number that sounds like it came from a usability vendor's slide deck, so it's worth asking where such a figure could plausibly come from, what it actually measures, and why the psychology of choice under constraint predicts it. The answer sits at the intersection of information architecture and decision science, and it has direct consequences for how Croatian agencies and in-house teams should be building sites in 2025 and beyond.
What a 22% improvement actually measures
Before treating the number as gospel, it helps to decompose it. "Find-a-page time" is not a single metric. In usability testing it usually means time-on-task for a locate-and-click exercise: a participant is given a page description ("find the page where you can request a refund") and the clock runs from the moment the prompt is read to the moment the correct page loads. That interval contains four distinct cognitive phases, and a nav menu can influence each of them differently.
First comes visual search: scanning the header for candidate targets. Second, semantic matching: deciding whether a label like "Solutions" or "Pricing" plausibly contains the thing you want. Third, commitment: the click itself, plus the small hesitation before it. Fourth, verification: the page loads and you confirm you're in the right place, or you hit back and start over.
A 22% reduction in total time is achievable almost entirely by attacking phases one and two. Fewer labels mean a shorter visual scan — the eye has less to sift. And when labels are fewer, each one tends to be broader and more carefully chosen, which paradoxically can improve semantic matching if the labels are concrete. The failure mode is the opposite: labels so broad ("Explore") that semantic matching becomes guesswork and participants burn time on the wrong branch.
This is where the number needs a health warning. A 22% average across a task set can hide enormous variance. If your four-item menu produces one spectacular misfire — say, burying contact details under "Company" — the average might still improve while a meaningful minority of users get lost entirely. Task-level medians and error rates matter more than the headline mean. Any team citing a 22% figure should be able to show you the per-task distribution, not just the aggregate.
There is also a selection effect worth naming. Teams that cut a menu from nine items to four usually do more than delete links. They rewrite labels, reorder by frequency of use, and often move secondary destinations into the footer or into contextual links inside pages. The measured gain is therefore a bundle: menu reduction plus relabelling plus redistribution. Attributing all of it to "four items" is generous. The honest framing is that a small, well-labelled primary menu is one lever among several, and the 22% is a plausible order of magnitude for the combined effect rather than a law of nature.
None of this undermines the core finding. It sharpens it. The interesting question is not whether four beats nine — it usually does — but why, and where the mechanism breaks down.
Choice overload and the cost of every extra link
The strongest theoretical backing for menu reduction comes from the decision-making literature, and it is more nuanced than the pop version.
Barry Schwartz's work on the paradox of choice popularised the idea that more options make people worse off. The academic reality is conditional: choice overload appears reliably when options are numerous, when they are hard to compare, when the decision is consequential, and when the chooser lacks expertise. A navigation menu is a near-perfect match for three of those four conditions. Nine top-level items are numerous enough to slow scanning; labels like "Solutions," "Offerings," and "Capabilities" are genuinely hard to distinguish; and most visitors arrive without a mental model of your site's taxonomy. The fourth condition — consequence — is usually low, which is why the effect is a slowdown rather than paralysis.
The more precise mechanism is Hick's law, one of the oldest findings in experimental psychology: reaction time increases logarithmically with the number of alternatives. Going from four to nine items does not double decision time, but it does add a measurable increment, and that increment is paid on every single visit. Hick's law also explains why the labels matter as much as the count. Reaction time depends on the information content of the stimulus set, and near-synonymous labels carry low information — they don't help you discriminate, so they cost time without buying clarity.
Then there is loss aversion, Kahneman and Tversky's finding that losses loom larger than equivalent gains. In navigation terms, every additional top-level link is a small bet the visitor must place. Click "Resources" and you might find the whitepaper — or you might land on a page of dead PDFs and have to back out. The anticipated cost of a wrong click is felt more keenly than the anticipated reward of a right one, so a longer menu raises the perceived stakes of every choice. A four-item menu reduces the number of bets and, crucially, makes each bet feel safer because the categories are broad enough to forgive a near-miss.
There is a countervailing force the choice-overload narrative usually ignores: recognition over recall. Nielsen's heuristic is unambiguous — users should not have to remember where something lives; they should be able to recognise it. This is the argument for richer menus, and it is why naive menu-cutting fails. If trimming to four items forces users to guess which of four broad buckets contains the page they want, you have traded a scanning cost for a recall cost, and recall is the more expensive of the two. The four-item menu only wins when its labels are concrete enough that recognition still works. "Pricing" and "Contact" pass this test. "Platform" and "Ecosystem" do not.
The practical synthesis: minimise the number of top-level choices while maximising the concreteness of each label. Those two goals pull in opposite directions, and the 22% figure is what you get when a team resolves the tension well rather than by simply deleting links.
The reinforcement loop that keeps bad menus alive
If four items are better, why do so many sites carry nine? The answer is organisational, not cognitive, and it is where behavioural psychology gets uncomfortable.
Adding a nav item is a variable-ratio reinforcement schedule for the person requesting it. A product manager asks for a top-level link to the new feature. Sometimes it produces a measurable lift in feature discovery; sometimes it does nothing. The request is cheap, the outcome is intermittent, and intermittent rewards are the most persistent kind — the same schedule that makes slot-machine behaviour so durable in the lab makes "just add it to the nav" so durable in organisations. Nobody ever runs the experiment in reverse, removing an item and measuring the cost, so the menu only ever grows.
There is a second loop: status. A top-level nav item is a visible signal of a team's importance. Moving "Partners" into the footer reads, to the partners team, as a demotion. This is a social and political cost, not a usability one, and it explains why menu audits so often stall after the easy wins. The behavioural insight is that removal is framed as loss (loss aversion again, now on the internal stakeholder's side), and losses are resisted more strongly than equivalent gains are pursued. A team will fight harder to keep a link than it would fight to add one.
The way out is to make the trade explicit and measurable. Instead of arguing about whether an item deserves top-level placement, instrument it. Track click-through rate on each top-level item as a share of total nav clicks, and track the task success rate for the destinations underneath. An item that receives 0.4% of nav clicks and whose destination is reachable in two clicks from a broader category is a candidate for demotion — and now the conversation is about numbers rather than status. This is also where the 22% figure earns its keep: it gives the team a shared estimate of what the clutter costs, which changes the default from "prove it should be removed" to "prove it should stay."
Designing the four: labelling, ordering, and the Croatian context
Assuming the decision to cut is made, the design work begins. Three levers matter most.
Label concreteness. Prefer nouns your users already use. If analytics show people search for "cijene" or "kontakt," those words belong in the nav, not their English equivalents. This is not a stylistic preference; it is recognition over recall applied to language. Croatian audiences are comfortable with English in tech contexts but not uniformly so, and mixed-language menus ("Solutions" next to "O nama") impose a small switching cost on every scan.
Ordering by frequency, not by org chart. The leftmost items get disproportionate attention. Put the highest-traffic destination first and the highest-intent destination (usually pricing or contact) last, where it serves as the terminal option for users who have scanned and not found what they need. Resist the urge to order by internal hierarchy.
One escape hatch. A four-item menu works best when there is a visible search field or a clearly labelled "All pages" affordance nearby. This resolves the recognition-versus-recall tension directly: the menu stays small, but nobody is trapped. The escape hatch should be visually secondary so it doesn't reintroduce the scanning cost you just removed.
A concrete illustration. A Zagreb-based B2B software firm we can call Studio Verbena rebuilt its marketing site around a four-item menu — Proizvod, Cijene, Primjeri, Kontakt — after a heuristic review found nine top-level items, three of which were near-synonyms. In moderated testing with twelve participants, median time to locate the pricing page fell from 14.2 seconds to 11.0 seconds, a 22.5% reduction; time to locate a customer case study fell 19%; but time to locate the careers page rose 31%, because "Karijere" had been demoted to the footer. The aggregate looked like a clean win. The per-task data told a more useful story: the menu reduction helped the high-traffic tasks and hurt one low-traffic task that the team then fixed by adding a footer link with a clearer label. That is what good menu work looks like — not a single number, but a distribution you are willing to read.
The Croatian context adds two practical notes. First, many domestic sites serve both B2B and B2C audiences from one header; four items is often too few for that dual mandate, and the honest answer may be five or six with a segmented entry point. Second, mobile share in Croatia is high enough that the four-item menu should be designed mobile-first — a four-item horizontal bar collapses gracefully, whereas a nine-item bar becomes a hamburger that hides everything and defeats the purpose.
Where this goes next
The forward-looking question is not how many items belong in a nav menu. It is whether the top-level menu remains the primary way people find pages at all.
Search-first navigation, command palettes (the Cmd-K pattern popularised by developer tools), and AI-assisted site search are steadily absorbing the locate-a-page task. When a user can type "refund policy" into a persistent search field and land on the right page in one step, the menu's job shifts from wayfinding to orientation — telling a first-time visitor what kind of site this is and what the main offers are. That is a different design problem, and it favours small, confident, concrete menus even more strongly than the current paradigm does.
The teams that will be ahead in two years are the ones instrumenting this now. Log every nav click with its label and position. Run a quarterly task-based test with five to eight users and record per-task times, not just the average. Keep a running list of demoted items and their measured cost. Treat the 22% as a hypothesis your own data can confirm or refute, not a benchmark to cite.
And when the next request arrives to add a fifth item, ask the question the reinforcement loop is designed to suppress: what would we remove, and what would we measure to know whether we were right? A menu is a series of bets on what matters. Four is a good number because it forces the argument to be had out loud.