The tree stands as the root of every TreeTest study (pun absolutely intended). In a study, we ask the respondents to find something by navigating a tree. The tree is a hierarchical structure of labels – not unlike a menu, a map of a website, or the directories in your computer’s file system.
The labels in the tree are also called ‘nodes’ and they can be of two types. Group nodes are exactly what the name implies – they are groups that aggregate more nodes into a single named unit. The tree-like structure that the tree is named after is created by placing group nodes inside group nodes, which in turn forms the tree’s branches.
Content nodes are found at the end of these branches, which is why they’re also called leaf nodes. They represent elementary units of content that don’t branch out any further. When respondents solve a tree testing task, it’s their job to find one of these leaves by browsing the tree. What you want to achieve, is for users to find content nodes easily.
What makes a good tree?
When preparing your tree test, an important thing to consider is what exactly makes a good tree. “What should be in the tree?” and “How it should be organized?” are the first questions that come to mind. But one question that most people forget to ask is “How should the tree be represented?”
In UXtweak TreeTest, you can load a tree directly from your website by either specifying the ID or the tag name and class of your menu. Even more complex tree-like structures can be pulled from your site if you use the “UXtweak your tree” feature. Due to this fact, one might be tempted to think that all it takes to create your tree is to make an exact copy of your menu and be done with it. However, from our experiences, this isn’t necessarily always true.
The tree should foremost reflect the content of the website, not its page structure. What this means is that any implicit content your website has should be included as an explicit label in the tree.
Let’s take the following example. Say that our website has a page called “About”, which has sections “Our mission”, “Our team” and “Our solutions”. While in the menu, these would all be under the same label (About), for the purposes of a tree test, it’s much better to give all these pieces of implicit content some explicit labels of their own, while turning the About label into a parent group node they all belong to instead. This way, the respondents can actually see the content which the tree wouldn’t portray otherwise. This makes the tree testing more in line with how the interaction would look like on a real website, where the user would see the sections of the About page once they open it.
Another tip for what the contents of the tree should entail is to leave out any helpers. On a live website, these offer alternative ways to look for information (e.g. Search, Contact us, Site map, Help). Since you’re testing the tree, you want the respondents to find information by looking for it within the tree, not by bypassing the problem.
Finally, don’t be satisfied with copying your site’s page structure and menus into your tree tests exactly as is. That’s not the best approach. Some labels are better left out of a tree test because they get in the way of testing. Other times, you will want to add labels that represent the content that isn’t visible immediately in the menu but is still present in the way the information is structured, implicitly.
💡 Tip: Don’t forget about Tree Testing best practices! A good tree is essential for effective research just as much as the right participants and correctly formulated tasks. Want to learn more? Check out the video below.
Conclusion
Creating a good tree for tree testing might take some practice, but it’s definitely worth the time. And by employing a good tree testing tools like UXtweak, you can collect essential user feedback to make your information architecture more intuitive.
Want to learn more about TreeTesting? Read our article: Why can’t parent nodes be selected as answers in TreeTest?
