Information Architecture is a topic that many people may have heard about. You might be wondering what it is and what is has to do with your knowledge base.
Information Architecture is a subset of User Experience design and it’s all about your relationship with your users.
It’s the discipline of sense-making. But why do we need?
Unfortunately, complex information objects (like websites) confuse users when they haven’t been designed properly. In many modern website designs, users aren’t empowered and they over–rely on search engines instead.
While search is important, this makes for passive users – rather than active learners.
Information Architecture for your knowledge base takes the principles of instructional design and applies them to your website structure.
Information Architecture is defined by Usability.gov as:
“Information architecture (IA) focuses on organizing, structuring, and labeling content in an effective and sustainable way. The goal is to help users find information and complete tasks. To do this, you need to understand how the pieces fit together to create the larger picture, how items relate to each other within the system.”
The “parts” of your knowledge base are made up of the content and categories. The way these are linked together creates a cohesive system that users can learn in order to find content on their own.
In this first example by Nathaniel Davis, the element of Information Architecture that is seen by your users is the navigation – the menu bars which are typically at the top and side of your knowledge base website.
These menu bars contain the links to the categories and content that comprise your knowledge base, and they should be organised in a logical hierarchy. These are the core instruments of your Information Architecture.
In contrast, Louis Rosenfeld and Peter Morville take a different approach by viewing the entire software interface as the visible element of your Information Architecture. Morville and Rosenfeld bring IA even further into the realm of User Experience, as opposed to a standalone discipline.
User Experience and Information Architecture are inextricably linked. Whichever approach you choose for your IA has to make sense to your users, and further both user and business objectives.
Peter Morville provides a comprehensive list of the principles behind Information Architecture:
As we can see from these two sources, IA is still an evolving discipline. It’s always, however, captured by one main idea: the relationships between things.
So you now understand Information Architecture, but how does this apply to your knowledge base in particular?
Your knowledge base has information architecture whether you like it or not. As Information Architect Abby Covert says:
There is a secret truth about information architecture: It never doesn’t exist.
You need to arrange your help content into logical and meaningful categories in order to create a coherent system for your users within your knowledge base.
Information Architecture is not so much a target to aim for as it is an ongoing process. It’s the framework for the way you structure your unique content helping it all makes sense. New content is always being added, and Information Architecture is never finished.
You should give equal important to the architecture of your knowledge base as your main brand website but recognised as unique and distinct.
The key difference between your brand website and your knowledge base is having a UX designer in charge of how information is presented. Your knowledge bases tends to have fewer stakeholders interested in its design, and thus the development of content is more organic.
This points to an important truth about Information Architecture i.e. not just owned by one person. It’s part of the whole User Experience for your product and company, and therefore the responsibility of everyone.
Focus on the purpose of your knowledge base – helping your users to self-serve. Your job is to educate them.
As the owner of a knowledge base, it’s unlikely that you’re a professional Information Architect. It’s good to learn about the overarching principles of IA, but you need something you can easily apply in your work.
Considering that you’re probably working as part of a larger team, here are the four distinct factors you can probably control on your knowledge base:
These are the main aspects of Information Architecture that you as a non-professional Information Architect should think about.
Our own knowledge base software Document360 contains all of these capabilities for organising your content. Some of the most powerful features to assist in your Information Architecture are:
This flexibility for organising is one of the biggest distinguishing features between knowledge base software and an ordinary website CMS.
Once you understand the nature of Information Architecture and its importance, your individual knowledge base must be tailored for your audience’s unique purpose. Your purpose will be slightly different in every case, as it depends on your product or service.
One element does remain consistent, though. Your knowledge base is a learning resource to help users understand your product and get the most out of it. As long as your IA fulfils this basic function, you’re on the right track.
Your audience purpose should be clearly defined in your organisational strategy, and it’s just a matter of applying it to your knowledge base Information Architecture. If you’re not sure what it is, then this is a good opportunity to define it.
Many companies survey their users to find out what they hope to get out of the product.
It’s helpful to look at real life examples of IA to make it less abstract.
Here’s our first example of a knowledge base with Information Architecture that stands out as helpful:
The purpose of the Twilio knowledge base is to enable developers to quickly and easily make their own products using the Twilio platforms.
It goes without saying that Twilio’s developer documentation is incredibly complex. Developers need a bird’s eye view of all the platforms at once.
As a result, this menu is how Twilio presents “All Docs”. That means each of these different topics is on the same hierarchy in the knowledge base.
You can assume that, if you dig deeper, each category will contain roughly equal amounts of content relating to these specific topics. Viewing topics on the same level of importance is also helpful because it helps the user build a clearer mental picture of an otherwise abstract product.
Content hierarchy means distinguishing between levels of importance. Don’t include content about a minor software feature on the same level the broad overview of your application.
Check out our whole post analysing the Twilio knowledge base.
Stripe has similarly complex documentation on its knowledge base.
In the Stripe docs the categories on both the left-hand menu and main content blocks completely laid out. The left-hand menu stays anchored while you navigate through the knowledge base, and also expands to reveal deeper subtopics when you click.
One crucial element of Information Architecture is to keep complexity hidden when it’s not needed, but allow users to browse through it when they choose.
We wrote a whole post deconstructing the Stripe knowledge base.
Information Architect Abbey Covert talks about making sense of complexity in her book How to Make Sense of Any Mess.
This poster also illuminates Covert’s view of Information Architecture:
Technical Writer Mark Baker has published many blog posts about Every Page is Page One.
Baker talks about the change in content consumption patterns due to Web 2.0. The reader is now in charge of constructing their own information experience, rather than the original author.
A search engine can point a user to any one of your knowledge base pages, meaning that they may never even encounter your carefully constructed homepage.
Information Architecture breaks down a large and complex amount of information into chunks. These are “standalone topics” that relate to each other conceptually, but any page can be read first. The difference is that every page links to other pages in case readers need more information.
Your job is to define these chunks and present them to users one at a time, similar to how you would present a blog. This helps users learn the structure of your knowledge base content and empowers them to take charge of their learning experience.
Expecting your users to rely on the search engine in your knowledge base isn’t realistic. It means they need to always know what problem they are having. But how many times does someone think they have a certain problem, which really turns out to be caused by something else?
Users are often not aware of what they don’t know. It’s your job to frame the problem correctly and teach users what they don’t know.
Every user is different, and even the best Information Architecture in the world may not be able to account for everyone. Even when your knowledge base is full of great content, your audience may not work out what is expected them.
That’s why your category titles, article titles, and interlinking show them the way. Another way to look at this as “signposting”, which we mentioned earlier.
You can include popular articles callouts on the homepage, and “related articles” on your content pages. Even if your audience doesn’t find what he or she wants on the first try, this gives them an idea of where to go next.
You should revisit your Information Architecture regularly as your knowledge base changes and grows. It’s an ongoing process.
If you put your users at the centre of your knowledge base, Information Architecture should naturally follow – as long as you also use these best practices.
Don’t be afraid to ask for feedback from your customers about how easy it is for them to find what they need.