Brief lessons from an information architecture review

Recently I’ve worked in a group looking at a large part of our site structure and information architecture (IA). This hasn’t just been a bunch of web experts sitting around talking in cosy acronyms and agreeing with each other. Instead we’ve been dealing with people from all around the company (which means, yes, having to speak in plain language to regular people) and disagreeing amongst ourselves as we do.

I like explaining things to people who don’t come from my little corner of the world. It means I have to think clearly and go back to basics, which often leads me to new realisations. I also like having good debates with other web people who see things differently to me. This reminds me that the basics I go back to are subjective, and sometimes worth rethinking. Getting both of these things out of the same project has taught me a few things worth sharing. For now I just want to get these things listed briefly; ideally I’ll ultimately write a post about each of them.

Information architecture and navigation have a weird relationship which can be hard to explain

The difference between the separate-but-related concepts of IA (the structure that fits all of your pages together) and navigation (the links, buttons, feeds, searches and other things that people use to move around your site) can be really confusing to non-web types. Your site’s menu is derived from your IA, but the rest of your navigation need not bear any relation to it. Try explaining that to someone who only sees the web as a user.

Internet users don’t need to know the difference between how sites are put together and how you move around them. But when those same users are also stakeholders in an IA project, things can get tough.

You’ll probably find yourself building an IA long before you move onto creating the content that fits into that architecture and gives your site the rest of its navigation. These tasks can inform each other and solve problems for one another, but if you need to get one of them done and agreed upon first this isn’t going to happen properly.

Laying out the IA in a visual way is a necessary evil that will create problems you won’t see until you try to turn the picture back into a website

The moment you sketch out your IA or site structure in a visual way – whether as a tree, in a spreadsheet or in any other way – you’ve made a representation of your site, or a metaphor for it. You have to do this since it lets you visualise the whole thing, but it subtly changes the way you see your site in other ways too.

While you’re rearranging branches on your tree or cutting and pasting cells around a spreadsheet it’s easy to forget that you’re working on a metaphor for your site – something that your readers or users will never see – rather than the site itself. All metaphors are imperfect, but good ones have the unfortunate side effect of (a) letting you forget that they’re not real, and (b) obscuring some things as they clarify others. You and your team all need to remember that the picture you’re building has to turn back into a website.

The biggest problem with a visual representation of your IA is that it looks like everyone starts at your homepage and travels down a “tube”

Your site structure starts from the homepage when you map it out, but you can’t expect your users to always begin there. They might search their way into any page, or begin from a landing page about a particular product, sale, or campaign. They could get a deep link from an ad, a referring site, a friend, or from something you push through social media. You can’t see this in a visual representation of your IA.

Visual IAs also obscure the way people will work if they’re on your site to do more than one task. Even if they start at the homepage for task #1, they won’t go all the way back to the top to start task #2.

Incidentally, this is a problem with a lot of professional user testing, which presents subjects with a homepage and then gives them a job to do. That’s not a realistic way to watch someone use the web.

Labels, categorisations, words and concepts all mean different things to different people

Words are wonderful things but they’re never as exact as you need them to be. This is especially true when you’re talking about wayfinding, navigation, labels, and categories of content. You need to keep your conversations really clear or you’ll end up thinking something different, but nodding in agreement.

For example, when you say “products” you could mean:

  • the navigation label that says “Products”
  • the section of your site about your products
  • the actual products that you’re selling
  • the content you have about your products.

If you say “we need to boost ‘Products’ up”, it’s not clear whether you’re talking about the location of the word “Products” in a menu, or informational hierarchy (the number of levels between your homepage and the section about your products), or content strategy (the way you talk about your products), or the stuff that your company makes (the quality of your products).

In a discussion about IA everything on your site is both what it is, and the idea of what it is. Often it’s also the place where that idea belongs in relation to everything else. Don’t be afraid to admit when you’re confused, and keep your conversations as clear as you can.

===

This post is 953 words long, with an average reading grade of 10.0.

Leave a Reply

Your email address will not be published.