Tree testing is a UX Design method for verifying that users easily find content in an interactive product's information architecture. The method consists in asking participants (real users) to find navigation paths in the clickable tree corresponding to the product's menu / sub-menu structure.
Write down the tree as an indented text outline
The first step is to write down the outline or tree structure (categories and subcategories) labeling and relating the various screens or pages that make up an early product prototype. Doing so comprehensively helps scope how many different screens and features will need to be wireframed, designed, and developed while giving a sense of how long (as in how many steps) are users' primary tasks and how complex is a typical usage scenario with the product.
Formulate a scenario of goal-based tasks
The second step is to craft up to an up to 10 tasks instructions to find a page or location in a tree using a top-down approach. Just like in usability testing, writing good tasks is the key to performing tree test studies.
For example, if you want to test the findability (vs. discoverability) of the billing page in your product, you need a task that asks participants to find or locate such a page. For example: “You've received a refund and want to verify how it has been applied to your bill”.
It is important to make these task instructions:
- short: no more than 2 clauses
- to the point: sometimes, attempts to create a naturalistic-sounding scenario lead to misleading signals that lead the participants in conflicting directions. Think here: writing a task with several focal points is as poor design as writing a survey question that compounds several qualifiers (e.g., how likely are you to buy or borrow this app?)
- nonleading: when phrasing a task, avoid matching keywords in the tree
Tip ✨
A good scenario comprises tasks to destination labels that are highly expected for this type of product (e.g., upload a photo and save it in a folder for a photo-sharing app) as well as destinations that make up the uniqueness of the prototype (e.g., schedule the sharing of your vacations photos at the end of this quarter).
Recruiting Tree Testing Participants
It is recommended that the participants recruited into tree testing studies form a representative audience meaning they match the demographic profile of real users on the site. Tree tests are fairly quick to administer since they are excellent candidates for unmoderated sessions and quantitative data analysis. Actionable patterns start emerging between 10 and 50 participants.
The positioning at UXbeam differs here though. What we've learned by conducting hundreds of tree tests and optimizations is that it often takes a few retests (or iterations) for the UX folks or the product team behind an initial tree to catch and fix benign labeling and structure mistakes. It then takes a few iterations to fix any major task instructions, tree labeling, structure, or paths issues.
In essence, running those tests on a non-targetted and naive audience is not only as effective. It is also way quicker, for that recruiting a targetted audience takes more time, coordination, and screening.
Tip ✨
We recommended making sure that most findability issues have been smoothed out by spending 1-2 hours optimizing a tree in unmoderated settings and with naive non-targeted participants. Then the optimized tree is ready to show to a small group of representative users and serves as a medium to collect qualitative or attitudinal feedback, on an early prototype that is already fairly easy to navigate and comprehend.
Data analysis
The quantitative data typically garnered during a tree test fall into the following categories:
- Success: whether a task instruction leads participants to the expected destination
- Directness: Whether the participants could find the correct destination without backtracking
- Alternate outcomes: cases where participants abandoned, declared the task not supported by the tree, or were convinced another destination was the right one
- Number of steps taken to perform each given task
- Paths or routes participants took up and down the tree while completing each task.
Depending on the desired granularity of analysis, these insights can be expressed in counts, averages, percentages, etc. At UXbeam though, we've found that the tree test data are more actionable when boiled down to these essentials:
- the predominant task outcome: Direct, Indirect, Elsewhere, Abandoned, and Non Existent
- the number of steps per task
- the predominant path for the task that captures the most frequent routes taken by the participants and prunes infrequent clicks or detours.
These results should then be articulated to answer the following key questions:
By analyzing the collected data, you can confirm or refute your hypothesis as to whether the designed navigation is useful for users.
