Posted on: 25 August 2016
Menus, Navigation, Pages, Content Structure: Which one of these things doesn’t “belong”?
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, that need to be discussed before we start talking about menus, navigation or pages:
- What’s the strategic intent of the product for which we’re creating the IA?
- Who are our primary, secondary and tertiary users?
- What are their key scenarios of use?
- What’s the content about?
- How much content is there in total; in each of the key areas?
- Is there a lot of ROT (Redundant, Out-of-date, Trivial) in that content?
- Will there be new content; if so, how much, what will it be about, when will it arrive?
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:
- Should we do open card sorting?
- Will we do closed card sorting as well?
- Do we need to consider reverse card sorting?
- How many users should participate, and who will they be?
- Will we do moderated or unmoderated sorting sessions?
- What content or which terms will we use in the sort(s)?
After these questions have been answered, and the research is done and analyzed:
- Which terms had strongest agreement?
- Which had low agreement?
- What did users want to put in 2 places and why; will we need to create a polyhierarchy or a strict hierarchy?
- Which terms did users not understand at all and why?
- Were there any discernable differences in the way different user personas sorted the terms?
- Does the business, or do the stakeholders, require that certain labels must be used in the content structure?
- Should our closed sort be a hybrid of level one, two or three headings, or strictly all level 1 headings?
- Are we confident enough with the results of the IA research as they are, or should we consider validating further with a test of our IA, known as a reverse card sort?
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
- What are the over-arching organizational principles that make most sense, given the content, the users, and the usage scenarios:
- Location based
- Persona based
- Time based
- Topic based
- Task based
- Some other organizing principle
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:
- What are the broadest, but also most distinct and well-understood, labels we can use to provide access for our users to all this content?
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.