Designing your Knowledge base Structure

In this post, I’m going to continue talking about Knowledge base content – I started this thread here, and added a diversion thread here.

I’m going to write about content you write or create yourself, which is about many of the specific things you have to do, and some of the issues that arise when trying to create content of this kind. I’ll refer to this as enterprise content – as it’s (usually) unique to a given company or organisation.

Getting Started

The first thing you need to do is decide who the consumers of your enterprise content are, because this will influence the nature of the content, it’s presentation, and it’s availability. I usually ask clients I’m working with to write down a single paragraph about each type of consumer, covering the expected level of expertise, and examples of the information they may be looking for. This then goes on to become part of the editor’s brief (more of which in later posts).

Grouping the content

Next what you should do is to stream or classify the content you wish to create. Unless you plan on having just a handful of documents, it is worth avoiding a ‘skip’ or ‘dumpster’ mentality where lots of unrelated content is thrown in together. Organising your content correctly at the start means your knowledge base can ‘scale’ correctly over time.

There are lots of ways to do this.

By document type. Examples might be:

  • Fault resolution: Documents that tell people how to resolve common faults.
  • How-to documents: These tell people how to perform common tasks that are not faults per-se, such as how to apply a service pack, deploy a ghosted workstation, order a new computer.
  • Bugs: A place where bugs or known errors and workarounds are listed

By subject matter. Examples might be:

  • Documents relating to operating system software
  • Documents relating to desktop software
  • Documents relating to hardware configuration

Which works best for you will depend on what type of company you are. If you make and sell specific hardware or software product, it might make sense to organise your content by product. If you are involved is more general IT support, it might make more sense to group by content type. Make sure the grouping will be understood easily by your consumers.

Serio refers to groupings of content like this as a Catalog. Unless you plan to have many thousands of documents, keep the number of Catalogs to as small a number as possible, particularly at the start. Too many does not help consumers, it confuses them.

Design Some Example Content

So far, we’ve got a picture of our consumer, and we’ve applied a simple organisation to our content. Now you need to write some example documents – not many, 3 or 4 in each Catalog should be fine. Here you’ll define the layout and, by example, the tone and style of the documents you’d like to see.

I’ll post next week on how to design a ‘good’ document (a totally subjective opinion I know) and how to create a quality system. I’ll also post some info on how you can ‘optimise’ documents for the indexing service that Serio uses.