Information architecture (IA) testing is a crucial first step in designing or redesigning a website. But of course, you already knew that. But what if you could be running better IA tests? Improving the way you conduct IA testing can ultimately lead to an improved finished product, and that means happier clients. In this guide, we’ll recap the basics of IA testing for those in need of a refresher, and then we’ll look at how to get the best out of your IA testing process.

IA testing recap

IA testing is all about discovering a site structure and flow that feels logical for a site’s intended users.

In fact, one of IA testing’s superpowers is the ability to provide data that overrides potential designs based on things like personal preferences, gut instinct and general feelings.
Generally, you’ll be using this kind of testing to create the best possible site navigation system, and process flows that don’t leave users lost and confused. Most of the time this is done through card-sorting and tree-testing.

Done well, IA testing means you can be reasonably confident that the wireframes and mockups you build later in the design process won’t leave potential users completely baffled.

But there are IA testing pitfalls that you need to avoid. Let’s run through some common IA testing mistakes and what you should be doing instead.

IA testing pitfalls

It’s often said that some testing is better than no testing at all, but that might not often be the case. With a bad test, the worst case scenario is misleading results that lead you to do the opposite of what you should be doing.

In the case of IA testing, make sure you avoid the following.

1 – Skipping IA testing altogether

It might seem tempting to save time by jumping right to the wireframe or mockup phase of testing, but like so many tempting shortcuts, skipping IA testing could end up being counterproductive.

Remember, the whole point of testing potential structures is to make sure you’re able to create wireframes and mockups that people find intuitive.

By skipping IA testing, you’re not actually removing it from the design process – you’ll just end up carrying out some really inefficient IA testing as part of your other tests.

How so? Well, if you’re running a first-click test on a static mockup and your test subjects routinely fail to answer a question like “Where would you find product X?” then each iteration of this mockup can really just be viewed as a slow, resource-intensive IA test.

IA testing allows you to develop a strong idea of what your mockups should look like without having to iterate over and over.

2 – Omitting users from your early planning

Users are at the heart of all usability testing, but sometimes they don’t get the attention they deserve.

It can feel like it’s quicker and easier to develop a testing plan and then decide who your subjects will be. In reality though, this approach will mean you start testing without a clear idea of the direction you should be heading.

If you have the resources, you need to interview potential users about what they’d expect from a site like the one you’re building. If your budget doesn’t stretch that far, then at the very least you need to conduct online surveys.

With the information gathered you can build user personas and from there go on to develop user goals. With that, you’ll be able to create things like meta data and potential user flows with much more confidence than if you’re just assuming what users will want from the site.

3 – Too narrow a field in IA testing

Card sorting and tree testing is all about preferences. But it can also involve limiting those preferences. After all, you can only expect a subject to sort so many cards into so many categories.

This raises the possibility that you might end up with a site structure that is good, but not the best possible.

Worse, you might end up with structures and flows that feel logical to users in early stages of testing, but falls down when it comes to things like interactive mockups.

So what can you do?

The first thing to do is make sure you use both open and closed card sorting. Open card sorting lets participants choose their own category names – that lets you know how they classify items, which gives you a stronger idea of the website navigation should be organised. If you’re just using closed sorting, then you’re forcing your subjects to use classifications they may not agree with.

The second thing you could try is the modified Delphi method. With this technique, you ask the first subject to carry out a standard open card sort. Then you allow subsequent subjects to modify the test. They can do anything they want – including renaming categories, or moving cards. They can even scrap the whole thing and start again. This process continues until you arrive at a stage where only minor changes are being made.

By opening out your early IA tests, you reduce the risk of moving to the next stage of the process with a suboptimal result.

4 – Skipping tree testing

Your card sorting tests have let you develop what looks like the perfect navigation structure. But that doesn’t mean you’re ready to start creating wireframes.

Card testing is a great way of developing a potential site structure, but that structure is presented to potential users in an artificial way. Subjects in card tests get to see all the potential options at once, whereas visitors to a website first see a collapsed navigation.

This raises the possibility that what seems like a logical structure when all information is available, may fail when some of that information is taken away.
Use tree testing (sometimes referred to as reverse card testing) to confirm (and if necessary refine) your card testing results.

5 – Testing the wrong number of people

How many people should be involved in an IA test? If you said 20-30, you’re either used to running big projects with big budgets, or you’re actually wasting money. Research by Jakob Nielsen shows the optimal number of subjects for card testing to be 15.

Any less than that, and you won’t get useful results. Any more than that and you’ll be expanding more resources for diminishing returns. The only exception is if you’re working on a big project with a big budget, then you can use up to 30 participants.

6 – Hiding away your most persuasive data

You carry out your card tests and tree tests, you sift through your results, you build some wireframes based on your findings to your clients and… They still think their idea is better.

What’s gone wrong?

Well, even though you know your testing is thorough and reflects the views of potential users, you still need to prove it to your client.

Test results on their own do nothing to convince someone that their gut feeling is wrong. So instead of presenting your clients with the end results of your testing and nothing more, show them the process that led to that conclusion.

In the case of IA testing, you’ll want to video your subjects wherever possible (and with permission, of course.) Ask them to explain why they made the choices they did.

If your client can understand how their potential site users (and hence customers) have driven the design choices you’ve made, you’ll find it easier to convince them you’ve got things right.

Of course, videoing candidates brings its own problems – if you’re guerrilla testing it’s not always easy to find a quiet place to record someone’s thoughts. And if you’re paying your subjects for their time, then asking questions will take more time and hence cost you more money.

Overall though, the benefits of videoed responses outweigh the downside.

Summing up

Although there’s no such thing as a perfect usability test, everything we’ve looked at here will help you make improvements to your IA testing.

That means you’ll be able to create wireframes and mockups with even greater confidence.

We’ll look at how you can improve the tests you run at that stage of the design process in a future post.