Tree Testing
Validate your navigation structure before you design the interface around it. Tree testing strips away all visual design and asks users to find items in a text-only hierarchy — revealing whether the structure itself works.
01 — TL;DR
Two sentences.
Tree testing is a remote research method where participants navigate a text-only hierarchy — stripped of all visual design — to find specific items, with paths and success rates recorded. By removing all interface cues, it isolates the navigation structure as the variable, producing clean data on whether the IA supports findability independent of labels or layout.
The method became widely accessible through tools like Treejack (Optimal Workshop). A tree test can be designed, distributed to fifty participants, and analysed within a week — producing quantitative findability data that supports IA decisions with evidence rather than opinion.
02 — When to Use
Apply this when…
When NOT to apply it
Skip it when the navigation has fewer than ten items (too simple), when the problem is label clarity not structure (different test needed), when you need to understand why users struggle (pair with think-aloud), or when the product has no hierarchical navigation.
03 — How It Works
The mechanism
Tree testing shows users only text labels, no visual interface. Participants rely entirely on understanding what each label means and how categories relate. Success and failure is attributable directly to structure and labelling, not visual design.
Tree testing validates, it does not design
The correct sequence: card sorting generates a structure grounded in user mental models, then tree testing validates it under task conditions. Teams that skip card sorting and go directly to tree testing often discover failure but have no user-grounded alternative to build from.
04 — Real Example
Atlassian Confluence's two-stage IA validation
When Atlassian restructured Confluence's navigation, the team first conducted card sorting to understand how users organised the product's concepts. The card sort revealed users grouped features around work contexts rather than product feature areas.
The proposed IA was then tree tested with task scenarios from real use cases. The tree test identified two category labels causing significant first-click errors — before any visual design. Fixing those labels at the IA stage cost an afternoon; fixing the same problem after a visual design had been built would have required a redesign sprint.
05 — In the Wild
Test yourself & see real examples
No examples yet — be the first.
Spotted a navigation that was clearly never tested for findability — or one where the hierarchy feels so intuitive it must have been validated? Submit what you observed.
Seen Tree Testing skipped in a real product? Help grow the evidence base.
06 — Common Mistakes
Where teams go wrong
07 — Variations & Related Principles
Connected ideas
Tree testing occupies a specific, non-substitutable role in the IA validation toolkit.
The most important pairing is tree testing with card sorting. Card sorting without tree testing generates a structure that feels grounded but has never been tested under task conditions. Tree testing without card sorting validates a structure designed without user input. Run them sequentially: card sort to generate, tree test to validate.
08 — 10-Min Exercise
Run it right now
⏱ 10 minutes · Solo · No prep
1. Open any product you use regularly. Write down every item in the top-level navigation as a flat text list, exactly as labelled.
2. Without navigating, predict: where would you find notification preferences? Billing information? Help documentation? Note which item you would click first for each.
3. Now actually navigate. For each task, note whether your predicted first click was correct and how many clicks to reach the destination.
4. Any task where your predicted first click was wrong — even as a regular user — is a tree testing signal. If you clicked the wrong category, new users almost certainly do too. A tree test with real users would confirm and quantify the problem.