Making several site trees compete against each other is great, but at some point, we need to reduce them down to a single high-performing tree.

Once we’ve run our first round of tree tests, on 2 or 3 of the most promising trees we thought up, we analyze the results. Typically we find:

• One of the trees performed the best, but it still has some problems to solve.
  
  
• Some of the trees just didn’t work for our participants. We can safely discard these trees and move on.
  
  
• Some of the lower-performing trees may have elements (certain groupings or terms) that actually did perform well, so it may make sense to incorporate these elements into our best tree.
  
  
• (In rare cases, we may find that none of the initial trees perform well enough to continue with. We’ll have to come up with some new ideas quickly (perhaps ideas that were discarded earlier) or go back and do more basic research with users.)
  
  

After the first round of tests, we either have:

• 2 trees that performed reasonably well, but should perform better with the revisions we have in mind, or
  
  
• 1 tree that clearly out-performed the others, and should improve further with our revisions.
  
  

We can now run a second round of tests to see if our revisions did indeed make things better:

• If we tested 2 trees, we can then determine which performed better and which we’re more comfortable going with as our actual site tree.
  
  
• If we tested 1 tree, we can look for any remaining areas or terms that need tweaking.
  
  

In a perfect world, we would keep testing until we had a perfect tree, but there is never time or budget enough for that. We typically only do more than 2 rounds of testing if there are important parts of the tree that are still not performing well enough. 

If we were expecting tree testing to be a one-off trick – build a tree, test it, and we’re done – it may be alarming that we recommend several rounds of testing, with several trees, winnowing and refining them until we get a single high-performing tree.

What makes this approach feasible is that we now have mature testing tools that are both:

• Cheap (affordable for any development team), and
  
  
• Fast (able to deliver results in a week or two)
  
  

The combination of cheap and fast changes how we should approach design. Instead of doing a single round of deluxe in-person testing (or worse, no testing at all), we can do several cheap online tests in less time and for less money.

There are cases where in-person testing is the way to go, particularly for complex interactions, or for when there are only a small number of participants available. But for most projects, several rounds of lightweight tests are a better bang for the buck.

And that means we can go wide at the start, and go deep through to the end.

Next: Putting it all together