Assumptions are bad for technical writing. Just because you know something doesn’t mean that the reader does.

If we write content based on the assumption that our reader knows something and our reader doesn’t, then our content could be completely incomprehensible to them.

The big danger of assumptions is that if the reader doesn’t know or doesn’t fully understand what you’re talking about, then the information you’re trying to pass on won’t be passed on.

MAKING ASSUMPTIONS

Here’s a great example. If you show a photograph of a floppy disk to young people, many of them will think you’re showing them a photo of a 3D-printed ‘Save’ icon. They’re too young to have encountered floppies.

It’s a funny story, and true. But I’m also making assumptions when I tell you it. I’m assuming that you’re old enough to know what floppy disks were. I’m assuming that you called them floppies like I did. I’m assuming your idea of a floppy is the same as mine, the plastic 3.5” floppy disk and not its 5.25” or 8” predecessors. I’m assuming that you know what 3D printing is, and what the ‘Save’ icon looks like in Microsoft Windows and so on.

That’s a lot of assumptions to hang a fun little story on.

I’ve deliberately taken my assumptions explanation too far, but I’m making a serious point. If you assume that your reader knows X, Y and Z, you may well be wrong – and if your writing is based on that assumption, then it may be of no value to the reader.

Writers tend to make incorrect assumptions about their readers’ knowledge in one of two ways. One, they assume the reader knows more than they actually do, which can cause confusion or possibly even danger if you’re assuming knowledge of safety-related issues they don’t have. Or two, they underestimate their readers’ knowledge and end up patronising them, which rarely makes the reader think good things about the author or the author’s document.

Getting the balance right can be tricky. It’s partly knowing your audience, which was described in Chapter 3, and it’s partly testing and editing, which is when incorrect assumptions tend to become apparent.

You might find it helpful to include a section on assumptions at the beginning of your content, especially for longer, more complex materials such as training manuals: that section would explain to the reader who the document has been designed for and what assumptions have been made, such as familiarity with a particular software application or business sector.

ASSUMPTIONS AND ACCESSIBILITY

Here’s a crucially important assumption that you shouldn’t make. It’s the assumption that everybody who’s accessing your content has the same physical abilities that you do. That isn’t always the case.

Many people use assistive technologies such as screen readers to access content. Others can’t use mice or touchscreens and rely on keyboard controls. This is particularly important if you’re creating digital media, as it may require you to think about how you present links or use images.

The Web Accessibility Initiative has an excellent guide to accessibility – including guidelines that the UK Government has made mandatory for its own sites – at www.w3.org/WAI/users/.

Accessibility of a different kind is relevant here too. Technical writing that’s published online isn’t necessarily going to be viewed on a desktop or laptop PC. It might be on a tablet, or a smartphone or even a smartwatch. If so, that requires a serious rethink of how you present your information: usability guru Jakob Neilsen recommends half the word count you’d have in print and a limit of one idea per paragraph.¹⁴

The UK Government has produced extensive guidance on accessibility for digital services, and that guidance also includes links to resources for testing content. You’ll find the most up-to-date version at www.gov.uk/service-manual/technology/testing-for-accessibility.

With technical writing it’s a very good idea to consider not just the medium you’re writing for today, but the other mediums your writing might be published in, in the future. That doesn’t mean writing for every conceivable platform from print to pixels. But if you’ve structured your project or document in such a way that it can be repackaged quickly and easily then you might be saving yourself a lot of work in the not too distant future.

JUNK THE JARGON, BANISH BUZZWORDS AND ABOLISH ACRONYMS

Jargon and acronyms can be valuable. IT needs to talk about the IoT, SaaS, SLAs or XML. Surgeons need to communicate with their team in perfect clarity without scaring the patient. Financial services businesses need jargon to differentiate between very complex products.

Used correctly, jargon and acronyms can be very useful. They streamline communications – an A&E doctor can ask for the patient’s BP and the nurse or paramedic hears ‘blood pressure’ and provides the systolic and diastolic blood pressure readings the doctor needs to know. ‘BP’ saves everybody a lot of time.

The problems occur when the other person doesn’t know what you mean. If you’re using terms or acronyms the reader doesn’t understand, you might as well make up your own words and tell them to fimble the jingjang until the squeeble meebles for all the good it’ll do.

The armed forces have a particularly large collection of fimbles, jingjangs, squeebles and meebles: the Ministry of Defence’s list of acronyms used in the armed forces for job titles, specific places and tools is nearly 400 pages long. Those acronyms are no doubt valuable in the theatre of war or in effective military communications. However, they’re meaningless to those of us who never need to refer to 2SL/CNH (the Second Sea Lord Commander in Chief Naval Home Command).

In technical writing, don’t use jargon or acronyms unless you’re absolutely certain that your audience will immediately understand them. Even then, consider whether you need to use them at all. If they are the most effective way to communicate your message, that’s great – but always explain them in full the first time you use them; don’t just say ‘TLA’ without explaining that it’s short for three-letter acronym.

If jargon or acronyms are making your text harder to follow, write in plain English instead.

That brings us to business buzzwords, which are often the very opposite of plain English. Buzzwords are in the air when a tech chief executive officer (CEO) – or more likely, a ‘Thought Leader’ – talks about surfacing content when they mean showing people stuff; when somebody says they’ll ping you when they mean they’ll send you an email or call you; when somebody doesn’t have the bandwidth to say they’re too busy. All too often business buzzwords replace perfectly good words with lesser, more vague, more pretentious alternatives.

KEY TAKEAWAYS

¹⁴ Jakob Nielsen (1 October 1997) How users read on the web. Nielsen Norman Group. Available from: www.nngroup.com/articles/how-users-read-on-the-web/