Plain Language & Readability
Writing that users can read fast, understand on first pass, and act on confidently — the craft behind every effective interface.
10 min read
The full lesson
Most usability problems are not layout problems — they are comprehension problems. Users abandon forms not because the button is in the wrong place, but because the label is ambiguous. They call support not because a feature is missing, but because the instructions were written in passive, legal-department prose.
Plain language removes that friction. It means writing at the level your users actually read, in the words they actually use, so they can take the action you both want them to take. It is also one of the most measurable UX investments you can make — rewriting a single error message or form label can cut task-failure rates by double digits.
What Plain Language Actually Means
Plain language is not dumbed-down writing. It is precise, purposeful writing calibrated to the audience’s reading context.
The federal plain-language standard — used as a benchmark by most large organizations — defines it as writing “clear enough that the intended audience can find what they need, understand what they find, and use that information to meet their needs.” In a UI, that means:
- The user grasps the meaning on first read, without backtracking.
- The user knows what action to take next.
- The user does not need to already understand the system to understand the copy.
Readability is the measurable side of plain language. Formulas like Flesch-Kincaid and SMOG give you a grade-level score. Tools like Hemingway App score sentence complexity. These scores are useful directional signals — not ground truth. A financial product explaining investment risk to first-time investors needs different calibration than a developer console explaining API rate limits. Audience and context set the target, not an algorithm.
The Core Plain-Language Principles in UI Context
Use the Active Voice
Active voice makes the subject clear and shortens the sentence. In a UI, it also shows who is responsible for what — which matters enormously in error messages and instructions.
| Passive (avoid) | Active (prefer) |
|---|---|
| “Your account has been created." | "You’re all set — your account is ready." |
| "The file could not be uploaded." | "We couldn’t upload that file." |
| "Payment is required before access is granted." | "Pay to unlock full access.” |
Passive voice is not always wrong. You might use it deliberately to soften blame — “Your session was interrupted” rather than “The network dropped your session.” The rule is: reach for active first, then choose passive on purpose.
Front-Load the Information That Matters
Users scan before they read, and they scan the left side and top of text first. Put the most important word or phrase at the start of a sentence, heading, or list item.
For button labels, that means the verb: “Download report”, not “Report download”. For error messages, that means the problem: “Card declined — check the number and try again”, not “There was a problem processing your payment information.”
Choose Common Words Over Formal or Technical Ones
Every domain has jargon. Jargon is precise among experts — the mistake is using it outside that audience without a second thought. Here are common substitutions that improve comprehension without losing precision:
| Jargon | Plain alternative |
|---|---|
| Authenticate | Sign in / verify your identity |
| Utilize | Use |
| Initiate | Start |
| Terminate | End / close |
| Proceed | Continue |
| Leverage | Use |
Technical audiences are an exception. “Deploy to production” is already plain language for a developer. Know your audience and calibrate accordingly.
Keep Sentences Short
Aim for an average of 15–20 words per sentence in UI copy. A sentence over 25 words in a tooltip, error message, or modal almost always contains a clause that can become its own sentence. Long sentences also fail on mobile, where line lengths are short and users are distracted.
Write for Skimming
Users in action mode — completing a checkout, filling out a form, reading an error — are not reading every word. They are scanning for the key term, the action, the number. Structure your copy so the essential information is visible in a quick scan:
- Use headings and subheadings to break up multi-step flows.
- Use numbered lists for sequential steps; bullet lists for parallel items.
- Bold the key term in a long sentence — sparingly.
- Keep paragraph blocks under three to four sentences.
Readability Standards and Accessibility
WCAG 2.2 addresses readability directly in Guideline 3.1. The requirements are:
- 3.1.1 Language of Page (Level A): the default language of the page is programmatically determinable.
- 3.1.2 Language of Parts (Level AA): when a passage changes language (for example, a French term in an English page), the language change is marked up.
- 3.1.5 Reading Level (Level AAA): when content requires reading ability beyond lower secondary level (roughly Grade 9 in the US), a version requiring lower reading skill or supplementary visual content is provided.
Most product teams only commit to Level AA, so 3.1.5 is not technically required. But it is a useful target for consumer-facing products where you cannot screen users by reading ability — healthcare forms, government services, financial onboarding. Writing at a Grade 6–8 level by default does not compromise sophistication; it extends reach.
Plain language also intersects with cognitive accessibility. Users with dyslexia, ADHD, or cognitive disabilities benefit from:
- Short, predictable sentence structures.
- Familiar words and consistent terminology. Use the same label every time you mean the same thing — do not alternate “billing address” and “payment address”.
- Generous whitespace so dense text does not create visual overwhelm.
Common Anti-Patterns in Product Copy
Nominalization (Turning Verbs into Nouns)
Nominalization (turning a verb into an abstract noun) adds words and reduces clarity.
- “Make a decision” → “Decide”
- “Provide confirmation” → “Confirm”
- “Give consideration to” → “Consider”
- “Conduct an investigation” → “Investigate”
In UI copy, nominalization often appears in button labels (“Submit your application”) and form instructions (“Provide your billing information”). The fix is almost always the verb alone.
Hedging and Throat-Clearing
Opening sentences that explain what you are about to say add no information:
- “Please be aware that…” → delete
- “For your information…” → delete
- “It should be noted that…” → delete
- “In order to…” → “To”
Every word in a UI carries a small cognitive cost. Hedge phrases spend that cost for no user benefit.
Jargon Without Escape Hatches
Technical terms are sometimes unavoidable. When you must use one, follow it with a brief definition on first use. “Your API key (a private code that lets apps access your account)” costs six extra words once and prevents confusion at every encounter after that.
Passive Blame-Shifting in Error Messages
“An error has occurred” and “The request was unsuccessful” are passive and responsibility-free. They leave the user with no way forward. Error copy should follow a three-part pattern:
- What happened (brief, honest, specific).
- Why it happened (when knowable and useful, without jargon).
- What the user can do next (always present).
Example: “We couldn’t connect to the server. Check your internet connection and try again — if the problem continues, contact support.”
Do
- Use active voice to make responsibility explicit — “We couldn’t process your payment” owns the problem.
- Front-load the most important information in every sentence, heading, and label.
- Use the same word for the same concept everywhere in the product; build a terminology glossary.
- Follow the three-part error pattern: what happened, why, what to do next.
- Calibrate reading level to your audience — Grade 6–8 for broad consumer products, higher for expert tools.
- Test comprehension with real users: read-aloud protocols surface ambiguous copy that no readability formula catches.
Don't
- Don’t use passive voice as a default — it obscures agency and adds words.
- Don’t stack technical jargon without definitions or escape hatches for non-expert users.
- Don’t open sentences or paragraphs with throat-clearing phrases like “Please be aware that” or “It should be noted.”
- Don’t assume a low Flesch-Kincaid score means the copy is good — readability formulas measure sentence length and syllables, not user comprehension.
- Don’t use different labels for the same concept across the product — inconsistency forces users to re-interpret and slows task completion.
- Don’t rely only on designer or engineer review for copy — stakeholder review introduces corporate voice; get copy in front of users early.
Readability Testing Methods
Readability formulas give you a fast, free directional signal. They measure sentence length and word syllable count — surface features that correlate with comprehension difficulty. Flesch-Kincaid Grade Level and SMOG are the most widely used. For UI copy specifically:
- Run your help text, onboarding flows, and error message library through a scoring tool (Hemingway App, Readable.com) as a baseline audit.
- Flag anything above Grade 10 for review.
- Prioritize revision on copy that appears in high-stakes moments: error states, purchase confirmations, destructive action warnings.
Formulas cannot catch jargon that happens to use short words, ambiguous pronoun references, or content that is grammatically simple but conceptually complex. For those, user testing is the only reliable method.
Think-aloud protocols are the gold standard for copy comprehension testing. Ask a participant to read aloud and narrate their understanding while completing a task. Listen for hesitation, re-reads, and misparaphrase — these signal comprehension failure. Five participants are enough for this kind of qualitative problem-finding. You are not trying to benchmark a score; you are finding where copy breaks.
Cloze tests are useful for assessing whether key words land. Delete every fifth word from a passage and ask users to fill in the blanks. Accuracy above 60 percent suggests the passage is comprehensible at the sentence-meaning level.
Plain Language in Design Systems
Plain language does not scale through individual writer heroics — it scales through systems. The content standards you embed in your design system become the defaults that every team writes against.
Practical components to include in your content standards:
- Terminology glossary: the canonical name for every product concept, with examples of correct and incorrect use.
- Voice and tone guidelines: the register for different moment types — error states, celebrations, empty states, confirmations.
- Copy patterns by component: what a modal title sounds like, how a tooltip is structured, how a destructive action confirmation reads.
- Reading-level targets by audience segment: if you have consumer and enterprise users, these may differ.
- Prohibited words and phrases: “please be aware”, “utilize”, jargon terms that keep appearing despite being off-brand.
When content standards live in a shared design system alongside component documentation — in tools like Storybook or zeroheight — writers and designers consult them at the moment they are making decisions. A standalone tone-of-voice PDF sitting in a drive folder and drifting out of date is the outdated alternative. Living documentation co-located with the components it governs is the current standard.
Measuring Plain-Language Impact
Plain language improvements are among the easiest design changes to measure because they often have direct task-completion proxies:
- Form completion rate: does rewriting field labels and instructions reduce drop-off at a specific field?
- Error rate on a specific step: does a clearer description of a requirement reduce validation errors?
- Support contact rate for a specific task: does plain-language help text reduce “how do I” tickets?
- Task-success rate in usability testing: do participants complete the task correctly after the copy change?
Run a before/after comparison with enough traffic to reach statistical significance, or use a moderated usability test with the old and revised copy as conditions. Tie your metric to a specific user action, not a readability score — the score is a proxy. Task success is the outcome.