There are a lot of how-to guides that help companies set up a knowledge base for both internal and external use. Before you choose an information and/ knowledge management however, it’s good to see what information needs to be put in what container. Here are 4 containers that are especially valid in help-(desk) environments.
Terminological based information management
In short: what does this word mean?
Like: what is an API?
Terminological information in companies is often referred to as ‘the glossary’. The list of words or abbreviations that are required of customers, users or employees to perform certain tasks.
This often seems the low hanging fruit. After all, everyone in and outside of the organisation knows what a flowering plant is right? It’s either a blossoming weed or a garden plant, as yourdictionary explains in this article about semantics. Imagine writing in your various help documents: “Please make sure no flowering plants are near the designated area of maintenance”. Would that mean that I need to first remove all the weeds, or, make sure there are no garden plants in the area. In the case of say, using an insecticide. You think that’s a cute example? Imagine something like this being in the help texts of multibillion agriculture chemical producer like BASF. Note: I’m very sure that this is example doesn’t apply to them ☺
Another example: the company doesn’t even know what they mean exactly. A few years back I worked at a company where the terms Daughter-company and Parent-company needed be explained. The problem? Nobody knew what it was exactly. In a more general manner these terms were an indication about the relationship to another, related company: either you were the smaller, supported party or, you were the bigger overarching company. Not that hard right? Except the definition determined if you had to pay a yearly fee or not. With legal implications if you didn’t.
Hence, terminology is important. Keep in mind the infamous 20/80% rule: 20% of the terminology will create 80% of the work, as those are the terms that people will have strikingly different ideas about.
Functionality based information management
In short: what does this button do?
Like: what happens if I press this button?
And: how is it different from this one?
If you hadn’t guessed it already, the first is a download button. The second is a ‘go’-button after having entered a search term. It could also have been a ‘go’-button after having entered contact details which someone would like to have processed. In a “contact-me-for-a-product-demo”. So yes, also important.
I’ve heard (mainly non IT, UI/UX, sorry) people say: “the new system will be self-explanatory”. Please don’t. Yes, a very good case can be made for good interface design, how it supports efficiency and understanding, but nothing will ever be fully self-explanatory. Which is OK. Just provide good support.
Especially with functionality questions, context is important. What was someone’s previous action, what part of the system of site are they active in and what are they trying to achieve as a next step? For the user, these shouldn’t be questions. They be made clear through consistent and clear terminology (point in case above), clear navigational hints and an overview of the process someone is in (see below).
Does a functionality really need explaining? Then be inclusive. Say someone doesn’t understand the download button, make sure you know what they don’t know about it. Picture a hover-over that says “This is a download button”, well, that might have been obvious. Make clear that the user knows what she’s downloading. A file? What file? E.g. “Download the employee survey 2016” is much better. That’s why download links are so popular these: they allow you to include text.
Process based information management
In short: where is the user in the overall process?
Like: what happens next?
Best example ever that we all know: “Thank you for contacting us”. Now what do I do? Another one: “We are processing you request”. Great, how long’s that going to take?
A good exercise is to bullet point the process for (the type of) user and make sure that it’s clear what the connecting steps are per phase. The end step of the last phase or action (depending on the size of the process) is important to the next phase. How often do you book a flight with someone and you go “Is that for both of us? The price seems a bit low”. Not at Transavia. They make it extremely clear what you’ve selected and what the current total amount of money is for what amount of travelers.
If you do need help in the form of larger display of text, preferably do it at the beginning or end of a process. For example:
“Thank you for registering! We’re going to ask you about your exact annual revenue of the previous year and the exact amount of employees, because those determine your fee. Don’t have that information at hand? Click the Reminder Button below to receive an e-mail tomorrow at 10 o’clock to remind you to continue your registration process”.
Or at the end of the process:
“Thank you for your contact details. We will let you know within 5 working days whether or not your application has been accepted. If your application has been accepted, you can immediately continue your enrollment. If you application has been denied we’ll provide feedback on the reasons.”
Task based information management
In short: How do I add a user?
Then there’s another type of information request: tasks. Those often need a little more explanation and are harder to leave out, solve with 1-3 words or solve with an icon or navigational element.
Sometimes users have a vague idea of where to look. For ‘payment options’ they probably need to check the tab ‘Financial Information’, and to add a user ‘User Management’ or ‘Team’ seem to make sense. However, I have seen examples where an overview of the payment procedure was not provided in the “Finance” tab, but in the general “Profile” area under “Bank Account Number – ABCD0001212121”, where they had to click the number to find out about the procedures, payment options etc.
Tasks might need more space to be explained, but they are easier to define and prioritize. A good analysis of the questions answered (by your help desk?) on a daily basis give you a very good overview of the top 10-20 questions asked for which a short how-to guide or FAQ can be composed. A canned e-mail response might also do the trick.
Whatever your format of choice is to deal with questions, make sure a clear distinction is made in the type of information, who and where it should be resolved. Create an overview, control over your help information and consistent and clear answers for your users by analysing and categorizing the questions you get and the answers you give. Not everything is task, not answers can be given via Twitter and not all process overviews consume the user’s time.