research methods
Tree testing
What is tree testing and what does it measure?
Tree testing checks whether people can find things in your site's structure, stripped of all visual design. You give them a text-only outline of the navigation and a task - "where would you go to do X?" - and watch which path they take. It isolates one question: is the information architecture itself findable, or is good design papering over a confusing structure?
Also known as: tree testing, reverse card sorting, findability testing
Prefer to watch?
Watch the recap 0:50
The demo
No design, no search - just the bare navigation labels. Your task: find where you'd go to return an item you bought. Click down through the tree.
What this demo shows (text version)
A site's navigation is shown as a plain text outline with no styling, icons or search - just nested labels like Orders, Products, Help and Account, each opening to sub-items. Given the task "return an item you bought", you click down through the tree to where you think it lives. Reaching a final item reports whether it was the right destination and the path you took.
Because everything visual is removed, success depends entirely on whether the categories and labels make sense - which is exactly what tree testing measures: the findability of the structure itself, via success rate, directness and first-click accuracy. It's the evaluative partner to card sorting, and it's best run before visual design, so you're not using polish to disguise a confusing structure.
Tree testing tests the skeleton, not the skin. By removing visuals, search and styling, it reveals whether your categories and labels actually lead people to the right place - measuring first-click accuracy, success rate and where they go wrong. It's the validating counterpart to card sorting: card sorting helps you build a structure, tree testing checks whether the structure you built works.
With no colours, icons or search to lean on - just the bare labels - finding the task suddenly depended entirely on whether the categories made sense. That's the point: tree testing exposes the structure on its own. If people get lost here, no amount of visual polish later will truly fix it; it just hides the wrong turns.
It works by subtraction. Strip away layout, imagery, search and brand, leave only the nested labels, and give a realistic task. Where someone clicks first, whether they reach the right destination, how often they backtrack, and where they go astray all become measurable - cleanly attributable to the structure and its wording, because nothing else is there to help or mislead.
The metrics are concrete: task success rate (did they end on the right node), directness (did they get there without backtracking), first-click accuracy (the first move is the strongest predictor of eventual success), and the specific wrong turns people take - which point straight at mislabelled or miscategorised sections.
Tree testing is the natural partner to card sorting. Card sorting is generative - it helps you discover how users group things and build a structure; tree testing is evaluative - it checks whether the structure you built is actually navigable. Run the tree test before you invest in visual design, so you're polishing a structure that works rather than decorating one that doesn't.