· 4 min

Plain Language Is Infrastructure

Unclear language excludes people as surely as a missing ramp. Why plain language in forms, letters and services is civic infrastructure.

We build ramps for buildings. Plain language is the ramp for information.

A letter from an institution arrives. It is two pages long. The key instruction is in the fourth paragraph, phrased as a passive sentence with three clauses and a reference to a regulation. The deadline is in small print at the bottom.

Many people will miss it. Not because they are careless, but because the text was written for the institution, not for them.

Unclear language excludes

Complex language is not neutral. It filters people.

It filters people reading in a second language. People with cognitive disabilities. People under stress. People with less formal education. People who are tired, busy or reading on a small screen.

That is a large share of everyone, at some point. When essential information is unclear, those people miss deadlines, lose entitlements, make mistakes and pay penalties.

Clear is not dumbed down

The common objection: plain language oversimplifies. It loses precision.

The opposite is usually true. Complex sentences hide ambiguity. Plain sentences expose it. When you rewrite a dense paragraph in simple words, you often discover that nobody was sure what it meant.

Experts benefit too. Specialists generally prefer clear writing because it is faster to read. Nobody enjoys parsing a nested sentence.

What plain language looks like

The GOV.UK Service Manual and style guidance push for short sentences, common words, active voice and content that puts what users need first (GOV.UK Service Manual). The principles are simple:

  • Lead with what the reader must do. Action first, background later.
  • Use common words. "Start" not "commence." "Help" not "facilitate."
  • One idea per sentence.
  • Active voice. "We will send you a letter" not "A letter will be sent."
  • Concrete dates and amounts. "By 15 March" not "within the statutory period."
  • Headings that answer questions. "What you need to bring," not "Documentation requirements."

It is a design responsibility

Language is interface. In forms, notices, error messages and help pages, the words are the product.

Designers working on public or essential services should treat content as a first-class material:

  • Involve content designers from the start
  • Test comprehension, not just completion
  • Read text aloud
  • Remove legal language from the main flow and link to it where required

Test understanding

A form can be completed without being understood. People guess, pick the first option, or leave a field blank.

Test for comprehension. Ask participants to explain in their own words what a page means and what they need to do. The gaps between what you wrote and what they understood are your backlog.

Failure first

The pattern that fails: an official notice written by the legal team, approved without user testing. People miss the deadline buried in paragraph four. Support lines fill up with questions the notice was supposed to answer.

The pattern that works: the same notice, rewritten to start with "You need to do X by [date]." The legal reference moves to the bottom. Calls drop because people understand the first line.

Language patterns that cause harm

Some habits appear again and again in official writing:

  • Nominalisations. "Submission of the application" instead of "submit your application."
  • Hidden actors. "It has been decided" instead of "we decided."
  • Stacked conditions. "If you are not, or have not been, in receipt of…"
  • Undefined acronyms and internal terms. Names of departments, schemes or systems that mean nothing outside the building.
  • Vague time. "Promptly," "in due course," "within the relevant period."

Each one makes the reader do work the writer avoided.

Rewriting, step by step

  1. Find the one thing the reader must do. Put it in the first sentence.
  2. Name the actor. Who does what: "You need to," "We will."
  3. Split long sentences. One idea each.
  4. Replace jargon with words your readers use. Search queries and support calls show you their vocabulary.
  5. Turn conditions into lists. "You can apply if:" followed by bullet points.
  6. Use real dates and amounts.
  7. Read it aloud. Wherever you stumble, the reader will too.
  8. Test with a few readers. Ask them to tell you what the text asks them to do.

Translation starts with plain English

Plain source text is also easier to translate accurately, whether by people or machines. Idioms, long clauses and ambiguous pronouns multiply errors in translation. Writing plainly in the first language is the cheapest way to serve readers in every other.

The point

Information that people cannot understand is information they do not have.

Plain language is not style. It is infrastructure: the thing that decides whether people can use the systems built for them.

Looking for a designer who owns the problem, not just the deliverable.

Available for full-time roles in product-led teams where experimentation drives decisions.