A tree test checks whether people can find things in your navigation, before anyone designs a screen. Participants see a plain, text-only version of your menu (the "tree") and are asked to find where they would go to do a task. Because there's no visual design, search or content to lean on, the results tell you how well your structure and labels work on their own.
It's one of the quickest ways to catch problems in an information architecture. You can run one in a day, it costs very little, and the findings are easy to share.
When to run a tree test
Tree testing is most useful when the structure is still cheap to change:
- Before a redesign, to find out where today's navigation fails. This gives you a baseline to beat.
- After a card sort or workshop, to check that the new structure actually works for real tasks.
- Before you build, to compare two or three candidate structures and pick the strongest.
- After launch, to confirm a change helped, using the same tasks as before.
If you want to know whether people notice the navigation on a real screen, or what they click first on a page, use a first-click test instead. Tree tests deliberately remove the page so you can judge the structure alone.
1. Build the tree
Start from your sitemap or menu and write it out as an indented list, one item per line. For example:
Shop
Women
Men
Gift cards
Help
Delivery
Returns & exchanges
Contact us
Account
Orders
A few tips:
- Include the whole structure, not just the branch you care about. People need the realistic set of choices to get lost in.
- Use your real labels. If you're testing new labels, test them as they'd appear, not a cleaned-up version.
- Leave out utility links that aren't part of navigating (search, log out, social links) unless they're part of what you're testing.
- Go as deep as your real menu goes. Most sites need three or four levels.
2. Write the tasks
Tasks are short scenarios that give people a reason to look for something. Good tasks are the heart of a useful tree test, so it's worth reading our guide to writing tree test tasks. The short version:
- Describe a real goal, not a label. "Your jumper doesn't fit and you want your money back" beats "Find Returns".
- Avoid using the words that appear in the tree, so you're not just testing word matching.
- Cover the parts of the structure that matter most, plus anywhere you suspect problems.
- Aim for 5 to 10 tasks. More than that and people tire, which skews the later ones.
For each task, mark every place that counts as a correct answer. If two places would genuinely work, mark both.
3. Set up the study
Before you share the link:
- Shuffle the task order so learning effects even out across tasks.
- Allow skipping if you'd rather have an honest "I give up" than a guess.
- Write a short welcome message that explains there are no wrong answers, and that you're testing the menu, not them.
- Preview it yourself from start to finish. You'll almost always spot a confusing task or a typo in the tree.
4. Recruit participants
You don't need a research panel. Most teams use a mix of existing customers, a mailing list, social channels or a link on the live site. If you do use a panel, pass each person's panel ID in the link so you can match responses and send them back to the panel when they finish.
As a rule of thumb, aim for around 50 participants for each group you want to report on. You'll see patterns from about 30, but the numbers settle down and become easier to trust towards 50. There's more detail in how many participants you need.
5. Read the results
For each task you'll want to look at:
- Success: how many people ended up somewhere correct.
- Directness: how many got there without going back up the tree. Low directness with decent success means people found it, but had to hunt.
- First click: which top-level section people chose first. A wrong first click is often the root of a failed task.
- Where people ended up: the wrong answers that attracted the most people are usually your quickest wins.
- Paths: the routes people took, which a pietree shows at a glance.
We go through each of these in how to read tree test results.
6. Fix, then test again
Tree tests are cheap, so iterate. Change the labels or structure where tasks failed, then run the same tasks again with new participants. Comparing the two rounds task by task shows what improved, and whether the difference is big enough to be more than chance.
A quick checklist
- The tree is complete, realistic and uses the labels you're testing
- 5 to 10 tasks, written as goals, without the tree's own words
- Every correct answer is marked for every task
- Task order shuffled, skipping allowed
- Previewed end to end
- Around 50 participants per group
When you're ready, you can set up a tree test in ClickTree on the free plan and have a link to share in a few minutes.
