Updated June 2019. Originally published February 2018.
Knowledge (/ˈnɒlɪdʒ/) –
Facts, information, and skills acquired through experience or education.
That’s the OED’s definition of knowledge. The example sentence they use is: ‘a thirst for knowledge’. In IT, ‘knowledge’ is used to refer to anything stored on a computer. And it appears my computer has an unquenchable thirst. Documents, policies, emails – we office workers feed our computers this stuff at an incredible pace.
Does anyone actually know what’s buried deep down in your Google Drive?
At Twine, we’re trying to change people handle their information – so nothing gets lost, and no one wastes their time. That’s why we put together this guide – a complete 4-part guide to organising all your important company knowledge into an accessible knowledge base.
Part 1 - What is a knowledge base?
Learn what a knowledge base is and why you need one
Part 2 - Planning your knowledge base
Where to star
Part 3 - Writing great content
Make content that’ll keep people coming back again and again
Part 4 - Keeping content up to date
Keep your knowledge base relevant
An internal knowledge base is a library used to store company information such as policies, handbooks and brand guidelines. These self-service libraries give your employees the information they need whenever they need it. They’re also sometimes known as wikis – you can think of them as a Wikipedia just for your company.
Knowledge content can range from short articles to multi-page documents to rich media galleries. Here’s a few examples from our company knowledge base:
A knowledge base can take many forms. An internal knowledge base (the one we’re interested in) is aimed at your own staff or team. An external library is aimed at customers. You’ve probably used the latter as most online products and services have one (here’s ours).
For all intents and purposes, they’re identical: both are made of content designed to help their end users do something. The difference is, your end user is an employee of yours.
Twine’s knowledge base is built around categories. You can have as many sub-categories as you like – you can even go as deep as you like with subcategories of subcategories of subcategories of... – you get the idea.
You can limit access to these categories to certain groups, departments or locations. This is called segmentation. With proper segmentation, a single knowledge base can be tailored for a variety of use cases such as:
Starting a new job can be bewildering – all those new policies and processes feel impossible to remember. That’s where a knowledge base comes in.
We have a category called New starter guide that sits right at the top of our knowledge base. It’s one-stop for everything a new hire needs, such as:
Beforehand, our onboarding was done with a mixture of verbal instructions, emails and PDFs. Now, we have everything a new starter needs written up into simple, short articles that they can read whenever they like.
When we first set this up, we used Twine’s Mandatory Read tool to notify and remind new starters of all these articles. However, we found having 20 mandatory reads overwhelmed them. Now, we just have one article that’s marked as mandatory: Welcome to the team. It’s a short introductory article that welcomes them and links to useful pages in the onboarding centre.
A knowledge base is like a library – it’s a place where information is stored to be referenced later.
For example, a big part of our knowledge library is for our developers. They document everything they do. That’s because they’ve got an impossible number of tools and protocols that need to be remembered. Having everything documented makes the lives of future developer that much easier. Whenever they need it, there’s a piece of content to guide them.
At Twine, we’re a remote company spread across the world – which makes training junior teammates trickier than your average office-based company. That’s why we treat a part of our knowledge base as a lightweight LMS (Learning Management System). Whenever a team leader finds an interesting resource online, they’ll add to their team’s very own L&D category. Depending on the size of the team, this can vary from a simple link to an article (like in the screen below) to a comprehensive resource list.
Building a knowledge library requires a lot of groundwork. Most companies are brimming with information and policy documents that are out of date, impossible to find or just plain inaccurate. It takes careful planning to translate this into a knowledge management strategy. So, before all else, we need to take stock of what you have.
We’ll start by performing a full content audit: sifting through your content, working out what you have, what you’re missing and beginning to think about how it should be structured.
It’s no good blindly copying documents and text over from your old system – inevitably, irrelevant content will find its way onto the new system and the same problems will remain.
Moving to a new platform is an opportunity to review your content and clean it up. Over the years, content will have become out of date, inaccurate or irrelevant. If this persists on the new Knowledge Library, it will lose credibility as a reliable source of information. Now is the perfect time to rectify this.
Here’s a checklist to get you started:
It’s not exciting, it is time intensive, and it takes careful planning to get right – but it’s essential to do it. Luckily there are plenty of resources out there to help you; here are our favourites:
After you’ve revised what you have, you want to consider how you are going to organise your clean, freshly gleaned content. This involves planning and executing a coherent structure – we call this the information architecture. Your users need to be able to find the content that they need to do their job, and it needs to be as intuitive as the interface around it.
This also includes thinking about keywords, tags and titles to ensure that your content performs well in search. You can map all this in a simple spreadsheet but the humble post-it note also works pretty well.
These articles are a good starting point:
Now you’ve got the skeleton in place, it’s time to put some meat on it. This means acting on what you’ve learnt in the content audit to produce new content where information is missing, updating old content to be accurate and making sure that all articles have a consistent style and layout.
We want to do your content justice. But we often speak to users who ask the same thing: can't we just attach all of our PDFs and call it day?
Our answer is simple: you could do that, but it’s hard to read those documents on mobile. To read a PDF or Google Doc on mobile requires a lot of pinching and scrolling. We don’t want that – we want our users to find information quickly.
There's two options you've got, one bad and one good:
Obviously, we always recommend the second option.
Of course, documents can be useful for things like printable forms. However, if the content in the PDF can be consumed just as easily on a web page, get it out of there.
This can work really well with things like instructional guides. It can be as simple as recording your screen, talking into your laptop mic and guiding people through how to use a piece of software or process. It can be a much more personal way to teach, rather than having people read an instruction manual – it’s an underused medium in internal comms.
Twine comes with a welcome content tool. This means whenever a user logs in for the first time, they’ll be greeted by your welcome video.
Get your guidelines right (style, tone and voice) – it gets all your writers on the same page, writing in a consistent style. If you don’t have the time or resource to make your own style guide, check out GOV.UK’s style guide and you’ll be sure to produce concise and coherent articles. If you want to go the extra mile, I’d recommend reading Monzo’s Tone of Voice guide – I guarantee it’ll make your content 10x more engaging.
A year in the life of the GOV.UK content team – an inside look at a real-life content team, from the Gov.uk blog.
“Content Strategy for the Web” – the book on all things content strategy.
When one company who had around 200 policies and forms that needed moving asked:
"Is it just a case of copying and pasting from a word/pdf into a text box to create a HTML page? In your experience, how long would you envisage this could take – approximately?"
We answered:
Time spent here depends on the approach that you take. If you are happy simply using the same content that is in the PDFs, this can be a fairly quick process (1 month). We're talking copy and pasting text, and uploading images. This work can be fairly laborious, so many companies opt with hiring an intern to do the grunt work here.
However, if you have the resources, we would recommend reviewing your existing content and reworking it so it is optimised for the web. This will involve adding links where appropriate, making the keywords and making sure that all articles are written using 'Plain English' and follow a good style guide. You'll also want to consider a content audit (seeing what you have) and an information architecture review (planning the structure of categories).
This obviously requires more time from your comms team, but in my opinion worth doing properly. I'd recommend you appoint an editor for the project to make sure that standards are consistent and the quality is high. For 200 policies, including content audit – I would estimate around 2 months to get this right. Time well spent for the accessibility benefits, in my opinion. The government team have done a good job at explaining the benefits of HTML documents in one of their blog posts.
Now you’ve got your content in order, it’s time to devise a plan about how you’re going to keep it that way.
The number one complaint from companies that come to us is that their intranet is impossible to navigate. This is not because of the interface design, but because the content on it is out of date, irrelevant or duplicated.
You need to get three things right:
Too often, rollout is seen as the end of the project: you scope it, you build it, you roll it out.
When technology and user habits are changing so fast, that’s just not an efficient approach. By the time you’ve launched your design, the things that you’ve designed for will have already started shifting. A year after rollout, things will start to become dated. A bit like that game ‘What’s the time Mr Wolf?’, if you turn your back on development, you’ll find everything will have moved.
That’s why continuous, iterative development is essential. Rollout isn’t the time to cease development; it’s the time to begin.
Encourage feedback and act on it. Make users groups, grab people in corridors, do whatever it takes. Regularly check in with users, observe them using the system and interview them to ensure that your design works in the field.
Validate your decisions
If you’re familiar with lean or agile methodologies, this will be a familiar concept. When designing platforms like intranets, we are forced to make best guesses and assumptions. That’s fine, but we should seek to validate these assumptions as soon as possible. This relies on those feedback loops that are frequent and continuous.
And once you’ve found something that could be better, don’t be afraid to make changes.
An incremental, user-led approach means that your knowledge base will stay fit for purpose for longer.
The work is never finished 👊
How can Twine help with onboarding?
We sat down with our newest member in the Twine team...
Are your internal comms engaging?
Create a free, pre-populated demo account and look around in your own time.
Create accountRequest a demo