Tree test in UX: how to run one and read the results

A tree test in UX is a study where people see only a text version of your navigation (the menu labels and their sub-levels, with no design) and are asked where they would go to find specific things. Run a UX tree test after you have a draft structure and before anyone designs screens, with about 50 people per user group, and judge it mainly by how many found the right place and how many got there without backtracking.

Nielsen Norman Group calls it a task-based method where participants look for key resources in a proposed hierarchy, and notes you do not need prototypes, layouts or visuals. That is the point: if people cannot find invoices in a plain list of words, a nice icon will not save them. (It might make them feel better about being lost.)

1. Build the tree down to the level where the answers live

The tree is your proposed menu written as an outline. NN/g recommends including the categories in your global navigation (and utility navigation, if you have it), going down to the lowest level of subcategories that holds the things participants will be asked to find. Its practical tip is to build the tree in a spreadsheet, with the homepage in the top cell of the first column, each lower level one column to the right, and one category per row.

Leave out search and page content. A tree test answers one question: does the wording and grouping of the menu lead people to the right place on its own?

2. Write tasks that describe a situation and never repeat a label

Each task is a short situation with one correct location (or a few) that you mark in advance, so the tool can score it. The hard part is writing it without giving away the answer.

Dave O'Brien's guide Tree Testing for Websites gives the core rules:

Avoid words that appear in the tree. "Find out who to contact about your warranty" sends people straight to a heading called Contact Us, by word matching rather than thinking.
Avoid the tree's word order too. O'Brien's example task "For a fixed asset such as a laptop, how would you request an upgrade?" walks through the headings in the same order they appear in the tree.
Describe a real situation in everyday language. O'Brien's example swaps "request a fixed-asset upgrade" for "Your laptop needs more memory. How would you ask IT for this?"
Keep it short and specific. A broad task makes a whole section look correct, which tells you nothing.
Test-drive every task. Have a colleague read it and say back what they think you are asking.

NN/g adds two useful task types. A warm-up task helps participants learn the tool, and in unmoderated tests it can catch people who are not paying attention. A "sleight of hand" task asks people to find a less important item whose only purpose is to test whether a parent category's label gives off the right clues.

Here is a made-up example. A small accounting app is testing this tree for bookkeepers at small businesses:

Home
- Sales: Invoices, Customers, Quotes
- Purchases: Bills, Suppliers, Purchase orders
- Expenses: Receipts, Mileage, Reimbursements
- Payroll: Employees, Pay runs
- Reports
- Settings

A weak task: "Where would you add a new bill from a supplier?" Two of its words are labels in the tree, so it measures reading speed. A better one: "Your printer paper company just sent you a $400 charge that is due next Friday. Where would you record it so it gets paid on time?" The correct answer is Purchases, then Bills.

Short version: 8 to 10 tasks, each a plain situation with no tree words in it. O'Brien recommends that range because it takes about five minutes, while 25 tasks would take 15 to 20 minutes, and after about 10 people tire, try less hard and skip more. Randomize the order so no task always benefits from what people learned on the previous one.

3. Recruit about 50 people per user group, and pilot with a few first

Tree tests need more people than usability tests, because the output is percentages. O'Brien's guide says to aim for about 50 participants per user group: around 30 starts to show patterns, 50 to 100 makes them clearer, and past a few hundred the extra people are better spent on a second round. If each person only sees part of the task list, multiply: 20 tasks with 10 shown to each person needs about 100 people to get 50 answers per task.

When you are comparing two versions of a tree, NN/g recommends 50 or more participants per tree, with each person seeing only one version, so the difference between them is larger than the noise.

Before collecting the bulk of your data, NN/g suggests running at least a few moderated pilot sessions to check task wording. Do it. Three people thinking aloud will find the task that everyone reads two ways, which is much cheaper than finding it in 50 sets of confusing results.

Recruit people who do the job. A tree test run on your marketing team mostly measures how well they know your product already. Research participant recruitment covers where to find business participants and what to pay them.

4. Read success and directness together, then look at first clicks

NN/g describes the main measures:

Metric	What it counts	What it tells you
Success rate	Share of people who ended at a correct location	Whether the item can be found at all
Directness	Share who went to the correct location without backtracking	How much effort finding it took
Time	Average time from start to finish of the task	How long finding it took, including hesitation
First click	The top-level category each person picked first	Where people expected the item to be
Destination	The final answer each person chose	Where the wrong answers clustered

Success alone flatters a tree. NN/g gives an example of a task where 74% found the answer but only half of them went straight there. Directness matters most for new and occasional users, who cannot rely on remembering where things are.

For a benchmark, NN/g cites Bill Albert and Tom Tullis, who reviewed 98 tree testing studies and found a median task success of 62%. Their rubric calls under 40% poor, 41% to 60% fair, 61% to 80% good, 80% to 90% very good and over 90% excellent. NN/g suggests aiming above 90% for tasks that are critical or bring in revenue, and notes that tree tests often understate what a good final design achieves, because they strip out search and visual cues.

Back to the made-up accounting app, with 50 bookkeepers on the printer paper task:

31 of 50 ended at Purchases, then Bills: 62% success, right at the median.
18 of 50 got there without backtracking: 36% directness.
First clicks: 22 went to Purchases (44%), 19 to Expenses (38%), 5 to Reports and 4 to Settings.

The first clicks tell the story. Almost as many people started in Expenses as in Purchases, because to many bookkeepers a supplier's charge feels like an expense. NN/g reads it this way: wrong first clicks show where people expected the item, and the fix is to move it or list it in both places. NN/g recommends cross-listing only when a substantial share would look under each parent, and its own example is 30% each. Here both parents clear that, so a link to Bills from inside Expenses is justified.

If first clicks had scattered across five categories instead of two, the problem would be the top level itself. NN/g says that pattern suggests overlapping categories, and points back to a card sort.

5. Tree test the card sort's output, and drop its "other" pile first

If you ran a card sort, its groups are a draft, not a menu. NN/g says card sorting does not usually produce the exact scheme to follow, and that participants often make vague catch-all piles. Those same people would avoid an "other stuff" item in a real menu, so do not carry it into the tree. Put each of its cards somewhere specific and let the tree test tell you if you guessed wrong.

Then loop: draft the tree, tree test, revise, and tree test again with fresh people, since anyone from round one has already learned your tree. Move to a usability test once there are screens. If you are redesigning against competitors, a UX competitive analysis shows how other products label the same things, which gives you a second tree worth testing against your own.

Your next step

Write your tree in a spreadsheet, draft 8 to 10 tasks, and read each one aloud to someone who has not seen the tree. Then pilot it with three people from your real audience before the full run. Instant Expert can find people matching a description such as "bookkeepers at small businesses who pay supplier bills every week" and send them paid invitations for a short call, and you pay only if someone books. For help with study design, the directory pages for user research experts and UX consultants are a good place to start.