By Catherine Heath on Writing docs from August 16, 2018
Information Architecture began its life in the design world as the “backbone” of good design – especially communications and print design – before filtering into the technology world.
It’s a term now used regularly in relation to websites, applications and other digital products. But what exactly is it, and how does it apply to knowledge bases?
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.”
Abbey Covert, Senior Information Architect at Etsy, academic, and author of How to Make Sense of Any Mess, discusses her top three questions she receives in relation to IA.
Peter Morville, well-respected author and Information Architect, presents a fantastic introduction to this concept in an interactive slideshow.
In their book Information Architecture for the World Wide Web, Lou Rosenfeld and Peter Morville identify the main components of IA as:
Information Architecture is important for websites because they are complex non-linear information objects requiring “maps” to direct users.
It focuses on the relationships between things rather than the things themselves. Thinking about how all things fit together means constantly affirming their relationship to the wider contextual goals.
It’s about breaking complexity down into meaningful chunks so that users can make sense of it, and also teaching them how to put those chunks back together into a meaningful whole if they need to.
To understand Information Architecture, you need to have a thorough understanding of your overall organisational vision and context-specific needs or goals.
It’s also a living entity – not a fixed structure that can be passed down from a higher authority forevermore.
Your Information Architecture is an abstract structure that will be represented visually in the User Interface. Rosenfeld and Morville present it as an iceberg.
Elements that are visible “above the water” in the user interface include categories, navigation and links. But most of your Information Architecture is hidden beneath the surface.
Based on the original iceberg analogy, Nathaniel Davis of the DSIA Research Initiative created this diagram to represent the field of Information Architecture:
Image caption: Information Architecture iceberg via UX Matters
All this can get a little abstract if you don’t intuitively understand Information Architecture. It can also be thought of as like a map of the London Underground.
It has:
If a user were to see the whole map at once, they would be overwhelmed. It’s not really representing the whole network of tunnels in the London Underground, but just the connections that travelers need to know about to make their journey.
You need to choose the part that must be shown in a given context. Sometimes on the underground they have these maps:
Image caption: Northern and Victoria Lines platform finder photograph via Ian Wright on Flicker under the Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) license
Markers must show whether users are at the right “stop”. IA is about information flow, and markers should also point to adjoining “stops”. Users must receive hints at how they can travel to their “final destination” – which they may never arrive at in a knowledge base.
It’s really important to be able to build up your knowledge base according to consistent internal categorization (like the Underground lines including the Northern Line and the Victoria Line).
Aside from simply using a search bar, this enables your customers to navigate your knowledge base by working out where they are in relation to the content they need to find.
Often, UX designers, content strategists, technical writers, or product managers are in charge of a site’s Information Architecture.
Information Architecture is usually something that designers think about all the time, but it’s not just for designers. It comes up for many writers in the cross-over field of “UX (User Experience) design”, since this is a field that most job titles have a stake in.
There are UX Writers, UX Copywriters, and Technical Writers (who write directly for users). Any one of these job titles may cover the domain of Information Architecture.
Information Architecture is a whole discipline but it is a term rarely heard of or used outside of the field. But you can apply the principles of information architecture to your documentation writing to make it easier to navigate.
Knowledge bases contain documentation that is consumed by users arriving in all directions (Every Page is Page One). This makes Information Architecture even more important.
Abby The IA presents a good definition and background to the term. She is an information architect who describes herself as a sense-maker. Kayako has also broadly defined Information Architecture in relation to knowledge bases.
“While we can arrange things with the intent to communicate certain information, we can't actually make information. Our users do that for us.” Abby The IA
Information architecture is distinct from the quality of your documentation writing. You can think of it as the way that libraries organize their books to help you find the ones you need. There are categories, there is order, and the structure (hopefully) makes sense.
Just as a website has top-level categories like ‘About’, ‘Contact’ and ‘Blog’, so does your help center. An alphabetized dictionary is also using Information Architecture, just as every book has IA.
Every website has IA, whether it is consciously designed or not.
Information Architecture is based on principles of cognitive psychology.
People are primed to look for links between your content to establish the architecture you’ve used, which they recreate inside their own heads as mental models. The thinker is gradually eliminating possibilities to arrive at their guesswork of the underlying pattern.
It rests on the principle that if a piece of information is one thing, it cannot be another. Intelligent structure reduces cognitive load.
This all happens unimaginably quickly and semi-consciously. Your Information Architecture needs to be so good that it’s intuitively easy to use, and doesn’t require clicking around your knowledge base reaching dead ends before your users can understand it.
We told you to think of IA as a map (or even a web or a network) governing how to get around in a particular place. If one thing has a name in common with something else, this implies they may have a relationship – like West Finchley and East Finchley on the Northern Line. Those places are the east and west parts of the same area.
In your knowledge base, the relationship may be that your content helps your user to master a particular task. Show that they have something in common through your naming choices.
If it turns out that two similarly-named things don’t have a relationship after all, the user may start to lose trust in your Information Architecture. That's why it's so important to name your categories consistently.
The importance of IA rests on the fact that people are programmed to look for patterns. They naturally arrange information in their heads according to patterns – often seeing patterns where there are in fact none, or a pattern based on a false premise (like racism). This helps them to reduce cognitive load by making predictions about what might happen next.
People are constantly deciding what is worth their time. Having a solid Information Architecture for your docs may help your users decide that yours are worth reading.
When you use Information Architecture correctly, your users can infer the amount of content that contextually surrounds the first piece of content they encounter. They are able to sense the size and shape of the whole (ie your knowledge base). They can guess what ‘level’ they are on when they first arrive at your knowledge base.
When designing the homepage of your knowledge base, you decide what you want your users to see first so it can hint at what comes later. It adds towards helping them to make sense of the complexity of any information domain.
Information architecture is intimately related to how you categorize the topics within your knowledge base. Your information architecture tells you where to place future content that you’ll write.
If your customers can reliably predict the layout of your knowledge base, this means they will be more likely to use it. It reduces the cognitive load for your customers. If you didn’t have Information Architecture, what would you have? FAQs.
The difference between an FAQs page and a knowledge base is primarily one of Information Architecture. It means that the complexity of the information contained within it is sufficient to require its own internal structure.
It’s not possible for Information Architecture to be missing from your documentation, because your readers will always interpret some kind of order. It can, however, be bad, unhelpful or weak, causing more harm than good for your users.
Of course, customers can always search for a term within your knowledge base if they can’t find what they're looking for, but what if they don’t know the name of the topic they want? They simply know they’re stuck, and they’re trying to find the right information to help them. Search capabilities are important but not the only discovery feature you need.
Information Architecture is something you invest in now that pays back dividends later.
Users will easily abandon their task if they can’t find something in your knowledge base. Failure to succeed results in customer churn, or an email to your help desk. This places more demands on your time.
When given a choice, people will always take the easiest option. If it becomes easier to google your product, ask another human, or quit using your product, that’s what they’ll do.
The ideal scenario for designing your Information Architecture is before you launch your knowledge base. This isn’t always possible and you can audit and redesign your existing knowledge base using IA principles (our knowledge base software KnowledgeOwl makes it really easy to move content and categories around).
Here’s how to get started:
Your audience is your users, but who are they? The more you know about them, the better. It’s not so much about random factors like age, weight and height but how you would define their relationship with your product. In the London Underground, the audience is users of public transport.
So your users could be customer support agents in a large enterprise team using customer support software. Or they could be independent small business owners using financial accounting software. The audience could even be your internal team.
You should have a goal (or multiple goals) for your knowledge base that can direct your Information Architecture. In the case of the London Underground, the purpose is to help move people around the city of London as efficiently as possible.
For example, if your goal is to help your customers self-serve or get more out of your product, then the architecture will facilitate this goal.
Ways that IA can help you achieve your goal include helping customers to discover content, providing them with context, or linking to a glossary.
Your audience and goals define the scope of your IA map. The scope of the London Underground map is the London Underground train network with links to National Rail and London Overground.
The scope of your map is your knowledge domain and involves specific outer and inner boundaries. If your knowledge domain is your product, then the knowledge base will not include anything outside of that domain. You may still link to concepts outside of your domain elsewhere online.
Your inner boundaries are the categories, like the zones 1–9 on the London Underground. You may not know the inner boundaries until you have created your taxonomy and categorized your knowledge base.
A stop is a unit of content, and this could be either a web page or a video. It’s best represented by an URL that you can point a hyperlink towards.
Make a list of all the content you want to include in your knowledge base. You can do this on cards and perform a UX card sorting exercise if that helps using online software, physical cards, or post-its. You can also do it in a spreadsheet.
Your number of stops will be constantly rising as you add more content, and sometimes it may be necessary to prune outdated content. These are stops you don’t need that will only bloat your knowledge base.
Your taxonomy is the practice and science of classifying your things or concepts, and the principles that underlie them. It’s developing your definition of a standardized naming convention (controlled vocabulary) to apply to all site content (Nielsen Norman Group).
On the London Underground these are the individual stops classified into Underground lines and zones.
Your things or concepts could be the features of your product, use cases, tasks, technical references, or any number of combinations of these things and others.
Each knowledge base taxonomy is unique and includes your category names, their place in the hierarchy and navigation structure. Here’s our post on exactly how to categorize your knowledge base.
Information Architect Abby Covert elaborates on taxonomy and how difficult it is to reach a consensus.
Markers are elements of your knowledge base that show users where they are currently and where they could next.
These are contextual clues like:
Navigational clues like:
And taxonomy clues like:
Some of your markers will be built into the knowledge base software you choose, which will automatically create breadcrumbs or offer Quick Links widgets for example.
Your taxonomy will now help you draw up zones in your knowledge base.
A zone is a category or a set of subcategories. We’ve published an in-depth post on how to categorize your knowledge base.
Look at your content and roughly figure out how your content should be organized. This depends on the amount of content you have for each topic (making up a category) and the relative importance of each topic or category.
Audit every piece of content you have (or intend to include) and place them in a map of your knowledge base.
Image caption: Example site map from Nielsen Norman Group
A knowledge base is also unlike the London Underground system because it’s possible to teleport around a website in a non-linear fashion. You can do this with hyperlinks which are your connections between stops.
Hyperlinks can be from:
You can make notes in your spreadsheet about how you will connect to other content in a linear and non-linear way, or connect your content once you have published it all in your knowledge base software.
Here’s a summary of the post:
Quality knowledge base software comes built-in with templates that have great Information Architecture, so you don’t need to worry about this when building your knowledge base. The creators of the software took all this into consideration when designing the templates.
Where you have the most control is naming your articles and your categories, as well as interlinking based on Every Page is Page One principles (check out this blog by Mark Baker).
Good Information Architecture is not easy to achieve, but it’s very much possible. Even if your knowledge base feels like it’s currently a mess, you can start organizing the information so it’s easier to find.
Constructing your knowledge base completely from scratch by developing the software yourself means it’s your responsibility to design with IA principles in mind.
Specialist software like our KnowledgeOwl knowledge base software takes care of most of this for you, and all you have to worry about is content. You don’t have to design elements like the search system, formatting, tagging or the navigation.
Your responsibility lies in categorizing, arranging and labelling evocatively and producing quality documentation. Sign up for a trial to see what we mean.
General posts useful to all documentarians about writing documentation, editing and publishing workflows, and more.
Your flight plan for how to get the most out of KnowledgeOwl features and integrate them into your workflows.
Major KnowledgeOwl company announcements.
Learn how others are using KnowledgeOwl & get pro tips on how to make the most of KO!
Find out more about who we are and what we value.
We believe good support is the foundation of good business. Learn about support tools and methodology.
Learn more about tools to solve various documentarian issues, within and beyond KnowledgeOwl.
Not sure what category you need? Browse all the posts on our blog.
Watch a 5-minute video and schedule time to speak with one of our owls.