Navigation design

Navigation is the part of the structure people touch on every page. When it works, nobody notices it. When it does not, visitors open menu after menu looking for a word that matches what they want, or give up and use site search, or leave. Navigation design is the work of making those choices easy: fewer, clearer options at each step, labels in your visitors' language, and signals that show where they are.

What navigation design covers

Global navigation. The main menu that appears on every page. We decide which sections earn a place there and in what order, and whether the menu needs a second level. Each label is chosen from the words your audiences use, checked against search logs and support enquiries.

Local navigation. The links within a section that let people move between sibling pages without returning to the main menu. On large sites this does more of the work than the main menu does.

Utility navigation. Links that matter on every page but are not sections: contact, sign in, accessibility information, language options. WCAG 2.2 success criterion 3.2.6 Consistent Help asks that help mechanisms such as "human contact details" appear in the same order relative to other content across pages, so we place them deliberately.

Breadcrumbs. A trail that shows where a page sits in the hierarchy and gives a one-click route back up. Google describes breadcrumbs as showing a page's position in the site hierarchy and helping people explore the site one level at a time. We specify where breadcrumbs appear and what they contain.

Footer navigation. A secondary map of the site for people who scroll to the bottom looking for something specific.

Contextual links. Links inside content that point to the next logical step. These belong partly to internal linking, and we coordinate the two.

Accessible menu behaviour

A menu has to work with a keyboard, with a screen reader and at high zoom, not only with a mouse. Our plans specify behaviour, not just structure. For dropdown menus we follow the W3C ARIA Authoring Practices example for disclosure navigation, which uses buttons to show and hide lists of links. The example explains that ordinary site menus do not need the full keyboard model of the ARIA menu and menubar pattern, which is why we do not recommend the menu role for them.

We also check WCAG 2.2 requirements that depend on structure:

• 3.2.3 Consistent Navigation (AA): menus that repeat keep the same order everywhere.
• 2.4.5 Multiple Ways (AA): more than one way exists to locate a page, such as menus plus search or a sitemap.
• 2.5.8 Target Size Minimum (AA): menu links and buttons are large enough to activate.

Our guide to accessible navigation patterns covers these in more detail.

How the work runs

1. Start from tasks. We agree the main audiences and the tasks each one comes to complete. A task list keeps the menu focused on visitors rather than on the organisation chart.
2. Review the current navigation. If you have an existing site, we map its menus and note where labels or groupings cause trouble. An audit can feed straight into this step.
3. Draft options. We prepare one or two candidate structures with labels, and explain the trade-offs between them.
4. Test, if included. A tree test shows whether people can find answers to real tasks using only the labels. We adjust whatever fails.
5. Specify. The final plan sets out every menu, its items, labels, order and behaviour, with notes for designers and developers.

What you receive

• A navigation map showing global, local, utility and footer menus.
• A label list with the reason behind each choice and rejected alternatives.
• Behaviour notes for keyboard, screen reader and small screens, referencing the W3C patterns.
• Breadcrumb rules: where they appear and how each level is named.
• A short governance note on how to add a new section without breaking the menu.
• Tree test results and changes made, if testing was included.

Signs your navigation needs work

• Menu labels match department names rather than visitor tasks.
• Several menu items lead to pages that cover the same thing.
• Your site search logs show people searching for items that are already in the menu, which suggests they cannot recognise the label.
• The mobile menu holds a different set of links from the desktop menu.
• Staff cannot agree where a new page should go.

What navigation design cannot fix

If the content underneath is duplicated or out of date, a new menu will lead people more quickly to the same confusion. In that case we recommend pairing navigation work with a content restructure. Navigation design also does not choose your visual style, although we can review a designer's work against the plan.

To sketch your current or proposed menu before talking to us, paste an outline into the hierarchy visualiser.

Questions about this topic

Do you design the visual look of the menu?

We specify structure, labels, behaviour and accessibility requirements. The visual design is done by your designer, working from our plan. We can review their mock-ups against it.

How many items should a main menu have?

There is no fixed number that suits every site. We size the menu to the number of distinct things your visitors come to do, then check by testing that people can choose between the items quickly.

Can you test the new navigation before it is built?

Yes. A tree test checks the structure and labels without any visual design. It is quoted as an optional extra because it needs participants and a testing tool.

Sources checked 4 November 2026 for navigation design

1. Multiple Ways (2.4.5), W3C
2. Consistent Help (3.2.6), W3C
3. Links, Google
4. Disclosure menu, W3C
5. Consistent Navigation (3.2.3), W3C
6. Breadcrumb markup, Google