Drafting a bunch of possible trees is a great thing to do, because it makes us entertain new (and sometimes unconventional) ideas, and because it makes us think hard about what users will do.

We could test all of these draft trees, and if we only have 2 or 3 of them, that’s probably the right thing to do at this early stage.

However, if we’ve been creative and come up with a larger number of trees, it’s best at this stage to do some triage – review the trees and decide which are the most promising (and feasible, given our content).

Triaging the draft trees

We typically do this “tree triage” by:

• Circulating the various draft trees to our project team, so they have time to review them

• Running a short workshop to discuss the various ideas and pick the trees to pursue

In the triage workshop (which is 60-90 minutes long, depending on how many trees we need to review), we:

• Briefly review the draft trees and their main ideas about grouping and labeling

• If necessary, combine ideas from some of the trees into a new tree that seems more promising than the originals.

• Pick 2 or 3 trees that look like the best candidates to test with users

At this point, we usually give standardized names to our candidate trees so we can easily identify them later. For example:

• We pick one of Michael’s trees – the one that features user groups at the top level – and rename it from “Michael users” to “tree 1”.

• Sarah’s tree, which uses broad activities as the top level, is renamed from “Sarah” to “tree 2”.

• And so on.

Fleshing out the candidates

Now that we’ve picked the trees we want to test, we need to flesh them out.

Earlier, we recommended that when “roughing out” a tree, create the top 2 or 3 levels, and don’t get stuck on wording. This is time saved for the trees that we discarded during our triage.

For the trees that made the cut, we now need to think through the whole tree. This means:

• Expanding the tree to include all the sublevels we want to test.
  For most trees, this will be all the sublevels that the eventual website will have. For some trees, however (particularly shopping sites that may have thousands of products), we may decide to test a representative sample of the lower levels.
  For more on how many levels to test, see Which part of the tree? in Chapter 6.

• Making our labels consistent.
  This is the time to clean up our wording so that we use parallel phrasing (e.g. “For patients”, “For doctors”, etc.) where possible, and stricter terminology (e.g. Are we calling them “cars” or “vehicles”?).

Checking coverage of content

Once we have decided on which trees to test, we also need to make sure that they represent all the content that we plan to include in our website.

It’s likely that we’ve covered all the major topics, but how can we be sure we’ve covered the minor ones too? Remember, if we miss something here, then discover it later (after testing, or even worse, during development), it may be painful to retrofit. Better to take the time now to make sure.

There is no magical way that we’ve discovered to check coverage of content. It’s simply a matter of comparing, line by line, our list of planned content to our candidate trees, and making sure that each tree accounts for all the content.

Next: Posing questions about tree elements