A proposed navigation can look convincing in a workshop because everyone in the room already knows where the content belongs. Customers approach it with a task instead: finding an invoice, changing a delivery address, or checking whether a service covers their area. Tree testing examines whether the category labels and hierarchy give them a workable route to that destination.

Participants use a text version of the navigation to attempt realistic tasks, without the layout and visual design of the finished interface. This makes it useful when the team needs to investigate the structure before investing in a redesign, or when it wants to understand whether an existing hierarchy contributes to findability problems.

What the test can tell you

Suppose a fictional retailer places delivery information under “Customer services”, while some shoppers first look under “Orders”. A tree test can show those routes and where participants eventually choose to stop. Follow-up questions may help explain the choices, although the path alone cannot establish whether a label, a misunderstanding of the task, or some other factor caused the difficulty.

This is different from card sorting, which asks people to group content and can suggest possible arrangements. Tree testing starts with an arrangement to evaluate. A team can use the methods together, but a card sort is not a prerequisite: testing the current navigation may be the most useful first step in a redesign.

Nielsen Norman Group’s tree-testing guide describes the method and its distinction from card sorting. Its stripped-down format is useful for examining the hierarchy, while also limiting what can be inferred about the complete website.

Preparing the tree and tasks

Include the relevant breadth and depth of the proposed navigation, including plausible alternatives to the intended destination. A test containing only the correct branch may flatter the structure by removing the choices that make the real task difficult. Define acceptable destinations in advance, especially where the same information can reasonably appear in more than one place.

Write task scenarios around the information people need without giving away the category label. For the retailer, asking whether an order can be delivered on a Saturday creates a reason to seek delivery information; asking someone to open “Delivery options” may simply repeat the answer. Pilot both the tree and the wording to check that participants understand the task and can use the testing format.

Recruit people relevant to the decision, considering differences in experience or responsibilities that may affect navigation. Plan the number of participants around whether the study is diagnosing problems or estimating performance with useful precision. A small round can reveal a confusing route, but its percentages should not be presented as precise measures of the whole audience.

Reading success, routes, and uncertainty together

Report outcomes for each task rather than relying only on an overall success rate. A high average can conceal a serious problem with one important destination. Look at where participants began, where they backtracked, where they stopped, and whether those patterns differ between the groups the site needs to serve.

Directness and time add context, but they need careful interpretation. A longer attempt may involve hesitation, reading, interruption, or difficulty with the testing tool; reaching a destination directly does not prove confidence or comprehension. In moderated sessions, participants’ explanations can help distinguish these possibilities. In unmoderated studies, use appropriate follow-ups and avoid filling gaps with assumptions about intent.

Revising the structure and checking the interface

Use the findings to propose a specific change, such as a clearer label, a different grouping, or another route to frequently needed content. Record why the evidence supports that proposal and test the revised structure when the decision warrants it. Reusing participants may introduce learning, so consider that when comparing rounds.

A successful tree test still leaves questions about the interface. Search, page layout, cross-links, and content previews can help or hinder someone following the navigation. Usability testing on the actual design can investigate those effects, allowing the team to assess whether the structure remains useful once it is part of the product people will encounter.