The fastest way to know if your navigation makes sense before you commit to building it

Tree testing is a method for evaluating information architecture in isolation. Participants see a plain-text version of a site or app's navigation structure — no visual design, no search, just the category hierarchy and its labels — and are asked to locate specific items by navigating the tree.

The goal is to test whether the structure and labels make sense to users, stripped of visual cues that might compensate for a confusing organisation. If users can't find what they're looking for in a plain-text tree, they won't find it in the final product either — they'll just fail more slowly, guided by visual signposts that mask the underlying Information Architecture problem.

These two methods are often paired and sometimes confused. They answer different questions.

Card Sorting is generative — it helps you understand how users mentally group and label concepts. You run it early, when you're building a taxonomy from scratch or questioning whether your current categories reflect user thinking.

Tree testing is evaluative — it tests whether a proposed structure actually works. You run it after drafting an IA, to verify users can navigate it before committing to building it.

A solid IA research process typically runs card sorting first to inform the taxonomy, then tree testing to validate it. Skipping the validation step means the first time users encounter the structure is in a live product — a much more expensive way to learn it's wrong.

The setup is straightforward:

1. Map your navigation tree in plain text — every level, every label, no styling
2. Write task prompts asking participants to locate specific things ("Where would you go to update your billing information?")
3. Run the test remotely — tools like Optimal Workshop or Maze handle this; 20–30 participants is typically enough for clear patterns
4. Measure three things: first-click accuracy (which branch they opened first), overall success rate, and directness (whether they navigated without backtracking)

The tasks are the most important part to get right. Vague tasks produce noisy results. Tasks that echo the exact language of your navigation labels are too easy and will over-report success — write tasks using terms your users would naturally use, not terms from your system.

Tree testing surfaces two distinct problems that need different fixes.

Wrong categories — users consistently open the wrong top-level branch first. This suggests the category structure doesn't match how users think about where things belong. The fix is structural: reconsider the taxonomy.

Wrong labels — users navigate to the right branch but then struggle to find the item. This suggests the sub-level labels are ambiguous or misleading. The fix is a UX Writing problem: the categories are right but the words aren't landing.

Distinguishing between these before you start designing saves significant rework. A navigation redesign that fixes the wrong problem is worse than not redesigning at all — it creates a new set of failures while users are still adapting to the change.

Tree testing is most valuable when:

• You're redesigning a navigation system and want to validate the new structure before any design work begins
• User testing flags that people struggle to find things, but you're not sure whether the problem is structure or labelling
• You've run card sorting and want to verify the resulting taxonomy works under realistic task conditions

It's less useful for transactional flows — checkout, onboarding, form completion — where the sequence matters more than findability. And it won't surface problems that only appear in the full visual context; Prototyping handles those. Tree testing is specifically for answering one question: does this hierarchy make sense to the people who'll use it?