Jobs are requiring more tech-savvy workers and remote work is increasing: your company needs an effective knowledge base to operate long-term. A knowledge base keeps institutional knowledge from becoming “unspoken rules”; it helps train new employees, and it organizes all your useful information into one clean database.
A knowledge base is a repository of useful information. While an internal wiki is generally for those inside your company or for other businesses you may have close relationships with, a knowledge base can also refer to a customer-facing resource designed to answer questions, provide troubleshooting tips, or just house instructional material. It works just like a wiki, gathering topic-based “articles” into an easy-to-organize system.
These tips will walk you through the entire process of setting up your knowledge base or internal wiki, from ideation to structure, organization, launch, and upkeep over time.
1. Customize Your Knowledge Base for an Ideal User
Before you create anything that people are supposed to use and engage with, think to yourself: who is the ideal user of this tool?
Why is this user seeking out the knowledge base? Are they a customer looking to understand a product? A mechanic or IT person trying to figure out how to troubleshoot it? Or is your knowledge base for employee training? Once you’ve decided who is going to be using this knowledge base, only then can you move forward with design and construction.
If your knowledge base is internal, focused on employees, then the language in the articles can be more technical and functional. You don’t have to butter up a customer; you can get right to brass tacks. Then the focus of your internal wiki becomes onboarding, collaborative education, and peer learning.
If your knowledge base faces outward, you’re going to want a more stylish interface. If customers are doing their own troubleshooting of your product, you’ll need more images and helpful videos to get them going.
Once you have this ideal user in mind, you can use it to mold every part of your new knowledge base toward what they need to succeed.
2. Choose Software to Organize Your Knowledge Base
A knowledge base can be as complicated or as simple as you like to match its ideal use. It can be an interconnected series of web pages, or it can be its own website, app, or database meant to be explored, saved, and shared.
A knowledge base could be something as simple as an interconnected series of Google Docs — though we don’t recommend it. Something like that won’t work at all for a customer-facing wiki, obviously, but even internal wikis made from a web of kludged-together Google Drive documents have a ticking clock on them. The URLs aren’t consistent, embedding content is difficult, and the search function needs work (we’ll get to the importance of that in a moment).
Ideally, you want a dedicated piece of software — an app meant for creating wikis and knowledge bases.
Perhaps one of the most important features of the software you choose is a solid search feature. True, the structure of your knowledge base is going to clue people in on where to find articles, but most people go right to the search bar first.
Here are a couple of places to start looking:
Tettra. Tettra helps you create a complex knowledge base with a clean look and intuitive organization. Tettra is a great solution for an internal wiki. If you’re looking to train employees, outline complex or complicated processes, or provide links to HR and other staff documents, Tettra might be what you’re looking for.
Helpjuice. Not as feature robust as Tettra, but Helpjuice is still useful for creating internal or external wikis and knowledge bases. Definitely worth checking out if you’re looking to create a knowledge base to share with customers.
3. Structure Your Knowledge Base
Before you dive into writing articles for your knowledge base, you must create an organizational strategy. This will not only help users find the articles they’re looking for, but it will also help you (and other contributors to the knowledge base) know what articles still need to be written. Essentially, you don’t know how many rooms to build in a house if you don’t have a blueprint.
How is the base organized? Basically, how many categories will your knowledge base have? Less is more here but allow for growth. Categories can be added later, sure, but then you’re essentially tasking someone to have to comb through the old articles and add the relevant categories manually. So, think this through at the beginning.
A mostly onboarding knowledge base might have categories like Onboarding, HR, Training, and Policies. A comprehensive internal wiki for all training, documentation, procedures, and policies might have more categories.
Map them out in advance, eliminate any redundancies, and let some of your colleagues tear apart the list to find better categories or categories you may not have thought of. Get a member from every department in on the process — if you forget something, you may regret it later.
How are individual posts structured? This is where you determine your article format. Do you use headers to separate sections? Are links embedded in the body of the text or at the end like footnotes? Do you link internally to another article or embed the relevant content? Does every article require an image?
Formatting is important because it ensures that your articles don’t look like they were assembled by 50 different people — even if they were. Formatting adds clarity and ensures important information doesn’t get skipped. Plus, it allows your users to find information more quickly.
Think about how supermarkets tend to be arranged in similar ways — deli on one end, produce on the other, freezer food all together. This helps shoppers orient themselves no matter where they are. Consistent wiki formatting will do the same for your users.
4. Don’t Try to Write the Whole Thing All at Once
Depending on the complexity of your company or field, the word count of your knowledge base could expand into textbook territory — or beyond. This breadth of scope is often what discourages knowledge bases from being finished (or, worse, being started at all).
Don’t commit to writing the Iliad when you can get three or four articles finished and have a solid start. It’s like the old saying: “How do you eat an elephant? One bite at a time.” Don’t try to eat the whole elephant for dinner is what we’re saying.
Think of your most common complaint. First, start with the most common problems (or most common pain points) that potential readers encounter on a daily basis. What question do new employees, customers, or colleagues ask the most? That’s your first article.
Start simple. If you’re familiar with the KISS principle (Keep it Simple, Stupid), this should be your guiding star. Every article should be only as long as it needs to be. An article can start as a few sentences or even just as a link to the relevant source material. Just get the article done, fit it into your wiki structure, and make sure it has all the necessary tags and categories to help it get found. The article that exists can be expanded later — an imaginary article cannot.
Create a schedule and stick to it. If you leave article writing to a whim, it’ll never get done. Instead, schedule that one article for the knowledge base gets written and uploaded every day, or every week, or twice a week, whatever suits the projected size of your knowledge base and your workload. Communicate this schedule to everyone responsible for writing the knowledge base. Stick to it!
5. Use Images and Video in Your Knowledge Base
All text and no images make Jack a dull boy — here, “Jack” is a knowledge base. A wall of text is no one’s friend, and sometimes images or video can convey information faster. Moreover, some people just naturally learn faster by seeing something rather than having it spelled out for them.
Consider the visual learners in your user base whose experience would be greatly improved with added graphics, charts, and diagrams or how anyone can benefit by having a complex process shown to them rather than explained. Even something as simple as an article about scanning documents on the copier and sending them to your email could benefit from a little visual instruction showing where the relevant buttons are.
Videos can add a personal touch to an article or go further in-depth on truly complicated topics. They’re also a great way to keep the attention of a user on a dry subject. Training videos for new employees, feature videos for customers, and useful PowerPoint decks can all be tossed into an article to aid understanding and add a little flair.
6. Find a Level of Support That Fits Your Product
When constructing a customer-facing knowledge base, there’s one rule you have to stick to. Luckily, it’s simple: the complexity of your knowledge base should match the complexity of your product. There’s no reason to deep dive into knowledge articles about products like clothing, beverages, or hammers. Colgate might have a website, but sometimes toothpaste is just toothpaste.
Try integrating support forums. A knowledge base linked to a support forum for your customers can help you cover all of your bases. Where your knowledge base fails, a customer may be able to find the solution from other users or your own support staff. Consider this, too: if a forum post becomes extremely popular, that probably means there’s a hole in your knowledge base somewhere. These red flags will help you patch the holes in your knowledge base just by sourcing user content.
Technical products may need a helpdesk. FAQs, diagrams, and support forums may only get you so far. Sometimes, customers encounter a strange problem or are having trouble parsing a troubleshooting document. Embedding some kind of helpdesk contact into your knowledge base might be a good idea.
For smaller businesses or less complex products, add a contact page to your knowledge base. Even something as simple as an email or a phone number could help customers who get completely baffled by either your product or simply navigating your knowledge base.
Match Your Knowledge Base to Your Needs
Creating a knowledge base doesn’t have to be a huge pain. A little strategy beforehand can save a lot of unnecessary or redundant work in the long-term.
- Plan your formatting.
- Organize your wiki structure.
- Choose your software.
- Determine your ideal user.
- Create a schedule.
- Add some visual flair.
- Anticipate user support.
From there, creating and launching your knowledge base is just a matter of solid scheduling and sticking to the plan.
