How to make good trees for tree testing
In this article, we will be explaining tree testing, and answer questions such as: What should be in the tree, how should the tree be represented, and give you a few tips for preparing better tree testing studies.
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.
In conclusion, 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.
This article was originally published on our blog http://blog.uxtweak.com/ where you can find more useful content about UX research and UX in general.