How to use tree testing and card sorting together for maximum effect

Tree testing and card sorting are an iconic duo. So much so that tree testing is often referred to as reverse card sorting. 

These two methods test the same information from different perspectives. Card sorting brings out the logic and mental models people have about your information, uncovering the ambiguity in interpretations of information and groupings.

Tree testing takes a proposed solution and provides clarity on the effectiveness of the information’s structure from a seeking perspective. 

Painting the full story with both techniques

While both these techniques uncover the story behind your information architecture, there’s little overlap between the two. 

• Card sorting uncovers the groupings and categories, or the "chapters", of the story. 
• Tree testing uncovers the structure, priority, and order in which the "chapters" should be laid out.

That’s not to say there isn't a link or connection between the two. The questions that each technique answers and the order in which they are conducted are different sides of the same coin. 

What does card sorting tell us?

Before starting a card sort, you'll know some of the terminology of your users, but you may not know the exact terminology or relationship between the words.

Here are some questions that will help you prepare your tests:

• How do users categorize these pieces of information?
• What are the possible relationships between these pieces of information?
• What is the structure/priority of each piece of information within a group?
• What is the order of the categories?
• Which items are commonly grouped together?

Starting with an open card sort allows people to create their own groups, and answer questions of which categories and relationships exist in this information. Then, using the most commonly created categories, use closed card sorts to test if your categories are understood by other users. 

By the end, you should have validated your terminology, categories, and order of information.

What does tree testing tell us?

At this point, you have the first part of your story–how users describe the pieces of information, their categories and any missing or inconsistent pieces of information from the study. 

Building upon the questions answered by the card sorting tests, we have laid out some of the questions that tree testing should answer:

• Can users find the information they need in the proposed structure?
• How clear is the path to find the information?
• How quickly can users find the information they need?
• Does the structure make sense when users can’t see all the information at once?

With both these sets of questions answered, we know that the relationships and groupings of our information are logical and meaningful to users and the structure can be used quickly and efficiently.

Which technique comes first?

When making sense of any mess, the first step is to understand what exactly makes up the mess in the first place. 

When you have your list of words then you know what needs to be categorized and then you can create its data structure. So, it makes sense to conduct card sorts first, followed by tree tests. This is because card sorting lays out all the information available. 

However, design is never that black and white. It can depend on the maturity of your information or your domain. 

In retail, for example, a lot of architectures already exist, so you want to try and match those mental models as much as possible to see where you can be consistent with existing mental models. 

It might be that these structures don’t fit exactly your users' needs, so your competitors are a good benchmark to start with. 

If you don’t have all the time or budget in the world, then it's completely fine to take inspiration from ready-made information architecture to start with. 

Adding items in an online card sort

Which technique should be used last?

No matter how you start your project, it makes sense to always end with a tree test. The purpose of the tree test is to create a structure that realistically shows how the information will be presented to users. 

The tree-like structure underpins menus on pages and the site maps of entire websites, whereas a card sort just gives you the categories of information but not in a way in which users are presented with that information in designs. 

Conducting a tree test last is like a "final" step in the process, because it takes a realistic representation of the information and tests the findability of the architecture. It does this by asking users to go through the proposed structure to solve realistic scenarios. 

Since the tree is what designs will be based on and is user-facing, it makes sense for this to be the last step.

Card sorting brings you ambiguity… 

Another reason why card sorting and tree testing go hand in hand is similar to the double diamond approach us designers love to apply to other areas of our thinking and working. 

You start off with a group of unordered and ungrouped information. So, you need to branch out to understand how users interpret that information. 

At this point, card sorting can show you multiple ways in which your users think. This may be differences in names for categories, ambiguous terms that can belong in multiple categories and even the facets that may have been missed in the beginning while collecting user terminology and goals. 

Adding categories in an online card sort

Tree Testing brings you clarity

The final steps of the double diamond are then of course to develop and deliver the information in a way that is going to be used. This is where the tree test comes in, after the card sorts. You use the insights from the card sorts to develop the structure of the information in a way that will be seen and used on the website. 

Tree testing narrows down the ambiguity because it’s the last step in defining the architecture without resulting in other options. Card sorting will give you multiple groupings, but tree testing does not give you multiple trees. 

Of course, it’s a good idea to run multiple tests with different structures to see which performs best, but the end result should be a clear idea of the final architecture design. 

Bottom-up approach

In addition to narrowing down the ambiguity stage by stage, another reason that card sorting and tree testing work well together is that they test the information from two different angles. 

When you run a card sort, you’re testing the information from the ground up, presenting all the information at once and asking the users to build the next level up hierarchy by grouping the facets.

If there are any anomalies in the larger group of facets that you’re considering, a card sort will highlight these easily - your users will let you know. 

You’ll typically see categories named solely with question marks or ‘I don’t know!’ if anything doesn’t make sense, before users have even reached any wrap-up survey questions on the topic.  

As well as answering the questions mentioned earlier, card sorts will uncover insights about the individual facets, which are the foundations of your information architecture.

Top-down approach

At this point, you know that all the information users need for your site is present in the architecture. 

What’s left is to determine whether that information can be found when there are multiple levels. 

Tree tests are referred to as reverse card sorting as they test the information from the top down. Your insights show you whether users are able to find what they’re looking for when all they can see are the top-level structures created in the card sort.

Setting scenarios that reflect a user’s thought process and that don’t incorporate any labels in the actual structure, tests the top-level categories via realistic situations. 

The metrics from a tree test give you insights into how quickly users find what they need and how direct they were in finding the information, as opposed to bouncing through the tree trying to find what they need.

Using similar approaches for both tests

Ensuring that information architecture works from the very beginning is crucial to not only structuring the story of your products but also prioritizing the work which needs to be delivered. 

If you are building a new product from scratch, you’re going to need research to uncover these insights quickly. 

Whether you choose to run your studies unmoderated or remotely, you can use the same method for card sorting and tree testing. 

You can even run both tests with the same people, which is great if you have a limited number of users at the beginning of product development, or limited numbers of accessible users.

Insights uncovered in card sorts are hypotheses for tree testing

Insights uncovered in card sorting exercises often prove to be a good indication of what is likely to be uncovered in the tree test. 

Things that were difficult to sort are likely going to be tricky to find. The same insights from both techniques can help to narrow down what needs to be addressed in the information architecture. 

Don’t forget, you can run multiple card sorts with multiples tree tests to iterate over any of your solutions. 

The cheap and fast nature of both techniques means it doesn't eat into budget either and there isn’t much planning difference between each test. Your instructions, introduction and wrap-up questions should be the same across each test version for consistency, as this will also help in analysis. 

Card sort results in the form of a dendrogram.

In summary

While the order of a card sort and a tree test may differ depending on your needs, there is no doubt that both these techniques go hand in hand. 

The card sort from a bottom-up approach shows you the categorical logic of the items, while the tree test in contrast shows you how the information works from a top-down approach. 

The ability to use the same methods for both tests means that you can run these tests consistently for the entirety of the project.

No information architecture process would be complete without using both these techniques together.