Which Type Of Narrative Is Commonly Used In Technical Writing?

Here is the gist of a conversation I had with a scientist a few years ago. I was teaching a one-day technical-writing course that she was (reluctantly) attending.
'What do you write?'
'Mainly records of experiments and field trials.'
'And do you enjoy writing?'
'No, I absolutely loathe it.'
'Why?'
'Because it's just going to sit in a dusty folder somewhere and no one will ever read it.'

My first thought was that it was going to be a long, hard day. Happily, I was wrong.

In this short post, I won't go through the protocols and conventions unique to technical writing, as that's not necessary to get results (although you may find this article on how to write a paper useful). No, the key is to approach it from first principles – the disciplines every writer, technical or otherwise, should be aware of and practise.

1. Be clear and logical

I usually enjoy training scientists. They have one essential quality that's gold dust for a writer – they're trained to think logically and clearly. While their PhD may be in low-temperature physics or fluvial dynamics, they bring a rigorous way of thinking that's incredibly helpful when it comes to writing up their work. Refreshingly, they're also often among the most enthusiastic and intelligent students.

When I'm training, the one thing I want people to take away is the power and importance of writing. It obviously helps if you have a love and respect for language as well, but that's a personal thing. If I could instil in the scientist a sense of pride in her writing, at least, I thought, that would be a start.

2. Focus on the audience

For some 15 years, I was the lead writer for Jaguar. I wrote the launches of their cars and all the company's major conferences and speeches, some of which were highly technical. But the first question any writer has to ask, regardless of the material, is always the same – who is going to read this? Or, if it's a speech, who is going to listen to it?

An automotive engineer, for example, will have a clear understanding of terms such as 'horsepower' and 'torque' and how they influence a car's performance. They will also be familiar with the host of abbreviations and acronyms that are common parlance in the engineering community. (Is there a sector that doesn't have its own jargon or buzzwords?)

If a piece of writing is peer to peer, it's generally fine to use these terms without explanation (but sparingly, please). An engine's performance may simply be expressed in measurements, graphs and charts – if the information is simply and clearly presented, the knowledgeable reader will be able to extract what they want and interpret it. The writing will have served its primary function, which is to communicate.

3. Consider every word

Most drivers, however, would struggle to explain 'horsepower' and 'torque', let alone the difference between them. Unless they're fully paid-up petrolheads, all they may know is that a powerful car will have a lot of both. Car manufacturers know this, of course, and that's when (supposedly sexy) language starts creeping into the writing. 'Effortless' and 'refined power', for example, are words Jaguar often use to describe torque delivery for the layman. (I fought long and hard to suppress the truly awful 'waftability', but it seems to have crept into the marketing.)

The point is that you use the appropriate language for the audience. The engineer writing the technical report isn't selling the car, so they don't need to use adjectives and adverbs (modifying words) to communicate performance – they can let the stats do the talking. In fact, if they submit their findings to scientific journals, they'll find that most editors delete modifiers anyway, because at best they're subjective, and at worst vague and confusing, especially for an international audience. Editors encourage authors to 'unpackage' concepts – to present them in simple, clear sentences.

4. Keep it brief

Most people have a lot of things they could be doing rather than wading through 50 pages of turgid, unfocused waffle. Know your reader, know what you want to say and know why you're saying it. Is it relevant to your reader? If not, why are you making them read it? And although you may have spent ages writing something, be aware of 'Mr Skippy' – the person who will just skim through the text. He may only read the sub-heads, so make sure they tell the story clearly.

5. Be active and engaging

Get people into your writing. The passive voice ('the trials were conducted …') may be the default in most technical writing, but the active voice is more direct ('we conducted the trials …'). You don't have to do it all the time: a balance between passive and active is best. But we're people and we like to read about ourselves, even if it's just a humble pronoun ('we'). Incidentally, a surprising number of journals recommend the active voice in their instructions for authors, including Nature.

And the reluctant scientist on my course? I saw her for a follow-up class a couple of months later and her writing had improved immeasurably, largely because she was now thinking clearly and writing short, clear sentences. Most importantly, she was taking pride in her writing and even starting to think of publishing her work. It had been a day well spent.

Jack can help you improve your team's technical writing. Call us on+44 (0)1273 732 888 for a chat to explore how.