Testing navigation with real readers reveals problems that analytics and internal reviews often miss. This guide explains how to plan a lightweight study, observe people finding news, and turn their difficulties into specific menu improvements.
Define what you need to learn
Start with questions, not a preferred menu design. A useful navigation test might investigate whether readers can:
- Find the latest local news.
- Locate coverage of a particular topic, such as politics, business, sports, or climate.
- Distinguish news sections from opinion, analysis, reviews, and sponsored content.
- Find a story from a known date or event.
- Locate practical information such as newsletters, podcasts, corrections, or the contact page.
- Understand labels on desktop and mobile.
- Return to the homepage or move from one article to another.
Write these questions before recruiting participants. They help you choose the appropriate method and prevent the session from becoming a general discussion about whether the site “looks good.” Navigation testing is primarily about findability, comprehension, and confidence.
Decide which audience matters most. A regional news site may need local residents, occasional visitors, and readers who arrive from search or social media. If the site serves several communities, test them separately when their terminology or information needs differ.
Also decide what is in scope. You might test the main menu, section pages, article-page links, search, footer navigation, or all of them. A focused study of one navigation system usually produces more actionable results than an attempt to test every page at once.
Choose a testing method
Different methods answer different questions. You can combine them, but keep each activity focused.
| Method | Best for | Typical output |
|---|---|---|
| Moderated task test | Observing real behavior and confusion | Failed tasks, comments, design issues |
| Unmoderated task test | Getting more responses quickly | Completion rates and time estimates |
| Card sorting | Discovering how readers group topics | Suggested categories and labels |
| Tree testing | Evaluating a text-only hierarchy | Findability by menu location |
| Analytics review | Finding high-traffic or abandoned paths | Evidence about existing behavior |
A moderated task test is the best starting point for most news websites because it shows why a person hesitates. Use card sorting when you are creating categories or replacing unclear labels. Use tree testing when you already have a proposed hierarchy and want to compare alternatives without visual design distracting participants.
Avoid treating one method as proof that a menu is universally correct. Each method measures a different part of the experience. A card sort can suggest a category structure, but it does not show whether readers can use that structure under time pressure. A task test can expose a confusing label, but a small sample may not tell you how common the issue is.
Prepare the test materials
Create a short test plan containing the following:
- The research questions.
- The audience you want to recruit.
- The pages, prototype, or staging site being tested.
- The tasks participants will attempt.
- The order of the tasks.
- The information you will record.
- The privacy and recording consent process.
Use a realistic test environment. If the navigation behaves differently on mobile, test a real phone rather than relying only on a resized desktop browser. If the site is not ready, build a clickable prototype or a simple version of the menu. Make sure every link needed for a task works; otherwise participants may fail because of missing content rather than poor navigation.
Prepare a moderator script. It should explain that you are testing the website, not the participant, and that there are no right or wrong answers. Ask readers to think aloud, but do not repeatedly interrupt them. Useful prompts include “What are you looking for?” and “What would you try next?” Avoid prompts such as “Have you checked the Politics menu?” because they give away the answer.
For remote sessions, test the meeting software, screen sharing, audio, camera, and recording settings in advance. For in-person sessions, prepare a clean browser profile, disable unnecessary notifications, and have a backup device. If you record, obtain explicit permission and explain how the recording will be stored and who can access it.
Recruit the right readers
Recruit people who resemble the site’s actual audience. Existing subscribers, newsletter readers, social followers, or local community members can be useful, but do not recruit only staff and close colleagues. Employees already know the site’s structure and vocabulary, so their behavior will not represent new or occasional readers.
For a small formative study, begin with five to eight participants who match the priority audience. This is enough to uncover many recurring problems, especially when the test is focused. If the site has substantially different audiences, such as local readers and national readers, divide participants into meaningful groups instead of treating everyone as interchangeable.
Screen participants with simple questions:
- How often do you read news online?
- Which devices do you use most often?
- Do you live in or regularly follow the area covered by the publication?
- Which topics do you usually read?
- Have you visited this website before?
Avoid revealing the exact task during recruitment. If you tell someone that you are testing whether they can find “the local politics section,” they may pay unusual attention to that label.
Offer a reasonable incentive and keep the session short. Thirty to forty-five minutes is usually enough for a focused moderated test. Longer sessions can cause fatigue, especially when several tasks require searching or reading dense pages.
Write realistic navigation tasks
A good task gives participants a goal and enough context without naming the control they should use. For example:
- “You are interested in how the city is changing its public transport system. Find the part of the site where you would look for related coverage.”
- “You want to read the newest news about the local council. Show me how you would find it.”
- “You remember reading an article about a storm earlier this month. Find that article or explain how you would search for it.”
- “You want to receive regular updates without visiting the site every day. Find the available options.”
- “You are looking for the publication’s corrections policy. Where would you expect to find it?”
Do not build every task around a successful path you already know. Include common goals, edge cases, and tasks involving different entry points. A reader may enter through the homepage, an article shared by a friend, a search engine, or a newsletter. Test whether navigation still makes sense after those different starts.
Define success before the session. A participant might complete a task by reaching the correct section, identifying the correct destination, or explaining a credible route. Record partial success separately from complete failure. For instance, finding “News” but not “Local government” is different from not understanding the menu at all.
Keep task wording neutral. Do not say “Use the hamburger menu,” “Click the category,” or “Look in the footer.” Those are instructions for completing the task, not a test of navigation.
Run the moderated session
Begin with easy questions about the participant’s news habits, then explain the think-aloud process. Give them the website and the first task without describing the interface. Start a timer when the task begins and stop when the participant succeeds, asks for help, or gives up.
During the task, observe:
- Where the participant looks first.
- Which labels they notice or ignore.
- Whether they open and close menus repeatedly.
- Whether they use search instead of navigation.
- Whether they scroll past relevant links.
- The language they use to describe categories.
- Moments of hesitation, backtracking, or visible frustration.
- Whether they trust the destination after arriving there.
Use neutral follow-up questions after the participant finishes or abandons a task. Ask “What made you choose that?” or “What did you expect to happen?” Do not defend the design or explain the intended meaning of a label during the test. An explanation from the team may be useful later, but it cannot repair the participant’s recorded experience.
If a participant is stuck, wait briefly, then use a standardized rescue prompt such as “What would you try next?” If they still cannot proceed, mark the task as failed and move on. Giving different amounts of help to different people makes results harder to compare.
After the tasks, ask broad questions:
- Which parts felt easiest?
- Which labels were unclear?
- What would you expect to find in the main menu?
- Was anything missing?
- Did the site feel different on this device from other news sites you use?
These questions are useful, but observed behavior should carry more weight than opinions stated after the fact.
Add accessibility and device checks
Navigation must work for readers who use keyboards, screen readers, zoom, high contrast, or touch devices. Include at least a small accessibility pass even if the main study uses typical desktop participants.
Check whether a keyboard user can reach the menu, open it, move through items, close it, and understand the current location. Verify that focus is visible and does not become trapped behind an open overlay. On mobile, check that touch targets are large enough, menus do not close unexpectedly, and important destinations are not hidden behind gestures that readers may not discover.
A screen reader check should confirm that menu buttons have useful accessible names, expanded and collapsed states are announced, submenu relationships are understandable, and repeated links have enough context. Test headings and landmarks on section pages as well. A reader may technically reach a page while still being unable to understand the structure.
Do not rely on automated accessibility scanners alone. They can identify some code and contrast problems, but they cannot determine whether “More,” “Explore,” or “Other” communicates the correct destination to a reader. Pair automated checks with keyboard use and, where possible, feedback from people who use assistive technology.
Analyze the findings
After each session, write a short summary while the details are fresh. For every task, record the outcome, time, path, errors, assistance provided, and participant comments. Keep direct observations separate from your interpretation.
Group issues by pattern rather than by participant. For example, several readers may fail for different reasons that all point to the same problem: section labels are too broad, local coverage is buried, or the menu changes between the homepage and article pages.
Prioritize findings using three questions:
- How many participants experienced the issue?
- How severely did it block or delay the task?
- How important is the task to the publication and its readers?
A problem that affects two people but prevents them from finding emergency or breaking-news information may deserve more attention than a minor wording complaint from five people. Record the evidence, likely cause, recommendation, and any uncertainty.
Distinguish navigation problems from content problems. If a reader finds the correct section but the page contains no relevant articles, navigation may be working while content organization is not. If the right article exists but readers cannot recognize its section, both the label and the presentation may need attention.
Improve and retest the navigation
Turn each high-priority finding into a concrete change. Possible changes include:
- Replacing internal terminology with words readers use.
- Splitting an overloaded category into clearer sections.
- Moving high-value destinations into the primary navigation.
- Adding a visible local or regional entry point.
- Making article breadcrumbs and related-section links consistent.
- Improving search filters for date, topic, or location.
- Removing duplicate or low-value menu items.
- Keeping mobile and desktop labels consistent.
Change one major variable at a time when possible. If you rename a label, move it, and redesign the entire menu simultaneously, you may not know which change solved the problem. For larger redesigns, compare two versions with the same tasks and audience profile.
Retest the most serious failures with new readers. Returning participants may remember the earlier design and perform better because of familiarity. Use the same task intent but rewrite the wording slightly so participants are not simply repeating a memorized route.
After launch, monitor search refinements, abandoned menu interactions, internal search terms, popular landing pages, and paths to important sections. Analytics can show that readers are struggling, but it usually cannot explain what they expected a label to mean. Continue occasional reader sessions, especially after adding new sections or changing the publication’s coverage model.
Troubleshooting common problems
If participants finish every task unusually quickly, check whether they already know the website or whether the tasks are too obvious. Recruit less familiar readers and include goals that require distinguishing between neighboring categories.
If readers use site search for everything, do not automatically count that as failure. Search may be their preferred strategy. Investigate whether they can find the correct result, whether navigation still supports browsing, and whether the search results use useful filters and labels.
If participants disagree about the best category, the content may naturally belong in more than one place. Consider cross-links, tags, breadcrumbs, or a strong search experience instead of forcing every story into a single location.
If remote testing produces poor observations, ask participants to share their screen and narrate their actions, but avoid leading prompts. If network speed or unfamiliar software interferes, offer an in-person session or an unmoderated backup test.
If the sample is small, present findings as directional evidence rather than population-wide statistics. Small studies are valuable for discovering problems, but they cannot prove that a precise percentage of all readers will behave in a certain way.
Know the limitations
Readers’ behavior in a test is not identical to behavior during a breaking-news event, on a slow connection, or while distracted on a phone. Moderation can also influence behavior, and participants may be more patient than ordinary visitors. Treat timing and completion rates as useful signals, not universal benchmarks.
Navigation tests also cannot replace content strategy, technical monitoring, accessibility evaluation, or analytics. They work best as part of an ongoing cycle: identify a reader goal, test the current path, make a focused change, and verify that the change improves findability without creating new barriers.