How to categorize your knowledge base

Knowledge base categorization is an important part of Information Architecture. Your categories create order out of chaos and reduce complexity.

Many technical writers struggle with both categorizing and labelling documentation. They wonder how their users consume information, and what terms their users use for parts of your organization or product.

The answer is: it doesn’t matter that much. That’s because Information Architecture is a map that you give your users to help them navigate your documentation more purposely and efficiently.

The map is based on a set of assumptions most people hold about:

• How websites work
• How information is typically structured
• The user’s current context.

If you haven’t already, learn how to create Information Architecture for your knowledge base. Then read on to learn how to categorize your knowledge base.

What is categorization?

The Cambridge Dictionary defines categorization as:

“To put people or things into groups with the same features.”

This gets us off to a good start, but doesn’t really tell us how to categorize our content, or what the ultimate purpose of categorizing might be.

Turning to Wikipedia, we now have an explanation that categorization means:

“Categorization is the process in which ideas and objects are recognized, differentiated, and understood. Categorization implies that objects are grouped into categories, usually for some specific purpose. Ideally, a category illuminates a relationship between the subjects and objects of knowledge. Categorization is fundamental in language, prediction, inference, decision making and in all kinds of environmental interaction. It is indicated that categorization plays a major role in computer programming.”

We can understand categorization by thinking about taxonomy – the practice and science of classifying things or concepts, and the principles that underlie them.

Categorization can be thought of as part of your taxonomy for the concepts within your complex information object – your knowledge base. Your categories are part of your taxonomy and they are limited to a specific knowledge domain, which forms the outer boundaries of your taxonomy.

Look at this taxonomy for British sharks:

Image source

The knowledge domain is “British sharks”. The creator has included all the sharks within this domain, and they are categorized according to their belonging in particular subcategories. The subcategories are defined by the presence of certain biological features.

In the context of taxonomy, categories are used as:

• A conceptual framework for discussion
• A tool for analysis
• A method of information retrieval

The categories in your taxonomy should be “mutually exclusive and unambiguous”, and include all possibilities (all of your content) when taken as a whole.

Your taxonomy should be:

• As simple as possible
• Easy to remember
• Easy to use in practice

What does categorization mean for technical writers?

Your categories are the zones in your Information Architecture map. They orient your user by telling them where they are. Categorization is how you organize your documentation into meaningful groups.

Labelling

Category labels serve as “markers” to your users showing what “stop” they’re at, and suggesting where they could go next.

It means labelling your documentation categories with evocative terms. Calling your categories “One”, “Two” and “Three” for example is not useful at all. Call them things that mean something to your users.

Example

For a typical ecommerce company, that might be:

• Checkout
• Orders
• Deliveries & Returns
• Account

These basic top-level categories are mostly defined by the stage in the purchase process, and are broad enough to include all your documentation.

What you need

You don’t need to know the minds of your users back to front to create a good taxonomy. It should ideally be similar to other “taxonomies” they have seen before for maximum efficiency.

Consistency is key, and as long as you have empathy you will be able to categorize effectively. Organisational objectives are important, but they are the least relevant factor when it comes to categorization.

Identify areas of your organisation or product

Your categories reflect the relationship between your customers’ needs, and the knowledge domain of your site. The knowledge domain is likely to be your organisation’s work, or a product along with features and related concepts. Your users’ needs are whatever they have come to you for.

External knowledge base 

External knowledge bases often represent a particular product or service. This means you can organise your categories by features, or come up with specific areas of issues that your users typically encounter.

Not only will you have information about your product, but there might also be related concepts, functionality, and use cases.

If your knowledge base is for customer support software, your categories might be:

• Getting Started
• Account Management
• Technical issues
• Reporting
• Integrations

These are fairly familiar categories that orient your user right away. Processes don’t always sit within a single team. For example, you might want to have all documentation relating to “product support” in one place – regardless of whether a dedicated team exists.

Internal knowledge base

If your knowledge base is internal, you are more likely to categorize it according to team domain. This is tempting but it’s usually best to focus first on user needs then work backwards. If your user base is particularly diverse, as in a large university, then you can provide the initial framework of understanding.

For a university admin department, your categories could be:

• Human Resources
• Finance
• Admissions
• IT
• Library Services

Their categories must encompass admin staff, academic staff, library staff, maintenance staff, current students, former students, and many more possible users. In this case it’s better to stick with organizational structure.

Ideally, you should label your categories with the internal processes you use in your company rather than basing it purely on internal teams. For example, “financial” is more descriptive and evocative than “accounts department”.

Your turn

Ask your customers some questions to gather more information about how they interact with your product or service. Use your empathy, and combine it with any analytics you have to decide on the best categories for your knowledge.

How to group your content

Most knowledge bases have content grouped using level of “depth” or “granularity”. Granularity is size relative to the whole.

Imagine an atom – it is made up of different-sized particles, each of which can be broken down into smaller particles. These subatomic particles are:

• Composite particles – made up of smaller particles
• Elementary particles – the smallest unit of matter

Image source

Content at a similar “depth” level should be grouped together.

What if you don’t have a pre-existing system that you can base your categories on, such as biological diversity or subatomic particles? You can decide that you want to have five top-level categories and draw up the boundaries based on having five roughly equal-sized segments.

You can use formatting to distinguish between the different content tiers. Introductory content can be shorter and more visual, written in a more conversational tone. It might be written in a way that is aimed at the more general or beginner user less patient with your product.

Think of your categories in terms of depth

The “depth level” of your categories must orient your user. This means your category names must be of an equal level of depth if they are on the same tier – top level, second level down, third level down, etc.

This equality of depth (or weight) builds consistency in your system, and contributes to a sense that there is an intelligent design.

Emotional significance

Use your intuitive understanding of the emotional significance of words to help you with this process. The words for your top-level categories should be “symbolic” rather than “descriptive”. They are concepts rather than actions.

Context

The meaning of words also depends on the context where you find them. For example, the word “community” is more significant in the context of the world as a whole, than in your local neighbourhood. Nevertheless the concepts are still related.

Distinguish between categories and content

A piece of content is a single unit of documentation such as an article or a video. It can be thought of as a “stop” on your map.

Content that is conceptually related can be grouped together into categories. For example, content all related to accomplishing a certain task, such as managing a user account. Categories may be a whole “zone” in themselves or part of a larger zone.

Categories function as signposts for your user directing them towards particular types of content that have been placed together. How well this mechanism works depends on whether you have used terminology that is both evocative and familiar to your users.

Create your top-level categories

Top-level categories tend to be labelled with short words or phrases that encompass a large body of documentation. They are broad and non-specific.

This means your top level categories should be broad and sweeping to encompass a large variety of content, such as ‘your account’ and ‘analytics’.

They should not be called things like ‘editor permission role’, ‘changing your contact details’, and ‘how to find your total unique visitors’.

Do you see the difference?

Your top-level categories should be broad enough areas that your customers will expect to see when they get to your knowledge base.

Examples

Take MailChimp as an example:

Stripe may hold the position for most-loved documentation. With the Stripe docs, they present their top-level categories as: Payments, Subscriptions, Connect and Radar, because these are what they identify as the most important areas for their users.

Wave has grouped its content based on its different purposes for the user: getting started, guides and reference.

How to choose top-level categories

They should reflect your product, but also mirror other knowledge bases out there. Using expected taxonomies capitalizes on your customers’ prior experience, and reduces the amount of effort it takes to learn a new system.

At the same time, you need to present your topics in a natural and logical way. Just because everyone else is doing it, doesn’t mean it’s the right way. Your top-level categories should also reflect how customers interact with your company, and what they would consider the most important topics for them to learn about. Empathy is absolutely key here.

How many categories should I have?

Try to keep your total number of top-level categories to less than ten (five, if you can manage it). This is for simplicity.

Also, ensure they are similarly significant to warrant being included as a top-level category.

Create your sub-categories

Once you’ve decided on your broad, top-level categories, these need to be divided into subcategories. Your subcategories are what separates each tier of your content from each other.

These are usually hidden at first to reduce the complexity of the information that users need to see. Users can click on each category to reveal its contents.

Github does it like this:

Their method is actually quite overwhelming because you can see too much all at once. Bitbucket works harder to keep some complexity hidden:

Hiding complexity

The more complex your product is, the more likely you are to need lots of subcategories. Bear in mind that not all categories will need to be divided up further and can be just fine on their own. Don’t aim for symmetry just for the sake of it.

In KnowledgeOwl, content pages can also be categories because sometimes a topic needs to be on the same level as a category, but cannot be divided any further.

As users explore deeper and deeper inside your knowledge base, some articles might explain very technical concepts, or cover brief but finely-grained topics.

Quicklinks

If you have content buried deep in a subcategory but you think it’s important for some users to see it on the homepage, you can always surface it using quicklinks or frequently used articles.

PRO TIP: If you don’t need to have lots of sub-categories, you can also organise shorter or more granular pieces of content into broader “guides”. Guides cover a wider spectrum of concepts than you’d usually find on a single content page.

“Getting Started” guides are popular with Software as a Service companies, and developer-focused documentation.

How to handle “deep” content

Some information is written at a more advanced (or “deeper”) level for more experienced users, or more technical users. It can’t be broken down anymore, and yet it’s hard for this kind of content to “stand alone” – nor should you want it to.

A deep-level content page may link conceptually to other deep-level content contained in separate categories, so in this case you can hyperlink. The link could either be from a relevant term in your documentation, or in the references/footnotes of your documentation.

You can also link to external reference material or a glossary.  

Review with your team

Gather as much input as possible from your team when categorizing your knowledge base. Other people may have a perspective that you don’t. They’ll know best what should be in there – at the same time, stand firm about your taxonomy.

Your customer support team will be of particular value in this exercise, since they know your customers and their perspectives.  

Once you’ve decided on your categories, show your plan to your team for a final review to ensure it makes sense, and is likely to be useful.

Use other knowledge bases as inspiration

Don’t be too proud to learn. Other people have done similar things before and done them well. Start paying attention to other knowledge bases and how they’re structured to build up a picture of what works well.

Here’s a list of good knowledge bases:

• Stripe
• MailChimp
• Python
• Ruby

Remember that each knowledge base’s categories are different due to its specific purpose, unique context, and different customer base.

Don’t try to directly copy anyone else’s design, and instead take inspiration from other knowledge bases that you like in order to produce your own appropriate categorization.

What happens if I don’t categorize well?

If you fail to categorize your documentation well, your users will become very frustrated and think you don’t know them. Over-reliance on the search bar is like expecting your customers to do all the work for you. It also doesn’t help that much with exploration of your product.

Providing them with a conceptual framework – a map – for your knowledge base is empowering customers to take part in an active relationship with your product.

Summary

Your knowledge base categories are a crucial part of creating an exceptional support experience for your users. Ensure you use your terms and labels consistently.

Make sure you benchmark your categories against others in the industry and ask your team for their input before you make any final decisions.

Don’t forget to make use of diagrams throughout your process, and particularly the good old-fashioned pen and paper.