Plain Language is Not Dumbing Down
What to say when an SME calls your plain-language revision too simple
This is article 2B of The Writers’ Table.
At some point in every technical writer’s career, a developer or subject matter expert reads a plain-language revision and says some version of: “This is too simple. Our users aren’t stupid.”
The complaint is often sincere. The SME genuinely believes that simple language signals disrespect for the reader’s intelligence. They’ve spent years developing expertise, and prose that doesn’t reflect that complexity feels like it’s hiding the work.
They’re wrong, but arguing about respect for users usually goes nowhere. The better argument is cognitive.
The Cognitive Load Problem
When a user opens documentation, they’re already in the middle of a task. They have a goal, they’ve hit an obstacle, and they’re looking for the specific piece of information that removes the obstacle. That user’s working memory is partially committed to their actual problem.
Cognitive load research — John Sweller’s foundational work dates to the 1980s, and the framework has been refined steadily since — establishes that working memory has a fixed capacity. Complex sentence structures, unusual vocabulary, and dense paragraphs increase extraneous cognitive load: mental effort spent on decoding the text rather than absorbing the content.
Plain language reduces extraneous load. It doesn’t reduce the complexity of the information — it frees up mental capacity to handle the complexity of the information. A reader who isn’t spending effort parsing a sentence can spend that effort on the underlying concept.
“The authentication token must be regenerated upon session expiration” takes more processing than “Regenerate the authentication token when your session expires.”
The information is identical. The cognitive cost is not.
What Plain Language Is Not
Plain language is not:
Short sentences as a rule. Some ideas require length. The goal is clarity, not a word count target. A 35-word sentence with clear structure and precise vocabulary is better than two 15-word sentences that obscure the relationship between ideas.
Basic vocabulary as a rule. Technical terms exist because they’re precise. “REST endpoint” means something specific that “web address” doesn’t capture. Use the precise term, explain it the first time it appears, then use it consistently.
The problem isn’t technical vocabulary — it’s undefined technical vocabulary.
Removing qualifications. If something is true under specific conditions, say so. Oversimplifying by cutting necessary caveats produces documentation that causes errors. The simplification that matters removes vagueness and keeps every necessary caveat intact.
The Real Rules
A few principles that hold reliably:
Put the condition before the action. “Click Save if you want to keep your changes” makes the reader absorb the action and then discover it’s conditional. “To keep your changes, click Save” delivers the condition first — the reader who doesn’t want to keep changes stops reading before they act.
Use active voice for procedures. “The form must be submitted” leaves the actor ambiguous. “Submit the form” is clear about who does what.
Define terms once, early, at the point of first use. Don’t distribute a glossary and expect readers to look things up. They won’t.
Keep sentences under 25 words when possible — not as an absolute rule, but as a test. A sentence over 25 words usually contains a clause that belongs elsewhere.
Defending Plain Language
When you need to defend a revision to a skeptical SME, two approaches tend to work.
First, demonstrate with a specific example. Take their original sentence, put your revision beside it, and ask a single question: “Which one is easier to act on?”
Original: Prior to initiating the export process, it is necessary for users to ensure that all pending changes have been committed to the database.
Revision: Commit your pending changes before you export.
The answer is obvious. The debate about “dumbing down” evaporates when the revision is in front of them.
And frame it as audience calibration. “I’m writing for the person who’s encountering this concept for the first time, not for someone who already knows it.” This tends to land better than arguments about clarity, because it positions the revision as a choice about audience rather than a judgment about the original’s quality.
The argument you should never make is that the SME’s original was bad writing. It isn’t bad, it’s just different.
It’s expert writing, written from inside the expertise. That’s a different register from documentation.
Both have their place; a task procedure is the wrong place for one of them.
The Legal Review Complication
One situation where plain language pushback gets complicated: legal and compliance review. In my experience, legal teams often prefer language that has survived review before — hedged constructions and established boilerplate feel safer than a fresh, direct sentence. That caution is defensible in contracts and terms of service. It’s almost never defensible in user documentation, where the goal is the opposite: users need to be able to act correctly on what they read.
When legal review introduces complexity into user-facing documentation, the question to ask is specific: “What risk does the plain-language version create that this version avoids?” If the answer is a concrete legal concern, address it. Sometimes a short disclaimer sentence resolves it without touching the procedure itself. If the answer is habit or general caution, push back and be ready to show the same before-and-after comparison you’d use with any other SME.
Further Reading
U.S. General Services Administration, Plain Language Guide Series at plainlanguage.gov — actively maintained and free federal guidance.
Nielsen Norman Group, “Plain Language Is for Everyone, Even Experts” (Hoa Loranger, 2017) — usability sessions with scientists, physicians, and IT managers showing that domain experts prefer plain language too, plus the “dumbs down” objection answered with data. nngroup.com
Ginny Redish, Letting Go of the Words: Writing Web Content that Works (2nd ed., 2012) — the standard practitioner text on plain language for web and product content.
ISO 24495-1:2023, Plain language — Part 1: Governing principles and guidelines — the first international plain-language standard; useful when an SME or legal team wants an authority to point to. iso.org
GOV.UK, “Writing for GOV.UK” — plain-English guidance grounded in reading-behavior research; plain English is mandatory across the entire site. gov.uk
What You Can Do
Find one sentence in your documentation — or in any technical document you have access to — that you think is harder to read than it needs to be.
Rewrite it using the principles above.
Next Monday: The Three Tiers of Editing — why developmental, structural, and copy editing are separate jobs, and why doing all three at once guarantees you’ll do all three badly.