Navigation audit worksheet
Not sure what needs fixing in your navigation? Before a redesign or research study, inspect important tasks, document possible problems, and leave with a summary of what to investigate next.
Complete the worksheet on screen, then print or save it as a PDF. See a completed example.
For the wider assessment process, see Information architecture assessment.
Entries are saved in this browser only.
Scope
Audit one navigation structure at a time. A main menu, mobile tab bar and signed-in area may offer different routes, even to the same users. Record which structure and version you inspected.
Priority tasks
List frequent or high-consequence user tasks. Describe each as a goal, such as "get money back for a late bus", rather than a menu label such as "Delay Repay". Before tree testing, turn these goals into neutral scenarios that do not reveal the intended destination. See Writing task instructions.
| # | Task, as the user's goal | Where it lives today | Who does it | Basis for priority | |
|---|---|---|---|---|---|
| Task 1 | |||||
| Task 2 | |||||
| Task 3 | |||||
| Task 4 | |||||
| Task 5 |
Inspection checklist
Tick an item after inspecting it, regardless of the result. Use its note for what you saw; add an observation record when evidence or a next check needs tracking. Ticks are not pass/fail scores.
Some of these conditions are deliberate and work well. The structure review in the Assessment guide covers when.
0 of 13 inspected
Routes to priority tasks
-
1.Coverage. For priority tasks that should be accessible through the navigation being audited, is there a route to each destination? Record missing or unclear routes.
-
2.Choices on the way. For each task, write down the labels you choose, in order. Note any step where more than one label could lead to the task.
-
3.Starting points. Start from a page where users commonly arrive, such as a top landing page in analytics. Can you reach the priority tasks from there without going back to the home page?
-
4.Hand-offs. Where a task spans two sections, such as paying a bill and then downloading the receipt, does each section link to the other?
-
5.Small screens. If navigation differs across desktop, mobile web or app views, which labels or routes move, merge or disappear? Inspect the versions your users rely on.
Labels
-
6.Label meaning. Which top-level labels use department names, product or brand names, or internal terms? Note each one and what it contains.
-
7.Overlap. Do any two labels describe content that could include the same priority task? Note the task and both labels.
-
8.Consistent wording. Do the menu label, destination heading and other links describe the same content or task consistently? Record meaningful differences.
Structure
-
9.Duplicates. Is any destination reachable under more than one label? Note whether each duplicate looks deliberate.
-
10.Content with no route. When you compare known content with the navigation, do some destinations appear to lack a menu route?
-
11.Thin sections. Does any section contain only one item, or none?
-
12.Mixed grouping. At any level, are sections grouped by different rules, such as topics next to audiences, or tasks next to department names?
-
13.Location. On deeper pages, what helps users identify their current location, such as a breadcrumb, active section or descriptive page title?
Observation log
Create a separate record for each observation, even when several relate to the same task.
- Observation
- What you observed in the navigation
- Evidence
- Screenshot, search log, report or other source
- Possible explanations (optional)
- What might explain this? Note alternatives if relevant.
- Open question (optional)
- What remains uncertain?
- Next check
- Test, data source or person to consult
No observations yet. Add one for each thing you noticed during the checklist.
Audit summary
Your selected findings, ordered by follow-up priority.
Still open
| Task 0 |
|---|
Choose the next check
Inspection identifies possible navigation issues. Use the appropriate follow-up to examine findability, competing explanations or missing content.
| If the open question is… | Next check |
|---|---|
| Can participants find the intended destination in the hierarchy? | Recreate the relevant navigation in a tree test, using neutrally worded task scenarios. How tree testing works |
| Can people complete the task in the interface? | Run a usability test on the live site or a realistic prototype. Observe where navigation controls, layout or page transitions help or hinder completion. Information architecture assessment |
| Is a label or the item's placement causing difficulty? | Use the current tree as a baseline. Compare controlled label or placement alternatives on matched tasks, keeping other changes stable. Patterns suggest explanations; they do not diagnose the cause by themselves. Assessment patterns table |
| Would a task's wording give away the answer? | Rewrite it before you test. Avoid leading tasks |
| How would users group this content at all? | An open card sort, when the sections themselves are in doubt. Open card sorting |
| Is the content missing, outdated or duplicated? | Review a content inventory with the content owner; check missing, obsolete or duplicate entries. IA deliverables |
| What happens after users search for this content? | Review query sequences, result clicks and repeat searches if available. To understand why people chose search, observe or ask them. |
| What would a redesign move or remove? | What a redesign deletes |
Completed example
Harbourline Transit is invented. The entries show how a finished sheet reads; they are not research results.
Show the exampleHide the example
Scope
| Field | Entry |
|---|---|
| Navigation audited | Main menu of the Harbourline Transit website: Tickets and fares · Plan a journey · Travel updates · Help · About us |
| Platform | Mobile web, checked against desktop. On mobile, Help moves from the menu to the footer. |
| Version and date | Screenshots of every menu level, taken 14 March |
| Users | Bus and ferry passengers, including regular and occasional riders |
| Auditor | Content designer, two years on the website, familiar with internal terms such as "Delay Repay" |
| Decision this informs | Which main-menu routes and labels should be tested before the summer release |
Priority tasks
| # | Task, as the user's goal | Where it lives today | Who does it | Basis for priority |
|---|---|---|---|---|
| 1 | Get money back for a late bus | Tickets and fares › Delay Repay | Commuters | A frequent support contact theme |
| 2 | Report a bag left on a bus | About us › Customer service › Lost property | Bus passengers | Frequent searches for "lost" in the site-search log |
| 3 | Find out whether the ferry is running in a storm | Plan a journey › Ferry › Timetables | Occasional riders | Contact-centre calls spike on stormy days |
Checklist notes (4 of 13 inspected)
- Choices on the way: Plan a journey › Ferry › Timetables. At the first step, Travel updates could also suggest ferry status, but it covers buses only.
- Small screens: On mobile, Help sits in the footer, below the timetable links.
- Consistent wording: Menu "Delay Repay", page title "Compensation for delays", footer link "Refunds".
- Mixed grouping: Top level mixes rider tasks (Tickets and fares, Plan a journey) with the organization (About us).
Observation log
| Task or item | Observation | Evidence | Possible explanations | Open question | Next check |
|---|---|---|---|---|---|
| Task 1 | The refund claim has three names: "Delay Repay" in the menu, "Compensation for delays" as the page title, "Refunds" in the footer. | Screenshots of menu, page and footer, 14 March | Riders do not recognize "Delay Repay" as the place to claim. Competing: riders find the page, and the claim form is where they give up. | Do riders looking for a refund open Tickets and fares at all? | Tree test of the current menu, with task 1 written as a scenario. Form completion figures from the analytics owner. |
| Task 2 | Lost property is three levels down under About us. | Menu screenshots; "lost" among frequent site searches | Riders look under Help, not About us. Competing: riders go straight to search whatever the menu says, and search finds the page. | Is search a workaround or simply the habit? | Review search-to-result paths, then compare observed navigation behavior or ask riders why they chose search. Then run a tree test using a neutral scenario for task 2. |
| Task 3 | Ferry service status sits under Plan a journey › Ferry › Timetables; Travel updates covers buses only. | Menu screenshots; Travel updates page content | The menu follows the company's bus and ferry divisions rather than the rider's question. Competing: ferry riders arrive on the timetable page from a search engine and never use the menu. | Where do riders land when they check ferry status? | Entry pages for ferry-status visits in analytics; ask the ferry team who updates the page. |
What a completed sheet shows
The worksheet documents observations from one version of a navigation. A tree test can evaluate whether participants find destinations in its hierarchy; prototype usability testing can examine whether they complete the full task. The inspection count is not a score.
This worksheet does not replace an SEO or accessibility audit.