It’s not widely used, but tree testing is agile, fast, and a powerful complement to card sorting.

Bear with me and do an exercise. Pretend you were asked to do the following thing (task) on a website:

  • You have some questions about what cancer treatments your insurance will cover. Find this information.

Here are the options you can choose. Where would you think this information would be?


  • Education & Training
  • About
  • Research
  • Cancer Care
  • Giving

What’s Information Architecture?

Believe it or not, the ease or difficulty of anticipating where to find information on a website is a big part of what makes a website usable.

I work in health care. When my team migrated one of our major cancer websites a few weeks ago, a big part of our migration involved looking exactly at this issue — also called the information architecture of the site.

What’s information architecture (also called IA)? According to, IA

“focuses on organizing, structuring, and labeling content in an effective and sustainable way. The goal [of information architecture] is to help users find information and complete tasks.”

Information architecture includes:

  • categories — the pieces of information (content) that get grouped together
  • relationships between category structures — interlinking between pages (or links)
  • labels (words) on categories
  •  — which categories & links are presented on the top navigation menu, secondary navigation, etc.

… So how did we evaluate the IA on our client’s site?

Tree testing is a type of usability test that lets you evaluate the information architecture on websites.

It’s similar to card sorting, which also helps you determine the best IA for a website by testing whether category structures (also called “buckets” or “categories”) are and easy to understand.

If you haven’t heard the term “usability testing” before, that’s okay. A simple definition from Experience UX says:

“Usability testing is a way to see how easy to use something is by testing it with real users. Users are asked to complete tasks, typically while they are being observed by a researcher, to see where they encounter problems and experience confusion.”

In this case, we decided to use tree testing instead of card sorting because our clients already had in mind a category structure that they wanted to test out.

But if we had no idea what type of category structure would work, then card sorting would be an excellent test to get a rough working idea of what those structures should be, followed by tree testing.

Why Do We Care So Much About Words Used on Links?

One of the things that tree testing does is evaluate whether the labels (words) used on links match people’s expectations. Professionals who study how people use websites have gone so far to say that “a link is a promise.​

Links need to take people to the content (page) they’re expecting to go to. If they don’t, people:

· get frustrated,

· perceive the website as less credible,

· and may not come back.

The language that’s used on links (in navigation and in text links) is a big part of how we accurately set users’ expectations.

Experts also say that problems with organization and labeling on websites cost businesses billions of dollars in lost revenue.*

Improving Our Site’s Information Architecture

To kick off migrating our client’s website, we needed to first get a lay of the land and conduct some usability testing. In our case, we wanted to see how easy it was for people to use the navigation. ​

So we took the navigation on our client’s website and did some tree testing.

Instead of any assumptions about how understandable the website’s navigation was to users, we wanted to actually test it out. First, we wanted to see what was working in the navigation scheme vs. what wasn’t.

Figure 1 (above): You can’t see it very well, but​ that’s a picture of a navigation menu with links along the top that say “Cancer Care,” “Research,” “Education & Training,” “Giving,” “About,” and “Donate.” There are additional dropdown links underneath each of the sections.

The added benefit of doing a “control” test is that with tree testing, it’s most effective to do a couple rounds (or “iterations”). You can test one category structure, then test another, (and another), and compare the results to see what category structures are easiest for people to make sense of and use.

Right away, we got some … interesting … feedback. Participants on our client’s Facebook page were saying it was too hard to find things (see figure 2 below).

So we knew pretty quickly that it wasn’t as easy for people to find things on the website as we wanted. Which told us we needed to do more tree testing.

Figure 2 (above): After we launched our first round of tree testing​, we got feedback from some of the people who had taken the test on our client’s Facebook page. As you can see, the participants were finding some parts of the information architecture in the navigation difficult to use.

How Do You Set Up a Tree Test?

So how did we conduct our tree tests? Tree testing works like this: ​

  1. Give the person who’s taking the test (the participant) a task.
  2. The task should be typical of what many users want/try to accomplish on your site (also called top tasks — just like that mental exercise I asked you to do at the beginning of this post).
  3. Ask the participant to indicate where she thinks that information would be. Depending on the software you use, the participant can do this by clicking on a button that says “I’d find it here” or “select”.
Figure 3 (above): This is what a test participant sees during a tree test: a task (stated in the form of a question), plus a list of menu items to choose from. Test participants can select the menu item they think contains the information that will help them accomplish the task. Note that tree tests don’t include any visual styling or UI elements like normal navigation menus do. That’s because the goal of tree testing isn’t to validate the effectiveness of the design; it’s to validate the effectiveness of your category structures.
Figure 4 (above): A tree test is fairly easy to take. All a participant needs to do is click on the button that says “I’d find it here” or “Select” to indicate where she thinks she’ll find the information that will help her complete the task.

And that’s it. Pretty simple. We created a set of 8 task questions. Importantly, we asked all 316 participants the exact same set of task questions, regardless of which category structure we were testing (this way, we could compare the results of each “tree” and see which one was easiest to use).

And then we did analysis once people finished taking the test.

For each round of testing, we tested at least 55 participants to make sure our data was valid so we could safely extrapolate the findings.

Don’t Turn Tree Testing into a Word Matching Game

Perhaps the biggest challenge in tree testing is avoiding the temptation to use the same words in a task that appear on your labels. So you wouldn’t want to write a task like this, for example: ​

  • Task: Find information about a new leukemia treatment.
  • Answer options:
  • Leukemia Treatments
  • Cancer A-Z
  • New Patients

Why do we not want to do this? People look for mental shortcuts. If we were to use the same words in our tasks that are on our labels, then test participants would turn tree testing into a mere word matching game (which defeats the point).

And if you’re reaaaaally curious, there’s a whole methodology out there about how to write usability testing ​tasks in a way that won’t bias your participants’ answers​.

Metrics We Looked At

​I won’t spend too much time going into the analysis we did, but here are 3 critical metrics that we looked at:

  • Task success rate: this is the percentage of participants who choose the correct answer for tasks. Obviously, we want this percentage to be as high as possible.
  • Directness: this is an important metric. If someone has to bounce to back and forth between several categories before deciding on the correct answer, then the categories (or the labels on them) aren’t as clear as they should be.
  • Time to complete each task: this measures how long it took participants to complete a task, on average. If it takes participants a long time to complete a task, this probably indicates that the categories we’re using differ from what our participants expect them to be.

What Were the Results?

By this point, I know you’re dying to know what the results were. What did our tests show?

  • Task success rate on our client’s previous website was 51% (low, low, low)
  • Task success rate on our tweaked version of that information architecture was 64% (better, but needs improvement)
  • Task success rate on the final version of the navigation was 78% (this last version is the navigation we ended up using on the current live site).

I know what you’re thinking … 78%? Shouldn’t you guys try to get that higher?!​

UX experts say that even a 70% task success rate could easily turn into a 90–100% success rate once users see visual cues from the design. So overall, we were pretty happy with the results.

Of course, we can always make IA better, and in six months from now we’ll probably do yet another round of tree testing to discover any new problems users are having. Behold!

Want to Learn More?

  • Think tree testing is as awesome as I do? Read a leading industry blog about tree testing
  • First Click testing is another type of usability test that evaluates the visual prominence of design features (also called UI elements) on a website. But some people also use first click testing to look at the categories or labels used in the navigation on websites.
  • Whether this figure is accurate or not, it’s obvious that information architecture is super important to a business’ bottom line.

Source link—-819cc2aaeee0—4


Please enter your comment!
Please enter your name here