Research Research
Tree Testing: How Easily Can Users Find The Information They Need?
Content list
Research Research

Tree Testing: How Easily Can Users Find The Information They Need?

Tree Testing: How Easily Can Users Find The Information They Need? cover

Can people easily find the information they want on your website or mobile app? To answer this question, you can use a technique called Tree Testing.

In this article, we will explain how you can apply this test to validate the Information Architecture of your products.

What is Tree Testing?

Tree Testing is a UX Research technique that analyzes a hierarchical category structure on your website.

We use this method to know if the information in the interface has an optimized organization, so users can easily find what they need. In this sense, we find answers to questions such as:

  • Are the titles and categories of the interface making sense?
  • Is the content grouped correctly and logically?
  • Do people have trouble performing tasks or finding information?

Tree testing has two main elements: the tree and the tasks.

The tree is your menu, and it shows your website structure: all its categories and subcategories-similar to a sitemap. The tasks are the activities you give to participants complete, like finding information about professors on an academic website. The task results will tell you:

  • how many users got it right and wrong;
  • the paths people took before they selected an answer;
  • how long it took them to complete the task.

Tree Testing is used in Information Architecture processes along with other techniques, like Card Sorting. But be careful; although similar, these two techniques are very different.

Reading tip: Information Architecture: How to Organize UI Content

The difference between Tree Testing and Card Sorting

Although these two techniques are used to help categorize the information on UIs, they work in different ways.

In Card Sorting, participants are presented with several items and must categorize them according to what makes the most sense to them. There are variations of this tool, but in general, this is how it works.

In Tree Testing, the categorization is already done. The test revolves around how people find and search for information within the hierarchy that already exists or to validate the results obtained with Card Sorting itself – and for this reason, it is also known as Reverse Card Sorting.

Therefore, Tree Testing evaluates your website information based on tasks that people would perform in real life. In this sense, it is very similar to other usability tests.

When should you use Tree Testing?

Since the goal of this technique is to validate the organization and categorization of content on a particular interface, you can use it at various points in the design process.

You can use Tree Testing at the very beginning of your project or in the initial research phase of a product that doesn’t even exist yet. You can also use it to improve a specific feature of a website or mobile app that is already in use.

Moreover, there are no structure limitations to using this kind of test. Whether it is a hierarchy of 50 categories or one with 5, you can conduct several small tests or a single test that encompasses the entire interface hierarchy.

In other words, Tree Testing can always be used to investigate the efficiency of your Information Architecture, no matter the moment of design you’re in or the size of your content structure.

Advantages and Disadvantages of Tree Testing

As with any method or tool, Tree Testing has advantages and disadvantages, and it is important to know them to get the most out of this tool.

Advantages

The advantages of Tree Testing revolve around its ease of use and the possibility that it can be run anytime.

Since Tree Testing doesn’t depend on other interaction elements—buttons, colors, animations—it is easy and fast to execute.

Because of this ease and speed, it is possible to run several tests to evaluate different versions of the Information Architecture. This way, designers and researchers can identify more precisely which structure configuration best suits the users.

Besides this, other advantages of the test are:

  • possibility to carry out remotely;
  • short sessions;
  • existence of specialized software;
  • the analysis of results is, in general, direct and fast.

Disadvantages

One of the advantages of Tree Testing is also one of its disadvantages.

The fact that tree testing doesn’t need other design and interaction elements to happen means that the evaluation is only about the content structure of the UI.

In this sense, an interface’s usability evaluation should not consider only Tree Testing. Instead, it is essential to complement it with other types of usability testing.

Another disadvantage of Tree Testing is the lack of qualitative data. Because it is usually held remotely and not moderated, it can be difficult to uncover the reasons why people made specific decisions during a test. Thus, it is more difficult to understand certain behaviors by Tree Testing alone.

Furthermore, natural interactions between users and websites have all interface elements, not just textual like in a Tree Test. This means people perform tasks more efficiently on a finished interface because there is context, signals, and other elements that improve usability.

This way, Tree Testing can generate results that don’t necessarily mean the structure is bad. In fact, according to User Interviews, a Tree Testing success rate of 60% can be compared to a 90% success rate in a finished UI.

Reading tip: Usability: How To Develop A User-Friendly Website

Hands-on: Tree Testing step-by-step

Tree Testing is not a complicated technique to apply, but it is essential to be careful not to miss crucial steps in the process.

In this sense, we can describe the following steps to perform a tree test:

  1. Defining objectives;
  2. Choosing tools and methods;
  3. Building the tree and writing down the tasks;
  4. Recruiting participants and executing the test;
  5. Analyzing results.

1) Defining objectives

This step is basic for any kind of test that you perform. Understand what the objectives of the test are. What do you want to improve, verify, validate, or evaluate?

In the case of Tree Testing, is the test to verify the entire structure and Information Architecture of the UI or just a part of it?

If the project is a redesign, what indicators should be improved, and how can Tree Testing help?

Writing down the test objectives will be the foundation for preparing the tasks and analyzing the results.

2) Choosing tools and methods

You can use paper prototypes to run a Tree Test. However, if you opt for specialized software like UserZoom or Treejack, you will save a lot more time.

In addition, the software guarantees the possibility to perform the test remotely, which is also an advantage and eliminates any geographic restrictions.

So, at this stage, think and define which tool best suits your needs and whether the test will be done in person or remotely.

3) Building the tree and writing down the tasks

Building the tree is quite simple. You can draw it in a spreadsheet and then import it into specialized software.

The important thing is to determine the categories and the levels of each subcategory in the tree. Take a look at the example below, taken from the NN/g website:

Exemplo de tree testing da NN/g
Example of Tree Testing | Source: NNg

Each row corresponds to a category, which in turn is within a parent category, indicated by the columns. Notice that the tree is quite similar to a site map, made only with text.

Draw the tree exactly as your website structure; it is important to provide all the details of categories and their sub-levels to the participants.

It is best to leave out categories corresponding to Contact and Search. Firstly because in Tree Testing, these two categories don’t work; they only work in the “real” version of the website; secondly, because it is important to remove any possibility of participants not performing the proposed tasks.

A Search field can induce people to provide answers such as: “I would search for this task through the Search bar, ” which is not the test’s objective.

How to write the tasks?

After building the information tree, it is time to write the tasks you will ask participants to complete. Consider the following:

What to test: write tasks based on the purpose of the test. What do you need to analyze? A specific part of information architecture or the structure as a whole? A particular point in the user journey?

Define the correct answer for each task: each task should have the right answer so that you can verify the error percentages.

Several paths may lead to the same answer if the content is extensive. In these cases, it is essential to map all these possible paths to analyze the results more assertively.

Tasks should illustrate hypothetical scenarios: instead of telling the participant precisely what to do, demonstrate the task with a hypothetical scenario.

For example, you are planning a 20-day vacation at the end of the year. Find the best destination that interests you and buy the tickets.

A bad example of a task would be clicking on ‘destinations’ and selecting a place.

Use a different language/avoid priming: Be careful when writing the Tree Testing tasks not to hint to the participants about the answers.

For example, if the UI has a link to “Claim Form,” avoid tasks like: “Find Claim Form.”

This type of task cues the participants and disguises the test results.

Set a maximum of 10 tasks: the tests shouldn’t last longer than 15-20 minutes or have more than ten tasks.

Therefore, understand which parts of the structure you will analyze and distribute the tasks according to this hierarchy.

4) Recruiting participants and executing the test

Defining who should participate in the test is a key step. Look for users who fit the customer profile of your product. So reflect on your target audience and persona definitions to help you in this process.

If you already have an established customer base, invite people from that base. Send an email and explain the reasons for the invitation and the test.

An ideal number of participants is around 50 people, according to NN/g. This number is sufficient to generate sufficient data and analysis to support decision-making.

The next step is conducting the test with the tree, tasks, and participants defined.

Tip: Running a pilot test with your design team is a good opportunity to check for possible inconsistencies or errors.

5) Analyzing results

Since Tree Testing is usually applied remotely and without moderation, the results are analyzed quantitatively.

In this sense, the most commonly analyzed indicators are:

  • how many participants got a certain task right;
  • how long it took the participants to complete the tasks;
  • which path the participant took to complete the task;
  • which tasks were harder or could not be completed.

You must align the analyses with the test objectives to understand whether the interface structure and hierarchy are efficient or not for the people using it.

Reading tip: UX Research Data Analysis: A Step-By-Step

Don't forget to like and share if you enjoyed this content! This small gesture helps us a lot! Feel free to continue browsing, and if you'd like to stay up-to-date, sign up for our newsletter!


We are proud to have people from our community hired every month by great companies, in countries such as
Brazil, USA, UK, Ireland, Germany, Netherlands, Spain, Portugal, Austria, Czech Rep., New Zealand, and Canada.

Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro
Parceiro Parceiro