Of the three phases of user experience (research, design, and testing), research is the one that tends to get abbreviated (or skipped entirely) when budgets and proposals are drawn up. Experienced designers know that this introduces big risks to the success of the new site, because it’s harder to design something good when we don’t really know who the users are, what they know, what they need, and what causes them the most pain.

While the first method discussed below (contextual inquiry) does take an investment of time and money, the other two methods (card sorting and baseline tree testing) can be done quickly and cheaply, so even with a shoestring research budget we should be able to get some useful insights to help us design a better site structure.

When we don’t know enough about our users, one of the best methods of finding out more is contextual inquiry – a fancy term for “watch, listen, then ask”. Wikipedia describes it as:

...an approximately two-hour, one-on-one interaction in which the researcher watches the user do their normal activities and discusses what they see with the user

Ideally, we visit the user in their natural habitat (home, office, commute, whatever makes sense for our purposes) and observe them doing tasks related to our website. During or after the observation, we ask them questions about what they did and why, so we can get a clear idea of what they knew, how they behaved, what they wanted, which issues they encountered, and so on.

As information architects, we pay particular attention to the respective elements of IA:

• which content they were after, and why
  
  
• how they mentally grouped different kinds of content
  
  
• which terms they used (and which terms they knew of)
  
  
• how they browsed or searched for items
  
  

For example, if we're researching how cyclists buy bike gear online, we might observe 20 people and discover the following:

Contextual inquiry takes time and some practice, but it’s great for showing what users really care about, how they behave, and why. We consider it the most fundamental user-research method in our toolbox.

For more on contextual inquiry, see:

• Usability Body of Knowledge: Contextual Inquiry
  
  
• User and Task Analysis for Interface Design, by JoAnn Hackos and Ginny Redish
  
  
•  Contextual Design: Defining Customer-Centered Systems, by Hugh Beyer and Karen Holtzblatt  

Card sorting is probably the best known (and most used) method in information architecture, and with good reason – it’s a great way to find out how users think about content.

Early in a project, when we’re looking for ideas for structuring our site, we can run an open card sort to see how our users mentally organise topics.

Whether it’s done in person using index cards, or online using web apps, the fundamentals are the same:

• We create about 40 cards that represent a range of topics on our site.
  
  
• We ask participants to sort these cards into groups.
  
  
• We ask participants to name the groups they’ve created.
  
  

Here's an example from the New Zealand Film Commission, where we asked filmmakers to sort typical content from the Film Commission's website:

We then analyze the data to see if there are patterns in how the participants grouped the items, and what they called those groups.

The findings from a card sort can fundamentally change how we structure our site. For example, suppose we are designing a recipe website.

• We might have initially thought about grouping the recipes by time of day:
  
  
  
  
• If the card sort revealed that most of our participants grouped the recipes by cuisine, we should really reconsider our main headings:
  
  
  
  

And card sorts are not restricted to top-level headings. We can also run card sorts on subsets of our content, to generate ideas for the next few levels down.

For any medium or large website, we recommend running open card sorts as part of the research that happens before we jump into design.

The definitive book on card sorting is Donna Spencer's Card Sorting: Defining Usable Categories. For a quick primer, see her 2004 Boxes & Arrows article.

During the research phase, we also recommend running a tree test, even before we’ve created draft site structures.

How can we test a tree if we don’t have a tree yet?

If we’re redesigning an existing site, we do have a tree (our existing site structure), and we should definitely run a tree test on it, even if we know the existing tree isn’t very effective.

Why? Because it gives us something to measure our new ideas against. Remember, we don’t just want to create a new site structure; we want to create a better one. And the way we ensure that is by baselining the old tree and later measuring it against our new ideas.

For example, one of the first organizations to use tree testing was ACC, a public-health service in New Zealand. When they redesigned their website a few years ago, they did a baseline test before they revised their site tree. Here's what they found:

And the scores are only part of the story. Baselining the old tree also helps us find out:

• Which parts of the old tree are problems that we can fix or rethink
  
  
• Which parts of the old tree are actually working well, so we can reuse those in the new site. We don’t want to throw the baby out with the bathwater.
  
  

Over and over, we see redesign projects head off in the wrong direction because the stakeholders think they know what to change. Doing proper research (such as contextual inquiry, card sorts, and baseline tree testing) helps us find the right direction before we start designing in earnest.

Next: The design phase: creating new trees