...

• To baseline an existing tree, discovering where the problems are and establishing a base score.
  
  
• To try out some new trees that you’ve we’ve come up with, looking for problems and comparing to each other (and the baseline tree, if any).
  
  
  

If you we are testing an existing IA (e.g. the structure of a current website that you’re we’re about to revise), you’re we’re obviously interested in finding out which parts of the current structure work well and which don’t.

Most of the time, you we will already have an idea of where some of the problems are. It might be from other usability testing you’ve we’ve done, from web analytics, from user feedback, from your our own gut feelings, or (most commonly) from some mixture of all of these.

When testing an existing IA, then, you’re we’re likely to be looking for:

• How well the suspected problem areas perform, and
  
  
• Which other (unsuspected) areas perform particularly well or poorly
  
  
  

If you’re we’re revising a site structure, you we will generally be looking for:

• How well the revised parts of the new structure perform, and
  
  
• Which other areas perform particularly well or poorly, especially areas that may be indirectly affected by the revisions you we made.
  
  
  

If you’re we’re creating structures for a new website, you we may not have much existing research to inform your our IA work. In this case, the main value of tree testing is being able to evaluate one or more structures early in the design process, before the website exists even in beta form.

Whether it’s architecture or brand design or vacuum cleaners, the best designers agree on one thing – generate lots of ideas early, then cheerfully discard the ones that don’t work out.

The same is true with site structures. Early in the design phase, you we should think up several different ways of structuring your our site. Yes, you we will probably have a favorite, but your our favorite may not be the best solution for your our users. If you we create some true alternatives and test them against each other, you’re we’re more likely to produce a better structure.

So, whether you’re we’re testing revised structures or new ones, a main goal of your our testing should be to compare multiple candidate structures and determine which performs best.

In our experience, what often happens is that tree A performs best overall, but parts of tree B do better than their counterparts in A. The natural next step is to create a hybrid (tree C), which usually ends up testing better than either A or B. If you we only created tree A, how would you we ever get to C, the better structure?

For most designers, the main reason to run a tree test is to determine if their main grouping scheme works well.

...

For more on grouping schemes, see Chapter 5 - Creating trees.

Another big reason to run a tree test is to test the terms we use. Will our users understand what “contingency planning” means? Will they be able to distinguish between “products” and “solutions”?

...

However, we may also find that two terms work equally well, in which case we can decide based on other factors. For example, a consumer-review site in New Zealand considered renaming their “Electronics” section to “Technology”, and this became the subject of prolonged internal arguments about whether users would understand the new term properly. When they ran tree tests, they made sure to include tasks that targeted these alternative terms in their trees. The result was a 51/49 /51 split; both terms worked well, so they could use either depending on other preferencesfactors.

Sharing and documenting issues and goals

When we tree test, there are several problems we typically want to fix, but yours may not completely overlap with mine. To run a good study, we need to be clear about what we're trying to find out, which means discussing it and writing it down.

...