Do you need to design an information architecture (IA) based on real user data? I use this guide as a . I won’t explain all steps in the process in detail, but it’ll be enough to get you going. There will be useful resources at the bottom of this blog post.
There are many things to do and say about information architecture and it’s easy (and a bad habit) to go straight into designing a sitemap before you do any research at all. Therefore, a useful checklist can help you bring valuable research into creating an information architecture. This blog posts walks through 5 steps for designing an information architecture that is not only based on assumptions, but on user research.
Not every project goes exactly like I’m writing down below, but this guide will help you see the importance of user research, how to validate the hypothesis before design, and how to eventually evaluate your design before implementation. In other words, this guide helps you minimising risks while designing the all important information architecture.
Step 1: User Research
Research Goals
In the first step you’ll need to gather some data about your end-user (or just user if you prefer). The goal of this step is to learn as much as you can about your users. There are a few questions that are critical to get an answer on in almost any situation when it comes down to information architecture:
- What do people need?
- What do they do with it?
- Where do they use it?
- What do they already know about the topic?
- How tech savvy are they?
- How do they describe things?
Research Methods
And how do I get this valuable user data you might ask? Well, as always in UX: it depends. But this doesn’t mean I can’t provide a list of the most common UX methodologies used to collect user data:
- Secondary research. Also known as desk research. Interesting resources might be analytics, customer support, website search analysis, competitive reviews, and previously done research.
- User interviews. Interviewing a user one-on-one gives you very rich qualitative data such as user’s goals and context. Also consider including some Subject Matter Experts (SMEs) into the interview participants lists. They can provide insights you might have never learned if you didn’t took the time to talk to them. Usually 5 to 8 interviews per persona is enough.
- Online surveys. Easy qualitative and quantitative data can be collected with surveys. It all depends on what you want to learn. Surveys can be used to learn the user’s top tasks, goals and context. The amount of participants you’ll need for an online survey strongly depends on your situation.
- Field studies. Conducting field studies is one of the most powerful qualitative research methods there are. Going out into the field will give you the richest qualitative data possible. If you get the chance to do this, you should!
- Card sorting. Understanding your user’s mental model, jargon and attitudes are very important when designing an information architecture. The most important data from these sessions are how your users will group the content. 15 users will do the trick. If it’s a complex platform you’re designing, you can go for 30 participants.
At this time, it might be a good idea to present your research findings to the team and/or stakeholders. By presenting your findings you can show the stakeholders what you’ve been doing all this time, and you can give potential SMEs the time to digest this information for when their input is needed in the next steps.
Step 2: Understanding Content
Gathering Content
It is important to understand not only the current content, but also the content you need for the next iterations. Understanding the current content can be done by documenting your platforms’ as-is situation. There are two common ways of doing so:
- Content gathering. Is a way of documenting samples of your platforms’ content (content types, pages, structures, components, files, search logs…). This is a popular method when you have a big platform with a lot of repetitive content and structures. The idea here is to learn just enough so you understand volume, how the content is structured, and what and where the content lives.
- Content inventory. This method usually captures most if not all content there is. The same principle and objectives apply as above to what you collect and what you want to learn during this phase.
Most of content gathering is done in a spreadsheet that can be modified to your needs. Doing this in a spreadsheet gives you the flexibility to add and remove as you go. In addition, it is extremely useful to go through the spreadsheet with our team and SMEs to align gaps, pain points, duplicated content and potential needs. Most common info collected via spreadsheets are the following:
- ID number. To easily identify the page when visualising the information architecture. When labels are changing its very helpful to refer to an ID number instead of an URL link. The latter will take too much place and clutter the overview of a e.g. sitemap structure.
- Navigation label. Labels of the hyperlink itself are extremely useful to collect. A label is the item a user will click on to continue.
- Page title. The page heading, often this is the H1 at the top of the page. This describes the theme of the page for the user.
- URL. The url of the page which you can copy from your address bar in the browser. URL structures can give you information such as hierarchy used by the system.
- Content type. Is the page a basic page, news page, article/blog, FAQ, or something else? You can use CMS default content types or create your own content types. As long as it brings value to designing your information architecture.
- Basic content description. This column should briefly explain what is on the page. It’s extremely helpful when discussing these pages with your team or stakeholders.
- Content hierarchy. Some way of describing the basic components that can be found on the page. From top to bottom. As a result, you can identify page layouts before you designed a single screen.
- Related content. This one can be hard to decide. Some platforms have a lot of embedded links in the content. Preferably you can use this column to collect information linked from any kind of sidebars or related links components.
- Attached files. Documenting how many files and which file types are attached to each page is valuable when you need to design an information architecture. Attached files can influence your design decisions significant, so it’s better to know upfront than to discover after your implemented design.
- Comments. Any notes or things you want to remember.
- Topic, tags or category. All the meta data for products, articles, news… Collecting this data is valuable when searching and filtering is complex or important.
- Author. Who wrote the content on that specific page.
- Owner. Who is responsible for the content? This is not always the author! Extremely valuable for when setting up a content strategy.
- Date last updated. When was the content last updated. Because of this you will be able to identify old content from new content.
The list doesn’t stop here. When you communicate content within your team or with stakeholders you might want to add some additional columns to capture information or insights. The length and dept of your content inventory or content gathering strongly depends on the situation.
Communicating Content
At the end of step 2 — if you haven’t already — it’ll be time to present your research findings. In addition, in this step you communicate the content, and your very first hypothesis. The output created for communicating content may include the following:
- Content inventory. This might be obvious by now, but it’s extremely important to share this document. It’s an alignment tool and/or source of truth that can be used during decision making.
- Site map. The most common output for an information architecture is the site map. A site map can be created by many standards. More important, it’s crucial you design the site map to communicate the structure. By keeping the purpose of the sitemap in mind, you can find the right solution for the presentation of this artefact. Sitemaps are also a great way to showing the as-is state of the information structure versus the to-be state of the structure.
- Alignment diagrams. There is no better way to visualise and identify knowledge gaps and pain point than by using a Customer Journey Map, Mental Model Diagram, or any other alignment diagram. Creating and communicating an alignment diagram is crucial for improving the content, layout, structure and flows.
- Authors and content planning. Making good agreements is important. And this deliverable ensures that these can be agreed in concrete terms. If you are a UX designer like me, this job might be done more efficient by a content designer/strategist. They know the ins and outs of improving and planning content.
It doesn’t matter which design process you follow, as long as you do your research to define a hypothesis and iteratively test this hypothesis, you will be fine. This brings you to the next step, testing your IA hypothesis.
Step 3: Test the Information Architecture
Method used for testing IA
There is one methods that is extremely common when it comes down to testing the information architecture:
- Tree testing. A tree test presents a category structure (aka tree structure) to the participant. The participants have to find the location in the tree structure where tasks can be completed. Tree testing is so common because it is the perfect complementary research method to card sorting. It evaluates the hierarchy quite accurate, and it’s less expensive than exploring multiple iterations of designed screens. There are many great tools out there that can help you set up and analyse tree tests remotely. Aim for at least 50 participants to minimise risks.
Iterate on the tree
Because tree tests are so easy to set up, you can easily validate each iteration. This way you can keep refining your information architecture until you feel comfortable with it. Remember, your work as a UX professional is all about minimising risks, and that’s exactly what you are doing here. Trying to find the balance between learning as much as you can (= maximise outcome) with as little effort as possible (= minimise output). After aligning the results of each iteration with the team and stakeholders, it’s time to design some screens.
Step 4: Design navigation and page layouts
Prototyping
Navigation is the byproduct of information architecture. It’s here where you decide how you present your tree structure — which you have been testing rigorously — to the user. We have to take into account the main navigation, local navigation, and all other forms of navigation. It is not always necessary to go much further than basic main and local navigations, but in some cases other types of navigation are crucial. Therefore, the screens should be designed in such a way that all important navigations can be evaluated through user testing.
When creating prototypes for information architecture it’s crucial to focus on the navigation design and page layouts. Both are the skeleton of your platform. Choosing the right fidelity is an important decision that will affect your insights. At this stage medium-fidelity prototypes work in most cases because it’s relatively cheap, and provides rich data and insights. Below are a few things we can learn from medium-fidelity prototypes:
- Detailed concepts and flows
- Screen layout and visual hierarchy/affordances
- Basic interactions
- Navigation
- Copy and labeling
Implement real content
In addition to the chosen fidelity of prototyping, implementing real content is crucial. However, you have to decide how much you want to learn which will have an impact on the prototype fidelity and how much real content you really need. Sometimes it can be too cumbersome to fill in all the details on all the pages. Therefore, it’s OK to make the content in the prototype as realistic as possible. The challenge will be to know where to stop.
Step 5: Test Navigation and Content
Evaluate your solution(s) through iteration
Since you’ve done Card Sorting and Tree testing to collect quantitative data, it’s OK to do qualitative usability testing to figure out the information architecture still works when implemented in your designs. Iterating on your insights collected from usability tests is key to success. Usability tests are considered cheap and easy to recruit. Here are some points on what you can learn with qualitative usability testing related to IA:
- How your product helps your users achieve their goals
- How your navigation facilitates common behaviours
- What pain points and roadblocks can be removed
Iterating on a medium-fidelity prototype by conducting qualitative usability tests gives you the opportunity to improve the design before live. Which, again, brings us more confidence, and minimises the risks for both business and user.
Summary
Following this checklist of 5 bigger steps can guide you to do some proper information architecture based on user research. If you want to get a thorough understanding of how to design information architectures, you can use the references and sources below to further investigate this topic.
References and Sources
Donna Spencer, A Practical Guide to Information Architecture, UX Mastery, 2010
Page Laubheimer, Apr 2022, Information Architecture: Study Guide, NN/group, assessed Jun 2022, https://www.nngroup.com/articles/ia-study-guide/
Mayya Azarova, Feb 2022, Secondary Research in UX, NN/group, assessed Jun 2022, https://www.nngroup.com/articles/secondary-research-in-ux/
User Research Basics, Usability.gov, assessed Jun 2022, https://www.usability.gov/what-and-why/user-research.html
Online Surveys, Usability.gov, assessed Jun 2022, https://www.usability.gov/how-to-and-tools/methods/online-surveys.html
L. Rosenfeld P. Morville J. Arango, Information Architecture, O’Reilly, Oct 2015
Professional Diploma in UX Design, UX Design Institute, assessed Sep 2020
Jim Kalbach, Mapping Experiences, O’Reilly, Apr 2016
Katie Sherwin, Mar 2018, Card Sorting: Uncover Users’ Mental Models for Better Information Architecture, assessed Jun 2022, https://www.nngroup.com/articles/card-sorting-definition/
Steve Portigal, Interviewing Users: How to Uncover Compelling Insights, May 2013
Maria Rosala, User Interviews: Advanced Techniques to Uncover Values, Motivations and Desires Conference course, assessed Mar 2022, https://www.nngroup.com/courses/user-interviews/
Kathryn Whitenton, Tree Testing: Fast, Iterative Evaluation of Menu Labels and Categories, assessed Jun 2022, https://www.nngroup.com/articles/tree-testing/