Navigation design: patterns for the website menu

In short

A good menu answers two questions: where am I, and where can I go? On this page I describe five patterns: the visible top menu, the mega menu, the hamburger menu, the bottom tab bar and the breadcrumb.

Which one you choose depends on the number of main links and on the device. What goes into the menu is a job of its own. That is called information architecture.

Visible top menu

The main sections sit side by side at the top of the page. Without tapping anything, the user sees what the website offers. On desktop this is the default choice.

NN/g recommends not using a hidden menu on desktop. The main links belong at the top of the page or along the left edge.

The limit of the top menu is space. When labels get longer or more numerous, the row wraps. Then shorten the labels or move the lower levels into expandable panels.

Mega menu

A mega menu is a wide panel that opens when the pointer reaches a main item. It shows the subpages in groups all at once. Nielsen and Li (NN/g, 2017) consider the mega menu a good choice when there are many options.

The same text gives concrete values for timing:

• The panel only opens once the pointer has rested for 0.5 seconds.
• When it opens, it does so within 0.1 seconds.
• When the pointer leaves the item and the panel, the panel stays open for another 0.5 seconds.

The panel can open on hover, on click or on tap. On a touchscreen there is no hover. A button that opens on click, on the other hand, works on every device.

Form the groups not by guesswork but with user data. NN/g recommends card sorting here; how that works is described in the guide to card sorting and tree testing. Each option should appear only once in the panel. The search field doesn’t belong in the panel but permanently visible on the page.

Hamburger menu: how invisible is it?

The hamburger menu is a menu hidden behind an icon of three horizontal lines. It saves space but has a price. Because users don’t see the menu, they may not think of using it.

Kara Pernice and Raluca Budiu measured this for NN/g in 2016. 179 participants worked on smartphones and desktops with 6 real websites. On each website they did 2 tasks, with the menu hidden, visible or combined.

How often navigation was used in the 2016 NN/g study

Device	Hidden menu	Visible menu	Combo (partly visible)
Desktop	27%	48%	50%
Mobile	57%	not tested	86%

Source: Pernice and Budiu, NN/g (2016). The shares give in how many tasks the navigation was used.

On desktop, visible and combo menus were used almost twice as often as the hidden one. When the menu was hidden, discoverability of content dropped by more than 20%. That showed on desktop and mobile.

Time got longer too. On desktop, participants with a hidden menu were at least 39% slower than with a visible or combo menu. On mobile, the hidden menu was 15% slower than the combo.

Participants rated the tasks from 1 (easy) to 7 (hard). The average difficulty was 2.6 for the hidden menu, 2.3 for the combo and 2.1 for the visible menu.

On mobile the picture is milder: the hidden menu was used in 57% of cases. According to the authors, it is more widespread on mobile, and people may be more used to it.

Their recommendation for mobile is clear. If there are four or fewer main links, show them all. If you hide more, also link important pages in the page content.

Budiu’s 2015 text on mobile navigation reaches the same conclusion. According to her, the hidden menu is the hardest layout to discover. Even someone who has opened it once may forget it later in the session.

Bottom tab bar

The tab bar is a bar fixed to the bottom edge of the screen that leads to a few main sections. It stays visible while scrolling. The user can switch between the main sections at any time.

Budiu (NN/g) describes the tab bar as a layout typical of apps. Its limit is the number of tabs. According to NN/g, it is hard to fit more than five options while keeping touch targets comfortably large.

How iOS and Android draw this bar differently is described in the guide to the differences between iOS and Android.

Put the frequently used sections in the bar. In the demo below, the return form sits in the Account tab. The user sees Account on the first screen but has to guess that the return form is there.

Breadcrumb navigation

A breadcrumb is a row of links that shows, in order, the parent pages of the current page. For example “Home > Kitchen > Pots”. In deep catalogues it gives users a shortcut one level up.

From Page Laubheimer’s NN/g guidelines, these rules help me most:

• The breadcrumb complements the main menu; it doesn’t replace it.
• It shows the website’s hierarchy, not the user’s history.
• The last entry is the current page and not a link.
• On flat websites with one or two levels it is unnecessary.
• On mobile it shouldn’t wrap over several lines. If space is short, you can consider showing only the last levels.

The language of labels

If the user doesn’t understand the label, even the best menu layout doesn’t help. Only the label tells them what is behind the link.

NN/g’s recommendations on the mega menu apply to every menu. Start the label with the most meaningful word and avoid made-up terms. Two labels side by side shouldn’t resemble each other.

The problem jargon creates in labels on corporate websites is described with examples in the guide corporate website UX. I test labels first with a tree test, because it needs no design.

Showing the active page

When users look at the menu, they should see which section they are in. You do that on two levels: a visible sign and an attribute for the screen reader.

The visible sign shouldn’t be colour alone. Under WCAG 2.2 success criterion 1.4.1 (level A), colour mustn’t be the only visual means of conveying information. For the active menu item, I use bold text and a line in addition to colour.

In the code, the link to the current page gets aria-current="page". According to MDN, only one element in a group is marked as current. In a multi-step flow, the value step is used for the current step.

Rules for accessible menus

Put the main menu in a <nav> element. Its implicit ARIA role is navigation, a navigation region (landmark). If there are several nav elements on the page, give each its own name, such as “Main menu” and “Breadcrumb”.

For expandable menus, the W3C’s ARIA Authoring Practices Guide (APG) provides a ready-made example: the disclosure navigation menu. In it, each main item is a button. On the button, aria-expanded says whether the panel is open and aria-controls which panel it opens.

The keyboard behaviour is simple. Tab moves between the buttons and the links in the open panel. Enter or Space opens and closes the panel. Esc closes an open panel and returns focus to the panel’s button.

The APG doesn’t use role="menu" in this example. The reason: typical website navigation doesn’t need all the keyboard interactions that the menu and menubar pattern defines. For an ordinary website menu, buttons and links are enough.

Live example: three menus, one task

Below is the menu of the same made-up store in three layouts. Your task is to start a return. Choose a layout and navigate the menu on the phone.

Three menus, one task

This demo runs with JavaScript. Summed up without JavaScript: in the same store, you reach the return form in 2 clicks with a visible top menu, in 3 with a hamburger and in 2 with a bottom tab bar. With the hamburger, not a single menu option is visible on the first screen.

A made-up store with invented menu labels. Every click counts as a step: opening a menu, closing it, a tab and a link. Visible options are the clickable menu entries currently on the screen; the hamburger icon doesn’t count. Esc closes an open menu and returns focus to its button. This is your personal attempt, not a test result. Nothing is stored.

In all three layouts, the shortest path is two or three clicks. The real difference is on the first screen: with the hamburger, not a single menu option is visible. If the user doesn’t think of tapping the icon, the path never starts.

The menus follow the APG’s disclosure pattern. Try it with the keyboard: move with Tab, open with Enter, close with Esc.

Which layout when

On most websites, several layouts work together. For example, a mega menu and breadcrumb on desktop, and a few visible links plus a hamburger on mobile. The table below sums up where each helps.

Navigation layouts and where they fit

Layout	Where it works well	Watch out
Visible top menu	Desktop; mobile with 4 or fewer main links	Needs space; long labels don’t fit
Mega menu	Catalogues with many categories, large corporate websites	Grouping and hover timing
Hamburger	Secondary links on mobile	Don’t hide main tasks
Bottom tab bar	Apps, a few frequently switched main sections	More than 5 destinations are hard to fit
Breadcrumb	Deep hierarchy, category pages	Doesn’t replace the main menu

For most websites I consider the combo layout the most balanced choice. Keep the two or three most used sections visible and put the rest in the menu.

How to test the menu

Before launch, test two different things. First the structure: is the right content under the right item? Second visibility: does the user find the menu on the screen?

You measure the structure with a tree test. You give the user a tree made only of labels and ask: “Where would you start a return?” That works even before there is a design.

Visibility has to be measured on the real screen. A first-click test shows where the user taps at the start of the task. A usability test with a few people also shows right away who never opens the hamburger.

My note

The most common menu mistake in my audits: the main task is hidden in the hamburger. The team opens the menu every day and doesn’t notice that something is hidden there. New users don’t tap the icon at all.

Before I decide on a menu, I write down the five most common tasks. For these tasks there has to be a visible path from the first screen. Everything else may go into the menu.

If you want someone from outside to look at your website’s menu: the UX audit reviews one flow from start to finish and delivers a prioritised list of fixes.