Knowledge Base Organization Techniques

Knowledge bases can be extremely helpful in both reducing the number of times that customers need to contact your support staff and as a valuable reference resource to your support staff. Today I’ll break down a few different techniques for organizing your knowledge base and point out the advantages of each.

Divide Information By User Type or Role

If you have multiple user or customer types that will be accessing your knowledge base you may want to develop separate areas for each audience. The Slack knowledge base for example has one area for “Using Slack” and then a separate area for “Team Administration.” This kind of division can make it much easier for users to narrow down what they are looking for.

As a hypothetical example, consider a school. A school would have Students, Teachers, Administrators and Parents. If they were to browse a knowledge base for information on “viewing grades.” Students would want to know how they get feedback from their teachers. Administrators would want to know how to view GPA and class averages. Teachers would want to know how to view their class’ gradebook. Parents would want to know how to view their child’s grades. In this situation breaking knowledge base information down by role would work great.

There are instances, however, where this may not be the best idea. In situations where roles are not clearly defined, or overlap greatly, organizing data by user type can cause confusion. For example a knowledge base for a camera would not function well if it were divided into sections for “Sports Photographers” “Nature Photographers” and “Portrait Photographers”. The reason for this is because each type of user needs to know how to perform the same actions with the camera, they might just choose different settings for a given situation.

Organize by Activity

You may only have one product to support but a wide feature base. In this case organizing by activity may be the right way to go. Take for instance Microsoft’s Outlook support site. They organize their articles by the activity. For instance, “Set up your email and get started”, “Working with Contacts”, “Meetings, Events, and Reminders” and “Archive and Backup Outlook Items” are all knowledge base sections. Breaking down the articles for a complex application like this into activity based sections make’s it very easy for users to find what they are looking to do.

One thing to watch out for with this method. If your knowledge base is purely activity based novice users may not know where to start. You will notice that Microsoft included a “getting started” section. This can help to alleviate one of the downsides of this approach.

Organize by Stage / Experience of User

Taking the project management software Asana as an example, they divide their knowledge base into 3 main sections, “I’m just getting started with Asana”, “I’m helping my team learn Asana” and “We’re expanding our use of Asana.” In this case the user identifies what stage they are in the usage of the product and then dives into the appropriate section to get relevant information. If your product has very defined usage stages this method can work great. You must be careful though that the stages are clear and that you don’t leave users searching through each stage for the information they need.

Tag and Cross Reference

No matter what organization method you choose for your knowledge base you can help users surface the information they need by linking to relevant information inside of articles. Depending on you Knowledge base tool you may have a number of different ways to do this.

In HelpSpot for example, you can include inline links to other articles. Most tools should have at least this feature. In more advance KB tools, like HelpSpot’s, you will also be able to add knowledge tags and related articles. Knowledge tags allow you to have a secondary form of organization that can span your primary organization method. For example the “time tracking” tag in our knowledge base for HelpSpot includes articles from the Users Manual, Getting Started Guide and the Admin Manual.

Hopefully these examples have sparked some ideas for your own support documentation.