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 benchmark 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”.

In a CI session, 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 find out that:

• Most of them are looking for parts and accessories, not bikes (perhaps because they prefer examining and trying bikes in person at a store).

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 robust user-research method in our toolbox.

For more on contextual inquiry, see ~book/article/etc.

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 content.

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.
  
  

• ss of participant card sort

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

• ss of similarity matrix and PCA

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 (breakfast, lunch, dinner, etc.).
  
  ~ss of grouping by time of day
  
  
• If the card sort revealed that most of our participants grouped the recipes by cuisine (Italian, Japanese, Mexican, etc.), we should really reconsider our main headings.
  
  ~ss of grouping by cuisine
  
  

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 you do before you jump into design.

An excellent book on this is Card Sorting: Defining Usable Categories by Donna Spencer. For a quick primer, see her 2004 Boxes & Arrows article.

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

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

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

Why? Because it gives you something to measure your 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 benchmarking the old tree and later measuring it against our new ideas.

• example - before/after scores from ACC

And the scores are only part of the story. Benchmarking 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