Skip to content
← Blog

Best practice

Navigation labels people understand

How to write navigation labels in your visitors’ words, show people where they are, keep the menu visible on desktop and test the labels before you build.

· 7 min read · Musab Alfawal

A website navigation bar with four plain labels. Services is bold and underlined, and the page title below it reads Services.

Navigation labels are the few words people read before they decide where to click. If those words make sense to them, they find what they came for. If they don’t, people guess, go back or leave.

Most unclear menus start inside the company. The team names sections after its own departments, or picks a word that sounded good in a brand workshop. Both make sense in a meeting and say very little to someone visiting for the first time.

How to write navigation labels people understand

Start with the words your visitors already use. You will find them in your site search logs, your support emails and the questions people ask on sales calls. If people search for “prices”, a label that says “Plans and packages” makes them translate before they click.

Labels like “Solutions”, “Explore” and “Resources” could sit on almost any website, which is why they tell a visitor nothing about yours. Someone looking for your rates has no reason to open “Solutions” before “Resources”. A plain label such as “Prices” or “Case studies” answers the question before the click.

Internal names fail in the same way. “Client Hub”, “Learning Centre” or the name of a product team mean something to the people who chose them. To a visitor they are a puzzle to solve before they can move on.

Keep the top level short. Every extra item makes the others slower to scan, and five or six is enough for most small sites. Make the labels parallel too: all nouns, or all short phrases of the same kind. “Work, Services, Prices, About, Contact” reads as one set. “Our work, What we do, Pricing info, Blog, Get in touch” reads as five different voices.

Put the word that carries the meaning first. People scan the start of each label and skip the rest, so “Prices for teams” works better than “For teams: our prices”.

Show people where they are

A good menu tells people two things: where they can go, and where they are now. The second matters most to people who arrive from a search result or a shared link, deep inside your site, without passing the home page.

Mark the current page in the navigation, and make the page title match the label that leads to it. If someone clicks “Prices”, the page they land on should say “Prices” at the top, not “Plans built for growth”. WCAG covers this in Success Criterion 2.4.8, Location, at level AAA: people should be able to tell where they are within a set of pages.

Use more than colour to mark the current item. A link that is only a different shade is easy to miss with colour blindness, on a washed-out screen or in bright sun. Success Criterion 1.4.1, Use of Color, asks that colour is never the only way information is shown. A heavier weight with an underline works on any screen. In the code, add aria-current="page" to the current link so screen readers announce it as well.

Hover shows what you can click, and after the click the marker and the page title move together.

The same header, fixed

Here is a studio website with a menu icon on a desktop screen and four brand words behind it, then the same header with its sections in view. The page content is the same in both. Only the navigation changed.

Before

A desktop site header with its menu icon open on four labels, Solutions, Explore, Insights and Connect, over a page titled What we do, marked with four numbered problems.
  1. On a desktop screen, every section hides behind a menu icon.
  2. “Solutions”, “Explore” and “Insights” could belong to any company. None says what is inside.
  3. The page title matches no label, so nothing tells you where you are.
  4. “Connect” is a clever word for Contact. People scan straight past it.

After

The same header with five visible labels, Work, Services, Prices, About and Contact. Services is bold and underlined and the page title reads Services, marked with three numbered fixes.
  1. Every section is on screen, named in the words visitors use.
  2. The current page is bold and underlined, so it doesn’t rely on colour.
  3. The page title repeats the label you clicked.

Keep the navigation visible on desktop

A menu icon saves space on a phone, where space is short. On a desktop screen there is usually room for five or six links, and hiding them costs more than it saves. Research by Nielsen Norman Group found that people use hidden navigation less, and find things less often, than navigation they can see. The effect was strongest on desktop.

Visible links do a second job as well. They tell a new visitor, at a glance, what the site offers. A closed menu hides that summary behind a click that many people never make.

On phones, a menu button is a fair trade. Put the word “Menu” next to the icon, keep the button in the same place on every page, and mark the current page inside the menu when it opens.

Mistakes, and what to do instead

  1. A site header whose links read “Solutions”, “Explore”, “Insights” and “Connect”.

    Don’t

    Brand words like “Solutions”, “Explore” or “Insights”.

    The same header with links that read “Services”, “Case studies”, “Prices” and “Contact”.

    Do

    Plain words visitors use: “Services”, “Case studies”, “Prices”.

  2. A site header whose links read “Client Hub”, “Learning Centre” and “Talent”.

    Don’t

    Sections named after your teams or internal projects.

    The same header with links that read “Client login”, “Guides” and “Jobs”.

    Do

    Sections named after what visitors want to find or do.

  3. A wide desktop header with only the site name and a menu icon, above the heading “Design for small teams”.

    Don’t

    A menu icon on a wide desktop screen.

    The same desktop header with four links in view beside the site name: Work, Services, Prices and Contact.

    Do

    Show the links. Keep the icon for narrow screens, with the word “Menu” beside it.

  4. A navigation where Services is marked only by blue text, above its code: a link with class="active".

    Don’t

    The current page shown by colour alone.

    The same navigation with Services bold and underlined, above its code: a link with aria-current="page".

    Do

    Bold weight and an underline, plus aria-current="page" in the code.

  5. Ten links wrapping onto two lines, from “Home” and “Our work” to “Case Studies” and “Get in touch”.

    Don’t

    Ten top-level items written in mixed styles.

    Five links, Work, Services, Prices, About and Contact, with About open on Team, Careers and Blog.

    Do

    A handful of parallel labels, with the rest grouped one level down.

  6. A navigation with Prices bold and underlined, over a page titled “Plans built for growth”.

    Don’t

    A page title that doesn’t match the label.

    The same navigation with Prices bold and underlined, over a page titled “Prices”.

    Do

    The same words in the menu and at the top of the page.

Test your labels before you build

You can test navigation labels before a single page exists. Two methods cover most of what you need to know.

A tree test shows people your menu as a plain text list, with no design, and asks where they would look for something. It tells you whether the labels and groups make sense on their own. A first-click test shows a screen and asks people where they would click to start a task. It tells you whether the labels still work once they sit in a real layout, next to everything else competing for attention.

Write the tasks with care. If you ask “Where would you find our prices?”, people will click “Prices” because the words match. Ask instead “Where would you find out what a website review costs?”, and you learn whether the label works for someone who doesn’t know your vocabulary.

  1. 1. Collect the words visitors use

    Read site search logs, support emails and sales notes. List the words people use for the things they want.

  2. 2. Draft the menu as a plain list

    Write the top level and one level below it, with every label in the same form.

  3. 3. Write tasks in everyday words

    Ask people to find something real, without using the words in your labels.

  4. 4. Run a tree test, then a first-click test

    Note where people look first and where they back out. The tree test checks the words, and the first-click test checks them in your layout.

  5. 5. Fix what failed and test again

    Rename or move whatever sends people the wrong way, then run the same tasks again.

Before you ship: a checklist

Questions people ask

Is the hamburger menu bad for UX?

Not on a phone, where space is short and most people know the icon. On desktop it hides options you have room to show, and people use hidden navigation less. If you use it, put the word “Menu” next to the icon.

How many items should a navigation bar have?

As few as your content allows. Five or six works for most small sites. If you need more, group the extras one level down instead of squeezing them into the top bar.

What is the difference between a tree test and a card sort?

A card sort asks people to group your content, which helps you find categories and the words for them. A tree test checks a menu you have already drafted, by asking people where they would look for things. Use the card sort to build the menu and the tree test to check it.

Resources

If this was useful, share it with someone it would help.