Technical writing

Articles and resources to help you turn your expertise into clear and precise technical documents

Featured

Shining binary data superimposed over nighttime cityscape

Presenting data

Dazzling with data: how to create charts that win friends and influence people

Check your figures

Make communicating numbers as simple as 1, 2, 3

Fundamentals

How to make an impact with numbers and statistics

Technical fixes

How to fix the 7 most common glitches in technical writing

All articles

Dazzling with data: how to create charts that win friends and influence people

How to make an impact with numbers and statistics

How to fix the 7 most common glitches in technical writing

These five techniques will transform your technical writing

Scientists in lab coats working on computers in laboratory

How to write for a non-technical audience

Make communicating numbers as simple as 1, 2, 3

Quick questions

For those answers that don't need a full article

This will always depend on the issue. A simple fault report need only be a page, summarising where and when the fault occurred, and how it has been remedied. Some reports, however, might extend to hundreds of pages. A report could, for example, be part of a bid for a project lasting decades that has to meet complex technical specification and legislation. In both cases, documents might be on file long term as a crucial record, so the writing must be clear, concise and precise, referencing who did what and when.

The answer to this question is one that applies to many other questions across all types of business writing. And that is: consider your audience. Who is going to read this report? What level of technical knowledge do they have? What jargon will be meaningful to them and what will leave them lost? Your purpose matters too: what level of technical detail is necessary for the document to do what it needs to do?

Technical writing often has a unique structure, Failure Mode and Effects Analysis (FMEA) being a good example. This rigorous approach aims to highlight potential failures in the design of a product or process before it goes live. Clearly identifying the reader is always important for what you write to be effective, but it's particularly important in this style of writing. Will your reader(s) understand complex technical terms? You can’t afford to leave them scratching their heads or simply losing interest if your writing is not on their level. Complex ideas don’t need complex language – it should be clear, concise and precise so the reader focuses on what’s being said rather than how it’s being said.

After training many scientists on our courses, we know this is a common fear. But making your work accessible is not the same as dumbing it down. It means writing for the right audience – and that means your work can have the practical applications that it should. And doing this may also mean increasing the size of the audience your work is exposed to, as NYU scientific writing lecturer Philip Rodenbough puts it, 'All technical writing is improved by making it more accessible – as long as we’re not completely re-explaining the very basics.'