Plain does not mean simple-minded
Plain language is writing that the intended reader can understand on the first reading and act on. It does not mean removing technical content or talking down to specialists. The aim is to take out the difficulty that comes from the writing, so that the reader’s effort goes to the difficulty that comes from the subject.
A common worry among engineers is that simpler wording will be less accurate. It need not be. The trick is to separate two things: terms that carry exact meaning, which you keep, and padding or decoration, which you remove.
Know which words must stay
Some technical terms are necessary. “Torque”, “latency” and “tolerance” each name something precise, and replacing them with everyday approximations would lose meaning. For these:
- Use the term consistently, with one name for one thing.
- Define it briefly at first use if any reader may not know it.
- Do not swap in synonyms for variety. In technical text, a new word suggests a new thing.
Other terms are jargon in the unhelpful sense: private shorthand, internal project names, or inflated phrasing that says nothing more than a common word would. Test each term by asking who the reader is. A word that is routine for your team may be opaque to a customer, a new colleague or an engineer from another discipline.
Swap inflated words for direct ones
Many long words can be replaced with shorter ones without any loss.
| Instead of | Try |
|---|---|
| utilise | use |
| commence | start |
| in the event that | if |
| prior to | before |
| a large number of | many |
| due to the fact that | because |
| it is necessary to | you must / we need to |
These are illustrations, not rules to apply mechanically. Choose what reads naturally in your context, and keep the formal wording where a standard or contract requires it.
Shorten and untangle sentences
Long sentences are not wrong in themselves, but technical sentences often carry too many ideas at once. A few habits help.
One main idea per sentence. If a sentence has three clauses joined by “which”, “and” or “while”, try splitting it.
Before: “The controller, which was configured with the revised gain values that were agreed at the previous review, was tested under load conditions in which the supply voltage was varied, and the output was found to remain stable.”
After: “We configured the controller with the gain values agreed at the previous review. We then varied the supply voltage under load. The output remained stable.”
Put the actor and action up front. Passive voice has its uses, for instance when the actor is unknown or unimportant, but it often hides who did what.
Before: “It was decided that the connector would be replaced.” After: “The team decided to replace the connector.”
Turn noun stacks into phrases. Strings such as “system performance degradation analysis procedure” force the reader to guess how the words relate. “A procedure for analysing how system performance degrades” is longer but easier to parse.
Prefer verbs to abstract nouns. “We performed an evaluation of the sensor” can become “We evaluated the sensor”. Phrases like “make a determination” or “provide an indication” usually shrink to one verb.
Keep precision while simplifying
When shortening text, check that you have not changed the meaning. Watch for:
- Numbers and units. Never round away information the reader needs, and keep units attached.
- Conditions. Phrases like “under normal load” or “after calibration” often qualify a claim. Do not drop them for brevity.
- Hedges that are real. If something is an estimate, an assumption or an untested expectation, keep the signal. Remove only hedges that are habit, such as piling “may” and “possibly” onto an already tentative statement.
- Warnings. Safety information should be clear and easy to find, and not buried in a long sentence. Requirements for how warnings must be written vary by country and industry, so follow the rules that apply to your product or workplace.
A useful check is to ask a colleague to restate the sentence in their own words. If their version differs from what you meant, the problem is in the writing, not in them.
Write for the reader you actually have
Technical audiences are rarely uniform. A specification may be read by designers, testers, buyers and, later, auditors. For mixed readers:
- Put a short, plain summary at the top for those who need only the gist.
- Put detail below it, labelled clearly, for those who need to check.
- Use examples. A short worked case, with simple numbers you have verified, often explains a rule better than another paragraph of abstract description.
- Keep a personal list of terms you tend to over-use; a personal glossary is useful both for consistency and for spotting jargon.
Readers whose first language is not English also benefit from plain wording. Idioms, humour and phrasal verbs often translate badly, and automatic translation tools handle shorter, direct sentences better.
A simple editing routine
- Read it aloud. Mark every place you stumble or run out of breath.
- Circle abstract nouns and passive verbs. Rewrite those that hide the action.
- Check every term. Is it needed, consistent and defined?
- Split long sentences. Aim for one idea each, without chopping the text into fragments.
- Cut what does not help. Remove introductory throat-clearing and repeated points.
- Check meaning. Compare the result with the original for numbers, conditions and warnings.
Readability tools can point to long sentences, but they cannot judge accuracy or audience, so treat their scores as hints rather than targets.
When jargon is fine
Among specialists who share a vocabulary, technical shorthand can be efficient and clear. The aim is not to ban it, but to use it deliberately. If you are unsure who will read a document, err towards explaining. If you are sure, write for those readers. Either way, the broader habits of structure and editing described under technical writing and the specific advice on writing requirements work together with clear wording.