How to write for a non-technical audience

But sometimes a writer from that technical world must communicate technical information to an outsider. The outcome can be rather like a French native explaining their language’s grammar to a non-speaker … in French.

There are many cases where a non-technical audience needs to be able to make sense of technical information. And from the label on a bottle of blood-thinning medication to a car’s user manual, a board making decisions about cybersecurity to a populace understanding dangers posed to public health – that need can be critical.

If vital information gets lost inside unknown jargon, unexplained acronyms and needless detail, it’s rare that this comes from a deliberate intention to confuse. As we’ll see, what’s often going on is not just a matter of vocabulary, but different ways of thinking.

The curse of knowledge (or why technical writing goes wrong)

‘The curse of knowledge’ is a term first used by economists in the 1980s. It describes how difficult it generally is for highly technical people to reconstruct how they were thinking before they became so knowledgeable. It’s now used more broadly to describe a failure to empathise with an audience that doesn’t have your technical command.

Either way, it explains one chief reason why technical writing for a non-technical audience can fail to do its job. And if you’re a technically minded technical writer, finding a way to recall that ‘before brain’ will go a long way in helping you communicate effectively.

To get technical writing right for a non-technical audience, it’s critical you recognise that much of what’s in your mind almost certainly isn’t in your readers’ minds. They don’t have your level of understanding or your grasp of the terminology. The frame of reference you’ve built up over years is what might be filling in the logic gaps in your writing. But it’s into those gaps that your readers can fall – and possibly be lost forever.

What seems straightforward or obvious to you could just confuse and frustrate your audience, unless you join the dots for them. At other times, you might be tempted to overwhelm them with detail they don’t need for their purposes.

Getting it wrong: the curse in a crisis

The sharing of information and guidance during the Covid-19 pandemic illustrates both ends of the getting-it-wrong-to-getting-it-right spectrum. It’s put technical writing in the spotlight as never before.

‘We’re following the data’ soon became the mantra of governments worldwide as a line-up of scientists, statisticians, virologists and epidemiologists emerged from their offices and laboratories to interpret the data for an anxious audience of (mostly) laypeople. The challenge of a lifetime, no doubt. And one tackled with varying degrees of success.

The UK Government faced criticism for press conferences that undermined their efforts to persuade the country they were taking the right action. Presentations appeared on televisions nationwide containing slides that were too complex, too numerous, and that overused specialist jargon and abbreviations. Not only did they offer little clarity to the millions of people already desperately trying to make sense of the drastic changes in their lives, they risked eroding trust in the UK’s leaders.

Two slides from the UK Government’s press conference on 31 October 2020

Countering the curse (or getting it right)

But others got the balance right. In November 2020, Sir Simon Stevens – chief executive of the National Health Service in the UK – took part in another televised Government press conference. He needed to explain why a second lockdown was necessary to prevent hospitals being overwhelmed by Covid admissions.

The presentation was concise and precise, authoritative but conversational – all hallmarks of good technical writing for a non-technical audience. And perhaps most tellingly, he didn’t resort to a barrage of complex PowerPoint in an attempt to reinforce his clear message. He used just one simple and powerful slide highlighting the steep upward curve of hospitalisations – a single slide that told us all we needed to know.

Sir Simon introduced the slide by saying he’d watched previous press briefings and found the amount and complexity of data ‘a bit hard to keep up with’. If someone in his position was having difficulty, it’s safe to assume the general population was floundering too.

It’s all about the audience …

Effective communication – whether written or spoken – begins and ends with the audience.

Technical writing is produced by scientists and statisticians, engineers and software developers, all the way through to mathematicians designing the algorithms that underpin risk calculations.

If that includes you and you’re addressing your peers, it’s fine to use the jargon and buzzwords you share. But when your audience is non-technical or outside your particular field, you must speak their language, not yours.

And to put them at ease and maintain their engagement, keep the tone conversational – it’s not a lecture or a submission to an academic journal. Your guiding principle should be to direct their attention to real things in the world they can see for themselves.

… And the objective

Alongside thinking about the who you’re writing for, think about the why. What’s your objective? Focus on where you want to take the audience and how you want to change or direct their thinking or actions.

Considering your audience means asking yourself if the style of writing is appropriate and the terminology will make sense to them. But clarifying your objective for that audience means going further. Ask which parts of the information are genuinely vital to meet that objective – whether that’s setting the clock on their microwave or agreeing to fund your research.

The balance of information is key: they need just enough. That’s enough detail to be effective, but nothing superfluous that could confuse them or bury your message.

For example, that person setting the clock on their microwave only needs to know what buttons to press and in what order, and nothing at all about the hardware specs below the display.

Similarly, if you’re making a presentation to the board about a new piece of software, they’re probably more interested in what it does and why they should back it, rather than how it does what it does. Find out who the board members are and their likely perspective – are they from marketing, sales, finance? See the presentation through their eyes. Ask the ‘So what?’ question from their point of view, not yours. What will persuade them? And if there is an important technical issue you think merits deeper discussion, perhaps you can deal with it in a Q&A afterwards.

What’s the story?

We don’t build credibility and understanding with complexity.
We all learn from the ground up. But when you’re teaching or explaining, it’s best done from the top down. What’s your headline? A next-generation search engine, a battery-powered ocean liner? No more lockdowns? Introduce your main theme and then tell the story behind it.

Stories engage audiences and plant ideas far more effectively than abstract concepts, especially if those stories are rooted in everyday experience. And you must hook the audience right from the get-go.

Questions engage. What do Apple, Amazon, Microsoft, Google and Disney have in common, apart from being zillion-dollar corporations? They all started in suburban garages. You’re setting up a journey-from-humble-beginnings theme to introduce a story – perhaps one about technical advances being based on strong ideas and the perseverance necessary to make them real.

Or start with a problem for which you have a solution. There are about seven billion people on the planet, but five billion don’t have access to safe surgical services. This was the launchpad for Touch Surgery, a London startup that provides online simulation programs for medical-education institutions worldwide.

Naturally, you won’t employ stories if you’re writing a user manual or a package insert for paracetamol. But for technical presentations, pitches, websites and even reports, look for the story.

Keep it real

Powerful stories form concrete images in the audience’s mind – ones they can easily picture and relate to. Always look for ways to make your technical information and data more concrete, visual or tangible: you’ll have a much greater impact on your audience’s hearts and minds.

Sir Simon Stevens tracked the rise in UK coronavirus in-patients from under 500 at the beginning of September 2020 to 11,000 at the beginning of November. But how can we visualise the statistic, make it more striking? He used a simple equation: 11,000 people is the equivalent of 22 hospitals full of Covid patients.

By the same token, we are less desensitised to vast numbers if we tell the personal stories of the individuals behind the statistics – the real-life anecdotes we can all connect with.

Analogies are a particularly powerful tool for communicating complex ideas. Physicists and engineers, for instance, will quite happily talk about torque being the rotational equivalent of linear force – in a car, it’s the power an engine has on tap to turn the axle. Cue lots of blank faces in the non-technical audience! But we apply torque in our lives every day when we twist the top off a jar or turn the roundabout in a children’s playground. Again, direct the audience’s attention to real-life equivalents they will instantly recognise.

Mind your language

We’ve mentioned that the language you use needs to suit the audience and purpose. This means you have to adjust based on the document or communication in question – and not just the jargon but the words in between. Try to keep the words between your specialist terms as simple as possible. Use mostly short, everyday words and short sentences.

And while you will need to adapt to your audience each time, this guidance is a great starting point.

Avoid abstractions

Concrete writing helps your audience keep up.

We can’t visualise abstractions and readers will particularly struggle when those concepts are far outside their own experience.

So be careful with theories, biases, concepts, frameworks, tendencies, issues, assumptions, ideas – they all describe … well, ideas. You’ll lose some of your audience immediately and leave others saying, ‘Well, it depends what you mean by “tendencies”.’ Use concrete terms wherever possible or find parallels in tangible, everyday experience.

Be aware of voice

It’s also important to be aware of the voice you use in writing because it affects tone. By ‘voice’ here we’re talking about two different ways of wording the same information: the active and the passive.

If you’re telling a story or painting a vivid picture, use the active voice – for example, ‘Larry Page and Sergey Brin founded Google’ (7 words). The alternative is the passive voice, which turns the construction around: ‘Google was founded by Larry Page and Sergey Brin’ (9 words).

The active is more conversational, direct and concise, and it’s generally easier to follow. The passive is often wordier and more formal – overuse it and your writing can become too dense and dull.

Having said that, there’s no absolute right or wrong here – they both have their strengths. But be aware of the choice you’re making and the effect that has each time.

Be direct (especially with instructions)

Language changes all the time, and we all use more direct forms of address today than we used to. A good example is the use of the imperative or command form of the verb in software instructions.

An imperative sentence starts with the verb (or ‘doing word’): ‘Push the button’, ‘Take the tablet’, ‘Remove the cover’.

Developers create sophisticated programs that are now a large part of all our lives, but users don’t need to know about the networks and clever widgets ‘under the skin’ that make things happen. They just need simple commands like Press, Turn, Copy, Delete, Paste, Send. They will happily assume the program will do what they want when they follow these commands.

Clear, direct language is the bridge between technical specialists and a non-technical audience.

The layperson test

A great test of your writing is to put a draft of it in front of someone. Choose a person with a similar level of understanding to your target audience. You understand what you’re talking about, but do they?

And don’t let them get away with a simple yes or no: grill them. Did they stumble over any of the terminology? Do they grasp your main message and can they explain it back to you? If you’re writing instructions, would that person feel confident following them? Can they answer questions the text should have made clear? Is there anything they’re unsure of that needs adding to or rewriting?

If you need to translate your technical know-how for a non-technical audience, you know you have an important job to do. Make sure that your audience gets all the benefit of your expertise by putting it in language they can understand.

If you’re looking to strengthen your team’s technical writing skills, have a look at our bespoke in-company technical-writing training. We also run scheduled open courses in technical writing for individuals to join.

Image credit: Gorodenkoff / Shutterstock