Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents
maxLevel1

  •  split this this into separate pages?

...


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.

...

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:

...

 

Creating new trees

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.

...

For more on creating trees, see Chapter 5 - Creating trees.

 

Going wide

...

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 we only create (and test) a single site tree, we’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.

Image Removed

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.

For more on going wide in UX design, see Jared Spool's short article on exploring multiple variations.

 

Data for the CEO

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

 

Guarding against genius design

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 we have a “genius” designer on the project, we must 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.

 

Learning from other industries

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:

...

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.

 

Going wide – an example

For an example of testing alternative ideas, let's look at Meridian Energy, a renewable-power company that needed to redesign its site tree.

When they ran an open card sort with their users, the results suggested that the current top-level headings didn’t match their mental model.

Image Removed

So they brainstormed a bunch of ideas, and decided that two of them were worth testing. They set up three tree tests - the two ideas plus the current site.

When the results came back a week later, the current tree perform poorly (as they expected). But so did the two new ones:

Image Removed

 

Obviously, they were not happy about this. Time to start over, right?

Well, not really. When they dug deeper into the results, they found patterns in both trees that performed very well. The problem was that there were other patterns and potholes that sabotaged the overall scores.

So, in round 2, they created a third tree that was a hybrid of the best of the earlier designs. And the third tree proved to be the charm:

 

Image Removed

 

Going deep - Iterating until we get it right

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:

...

After the first round of tests, we either have:

...

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

...

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. 

 

Keeping it cheap and fast

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:

...

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.

 

...

and going deep

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)

The next two sections describe each of these approaches in more detail.

 

...

Next: The design phase: going wide