How Do You Design Mobile Navigation for a Site With Too Many Pages?

How do you design mobile navigation for a site with too many pages?

You stop trying to represent the site and start representing the journeys. A mobile menu cannot be a map of two hundred pages, and attempting it produces a scrolling list nobody reads. Pick the six to eight destinations that most visits actually need, and give everything else a different way in.

The hard part is not the design, it is the negotiation. Every section of a large site has somebody who believes it belongs in the main menu, and all of them are partly right. Somebody has to decide, and the decision has to be defensible on evidence rather than on seniority.

The reframing that usually helps is this. The menu is not a promise that everything is reachable from here. It is a claim about what most people came for. Reachability is the sitemap's job, and search's job, and the footer's job.

Why does the desktop menu never translate?

Because a desktop menu shows relationships and a mobile menu shows a queue. On a wide screen you can display three columns at once and a person understands the grouping instantly. Collapse that to one column and the grouping disappears, leaving a long vertical list where everything looks equally important.

The second difference is cost. On desktop, hovering over a menu is nearly free, so exploration is cheap and a large menu is tolerable. On a phone, every level is a deliberate tap and a small wait, and the person has already decided they are looking for something specific. Exploration is expensive, so browsing stops being the behaviour you are designing for.

What follows is that the mobile menu is not a smaller version of the desktop one. It is a different artefact with a different job, and the sites that get this right usually stopped trying to keep them consistent. Consistency in structure is worth less than being usable on the device the person is actually holding.

What actually belongs in the mobile menu?

The destinations that serve the reasons people arrive. Usually that is what you sell, who you are, proof that you are credible, a way to get in touch, and whatever the main content hub is. Five things, occasionally seven. If your list is longer, you are describing your organisation rather than the visitor's intent.

Work out the real list from behaviour rather than from the org chart. Look at where people go from the homepage, what they search for on the site, and what your sales conversations start with. Those three sources usually agree, and they usually disagree with the menu you currently have.

Name the items the way visitors would. Solutions is a word companies use and buyers do not. If your menu contains a word that would never appear in a customer's question, it is a label written for an internal audience, and it is costing you taps from people who could not tell it was relevant.

How deep should the menu go?

One level of nesting, occasionally two, never three. Each level you add removes a slice of the people who were willing to keep tapping, and the third level on a phone is essentially private. If something genuinely needs three levels to reach, it needs a landing page instead.

The better pattern for a deep site is to put the depth on a page rather than in the menu. Let the menu take somebody to a section landing page that lays out everything underneath it, with room to explain what each thing is. A page can afford description. A menu item is two or three words with no context.

That also gives you something a menu cannot: a place to be found. Section landing pages can rank, can be linked to, and can be cited. Menu structure does none of that. What such a page then does immediately under its hero decides whether the visit was worth anything, which I covered in the piece on the section right after the hero. Every time you push depth out of the menu and onto a page, you gain an asset instead of a fold-out.

What do you do with the pages that did not make it?

Give them three other routes in: the section landing pages above them, contextual links from related content, and a genuinely complete footer. Most traffic to deep pages on a large site does not arrive via the menu anyway. It arrives from search, from a link, or from the page before it.

The footer is underrated here and badly used almost everywhere. On a large site it can carry a full directory that nobody has to scroll past, because it sits after the content. That is the right place for completeness, and it lets the header be ruthless without anybody losing access to anything.

Contextual links matter more than either. A person reading about one of your services should find the adjacent one mentioned in a sentence, not in a nav they have to reopen. That is also how breadcrumbs earn their place on a deep site, which I argued in a separate piece.

Should search replace navigation on a big site?

No, but it should be visible, and on a genuinely large site it should be the first thing in the menu rather than an icon hidden in a corner. Search serves the people who know what they want. Navigation serves the people who do not. A big site has plenty of both.

The condition is that your search has to actually work. Site search on most business websites is poor, returns the wrong things, and has never been tested by anybody who did not already know where the content was. Promoting bad search is worse than hiding it, because it converts an uncertain visitor into a disappointed one.

So test it before you promote it. Take ten real questions from your inbox, type them into your own site search, and see whether the right page comes back. If it does not, fixing that is a better investment than another round of menu debate, and it is usually cheaper.

How do you handle the primary action?

Keep it out of the menu and permanently visible. If the main thing you want somebody to do is book a call or start a trial, that should be reachable without opening anything. The menu is for navigation, and burying your main action inside it means it only exists for people who were already looking around.

A small persistent element at the top or bottom of the screen does this without eating much space, which is the pattern I walked through in the tutorial on a sticky mobile call to action bar. The temptation is to make it large and sticky and animated, which converts a helpful presence into an obstruction on a small screen. Quiet and always there beats loud and intermittent.

Inside the menu itself, the action can be repeated at the end, where somebody who just read the whole list arrives without having found what they wanted. That is a good moment to offer a person to talk to rather than another page to visit.

What breaks when the menu gets long?

Three things, predictably. The items below the fold of the open menu stop being seen at all. The grouping becomes invisible, so everything reads as a flat list. And the close control drifts away from the thumb, which turns leaving the menu into a small annoyance that people remember.

The subtler failure is that a long menu changes what the site feels like. A short, confident menu suggests a company that knows what it does. A menu with fourteen items and four sub-levels suggests an organisation that could not agree, and visitors read that accurately even though they could not articulate it.

There is also a maintenance cost that shows up later. Long menus are edited by addition, never by subtraction, because removing an item requires a conversation and adding one does not. Two years in, nobody can explain half the entries and nobody will take responsibility for deleting them.

How do you test it honestly?

Give five people a real task on a real phone and watch without helping. Find the page about X. Work out whether Y is something this company does. Get to a place where you could ask a question. Watching somebody hesitate tells you more than any amount of analysis of click data.

Do not brief them, and do not explain the structure first. The moment you say the services are under Solutions, you have destroyed the test, because the thing you are testing is whether that label communicates on its own. Silence is the method.

Afterwards, look at where people tapped before they found the right thing. Wrong first taps are the most useful output of the whole exercise, because they tell you which label promised something it does not deliver. That is a naming fix, and naming fixes are cheap compared to restructuring.

What should you do next?

Open your own site on your phone and try to reach your three most important pages in two taps each. If you cannot, you have found the work, and it is probably a labelling problem before it is a structural one.

Then write down the five things most visitors actually come for, from evidence rather than from memory, and compare that list to your current menu. The gap between those two lists is the entire redesign, and it usually takes an afternoon to identify and a week to argue about.

If you have a large site where the menu has grown by accretion and nobody wants to be the person who cuts it, reach out. An outside opinion is often what unsticks that conversation, and the answer is usually less dramatic than everybody fears.