Navigation
Concept
The machinery that carries people from one screen to another while telling them where they are standing and where they can go from here.
Why it exists
The same problem repeats from the moment a product passes ten screens. The person who built it holds the whole layout in their head and knows which screen hangs off which. Somebody arriving for the first time has only the one screen in front of them. Where they are now, what else exists besides this, and how to get back to the place they just left cannot be worked out at all unless the screen says so.
Early Pagedeck went exactly this way. There were six screens when the doors opened, and six links laid across the top were enough. The trouble came afterwards. Every time Theo attached a feature, one more link appeared in that row, and a year later nineteen of them were pressed into a single line. The row overflowed, so the text got smaller. It still overflowed, so the less-used entries were pushed toward the end. Which ones got pushed back was settled by whoever spoke loudest that week.
The consequence reached Sofia first. Every customer training session brought the same question: where is the setting that turns a document into a shared one? That setting lived inside the twelfth of the nineteen links. People were not failing to use a feature that did not exist; they were failing to use one whose location they could not find, and thirty tickets of that kind piled up every month.
Navigation is the promise to stop solving this screen by screen. Rather than deciding where to hang a link each time a feature appears, a team decides up front how the whole product divides into a handful of groups, and where on screen and in what shape each group sits. Features that arrive later find a place among the ones that already exist. If there is nowhere to put a new feature, the shortage is not of space; it is a signal that nobody has yet decided which branch of the product the feature belongs to.
The division of labour with information architecture, sitting directly above, is worth keeping straight. Information architecture is the skeleton that decides how content is split into groups and what each group is called. Navigation is the part that brings that skeleton onto the screen so a finger can actually travel along it. Get the skeleton wrong and people wander no matter how polished the menu on top of it; get the skeleton right and leave it unexposed by any menu, and it may as well not be there.
How this field breaks down
The terms under navigation split into two branches. How far a menu takes responsibility is scope. What shape it takes on the screen is form. Scope comes out of how the product was divided in the first place, and form comes out of how to draw that division for a given screen size and situation.
Scope divides on how many screens a menu follows you across. There are three places.
- Global navigation — the top-level menu that looks the same wherever you are. At Pagedeck that is where the large branches of the product go: documents, teams, templates. Its entries are always on screen, which makes this the most expensive real estate in the product, so teams usually hold it to somewhere between five and seven items.
- Local navigation — the lower menu that appears only once you have entered a particular area. Members, permissions, and billing show up after you step into the team screen, and not before. Nobody outside that area ever sees these entries, so adding more of them costs little. The flip side is that people outside the area do not know such a feature exists at all, which is why anything a first-time user has to pass through does not belong here.
- Utility navigation — the menu that gathers the things helping from the side, such as account and settings, rather than branches of the product itself. They are not used often, but at the moment they are needed they have to be found, so they sit in a corner like the top right of the screen, in the same place every time. At Pagedeck, pressing the account picture in the top right opens profile, notification settings, and sign-out in that same order every time. Change that order once and the people who had stopped looking before pressing are the first to get lost.
The relationship among the three resembles the scales of a map. Global is the map of the country, local is the map of a city inside it, and utility is the legend attached to every map regardless of scale.
Form is how the same scope gets drawn on the screen. Five shapes come up constantly.
- Breadcrumb — the current position written out in one line together with the path above it. Documents › Team documents › 2026 plan settles where you are and how to climb one level in the same stroke. It earns its keep in products more than three levels deep. Attach one to a product only two levels deep and it takes up a line while telling the reader nothing they did not know.
- Tab bar — three or four slots holding the main branches along the bottom of a mobile screen. It sits where a thumb lands, so moving is fast, but past five slots the labels smear together, which makes what to leave out a harder decision than what to put in.
- Sidebar — a tall vertical strip down the side of the screen. Vertical space stretches more easily than horizontal, so twenty items fit, and collapsing and expanding sections shows hierarchy at the same time. Document tools and admin screens mostly take this shape. The catch is that the longer it runs, the more the lower entries need a scroll to reach, and an entry pushed that far down is in much the same position as one that has been folded away.
- Hamburger menu — the whole menu folded away behind an icon of three lines. It eats the least screen of any option, but what is folded is not seen, and what is not seen does not get used much. It reads less as a choice than as what you reach for when a narrow screen leaves nothing else.
- Mega menu — a large panel that opens everything under one item at once when the pointer lands on it. It suits products that are wide and shallow, like a shop with several hundred kinds of goods. The price of showing everything in a single view is that it covers more than half the screen. Used on a product that is narrow and deep instead, half of the opened panel sits empty.
Scope and form are not two menus chosen separately; they come in pairs. The same global navigation sits as a sidebar on a desktop and as a tab bar on a phone. A narrower screen does not mean dropping entries but redrawing the same entries in another shape, and which of them make it into the five slots of a tab bar while the rest go behind the hamburger says plainly what that product considers important.
How it sounds at work
"This shouldn't go up into global, it should come down to local. It's only used inside the team screen."
The feature is not used often enough to follow people onto every screen, so the proposal is to show it only inside the area it belongs to. Moving it down also puts it closer to the people who actually use it.
"The tab bar has five slots and you're asking for a sixth, so one of the current five has to come out."
Where the number of slots is fixed, what to add is the same question as what to remove. Anyone arguing for a sixth needs evidence that it gets used more than one of the five already there.
"Putting it behind the hamburger will hurt the numbers. Last time we folded search away, usage halved."
A warning that anything sent behind a folded menu gets treated as though it were gone, backed by a figure this product already lived through.
When Pagedeck released its document template feature, this conversation ran for three days. Mia wanted templates in the top-level menu to shorten the time it takes a new signup to create their first document, and Noa answered that the top row already held five slots, so something had to come out. The candidate for removal was search, and that proposal folded when Ravi arrived with a figure: people who had used search came back the following week at twice the rate of people who had not.
What they changed was the location. Templates went not into global but into the first row of the local menu on the document list screen, and in exchange a small marker was attached in the top row for accounts less than two weeks old. Theo pulled the numbers a week later, and the share of people who opened a template fell short of the target while search usage held steady. Mia closed it out by deciding that instead of widening the top row, the team would revisit the order of items inside the local menu.
What people get wrong
The most common mistake is believing that showing more menu is kinder. If what someone wants is already on the screen, it takes one press, which makes the reasoning easy to follow. What actually happens is that the time it takes to pick one item grows along with the number of options, and past a certain line people stop reading rather than choosing. In the era when nineteen entries ran across the top of Pagedeck, four of them were getting pressed, and the other fifteen did not reach double-digit clicks over a month. Left alone, the entries nobody uses eat into the space belonging to the ones everybody uses. A menu is closer to a display shelf than a warehouse, and a shelf holding all the stock makes nothing stand out. For a product with genuinely many items, the better move is not a longer menu but work on search UX, the branch covering the experience from typing a query to reading the results. For someone who knows the name of what they want, one input box beats ten menu slots.
The other mistake is treating navigation as decoration laid on at the end of design. The visible shape of the menu looks like the whole deliverable, which invites that reading. But the names and groupings written into a menu were settled a step earlier, and those names go on working off the screen. They land in the address bar, they appear as titles in search results, and they get quoted back in support tickets. Rename the group called team documents to workspace and it is not only the menu text that moves: help articles, training material, and the words customers have been using all fall out of alignment at once. That is why this work starts by deciding how many branches there are before any screen gets drawn. Draw the screens first because the schedule is tight and the cost of fixing the names later runs higher than the cost of fixing the screens.
Where to go next
- Information architecture
see where the names and groupings in a menu are decided. When a navigation fix stalls, the answer is usually on this side
- Global navigation
the most expensive of the three scopes, so reading it first makes the rest of the calls easier. It also covers where that figure of five to seven items comes from
Sub-terms
Last updated 2026-09-16