I think information architecture, (IA), is a fascinating topic and an IA is a very fulfilling thing to construct. So why is it that, during the design process, so many conversations about IA quickly turn into conversations about menus, navigation, interaction design, or worse, what the pages will look like with all those labels on them. Part of the answer is simple: we all want to see what the design will look like; we want to discuss screens. Part of the answer is process related: we don’t have IA as a distinct phase in our design process…that is, if we have a design process at all.
But here’s the thing: we need both – a design process that enables us to design that “intuitive, delightful, easy to use” product (application, website, intranet, e-commerce site, digital asset with lots of content) without taking forever to do so and, yes, a distinct phase for the creation of the IA within that process.
Rarely do we isolate discussions around IA, let alone the activity of constructing one. And yet we should treat the creation of the IA as a phase in and of itself. The structure of our content acts as the foundation for the product we are designing and warrants a lot more attention and thought than it typically gets.
There’s so much to talk about when we are designing an IA that has nothing, (yet), to do with what the pages will look like, how users will navigate through those pages, or even, what the menu structure will be on those pages. Listed below are 23 questions, (in reality there are more, but these are essential), that need to be discussed before we start talking about menus, navigation or pages.
Discussing the answers to any of those questions is completely germane to a conversation about IA and essential to understand as thoroughly as possible before we start creating it.
Then there’s IA research to discuss:
And after these questions have been answered, and the research is done and analysed:
There is always lots and lots to talk about there. And then the hard work of actually building the IA really does begin: we start to create a content structure. What we are really creating is a document that tells us what content will go together, (where it will “live”), under which labels, and what the relationship is between different buckets of content beneath the labels. We’re not yet talking about how users will navigate to and/or through that content.
Given all we know from the conversations and insights gained from discussing and thinking about the previous points:
Only now do we start to create the labels and write them down; either in an Excel sheet or another tool, or a simple list. We start thinking about where the different buckets of content that were grouped together in the card sorting will live in the IA. We ask ourselves this key question:
This question is really asking about how we help users find the content; not how they navigate through it; it’s a question about labels and semantics at this point. We need to be careful that those labels aren’t so broad as to become useless, or so narrow as to lock us in when down the road we get new content. In effect, how well we answer that question about the labels we choose for “level 1” of our IA, determines how scalable the architecture is, an important point since redesigning an IA shouldn’t be an annual event.
And once we have a structure of labels for level 1 of the IA, we start to create the labels that will live beneath these; the level 2 labels, and then the labels that represent the content that will live beneath level 2 and so on. All of this determines the structure of the content on the site and wards off “orphan pages”, or content that doesn’t live within, or map back to, any of the level 1 labels.
In our experience at Akendi, most of the large sites or intranets we work on have up to 5 levels in the IA; very occasionally a 6th; most of the software applications we work on have 2-3 levels of IA. The amount of content that is associated with each of those levels, and in particular those deeper levels in the IA, (levels 3-6 typically), as well as the design pattern that best suits the type of content that lives in those levels, will determine whether or not the labels for levels 3,4,5,6, become actual menu items or not. There are many ways to transpose an IA and provide navigation to content through good interaction design; the IA doesn’t determine that, the navigation structure does. The IA determines what buckets of content should stay together but how they’re revealed or laid out in our wireframes or on our pages are great conversations that should follow resolution of the IA questions.
So let’s start talking…about IA! Bring at least some of these questions to the table the next time you’re faced with a design project. I assure you the insights will be worth discussing.
Cindy Beggs, MLS, is Partner and Vice President at Akendi, a firm dedicated to creating intentional experiences through end-to-end experience design. To learn more about Akendi or user experience design, visit www.Akendi.com.
Akendi is a product strategy, user experience design and usability research firm. We are passionate about the creation of intentional experiences – whether those involve digital products, physical products, mobile, service or bricks-and-mortar interactions. We work shoulder-to-shoulder to optimize the experiences you deliver. Akendi Corporate Overview (PDF).
Experience Thinking innovation firm in Product UX Strategy, User Experience Design & Usability Testing for Companies: Toronto, Ottawa, Montreal, Vancouver, Canada.
T: +44 (0)20 35982601
22 Highbury Grove
London, N5 2EF