Determine your content hierarchy

Some knowledge base tools restrict the number of "levels" in your content hierarchy to three levels:

Level 1 content

• Level 2 content
  • Level 3 content
• Level 2 content

Level 1 content

KnowledgeOwl doesn't do this.

While this means you have some amazing flexibility to your content hierarchy, all that freedom can be a bit challenging. How should you organize your content? How deep should your subcategory hierarchy go?

The trouble is, there's no one right answer to this question. Go take a look at 3-5 knowledge bases or websites you use frequently, and you'll quickly find out that each of them arranges things slightly differently. So we can't tell you an exact equation to follow to make sense of this. If you do a search for "information architecture scheme" or "taxonomy", you can surface a lot of studies and advice on these topics--many of which will conflict with each other.

Rather than try to reinvent the wheel, we'd just like to share some experience in trying to arrange our own knowledge bases. 😊

#1: You won't get it perfect

Hopefully this isn't too disheartening to start with, but: you aren't going to get your hierarchy perfect. Definitely not the first time out, and frankly, maybe not ever. Accept this imperfection. Embrace it, even. Go into it recognizing that you'll need to iterate.

#2: Some people will naturally browse; some will naturally search

Studies on this topic are fairly varied as to the actual percentage of readers who search first, and there's fairly little research specifically on knowledge bases (rather than websites as a whole).

Which isn't to say that your content hierarchy isn't important, but remember that it's not the only way your readers will find your content!

#3: Keep it simple, organized, and consistent

If you're creating a knowledge base for your internal policies and procedures, it can make sense to have each department or team be one top-level category. People in that department or on that team will naturally look in "their" category for content relevant to them. This might not be the fanciest of hierarchies, but it's one that your readers will adapt to fairly quickly. (Using Shared content articles for content that lives in multiple departments/teams can ease your administrative burden, too!)

This is also a good strategy if your knowledge base documents multiple products--having each product as its own top-level category makes sense, maybe with a consistent subcategory structure.

Since all organization and hierarchy is a little arbitrary, most readers will need to "learn" your structure. Make that structure easier to learn by keeping it consistent. For example, if you have one top-level category that has 50 articles in it and your next top-level category has 4 levels of subcategories, and some of those subcategories have articles in them and others only have other subcategories...the logic to your structure isn't going to be very clear to your readers.

Whatever logic you use, try to commit to it and be consistent.

#4: Fewer top-level categories is not necessarily better

We've seen the suggestion a few times to keep the number of top-level categories you have to no more than seven. If you've looked at this support knowledge base much, you'll likely have noticed that we break that rule. We have eight top-level categories displayed on the homepage, and we actually have ten top-level categories once you count Release Notes and the Getting Started Guide.

We previously had four, and I can say, it was a lot harder figuring out where content "lived" in the four-category structure.

#5: Focus on information-seeking goals or actions

There is a ton of research on information architecture and taxonomy, and we're really oversimplifying here, but one of the easiest ways to structure your content is to focus on the goals or actions your readers will most need to do, or that you want your knowledge base to most readily address.

When we reorganized this support knowledge base, we considered several factors for our content layout:

• Were there areas of knowledge that were primarily referenced by different types of customers, or different departments/teams at the same customer site?
  This helped provide the rationale for splitting out "Security and permissions", "Account and billing", and "API and webhooks" as their own categories. Security and permissions nearly always involve a customer's IT department; account and billing often involve billing contacts who are rarely in KnowledgeOwl; and API and webhooks is geared toward developers or highly technical individuals. These categories make it easier for those separate teams to find their way in the knowledge base, while also being category labels that make sense to content creators who might be browsing through the knowledge base.
• Were there areas of our knowledge base that caused a high volume of support conversations? 
  This helped provide the rationale for making "Look and feel", "Write the Docs", "Features", and "Search" their own top-level categories. The key here was to focus on the high volume of conversations that seemed to be a result of customers not finding info/simply not understanding whether a feature existed or how it worked, rather than running into problems using it and needing our help to fix it. We thought of these conversations as product questions rather than bug reports or feature requests.
• Were there areas of our knowledge base that were heavily referenced by authors who were on a free trial or evaluating our software?
  This helped provide a rationale for moving "Reporting" and "Search" to the top-level, since both of these tend to come up in software evaluation processes. It also provided support for having "Security and permissions", "Account and billing", and "Look and feel" at the top-level, since many of these questions come up during the initial phase of configuring/setting up a knowledge base.

#6: Test your categories

Once you think you've identified some good candidates for the top level of your content, do a test: grab some random pieces of content you already have. Sit down with at least one other coworker, and each of you independently try to put that content in one of those top-level buckets.

Once you're done, compare notes and see if you put them in the same place. If you did, this could be a sign that your labels and your categories make sense. If you didn't, this can be a sign that you still have some iterating to do (either in the categories themselves, or the wording of them).