Plain Language in Technical Writing: How to Write Docs People Understand

Most documentation problems aren't caused by missing information. The answer is usually on the page somewhere. The trouble is that it's buried in a 40-word sentence, hidden behind jargon, or split across three paragraphs that say the same thing.

Plain language fixes that. This guide covers what plain language means in technical writing, why it works for experts too, the techniques that matter most, and how to check readability and understanding without gaming a score.

What is plain language?

Plain language is writing that readers can find, understand, and use the first time they read it. It isn't "dumbed-down" writing. It's writing where the wording, structure, and design all work for the reader instead of against them.

In the US, the Plain Writing Act of 2010 defines plain writing as "writing that is clear, concise, well-organized, and follows other best practices appropriate to the subject or field and intended audience." That last part matters for technical writers. Plain language doesn't ban technical terms. It asks you to match your words to the people reading them.

The four plain language principles (ISO 24495-1)

In 2023, plain language got its first international standard: ISO 24495-1, Plain language — Part 1: Governing principles and guidelines. It rests on four principles. Each one makes a useful test for a documentation page:

1. Relevant: readers get what they need. Does this page answer the question that brought the reader here?
2. Findable: readers can easily find what they need. Can they spot the answer in seconds through headings, lists, and search?
3. Understandable: readers can easily understand what they find. Are the words, sentences, and examples clear to this audience?
4. Usable: readers can easily use the information. Can they act on it by completing the task, making the decision, or fixing the problem?

Only one of the four is about the words themselves. A page full of short sentences can still fail if it answers the wrong question or hides the key step.

Why plain language works for expert readers too

A common objection from technical teams is "our users are engineers, they don't need things simplified." The research says otherwise.

Nielsen Norman Group ran usability studies with domain experts in science, technology, and medicine. Participants included IT managers, professors, and healthcare professionals with advanced degrees. Even these highly educated readers wanted short content they could scan. One professor, faced with a dense page, said: "This is crazy dense… I'd rather have less."

Their recommendations for expert audiences are specific:

• Use the words your audience uses. For specialists, the right jargon is a useful shortcut, as long as you've confirmed they know it.
• Keep sentences to roughly 15–20 words.
• Aim for a 10th–12th grade reading level, even for experts. Text above that takes too much mental effort.
• Format for scanning with informative headings, bulleted lists, and white space.

Some public-sector teams go further. The UK Home Office design manual recommends "writing for a maximum reading age of 9, even if you are writing for a specialist audience." It notes that clear language particularly helps people with learning disabilities or cognitive issues, people with dyslexia, autistic people, and people reading in a second language.

That last group is easy to forget. An English help center is often read by people whose first language is something else, and every idiom is a small wall between them and the answer.

Plain language guidelines for technical documentation

The techniques below come from the US federal plain language guidance on Digital.gov and the research above. They're listed roughly in order of impact for typical product and IT documentation.

1. Write for one clearly defined reader

Before editing a sentence, decide who the page is for. An admin configuring single sign-on and a first-time user resetting a password need different pages, not one page that tries to serve both.

2. Use active voice

Active voice makes it clear who does what. Digital.gov puts it simply: active voice "eliminates ambiguity about responsibilities."

• Before: The configuration file must be updated before the service is restarted.
• After: Update the configuration file, then restart the service.

In procedures, the imperative ("Update…", "Select…", "Restart…") is usually the clearest form of active voice. It tells the reader exactly what to do.

3. Prefer present tense and "you"

Present tense makes writing "simpler, more direct, and more forceful," according to the same guidance. Addressing the reader as "you" removes a layer of abstraction.

• Before: The user will be presented with a confirmation dialog.
• After: You see a confirmation dialog.

4. Unhide your verbs

A hidden verb is a verb that has been turned into a noun. It usually needs an extra verb to make sense. Watch for endings like -tion, -ment, -sion, and -ance.

• Before: Perform an installation of the agent and conduct a verification of the connection.
• After: Install the agent and verify the connection.

This is often the fastest edit in technical docs. It shortens sentences and makes steps more direct at the same time.

5. One idea per sentence, one task per step

Long sentences with several clauses make readers hold too much in their heads. Split them. In procedures, give each step one action. If a step contains "and then," it's probably two steps.

6. Define terms once, then use them consistently

Plain language doesn't mean avoiding every technical term. It means using the term your reader expects, defining it the first time if needed, and never switching synonyms halfway through. If the button says "Workspace," don't call it a "project" in step 4.

7. Structure for scanning

Most readers scan documentation looking for the one line they need. Help them:

• Put the answer or outcome first, then the detail.
• Write headings that say what the section does ("Reset a user's password"), not just name a topic ("Passwords").
• Use numbered lists for sequences and bullets for options.
• Use tables when readers need to compare values or settings.

Plain language examples: before and after

Here's a typical paragraph from an internal IT guide, rewritten using the techniques above.

Before (57 words):

In the event that a user experiences difficulties with regard to the authentication process, it is recommended that a review of the account status be conducted by the administrator, following which, should the account be determined to be locked, the performance of an unlock operation via the admin console may be undertaken in order to restore access.

After (32 words):

If a user can't sign in:

1. Open the admin console and check the user's account status.
2. If the account is locked, select Unlock account.

The user can sign in again right away.

The rewrite uses active voice, unhides verbs ("a review … be conducted" becomes "check"; "the performance of an unlock operation" becomes "unlock"), and turns a buried procedure into numbered steps. It's also easier to translate if you publish in more than one language.

How to use readability scores (without gaming them)

Readability formulas are useful smoke alarms. The two most common are both built from just two inputs: average sentence length and average syllables per word.

• Flesch Reading Ease produces a score from roughly 0 to 100, where higher means easier. Scores of 60–70 correspond to "plain English," about an 8th–9th grade level.
• Flesch–Kincaid Grade Level maps the same inputs to a US school grade. It was developed for the US Navy in 1975.

These scores flag long sentences and long words. They can't tell you whether a page is correct, well organized, or answers the right question. As Wikipedia's summary of the research notes, readability formulas "neglect between-reader differences and effects of content, layout and retrieval aids."

Use them like this:

• Set a target range per audience. For example, a general help center might aim lower than an API reference. Treat the target as a guide, not a pass/fail gate.
• Investigate outliers. A page scoring far below the rest of your docs is worth a second look. Usually one or two monster sentences are dragging it down.
• Don't chase the number. Chopping sentences into fragments or swapping precise terms for vague ones can improve the score and still make the page worse.

Accessibility standards point the same way. WCAG success criterion 3.1.5 (Level AAA) asks that when text requires reading ability beyond lower secondary education, you provide supplemental content. That could be a plain-language summary, illustrations, or audio. For complex technical topics, a short plain summary at the top of the page is a practical way to meet that intent.

Sonat includes a built-in readability guide that scores your topics, so you can spot dense passages before they're published instead of finding out from support tickets.

Test for understanding, not just for style

The final plain language principle is "usable," and the only reliable way to check it is with real readers. Digital.gov's plain language guide series includes a whole section on testing for understanding. You don't need a usability lab to start:

• Task test: Give someone from the target audience a task ("Add a new team member with read-only access") and watch them use only your doc. Note where they hesitate.
• Paraphrase test: Ask a reader to explain a page back to you in their own words. If their summary is wrong, the page is unclear, not the reader.
• Feedback on every page: Collect "Was this helpful?" responses and comments where readers actually are. Pages that keep getting low ratings are your editing queue.

Sonat builds this feedback loop into published docs, so authors see which topics confuse readers and can fix them in the same place they write.

Make plain language a habit, not a one-off edit

Plain language works best as part of how your team writes, not as a yearly cleanup. Add the four ISO principles and your sentence-length and reading-level targets to your documentation style guide. Check readability in every review, alongside accuracy. Keep a shared list of hidden verbs and jargon your team overuses, with plain alternatives.

Conclusion

Plain language isn't about writing less precisely. It's about removing everything between your reader and the answer they came for. Start with one page that generates a lot of support questions. Rewrite it with active voice, short sentences, and clear steps, check its readability, and watch what happens to the feedback.

If you want readability checks and reader feedback built into the place you write, you can start with Sonat for free.