How to Revamp Your Knowledge Base Architecture
In my time as a support agent, some of the most frustrating customer questions to answer actually had nothing to do with the customer. They were asking entirely reasonable questions and doing so very politely.
I was frustrated because I knew that the perfect answer to their question was right there in our help documentation; very often I’d written it myself! But an answer merely existing in a knowledge base isn’t the same as that answer being findable, scannable, and understandable.
Creating and maintaining a knowledge base is a lot of work, but that effort is wasted if the knowledge isn’t easily accessible to the people who need it. This guide to redesigning your existing knowledge base architecture will help your team and your customers get the most out of your help documents.
This is chapter eleven in our Ultimate Guide to Using a Knowledge Base for Self-Service Support. When you're ready, check out the other chapters:
Chapter 1 – Knowledge Base 101: Definition, Types, and Benefits
Chapter 2 – Quick Start Guide to Creating a Knowledge Base
Chapter 3 – Knowledge Base Design Tips for Better Self-Service Support
Chapter 4 – Incredible Knowledge Base Examples That Get It Right
Chapter 5 – Tips & Templates for Writing Great Knowledge Base Articles
Chapter 6 – Creating Knowledge Base Videos: Tips, Tools, and Examples
Chapter 7 – Simple Knowledge Base SEO Tips Anyone Can Follow
Chapter 8 – The Best Knowledge Base Software + How to Choose One
Chapter 9 – Actionable Knowledge Base Metrics to Start Tracking Today
Chapter 10 – Knowledge Base Tips for a Better Customer Experience
Chapter 11 – How to Revamp Your Knowledge Base Architecture
Why redesign your knowledge base?
Why would you want to spend your time redesigning your knowledge base? It’s not like you don’t have plenty of work to do already! Of course, the whole benefit of knowledge base software is that it allows your customers to find answers for themselves and not have to ask for help and wait for you to reply.
Investing time and energy into redesigning your existing knowledge base is worthwhile when the benefits you expect to earn outweigh the upfront effort required.
Here are a few common reasons to consider a knowledge base redesign:
Customers are frequently asking questions that your knowledge base already answers. Some customers will always default to contacting support, but others would much prefer to find the answer themselves. If your knowledge base has the answers they need but they’re still asking you, that suggests a problem finding or reading the content.
You have content you know is out of date, but you’re not updating it. Have you ever left your garage so messy for so long that it seems pointless to even try to be tidy? Knowledge bases can be the same way. If you’ve stopped trying to improve the existing content, it might be time for a reboot.
You’re hesitant to send customers to your knowledge base because it’s hard to read. If your knowledge base articles are hard to read or poorly arranged, your team may hesitate to recommend them.
If any of those resonate with you, or if you have your own set of reasons, then read on for our guide to planning and executing a knowledge base redesign.
The 5 step plan for a successful knowledge base redesign
A knowledge base redesign can feel daunting, especially if you have a large or … well aged … set of documents to work with. The following plan will increase your chance of success significantly, and it can be adapted to suit your resources and situation.
1. Know your capacity
Before you start work, take time to develop a realistic understanding of where you stand.
What capabilities do you have access to? Do you have designers available for visual styling? Do you have an information architect or user experience expert who can contribute to the project? Technical writers or contributors from the support team?
How much time can you spend? If you’re running this project while keeping up with a busy support queue, you need to be realistic about what is possible. Better to commit to a few hours a week and succeed over time than try to do it all and fail.
What tools are available? Are you using knowledge base software already? Do you have other tools to test out? Can you easily create screencasts or animated GIFs?
2. Conduct a knowledge base audit
Understanding what you are working with will inform how you roll out changes.
What content do you already have? Whether you use your knowledge base reporting tool, get a database export, or just paste into a spreadsheet, generate a list of all the different pages in your knowledge base. A full content audit is beyond the scope of this article, but starting with a list of titles will help you know what you’re working with and help you decide where to start.
How are your customers accessing that content? Knowledge base design is not just about the design of individual pages. It’s also about the design of the entry points to those pages. If your content is hard to access at all, then redesigning the pages will be wasted effort.
Common access points to review:
Marketing website (navigation menu, your contact page)
In-app prompts (if you’re working on a software product)
Customer communications (linked in your invoice emails or printed in your brochures and manuals)
In your customer support replies (if your team send links to your customers, or in your support email footer)
3. Inform your redesign
Which pages should your redesign concentrate on? What exactly needs to be redesigned? To answer those questions, take advantage of the following sources of knowledge base data.
Reveal what your customers are searching for. Your knowledge base software may be able to tell you the phrases and words your customers search for (see Help Scout’s Docs reporting for an example). If there are popular searches leading to zero or few helpful results, you know which content to add. But if there are popular searches which lead to the right page, yet still end up as support tickets, those are the perfect target for redesign.
Know which pages are most heavily used. Some questions cannot ever be removed entirely, and related answers in your knowledge base will always be among the most read. Design improvements to those pages will have a much greater impact than working on rarely seen content.
Ask your support team. Your customer support representatives may know of help documents that aren’t being found or that customers aren’t understanding clearly. Ask them for their priority lists!
Use help desk reporting. Some help desk tools integrate with a knowledge base and are able to tell you which knowledge base articles are most often recommended in support answers.
Review customer feedback. If you have “was this helpful?” or similar feedback systems on your help documents, those are an excellent source of data for prioritizing your redesign plan.
4. Review your information architecture
Information architecture (IA) is about how you structure and create a hierarchy of information in your knowledge base. A full IA review process is an entire project on it’s own, but having a basic understanding of how to make information accessible and findable is vital.
One lightweight option is to use the document you created in the content audit step and conduct a card sort. Have customers, potential customers, or even members of your staff (who aren’t involved in the knowledge base itself) tell you where they would expect to find certain answers, and you’ll quickly see where you may have navigation or labeling problems.
Can your customers find the right area to look for their answers? Do the titles and categories you have chosen match the words your customers use to describe the same content?
For a deeper look at information architecture, start with Donna Spencer’s book, A Practical Guide to Information Architecture.
5. Set your goals
By now you should have a good idea of what needs to be done, in what order, and what skills and capacity you have to do it all.
Use that information to set a realistic scope for your project. You don’t have to (and probably shouldn’t) commit to redesigning every page all at once, so pick the biggest wins you can get done in the time you have.
Some example redesign goals might be:
Developing a new style sheet for the knowledge base to make existing content more readable
Redesigning the top 20 most visited articles for increased clarity and scannability
Creating a process for updating three old articles per week to the new format
Adding animated gifs to the most frequently used process documents
Now, it’s finally time to do some designing!
Redesigning knowledge base documents
With goals set and a list of documents to improve, you’re ready to start redesigning. What form should that redesign take? It depends on the specific issues you’re attempting to address. Often there will be multiple possible improvements, so start with the ones that are easiest for you to implement, considering your time and skills.
Styling redesign
This technique is best used when your content is solid and your pages are technically well-structured (e.g., using HTML headings, list items) but the pages are difficult to scan or hard to read.
If you’re fortunate, some tweaking of the CSS style sheet can make a big difference to all the pages of your knowledge base at once. If not, it might be more of a per-page editing process.
Structural redesign
If you have the right information in your knowledge base but it’s spread over too many different pages or lumped together in too-long sections, then a structural redesign is in order.
It is tempting to take your existing pages and just reformat them to make them a little clearer — that is beneficial, but the bigger wins come from rethinking what information should be on any given page, as well as how to present it.
Move down your priority list, taking a section at a time. For each section, look at your help desk reports or have your support team generate a list of the common questions.
Now you can rework your content to address those questions. Don’t be afraid to repeat information across pages when it makes sense, because you can’t rely on your customers having read all the other related content.
How Campaign Monitor redesigned its knowledge base
Carlee Potter and Craig Simms are the technical writing team at Campaign Monitor, a SaaS email marketing application. Over the last year, Carlee and Craig have rebuilt, redesigned, and migrated the Campaign Monitor help documentation from an internally built tool into Salesforce’s Service Cloud knowledge base.
In this interview, we cover:
The difficulties of writing “white label” help documentation.
How they measure whether their documents are working or not.
Why they decided to rewrite almost 400 documents.
Their challenge in getting management budget and attention for the project.
The development and design of their new knowledge base.
Their suggestions for anyone considering a similar project.
Measuring the impact of a knowledge base redesign
Given that you will be investing a significant amount of effort into your redesign, it is worth having some clear metrics to determine whether it was time well spent.
Ideally you would have these measures in place before the redesign so you can track any changes after your project is completed:
Page visits — How many unique visits is your knowledge base receiving? Break it down into categories and individual pages so you can compare pages before and after they are redesigned.
Bounce rate — How many people arrive at a particular help document and, from there, leave your help website? Typically in web marketing a high bounce rate is a bad thing, but when your goal is to get customers an answer and let them get back to their work, having them wandering from article to article can indicate a problem.
Failed searches — How many people search in your knowledge base and then go on to create a support request within a few minutes? It’s reasonable in that case to assume that the document didn’t answer their question sufficiently. After you’ve redesigned the page, does that number improve?
Usage of help docs used in support replies — How often is your support team referring to help documents in their answers to customers? An increase in usage can indicate growing confidence in the quality of the documentation.
Direct feedback from knowledge base pages — If you have a “was this useful” type form on your documents, can you see improvements in ratings after the pages are redesigned?
Customer contact rate vs. knowledge base visits — The customer contact rate is the percentage of active customers who contact your support team in a given month. If you see an increase in knowledge base traffic that correlates with a decrease in customer contact rate, that’s a great sign that your documentation is helping.
Design is never really complete, because there are always more improvements to make. Even when you finish your redesign project, keep the plan around to review and revise for your next round of changes.
