Plain Language

Complicated language in interfaces and documents is rarely deliberate. It accumulates through a combination of legal caution, technical jargon, corporate habits, and a cultural conflation of complexity with sophistication. The result is writing that says less while using more words — and users who stop reading, misunderstand instructions, or abandon tasks.

Plain language is the antidote. It is not simple-minded writing. It is writing that has had the effort applied to make complex information accessible, rather than letting complexity stand unchallenged.

The plain language principles

Plain language has a small set of core principles, consistently applied:

Use common words. The word “use” is almost always better than “utilise.” The word “help” is almost always better than “assist.” The word “now” is almost always better than “at this juncture.” When a simpler word exists and is unambiguous, it is better than a more complex one.

Prefer active voice. “The form was submitted by the user” is passive. “You submitted the form” is active. Active constructions are shorter, clearer, and feel more direct. Passive voice is appropriate in specific contexts — when the actor is unknown or unimportant — but should not be the default.

Use short sentences. A sentence that contains two ideas is usually better as two sentences. A sentence over twenty-five words is a candidate for splitting. Sentence length is not a style preference — it is a readability factor.

Eliminate filler. “In order to” is almost always “to.” “Due to the fact that” is “because.” “At this point in time” is “now.” These fillers feel formal; they communicate nothing and obscure the sentence’s meaning by making the reader work to find it.

What plain language is not

Plain language is not a ban on technical terminology. When writing for an audience that knows a technical domain, using the correct terminology is clearer than a layperson’s paraphrase. A developer does not benefit from “the piece of code that runs first when the page loads” when “entry point” is unambiguous and precise.

Plain language is also not a requirement for short content. Long articles can be written in plain language. Complex subjects can be covered clearly. The goal is not brevity — it is that every word earns its place. Long-winded writing uses many words to say little. Plain writing uses the words the meaning requires, and no more.

The readability test

The practical test for plain language is reading aloud. If a sentence sounds unnatural when spoken, it will be unnatural when read. If you would not say it in a conversation, you should not write it in an interface. This rule catches the most common plain language violations: passive voice, nominalisations (turning verbs into nouns — “make a determination” instead of “decide”), and convoluted sentence structures.

A secondary test is the substitute question: what would I say if I had to tell this to a colleague verbally? The verbal version is usually the plainer version. Write that.

Plain language as respect

The best argument for plain language is not efficiency — it is respect. Readers come to your interface with a task to accomplish. Obscure language increases the cognitive load of their task, often not because the content is complex but because the writing is unnecessarily complicated. Plain language says: I value your time and I’ve done the work to make this easy to understand.

That work is not small. Clear writing is hard. As Pascal reportedly observed, he did not have time to write a short letter, so he wrote a long one instead. Plain language requires the discipline to cut the words that are there for comfort or habit, and leave only what is needed.

Plain language and brand voice can pull in opposite directions: clarity demands the simplest possible expression; voice sometimes requires personality that complicates that clarity. The Conflict Matrix covers when each wins.

Continue to sentence and paragraph structure — how to organise prose so each unit of content does one clear job.