What is Tree Testing?

Tree testing (sometimes called reverse card sorting) is a usability method for evaluating a hierarchical structure, typically a site map or app navigation, by presenting it to participants as a plain text "tree" of nested categories and asking them to find where a specific item or task would live. Participants click down through the labels (Products, then Software, then Analytics) until they choose a destination, and the test records where they went, how directly, and how long it took. Because the tree is stripped of visual design, layout, search, and content, the method isolates one variable: whether the labels and the hierarchy, on their own, lead people where they expect to go. It is an information-architecture method, and it exists because the structures that look logical to the people who built them routinely fail the people who use them.

Tree Testing and Card Sorting

The two methods are complementary halves of IA research. Card sorting is generative: participants group content into categories that make sense to them, revealing their mental groupings so a structure can be designed. Tree testing is evaluative: a proposed structure is tested to see whether it works. The typical sequence is card sort, design the tree, tree test, revise, tree test again, and the second round is where the method's iteration pays off, because label changes are cheap to make and immediate to measure. Tree testing also serves as a baseline: running the existing navigation as a tree before a redesign quantifies the problem and gives the new structure something to beat.

The Metrics

Success. The share of participants who ended at a correct destination for each task. The headline number, reported per task, and the first place to find broken labels.

Directness. Whether participants reached their answer without backtracking. A task with high success and low directness has a structure people can navigate but not confidently, which usually means a label that is ambiguous at one level.

Time. How long each task took; slow tasks indicate hesitation between plausible-looking branches.

First click and destination paths. Where people went first, and where the failures ended up. A failure cluster at one wrong category is a finding about that category's label, not about the participants.

Running It Well

1. Write tasks as goals, without the labels.
"Find out how much the pro plan costs" rather than "find Pricing"; using the tree's own words in the task turns findability into word-matching, the same rule that governs task scenarios everywhere.

2. Test the whole tree, not a fragment.
Participants need the real breadth of choices at each level, including the tempting wrong ones, or the test flatters the structure.

3. Randomize task order and keep tasks to a handful.
Eight to ten tasks per participant is typical; more induces fatigue and learning effects.

4. Recruit enough to trust the percentages.
Tree testing is quantitative: fifty or more participants per tree gives success rates a usable margin, and unmoderated fielding to a screened panel makes that number routine rather than expensive.

5. Iterate on the labels, not the participants.
Failures are structure problems; fix the tree and re-test. Two or three rounds usually converge.

The Limitations

Tree testing evaluates the structure in isolation, which is its strength and its blind spot: real navigation has visual hierarchy, search, cross-links, and content previews that a text tree removes. High tree-test success does not guarantee a findable product, and a live-site first-click test or full usability study on the real interface is the confirming step. The method also says nothing about whether the content belongs in the structure at all, only whether it can be found where it is.

Where This Leaves You

Tree testing asks the one question a site map can't answer for itself: can people find things in it? Strip the design away, write tasks as goals, test the whole tree with enough participants to trust the numbers, read failures as label problems, and iterate. Pair it with card sorting to design the structure and with real-interface testing to confirm it, and the navigation nobody can find their way around becomes a measured, fixable problem.