In short
A navigation should hold roughly five to seven top-level items, labelled in the words visitors already use rather than your internal vocabulary. Structure matters less than naming: most navigation failures are people not recognising a label rather than a hierarchy being wrong. Test with a tree test before building, because that isolates whether people can find things from whether the page looks good.
Labels beat structure
The usual instinct when navigation is not working is to reorganise it. Usually the structure is fine and the words are wrong.
Someone looking for prices does not click "Solutions". Someone wanting to know if you handle their industry does not click "Approach". These labels make sense internally, where everyone knows what lives behind them. To a first-time visitor they are opaque.
Use the words your visitors use. Read your enquiries, your search queries, your support messages. If people write "how much", the label is "Pricing", not "Investment".
The test: could someone outside your organisation predict what is behind each label? If not, the label is the problem, whatever the structure looks like.
How many items
Five to seven at the top level works for most sites.
Below five, you are probably hiding things that deserve visibility. Above seven or eight, scanning becomes work, and items in the middle get overlooked.
This is not a rule from memory research — the "seven items" claim is widely misapplied — it is a practical observation about horizontal space and scanning. On a phone the constraint is different and usually forces a menu anyway.
If you genuinely have more, the answer is grouping, not a longer bar.
Order matters more than it looks
The first and last positions get the most attention. Put your most important item first, and your primary call to action last, visually distinct.
Order the rest by what visitors need, not by your org chart. "About" rarely deserves second position; "Work" or "Pricing" usually does.
When a mega menu helps
A mega menu — a large panel showing many options at once — is right when you have genuinely many destinations that people browse rather than search, and where seeing the range is itself useful. Retail categories, large service catalogues, documentation.
It is wrong when it is used to avoid deciding what matters. A mega menu with forty links because nobody would agree on eight is not navigation; it is an unresolved argument rendered in HTML.
If you use one: group with real headings, keep groups short, do not nest further, and make it keyboard-navigable — hover-only mega menus are a common accessibility failure.
The current page must be obvious
People need to know where they are. Mark the current section clearly, with more than colour alone — a weight change, an underline, or a marker, so it survives both greyscale and colour-blindness.
On deeper sites, breadcrumbs do this better than navigation highlighting, and they cost almost nothing.
Mobile
The hamburger icon is understood at this point. The argument against it is not comprehension but that hidden navigation is used less than visible navigation.
So on mobile, keep the one or two most important actions visible outside the menu — usually the primary CTA and perhaps search. Everything else can live behind the icon.
Inside the menu: full-width tap targets, at least 44px tall, an obvious close control, and no nesting deeper than one level. Multi-level accordions on a phone are where people give up.
Search is not a substitute
Adding search does not fix bad navigation. People search when browsing fails, and a site whose search is heavily used relative to its size usually has a navigation problem.
If you do offer search, look at the queries. They are the most direct statement available of what people cannot find — and they often name the labels you should have used.
Footer navigation is real navigation
People reaching the bottom of a page are looking for something. The footer is where secondary destinations belong: legal pages, detailed service lists, contact routes, careers.
That frees the header to stay short. Trying to make the header comprehensive is what produces navigation nobody can scan.
Test before you build
The cheapest and most useful test is a tree test: give people the structure as plain text, with no design, and ask them to find things. "Where would you look to find out what a redesign costs?"
It isolates the question — can people find things — from every visual factor. It takes an afternoon, needs no prototype, and consistently reveals label problems that no amount of internal discussion surfaces, because internally everyone already knows the answer.
After launch, look at where people actually click. Items nobody uses are candidates for the footer; heavy use of search points at what is missing.
If your site has grown and the navigation no longer matches what people come for, book a call.
Common questions
How many items should a navigation menu have?
Roughly five to seven at the top level. Fewer usually means something important is hidden; more makes scanning into work and causes middle items to be overlooked. If you genuinely have more destinations, group them or move secondary ones to the footer rather than lengthening the bar.
Why do people get lost in navigation?
Usually because of labels rather than structure. Terms like 'Solutions' or 'Approach' make sense internally where everyone knows what sits behind them, but a first-time visitor cannot predict it. Use the words visitors themselves use — if people write 'how much', the label is 'Pricing'.
When should I use a mega menu?
When you have many destinations people browse rather than search, and seeing the range is itself useful — retail categories, large catalogues, documentation. It is the wrong answer when it is used to avoid deciding what matters, which produces forty links and no hierarchy.
Is a hamburger menu bad for usability?
It is well understood at this point; the real issue is that hidden navigation gets used less than visible navigation. Keep the one or two most important actions visible outside the menu on mobile, and inside it use full-width tap targets of at least 44px with no nesting beyond one level.
How do you test navigation before building it?
Run a tree test: present the structure as plain text with no design and ask people where they would look to find specific things. It separates findability from visual factors, takes an afternoon, needs no prototype, and reliably surfaces label problems that internal discussion never does.
