How do you think about information architecture when you’re designing a website or app? The research phase is completed. You understand the problem space and the project goals, and you’re all ready to sharpen your pencils and think about the execution. Soon enough there’ll be wireframes and designs, maybe a prototype and few rounds of user testing to come. But these deliverables are all partial, or conceptual, and don’t carry the full set of information needed to build the product.
Your wireframes might show the open state of the navigation, but do they show every section to every level? (and if they do, stop it. It’s a waste of time and will lead to errors and confusion). Your interactive prototype might provide a whizz-bang demonstration of how multiple filters work in combination, but does it show every scenario for every product you sell in the shop? Again, don’t. You’ll go mad.
Most UXers will at some point draw up a sitemap to help solve some of these documentation issues but there are a few more less-widely used tools in the box too. These take IA beyond navigation and into its full world of structured information.
OK, this one you know about, but the ‘up to date’ bit here is key. In the past I have delivered projects in a phased approach where the sitemap is agreed at the start of the design phase, and left to gather dust, while questions around titles, labels and navigation systems are resolving during wire-framing. These changes are rarely backdated, so by the time the wireframes are finished the sitemap is meaningless.
Yes, the sitemap is often a precursor to wireframes, but wireframes cannot carry your sitemap. The two should be complementary documents, both kept up to date with changes and handed over to development teams as a set. One does not with one have ‘authority’ over another.
It’s important to demonstrate how you anticipate the user moving around the site. Wireframes and prototypes will undoubtedly contain examples of the navigation model in action but it’s important to take the time to be explicit and especially to show the extreme cases. A good example here is how 4th tier navigation presents itself on mobile or something similar. Look for extremes in your sitemap and make sure the wireframes and designs can handle them presentationally and functionally. I tend to create pages or interactions specifically for this purpose. Give examples of the trickier points or where there’s potential for confusion. It’s not fun trying to infer navigation behaviour from a wireframe that’s focused on something else, like a category page.
For areas of the site where the user progresses sequentially from one step to another, like in registration or a basket and checkout, a simple flow diagram showing the order of pages and steps can add clarity. Use titles and numbering from the wireframes in the flow diagram so it’s clear how the two fit together. Like navigation models, these don’t have to be included as a separate item; they can be in your wireframe pack, just specify what they are.
On pages which use filters, like search results or product listings, it can be helpful to list the metadata which is available for filtering. This is especially important when this might vary across content type. For instance, an e-commerce site which has different product categories might provide a different filter set for each type of product. A clothing category might offer options around size, colour and style. And one on books books may be focused on age, genre and format. Depending on the project, sometimes you will need to specify these options upfront, or pick from a list of available product data.
Depending on time, budget and responsibilities, you may not need to detail every single category. But, if you have ambitions or assumptions, make sure they are noted explicitly.
The same applies for filtering around news and blogs. If you have a tool set in mind, e.g. author, theme and date, make sure it’s pointed out. Otherwise, it's just a visual element in wireframes, which may or may not be noticed and copied exactly.
Sites and apps will often make use of page templates, particularly those which are based on a CMS. During the design phase a UXer might draw up one or two examples of a product page, and demonstrate how it displays on different devices and breakpoints. Implicit in these examples is a set of structured content: items which you would expect every product page to have: title; images; short description; long description; price; delivery costs etc. Some of these may be displayed at every breakpoint, others may be for mobile only.
What’s useful at an IA level is to provide a list of each item on the page and which breakpoint(s) it appears on. This is so that developers building the page template explicitly know what fields to include.
This content list can also help designers who may otherwise design breakpoints in a way incompatible with your vision. This is not to knock designers. but too often we’ve had revise designs because functionality that needed to be structurally identical on desktop and mobile looked different enough in the wireframes to be perceived as two separate items. Listing the page format away from a specific example can help overcome this.
Providing supporting IA documentation alongside wireframes ensures that the structure of the site is fully documented. It also means that designers, developers and clients are not left trying to infer details which wireframes are not designed to support. Seeing IA and wireframes as a joint deliverable rather than a step from one to the other will help avoid costly assumptions and mistakes, and lead to a more successful delivery.
Want to read more?
Kathryn has been working closely with customers and stakeholders for over a decade, helping them to define their information architecture, design and user research strategy. She has worked across a variety of industries and clients, specialising in secure systems for government before moving into the commercial sector with clients such as Vodafone, Fullers, British Gas and National Rail.