A tree test is only as good as its tasks. Well-written tasks show you where your navigation genuinely confuses people. Poorly written ones mostly measure whether people can spot a matching word, which tells you very little.
Start from real goals
Every task should come from something people actually come to your site to do. Good sources:
- Top search terms on your site
- Common support questions and contact-form topics
- The most visited pages, and the most important ones for the business
- Areas where your team disagrees about where something belongs
Write each one as a short scenario with a goal, not an instruction to find a page.
| Instead of | Try |
|---|---|
| Find Returns & exchanges | You bought a jumper online and it doesn't fit. Where would you go to send it back? |
| Find Store locator | You want to try something on in person this weekend. Where would you find your nearest shop? |
| Find Care instructions | You want to know whether a wool coat can go in the washing machine. Where would you look? |
Don't give the answer away
The most common mistake is using the same words as the correct label. If the task says "returns" and the tree has a label called "Returns", people can scan for the word without thinking about the structure.
- Describe the situation, not the destination.
- Use the words your customers would use, which often differ from your labels anyway.
- Watch for partial matches too: "delivery" in the task will pull people towards anything with "Delivery" in it.
Keep each task to one goal
If a task has two parts ("check your order and change the address"), people can succeed at one and fail at the other, and you won't know which went wrong. Split them into two tasks.
Make sure there's a right answer
Before you finalise a task, find its answer in the tree yourself and mark it as correct. Then ask:
- Is there more than one place that genuinely works? Mark them all. Otherwise you'll record failures that aren't really failures.
- Is the answer deep enough to be interesting? Tasks whose answer is a top-level item tell you little.
- Would your team agree on the answer? If not, that disagreement is worth testing, but agree the answer first.
How many tasks
Aim for 5 to 10. Beyond about 10, people get tired and start guessing, and they've also learned a lot about your tree by then, which makes later tasks easier than they should be. Shuffling the order helps spread that learning effect evenly across tasks.
If you have more than 10 things to test, run two studies with different participants, or prioritise the tasks that matter most.
Mix easy and hard
Include a couple of tasks you expect to go well. They make a useful baseline, they keep participants motivated, and if one of them fails, that's a surprise worth knowing about.
Ask why, briefly
A short follow-up question after a task, such as "What were you looking for?" asked only to people who didn't find it, can explain a failure in their own words. Keep follow-ups to one or two questions so the study stays quick.
A final check
Read each task aloud and ask:
- Is it a realistic situation for our users?
- Does it avoid the words in the correct label?
- Is there exactly one goal?
- Have I marked every correct answer?
Then preview the whole study yourself. If you hesitate over a task, participants will too. Once you've collected results, see how to read tree test results.
