Plain Language for Technical Writers: Clarity Under Pressure
Clarity is the whole job. A technical writer can have perfect information architecture and a flawless toolchain, but if a reader has to reread a sentence three times to understand a step, the documentation has failed at the point of contact. Plain language is the craft of making complex information understandable on the first read — and it is a learnable, teachable discipline, not a talent you are born with.
This guide is for working professionals who want to sharpen the sentence-level and editing skills that separate adequate documentation from excellent documentation. It pairs with our beginner's guide to technical writing for foundations and our style guide article for consistency at scale. Google's developer documentation style guide at developers.google.com/style is an excellent, freely available model of plain-language conventions.
What Plain Language Really Means
Plain language is often mistaken for dumbing down. It is the opposite: it is the discipline of conveying precise, sometimes highly technical information with the least possible cognitive load. It means choosing common words over showy ones, keeping sentences to one idea, structuring information so the main point comes first, and removing everything that does not earn its place. The reader's effort, not the writer's vocabulary, is the measure.
Crucially, plain language does not mean imprecise language. In technical writing you must keep the exact term for the exact concept — an argument is not a parameter, and blurring them to sound friendlier causes bugs. Plain language keeps the necessary technical terms and strips away the unnecessary complexity around them: the convoluted sentence structure, the hedging, the passive constructions, the abstraction. Precision and simplicity are allies, not opposites.
Sentence-Level Craft
Most clarity problems live at the sentence level. The highest-impact habits are simple to state and hard to sustain under deadline. Prefer the active voice: "the server returns an error" beats "an error is returned by the server" because it names who does what. Keep sentences short — aim for one main idea each, and break any sentence that needs a second comma to survive. Put the most important information first, before conditions and caveats.
Use strong verbs instead of nominalizations: write "configure the endpoint," not "perform configuration of the endpoint." Cut filler intensifiers (very, really, simply, just) and hedges (basically, essentially) that add words without meaning. Replace vague pointers like "this" and "it" with the actual noun when there is any ambiguity. And write imperatively in instructions — "click Save," not "you should click Save" — because the reader is doing, not contemplating. These moves, applied relentlessly, transform prose.
The Self-Editing Pass
First drafts are for getting the information down; editing is where clarity is made. The professional habit is to separate these into distinct passes so you are not writing and criticizing in the same breath. Draft freely, then return with fresh eyes — ideally after a break — and edit ruthlessly. A useful sequence is structure first (is the order right?), then paragraphs, then sentences, then words, then a final proofread for typos and formatting.
Read your work aloud; your ear catches clumsy rhythm and run-on sentences that your eye skims past. Cut mercilessly on the second pass — aim to remove a meaningful fraction of the words without losing meaning, and the piece will nearly always improve. Where possible, get a peer review, because you cannot see your own assumptions; the passages that seem obvious to you are exactly where you have skipped a step the reader needs. Our article on style guides shows how to make many of these edits automatic across a team.
Voice, Tense, and Person in Technical Prose
Consistency in voice, tense, and person is invisible when done well and jarring when not. The conventions most technical style guides converge on are: use the present tense ("the function returns" not "the function will return"), address the reader directly as "you," and use the active voice by default. These choices make instructions feel immediate and unambiguous about who acts.
Second person ("you") is standard for procedures because it speaks to the reader as the doer. Reserve first person plural ("we") for the rare cases where the product team is genuinely the actor. Avoid drifting into a detached, passive institutional voice, which distances the reader and hides responsibility. Set these conventions once in your style guide and apply them everywhere; the uniformity itself is a clarity feature, because readers stop noticing the prose and absorb the content.
Writing for a Global, Translated Audience
Documentation is read worldwide, often by people whose first language is not English and often through machine or human translation. Writing for this reality is a plain-language skill in itself. Keep sentences short and syntactically simple, because complex clauses translate poorly. Avoid idioms, cultural references, humour, and metaphors that do not travel. Use consistent terminology — never vary a term for stylistic variety, because synonyms confuse both translators and non-native readers.
Be explicit rather than relying on implication: spell out relationships that a native speaker might infer. Avoid noun stacks ("user account settings management panel"), which are ambiguous in English and worse in translation. These practices, sometimes called writing for global or simplified English, improve clarity for everyone, not only translated audiences. The Write the Docs community documents localization-friendly writing well at writethedocs.org.
Measuring Readability Honestly
Readability formulas like Flesch-Kincaid and automated tools can flag long sentences and dense paragraphs, and they are useful as a rough signal and a way to track trends. But treat them as a smoke detector, not a grade. A low reading-grade score does not guarantee comprehension, and technical content that must use technical terms will never score like a children's book. Gaming the metric by chopping every sentence produces choppy, harder-to-follow prose.
The honest measures of readability are behavioural: do readers complete the task, does support volume drop, do usability tests show first-read comprehension? Combine automated linting for consistency with real user feedback for truth. To build these clarity and editing skills systematically, the Darlo plain-language editing course offers guided practice with before-and-after exercises, and the free self-editing checklist below distills this article into a repeatable pass you can run on every draft.
Technical Writing Self-Editing Checklist
A one-page editing pass covering structure, sentence craft, active voice, terminology consistency, and translation-friendly language to run on every draft.
Does plain language mean removing technical terms?
No. Plain language keeps the precise technical term for the precise concept and removes the unnecessary complexity around it — convoluted sentences, hedging, passive voice, and filler. Precision and simplicity work together; you never sacrifice accuracy for readability.
Why is active voice preferred in technical writing?
Active voice names who performs the action, which removes ambiguity in instructions. "The server returns an error" is clearer and shorter than "an error is returned by the server." It also makes responsibility explicit, which matters in procedures.
Are readability scores like Flesch-Kincaid reliable?
They are a useful rough signal for spotting long sentences and dense text, but not a true measure of comprehension. Technical content with necessary jargon will never score like simple prose. Rely on task completion and user testing for the real verdict.