What is Tree Testing?
Tree Testing is an early-stage usability method. It is evaluative, task-based, and consists in measuring how users find items in an interactive product, be it a website, an application, or a blog.
Why do we use Tree Testing?
TLDR: To validate that app users (or website visitors) find the features (or content) corresponding to their goals.
The tree testing method helps discover and test what categories and labels make sense to your audience, and validate the proposed structure of your product prototype. Tree tests basically reveal where visitors expect content on your site or app and whether a product's features are easy to find in the first place.
It is pretty much the most effective and lean option for:
When in the Design Process?
Tree Testing should be done early in the product cycle, right after having gathered and synthesized requirements from stakeholders, users, and competitors. These requirements are typically synthesized during a few rounds of affinity mapping, or, when their number exceeds 15, of card sorting. Affinity mapping and card sorting should lead to a preliminary idea of:
- list of goals or tasks users will use the product to achieve their goals, often represented as user flows.
- the product's content and hierarchy is called an information architecture (or sitemap) and can be conveniently written down as a text outline or 'tree'
Note, the ‘tree’ does not reflect any design elements of the proposed navigation - thus allowing to test a product in its most basic form without the influence of design and without having to design or code anything. This method then informs the wireframing and design of screens by establishing their organization relative to each other as well as validating naming conventions.
How to conduct a Tree Test?
Typically, 10-50 participants need to be recruited to perform the test. During a tree test, participants are asked to complete a series of tasks such as finding information or reaching a specific destination in the proposed tree (app or site structure).
A report of where they can click and the paths they take offers actionable insight into the effort required to reach a goal. Ideally, most goals or tasks should be found without hesitation and backtracking. A tree test is ready for qualitative feedback and wireframing when 80% of the tasks are Direct to first-time users.
How worthwhile is tree optimization?
2 words: cost-effective and accessible
The beauty of this method lays in its cost-effectiveness: if the product team was to wait for a clickable prototype to assess if users find what they're looking for means discovering navigation and labeling issues down the road :
- that WILL be time-consuming to fix (you may have to restructure the prototype, remove some screens, etc.).
- Also, the pathfinding issues WILL be compound with other design issues such as layout, contrasts, illustrations, etc.
In contrast, tree testing is incredibly accessible to different team roles for the very reason that it only takes a text outline of the product (the tree or architecture) and a scenario of tasks or use cases users will be expected to achieve with the product. Arguably, anyone armed with these 2 assets, tree testing data and a knack for copywriting can ace that foundation stage of UX design: UX designers, PMs, Developers can equally nail this.
The bottom line
Building a prototype without tree testing is pretty much like shooting a movie without a script. Doing so might be tempting but the overhead costs will fail your project, both in terms of its rentability (more post-production and retakes and revisions) and commercial potential (like a movie people find unintelligible).
Overcome these faux-pas by putting in a few hours in outlining the information architecture of your product and running iterative tree tests with UXbeam, the only online tool that includes tester recruitment and lets you optimize most trees within the hour.
