Primetime for tree testing is early in the design phase, once we’ve done enough research to feel we have a good handle on our audiences, their background, and their needs.

We start creating drafts of new site structures immediately after we finish a content audit – that is, after we decide which content we will be adding, updating, or deleting. While content is always a moving target, it really helps to have most of it identified and locked in before trying to design a structure for it.

This work on content and structure can be done in parallel with conceptual design, but usually comes before more detailed work such as page layouts, fine-grained interactions, and visual design.

In the design phase, we can increase the quality of our site tree by doing two critical things:

• Going wide (testing several alternative trees at the start)
  
  
• Going deep (testing and revising down to a single tree that performs well)
  
  
  

From our research, we should have several ideas about what to change (and what not to) in a new site tree – not just grouping, but labeling too.

We can then start sketching out new trees by looking at these ideas and our list of planned content. It’s typical to rough out 2-5 different trees at this stage, down to level 2 or level 3, just to explore how they might work. You might do this yourself, or (even better) you might involve the whole team to get a wider variety of informed ideas.

For more on creating trees, see Chapter ~.

At this early stage of design, it’s a mistake to create just a single site tree.                                           

It’s too early to finalize our thinking; we probably haven’t done enough research and we haven’t actually tested our idea with users. If it doesn’t work out, what do we do – start over? If you only create (and test) a single site tree, you’re taking a big (and unnecessary) risk.

The smart thing to do here is “go wide” – that is, generate several different site trees to exercise our various ideas, then pick the 2 or 3 most promising trees to test against each other.

• diagram of 3 different trees

This may seem like a lot of extra work, but it’s not. It turns out that trying to settle on a single tree at this stage is usually very difficult. There are different groupings to try, different terms to try, and (if we’re working with a team) diverging ideas from other members. We’ve found it easier to generate several trees that incorporate these inputs than it is to try hacking and slashing them all in a single structure.

By “going wide”, we raise our chances of hitting on the best design. We start with several candidate trees, then use a reliable method (tree testing) to choose the best one.

Consider also that the “other members” that you get input from might include the CEO. And (trust us), if you need to shoot down their out-of-left-field idea, it’s much easier to do that with objective data from testing than just your personal opinion.  J

Perhaps most importantly, testing lots of ideas early on avoids the peril of genius design. By that, we mean designers who believe they are talented, and tend to believe that all their ideas are good ones.

If you have a “genius” designer on the project, tread very carefully. Because when a designer falls in love with a single idea early on, it’s really hard for them to get away from it.

Fixing on a single idea too early is not a new problem. Other industries encountered this (and solved it) years ago.

Consider traditional graphic design and advertising. In both professions, the classic approach is to go wide in the early conceptual phase:

• Brainstorm dozens of ideas
• Explore 5-10 in more detail
• Pitch the top 3 to the client

It brings to mind the advertising person who said that if they went away and worked and then came back with a single idea to pitch, they would be fired on the spot.

~WUD slides - Meridian

Next: Putting it all together