Tree testing

How to write good tree test tasks

The tasks make or break a tree test. Here's how to write realistic scenarios that test your navigation, not people's ability to match words, with examples.

Guide · 3 min read · 26 October 2026

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 ofTry
Find Returns & exchangesYou bought a jumper online and it doesn't fit. Where would you go to send it back?
Find Store locatorYou want to try something on in person this weekend. Where would you find your nearest shop?
Find Care instructionsYou 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:

  1. Is it a realistic situation for our users?
  2. Does it avoid the words in the correct label?
  3. Is there exactly one goal?
  4. 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.

Keep reading