I recently had a conversation with someone that went something like this:
Him: "So what do you do then?"
Me: "I'm a Knowledge Management Consultant. I'm currently helping a client implement SharePoint."
Him: "Oh, that's interesting. We've just started using SharePoint and we're struggling with getting the right branding and styling on our publishing site. Any tips you can give me on working with their CSS?"
Me: "Not really, I tend to work on the content management and collaboration parts, rather than the publishing side of it. But the Microsoft help material is very good and I can point you...."
Him [interrupting]: "What do you mean, you don't do publishing sites? I thought you said you were a consultant?"
Me: "I am, but SharePoint is..."
Him: "So you don't know what you're talking about then?"
The conversation went downhill from there, as my interlocutor almost, but not quite, accused me of lying about what I did and got increasingly irate and frustrated. In the end we parted company with him still muttering and me shaking my head ruefully.
Now you might instinctively think bad thoughts about my ill-tempered friend, but that would be a knee-jerk reaction. He was clearly struggling with a complicated and powerful piece of software, and meeting someone who might be able to bring some light to the shadows must have gotten his hopes up, hopes which I promptly dashed. It's only natural that he was frustrated, even if he didn't necessarily express that in the most constructive way. What's more instructive about this encounter is that it represented a microcosm of the way an entire enterprise often feels about implementing SharePoint.
If you've encountered SharePoint before then the likelihood is that your experience hasn't been overwhelmingly good. I've met more far more people with negative things to say about SharePoint than I have people with positive things. It's like the England football team - depressing, confusing, poorly performing, promising lots and delivering little. But like the England football team, SharePoint's individual components are good, yet the sum seems to be less than the whole of its parts. To continue this analogy one stage further, the management just doesn't seem able to turn a collection of good things into a better coherent whole.
The question is: Why not?
Let's start an answer to that with the obvious point that SharePoint is large and complicated. If you have SharePoint then you're going have Microsoft Office, which increases both the size and the complexity by a significant factor. Office itself can be pretty difficult to get to grips with as a whole, when you've got both client and online versions, as well as lots of tools that weren't in the traditional Office package of a few years ago, like Sway, Planner and Video. Then there's OneDrive, which is actually just a personal SharePoint site with a front-end, and Power Apps, Flow and Delve. The sheer number of these apps is dizzying, and they all work together if you want them to, and each one is a whole book and training session on their own just to get comfortable with the basics. Even programs as venerable and well-know as Word, PowerPoint, Excel and Outlook have lots of functionality that most users never know about or haven't got to grips with. Then you add a powerful electronic document and records management system like SharePoint on top of all that and dear Lord, where on Earth do you even begin?
This alone is enough to put a lot of people off, and not just users. Designing, implementing, training and supporting that kind of enterprise-level suite of applications, with its mind-boggling array of options, parameters and functionality, is not a job for the faint-hearted or workshy. For users it can be even more daunting because they're not supposed to be the experts and usually have very little time to dedicate to learning these tools.
The biggest part of this problem is that often the people deciding to use SharePoint underestimate the investment of time and resources needed to design, implement and support it, and they seriously underestimate the investment of time and resources needed to train users. Many a C-level decision-maker has seen a demonstration, or worked in another company with a successful SharePoint implementation, or seen that it's a highly-recommended tool by a relevant professional body. These are all valid reasons (although not sufficient on their own) for choosing SharePoint, but they're not valid reasons for thinking that SharePoint is easy, simple or quick to implement and maintain. If you've seen SharePoint working well then you can't even begin to imagine how much work has gone into making that happen.
It's worth saying as well that when users struggle with SharePoint it's not always because it hasn't been implemented well. SharePoint is so large that you can't even hire a consultant direct from Microsoft that knows all of it to a significant degree. It's also not the most intuitive experience, which makes learning it harder. Training users is always easier when an application has obvious signposts and markers for the users, because once they've got a rough idea of how things work they can generally find their way around and work out how to do things using these signposts and markers. But there are plenty of areas in SharePoint where these signposts and markers are missing, often because a certain feature or parameter is "owned" by one application within SharePoint/O365, so you can only get to it from that application. This means a lot more rote learning is required to know how to do things. On an application as large and complicated as SharePoint this means that the learning curve is high, which acts as a significant barrier to adoption across a business.
When you take these problems together - the size, the complexity, the difficulty learning it - it becomes easier to understand why my frustrated friend felt like he was banging his head against a brick wall. He's most likely up against a deadline, he's faced with a suite of applications that is so large it's very difficult to know where to start, and when he does start the amount of learning to be done must feel insurmountable.
All of which leads to the reason that many companies struggle to have a successful implementation of SharePoint: It's not a one-off implementation, it's an ongoing process of training, learning and incremental advances for the entire life of the application.
Every user needs to be trained, and not just with a 60 minute introductory session. Every new starter has to be trained. Existing staff have to have access to refresher training. Training material needs to be updated as new functionality is released. Content and working practises have to be analysed so they can be successfully migrated. Deletion, retention and preservation policies must be decided and implemented from the very start. Metadata must be applied to migrated content and added to all new content. Workflows must be designed, created and added. Security must be applied. And throughout all this you have to deal with the change management aspects by engaging the users, communicating the plans and timelines, quelling fears, and listening to concerns. If you can do all this, and still meet your success criteria then you'll have a successful implementation.
SharePoint is not an application, it's a long-term commitment of people and time.
(Note: A cardinal rule on this blog is that I never discuss current or previous clients. Nothing from this post should be inferred about any company I've worked for; as always this is a general discussion about issues that we find in our industry.)
Knowledge Base (KB) articles are normally technical and as such in the realm of the technical writer. Where an FAQ might encourage you to try a new product or feature, a KB article helps a user get past a problem when they're already using that product or feature. So if FAQs represent "sales self service", KB articles represent "support self service".
With this in mind, you should focus your initial efforts on writing KB articles that will answer the most asked support questions. This will provide the greatest return on investment for your documentation. Once you've built up a library of articles, you should try to move to a position where new KB articles are written in response to incoming customer questions. Ideally, if a customer asks a question once, and the answer isn't publicly available, you'll publish a KB article answering that question within a short period of time
But how do you write a good KB article? Well, the basics of writing good documentation don't change, but there are a few things which are more important when writing KB articles. Let's got through them below.
1. Know the subject
First and foremost, don't publish an article unless you're certain it's correct. This applies to experienced staff who think they know exactly how the product works just as much as it applies to less experienced staff. As an example, I once wrote a KB article on the possible permutations of accounts and permissions that could be setup for a web application and IIS, but I'd misunderstood the scope of the question. The result was a rewrite that took some time because the people who understood the technical side were difficult to get hold of, and more importantly it confused a couple of customers, which was the worst possible outcome. This leads directly to #2.
2. Proof read for technical correctness
Get 2 different people to proof read it if necessary. There's no shame in asking for the input and oversight of people who are more technically qualified or experienced than you. As a technical writer you are expected to understand technical issues so you can communicate them, but you're not expected to know all of the technicalities of a product better than anyone else. That's why you have architects, designers, administrators, installation experts, etc. Use them.
3. Iterate. Then iterate. Then iterate again.
Preferably find someone who doesn't know how to perform the actions you're explaining and ask them follow the instructions through. If they don't understand it first time, or they ask about an ambiguity, alter the article until it's clear and unambiguous. This is not a negative step, it's a necessary part of writing a good piece of technical documentation. A KB article can deal with complex issues that can be even more complex to explain, so the first draft of a KB is unlikely to be the last. Write, test, alter, repeat.
4. Don't overestimate the reader's knowledge
AKA Know Your Audience. If you're writing for a data entry operator then take the time to explain things that seem obvious to you. Remember, if you weren't knowledgeable enough about the software to write technical documentation about it, you wouldn't be writing KB articles. You know more than your target audience so walk them through things if necessary.
5. Don't underestimate the reader's knowledge
AKA Know Your Audience part II. If you're writing for a System Administrator then try to avoid the whole "teaching your grandmother to suck eggs" thing. It's a tricky balancing act but if the target audience is (supposedly) technically competent or highly knowledgeable then they won't thank you for wasting their time or making them feel stupid.
6. Make it modular
If you find yourself walking through the same process in more than one KB article, then write a separate article that just deals with that process and link to it in future articles. This saves you time and helps the user by not cluttering up articles with information that's duplicated elsewhere.
7. KISS
The old "Keep It Simple, Stupid" acronym. In the case of KB articles, this means that you should try to capture one task or process in one article. Don't try to cram too much in, and don't shy away from writing a series of articles that deal with the distinct stages of a complicated process. At the start of each article in the series tell the reader that they should be familiar with the information in the preceding articles before continuing. This allows them to feel that they are making progress and allows you to write self-contained articles that just deal with the problem in hand.
8. Step-by-step
Don't explain a process in a paragraph. Use a numbered list, and make 1 numbered point = 1 step. As a rule of thumb, if there is more than 1 action in 1 numbered point then turn it into 2 numbered points.
This goes hand-in-hand with points 4 and 5 about knowing your audience. If you're writing for System Administrators who know the product, don't be afraid to write:
"1. Log into the application and navigate to screen x"
Equally, if you're writing for potentially inexperienced users don't be afraid to write:
"1. Log into the application."
"2. Navigate to screen x. In a default setup this will be located at System > Parameters > screen x"
Generally paragraphs should be used to explain something from a conceptual perspective and numbered lists should be used to explain actions and steps.
9. One Step, One Screenshot
If you write an article with 10 steps, use a good screenshot for each one if it will help the user. A picture tells a thousand words when you're trying to understand something new. Users aren't short of the bandwidth needed to download a 20kb png file and I know that the use of screenshots is controversial, but don't preclude them on a point of principle.
10. One Screenshot, One Lawsuit
I can't say this enough: Check your data. I have seen a KB article published by a colleague who'd taken screenshots using a live database, and those screenshots included identifiable information about customers. If you have access to live databases, or, as if sometimes the case in development teams, a customer database provided for the purposes of testing, then check, check and recheck your data. If in doubt, create dummy data, and if you can't then obfuscate any data or consider not using screenshots. Using live or customer data is a one way ticket to a lawsuit for your company and quite possibly the sack for you.
11. Quality, not Quantity
Yes, it looks great if you bang out 20 KB articles in an afternoon, but it doesn't look so great a week later if 19 of them have been the cause of support tickets. You're supposed to be helping support, not making more work for them. You can't rely on a proofreader to weed out every mistake, because it may be that you're the person who's supposed to be an expert on whatever it is you're writing about (this is especially the case if you're not a technical writer and you're adding KB articles). Writing KB articles is not a fast and easy way to look good. It is difficult to write well, and even more difficult to write well at speed. Take your time, think about what you're doing, focus on getting it clear and correct.
12. Spell check is not optional
If you're a technical writer you'll know this, but if you're not then hear this: You can't spell. Seriously. Technical writers do this for a living and we spellcheck everything. Learn to love Word and its spell checking, grammar checking, and little squiggly lines. These is no excuse for a spelling error in a KB article and it will make you look incompetent. It will also make your company look incompetent and reflects badly on everyone. Don't be the person who makes your users wonder how on Earth your company can write decent code if they can't even use a spellchecker.
KB articles are a great way to take the load off support and give customers the power to fix their own problems. Get it right and you'll find the rewards far outweigh the costs.
Style guides cover a multitude of areas and it can sometimes be difficult to separate the purely writing-focused guides from the general UI/UX guides. This is not surprising, considering how much UI/UX, technical writing and comms/marketing are starting to coalesce around the central idea of user focused design. But if you're not working in that environment, or if you are but you still want some purely writing focused resources, it can be a little difficult to sort the wheat from the chaff.
With that in mind, I've put together a list of some useful guides below:
Online
- MailChimp - One of my absolute favourites because they focus on the likely user mood at the point of the interaction, and tailor their writing accordingly. This is a relatively unknown style guide, but it should absolutely be one that you spend time looking through.
- Mozilla - A (relatively) short and to the point style guide that focuses on developer documentation. If you write for developers (SDK, API, etc) then this is an excellent resource.
- Apple - As you would expect from Apple, this is not the longest style guide but it is proscriptive. One of the most useful features is the table that converts "developer speak" to "user speak", so for example "focus ring" for an Apple developer is Highlighted area" or "area ready to accept user input" for an Apple user.
- Google - This focuses on writing for a worldwide audience and as such is concerned with clarity and simplicity above all. If you're writing for a geographically diverse audience, especially one which is not highly technical, then this guide will help you a lot.
- GDS - The Government Digital Service guidelines for the UK Civil Service. Not as easy to navigate as many guides, because topics are provided in an A-Z format rather than curated into groups, but contains a lot of information and is recommended if you're writing in UK-English. (The lack of curation is odd; GDS people are normally very big on user-focused design, and this...isn't. But if you can get past that, the information contained is often difficult to find elsewhere.)
- 18f.gov - The American equivalent of the GDS style-guide, this is focused more on US-English and the needs of federal/state public bodies, as you would expect. But it's comprehensive, well-written and very good on grammar and "correct" writing so even if you're not writing in US-English, it's still a very useful resource. And if you ARE writing in US-English, it's indispensable.
- Microsoft - Microsoft provide one of the best known and popular style guides in print (see below) but this resource is far too valuable to miss off the list. The link takes you to a page with just a single dropdown, from which you can download a PDF style and language guide for just about every language you've ever heard of, and many you haven't. French, German and Russian are fairly obvious, but how about Khmer, Igbo and Xhosa (the African language with the clicks)? If you write in any language other than English then this is probably the single most valuable guide on this list.
Print
- The Elements of Style - The classic book on how to write. The focus is not on software documentation (unsurprisingly, as it was first published in 1920), but not having a copy of this is like being a quantum physicist who's never read Einstein's papers on relativity. Some things are just fundamental to your profession.
- The Economist Style Guide - Another without a software focus, and the first edition was published 30+ years ago, but if you want to write clearly and - according to the Economist - with a little flair, this is the book for you. Its best feature is undoubtedly its effort to focus on real-world examples that are universal in application without being generic to the point of mere common sense.
- The Chicago Manual of Style - If you've only heard of 1 style guide, the chances are it's this one. Now on it's 16th edition, it includes specialised sections on writing for digital technologies, including writing with XML. If your office doesn't have this on its bookshelf, it should be because you've got the next guide on our list.
- Microsoft Manual of Style - A slightly more specialised guide than Chicago, but no less useful for it (and probably more so if you're a technical writer). Unless you write software for Apple and only Apple, this guide will show you why so much software documentation has the style and tone that it does.
- The IBM Style Guide - One of the most comprehensive style guides available for the modern technical writer. It is particularly strong on Information Architecture and content design, but don't let that fool you: this is a standout resource for all writers.
- Developing Quality Technical Information - Another IBM publication and not strictly a guide, but so useful that leaving it off the list for that reason would be petty. There is significant overlap with the IBM Style Guide, but this focuses more on training you and less on being a reference work. Unless you're an acknowledged expert in technical documentation, you'll gain a great deal from this book.
There are lots more style guides out there. If you have a favourite that's not in the list then tell me in the comments and I'll add it in.
