Tree testing: test navigation before designing the menu

When a user cannot find information, the cause may lie in the category name, content organization, or visual presentation. Tree testing helps investigate structure and labels before adding other design layers.

Prepare a tree that represents the proposal

Imagine a fictional employee benefits portal. The team wants to know where people look for course reimbursement.

The tree can bring together categories such as development, health, and payments. Within them, corresponding content and services appear. The goal is to test a plausible structure, with alternatives that might compete for attention.

Avoid removing all branches that do not contain the answer. An artificially short tree can make the task easy and hide an ambiguity that will be present in the product.

Write a need without repeating the label

If the category is called “Professional Development,” a task that says “access Professional Development” does not help evaluate discoverability.

Try a scenario like: “You completed a work-related course and want to know how to request that the company reimburse part of the cost.” The person needs to interpret the objective and choose where they would look for the information.

Provide only the necessary context. If company rules determine the path, include the relevant conditions in the scenario to avoid a response based on assumption.

Define accepted destinations

In UXTap, the tree testing block allows you to build the tree and mark the destinations considered correct. More than one destination may make sense depending on the architecture.

Define these answers before data collection. If you discover a plausible interpretation afterward, record the revision instead of silently changing the criterion.

Also check if the person can skip the task. An explicit exit helps distinguish between no response and a destination choice.

Observe the journey, beyond the arrival

Two people can choose the correct destination via different paths. One goes directly into the expected branch; another explores alternatives and returns before concluding.

In UXTap, tree testing analysis includes success, path, and directness. Read these measures together and check the basis used for each, including the treatment of skipped tasks.

A good reading spreadsheet can separate:

• Chosen destination.
• First category opened.
• Returns or deviations.
• Subsequent justification, when collected.
• Change that deserves testing.

These elements help locate where the structure begins to generate uncertainty.

Example: two categories compete for the same need

Suppose participants look for reimbursement under “Payments,” even though the proposal places it under “Development.” This behavior may indicate a financial expectation or a lack of clarity in the label.

The team has alternatives: revise the category, create a contextual entry, or make the content accessible via different paths. Tree testing does not automatically choose between these solutions.

Test a revised proposal with equivalent tasks. If you change names and structure simultaneously, record that the new round evaluates the set of these changes.

Write a task for each architectural question

In the fictional benefits portal, imagine that course reimbursement could be placed under “Career” or “Benefits.” A suitable task would be: “You paid for work-related training and want to check if the company can reimburse this amount. Where would you look for this guidance?” The scenario provides the need without repeating the label of the team's preferred category.

Before testing, define the destination that contains the guidance and assess whether another entry should also be accepted. If the product intends to offer the same content via different paths, the research should reflect this decision. If only one destination resolves the need, make this explicit in the analysis criterion.

Include plausible competing categories. A tree with a single branch related to the topic reduces the choice to recognizing the only available option. At the same time, do not add areas unrelated to the product merely to increase difficulty. The structure needs to represent a proposal that the team genuinely considers implementing.

Read an attempt in layers

Start with the first-level choice. It informs the initial expectation of where the topic belongs. Then, observe category openings, returns, and the chosen destination. Finally, relate the journey to the outcome. Arriving at the correct place after exploring several branches is different from finding it directly.

In the example, one person might open “Benefits,” return, and find the guidance under “Career.” Another might go directly into “Career” and end up on an internal courses page, which does not deal with reimbursement. The first resolved the task with a detour; the second followed a direct path but did not reach a suitable destination. An isolated measure of directness does not distinguish these situations.

Record skipped tasks and cases where the person chose a destination without conviction. These should not disappear from the discussion because they hinder a positive outcome. Interpretation depends on the considered basis; inform who received the task and which responses were included in the analysis.

Differentiate between name problem and position problem

If participants consistently choose another branch, investigate the content's location. If they reach the expected branch but confuse two leaves, examine the distinction between the labels. If they explore many places without identifying an alternative, a category corresponding to the need might be missing.

Prepare two revision hypotheses, when it makes sense. One might change the label from “Development” to a more concrete expression. Another might add a contextual entry under “Benefits.” Preserve the destination and scenario needed to compare discoverability, recording what was changed.

Then, take the structure to the real menu. A search, a shortcut, or the navigation's position can change the path. Tree testing isolates part of the architecture but does not demonstrate how the entire page will be used. A first-click test can examine the start of the task in the visual context before you evaluate the complete flow.

Complete validation in the interface

A visual menu offers clues that the textual tree does not have, such as spatial groupings, icons, and simultaneously visible items. It can also introduce its own difficulties.

After revising the architecture, prepare a task in the prototype or on the website to evaluate real navigation. Relate the result to what was found in tree testing.

To start, choose a frequent need and build the corresponding tree in UXTap. Conduct a pilot, check the accepted destinations, and observe the first chosen branch. The next decision should address a specific language or organization problem.

If labels still lack a clear basis, revisit card sorting. The information architecture resources allow you to organize this investigation sequence.

Frequently asked questions about tree navigation

Do I need to represent the entire site in the test?

Represent the necessary context for plausible choices. A segment may be sufficient when the decision concerns a specific area, provided that relevant alternatives are present. Declare the scope: testing the benefits area does not allow concluding that all corporate navigation works well.

Can I accept more than one destination as correct?

Yes, when these destinations truly meet the need and this is part of the evaluated architecture. Define the criterion before looking at the responses. Adding destinations afterward merely to improve the success rate hides a problem that may need revision.

What does success with many returns mean?

It means the person reached an accepted destination, but the journey may have required exploration. Examine which categories the returns occurred in and if there is a pattern among participants. Do not classify every return as a problem: it can be part of a reasonable choice, depending on the content and task.

Create your UXTap account to prepare your first study.