Plain Language and Style Guides: Techniques That Make Technical Writing Clear
Clarity in technical writing isn't a talent you're born with — it's the result of applying a handful of concrete, repeatable techniques. The gap between confusing documentation and documentation that just works is rarely about vocabulary or eloquence; it's about disciplined choices around word usage, voice, structure, and consistency. Master these strategies and your writing improves immediately and permanently.
This guide collects the highest-impact techniques working technical writers use every day. For the wider discipline they support, start with our beginner's guide to technical writing, then apply the strategies below to whatever you're writing next.
Write in Plain Language by Default
Plain language means expressing ideas as simply as the subject allows — not dumbing down, but removing the friction between the reader and the meaning. It favours common words over fancy ones ("use" not "utilise", "start" not "initiate"), short sentences over sprawling ones, and concrete statements over abstract ones. The goal is that a reader understands your sentence correctly on the first pass, without re-reading.
Plain language is especially critical for a global audience, where many readers are not native English speakers. Complex sentence structures, idioms, and unnecessary jargon disproportionately hurt them. The plainer your writing, the more people can use it and the more reliably machine translation renders it. Plain-language principles are backed by decades of research and codified in resources like the U.S. government's Federal Plain Language Guidelines.
Active Voice, Present Tense, Second Person
Three grammatical defaults do most of the heavy lifting in clear technical writing. Active voice ("Click Save" not "the Save button should be clicked") makes clear who does what and is shorter and more direct. Present tense ("the system displays a confirmation" not "the system will display") is simpler and describes how the software behaves as a stable fact. Second person ("you") addresses the reader directly, which is exactly right for instructions.
Together these produce prose that is direct, unambiguous, and easy to follow — which is why every major style guide mandates them. Passive voice isn't forbidden (it's occasionally the right choice when the actor is unknown or irrelevant), but active should be your strong default. These conventions connect to the reader-psychology reasons we explore in our article on the psychology of technical writing.
Adopt and Enforce a Style Guide
A style guide is the single highest-leverage tool for consistent, professional documentation, because it settles hundreds of recurring micro-decisions once so writers stop re-litigating them. Rather than build one from scratch, adopt an established base: the Google developer documentation style guide or the Microsoft Writing Style Guide are both free, comprehensive, and widely respected for software documentation. Layer a short house style guide on top for your product-specific terms and preferences.
A style guide covers voice and tone, capitalisation, how to format UI elements and code, treatment of numbers and dates, and terminology decisions. The payoff is consistency — and consistency reduces the reader's cognitive load because they learn your conventions once and reuse them everywhere. Enforcement matters as much as authorship: automated prose linters like Vale can check content against your style guide on every change, turning subjective debates into objective checks, as we describe in our docs-as-code toolchain guide.
Consistent Terminology and a Glossary
Using different words for the same concept is one of the most damaging habits in technical writing. If you call it a "user" in one place, a "customer" in another, and an "account holder" in a third, the reader wonders whether these are three different things. In technical documentation, synonyms create ambiguity, not variety — the elegant-variation instinct writers learn in school actively harms clarity here.
The fix is a controlled vocabulary: pick one term for each concept and use it consistently everywhere, then record these decisions in a glossary. A glossary serves double duty — it disciplines writers and helps readers who encounter unfamiliar terms. Consistent terminology also improves search (readers find what they search for) and machine translation (consistent source produces consistent translations). This discipline is foundational to the structured, reusable content that scales across large documentation sets.
Ruthless Editing and Self-Review
First drafts are always too long, too vague, and too cluttered — that's what first drafts are for. The quality emerges in editing, and the core editing move is cutting. Every word, sentence, and section should earn its place by helping the reader reach their goal; if it doesn't, it goes. Watch for wordy phrases ("in order to" becomes "to", "at this point in time" becomes "now"), redundant qualifiers, and preamble that delays the reader from the actual instruction.
Build a self-review habit before you send work for review: read your draft as the target reader would, ideally after a break so you see it fresh; run the procedure yourself to confirm accuracy; and read it aloud to catch clumsy phrasing your eye skips. A short self-editing checklist — active voice, one idea per sentence, consistent terms, front-loaded key points, tested steps — catches most issues before anyone else sees them.
Structure Sentences and Procedures for Action
How you structure information determines how easily a reader can act on it. For procedures, use numbered steps where each step is a single action starting with an imperative verb ("Enter your email address"), and show the result when it matters ("A confirmation message appears"). Put any condition before the action, not after — "To enable notifications, open Settings" works because the reader knows the goal before the instruction, whereas the reverse forces a mental re-read.
At the sentence level, front-load the main point, keep one idea per sentence, and prefer lists to buried series of comma-separated items. These structural habits, applied consistently, make the difference between documentation readers trust and documentation they abandon. To practise all of these strategies with feedback on real documents, Darlo Technical Writing's Clear Technical Writing course includes a downloadable self-editing checklist and a house style guide template you can adapt for your team — explore the course catalogue to sharpen your craft.
The Technical Writer's Self-Editing Checklist + House Style Guide Template
A free one-page self-editing checklist covering voice, clarity, and consistency, plus an editable house style guide template built on the Google and Microsoft guides.
Should I always avoid the passive voice?
No — active voice should be your strong default because it's clearer and more direct about who does what, but passive voice is occasionally the right choice when the actor is unknown, irrelevant, or when you deliberately want to emphasise the object of the action. The rule is to use active by default and passive only with a reason.
Which style guide should my team adopt?
For software documentation, adopt the Google developer documentation style guide or the Microsoft Writing Style Guide as your base — both are free, comprehensive, and widely used. Then layer a short house style guide on top for your product-specific terminology and preferences rather than writing a full guide from scratch.
Why does using synonyms hurt technical writing?
Because in documentation, different words for the same concept create ambiguity rather than variety. If you call something a "user" here and a "customer" there, readers wonder if they're different things. Pick one term per concept, use it everywhere, and record it in a glossary — consistency also improves search and translation.