Plain language: how to write so everyone understands

Plain language is often mistaken for short words and a friendly tone. The International Plain Language Federation offers a more useful definition: a communication is in plain language if its wording, structure and design are so clear that the intended readers can easily find what they need, understand what they find and use that information.¹

Three things follow from that definition. It is about the intended readers, so the same text can be plain for engineers and unclear for farmers. It covers structure and design as well as words. And it is measured by what readers can do afterwards. The Federation notes that this definition forms the basis of the plain language standard published by the International Organization for Standardization (ISO) in 2023.¹

For organisations that serve the public, unclear writing has real costs: forms filled in wrongly, calls to helplines, advice that is not followed and reports that nobody finishes. GOV.UK makes plain English mandatory for all of its content, explaining that many people who need to read it will struggle unless language is kept simple.²

Plain language also respects readers who use English as a second or third language, which in East Africa is often most of your audience. Australia's government Style Manual notes that common, simple words help people with low literacy, people with disability and people who speak English as a second language.³ In Rwanda, where documents often move between Kinyarwanda, English and French, plain source text also translates more accurately.

The most common objection is that plain language will make technical work look simplistic to donors, ministries or academic partners. The evidence points the other way. GOV.UK reports that people with higher levels of literacy prefer plain English, and that specialists who can understand complex language do not want to read it if there is an alternative.²

Usability research by Nielsen Norman Group with domain experts in science, technology and medicine found that even highly educated readers want succinct information that is easy to scan.⁴ It recommends writing at about a 6th to 8th grade reading level for general audiences and a 10th to 12th grade level for specialists, and notes that no one has ever complained that a text was too easy to understand.⁴

Most plain English writing guidance agrees on a short set of habits. Australia's Style Manual advises using everyday words that most people understand, aiming for an average of about 15 words per sentence, and preferring the active voice because it is more direct and often shorter.³ GOV.UK suggests splitting sentences over 25 words and not using formal or long words when easy or short ones will do.²

Jargon needs special care in development work, where acronyms and sector terms pile up quickly. Digital.gov distinguishes jargon, which it describes as complicated language used to impress rather than inform, from necessary technical terms.⁵ Its advice is to substitute everyday language as often as possible and, where a technical term is unavoidable, to define it where you use it rather than in a long glossary.⁵

• Write "we will" and "you must", not "it is envisaged that".
• Use verbs, not nouns made from verbs: "decide", not "take a decision on".
• Spell out an acronym the first time and ask whether you need it at all.
• Use the same term for the same thing throughout.

Good words cannot rescue a document in the wrong order. Digital.gov advises putting the most important information at the beginning, starting with your purpose and bottom line, and placing background information towards the end when it is needed at all.⁶ It also recommends presenting process steps in the order the reader will follow them, and putting general information before exceptions and conditions.⁶

Ask what questions your reader will have, then answer them in that order under clear, descriptive headings. For long reports, Digital.gov recommends a table of contents that works as a reliable roadmap so readers can find what they need quickly.⁶ In our own practice, we often turn the key questions into headings in summaries and briefs, because readers scan for their own question first.

You cannot judge your own writing as a newcomer would. Digital.gov's guide to testing for understanding describes paraphrase testing, where individual readers explain a short text in their own words, and usability testing, where they try to find and use information in a longer document or website.⁷ It advises planning to test at least twice, revising between rounds.⁷

Testing does not need a laboratory. A handful of people from the actual audience, a printed page and a few open questions such as "What would you do next?" will often reveal problems the writer could not see. Readability scores can flag long sentences, but only readers can tell you whether they understood and could act.

Plain language lasts when it becomes a habit rather than a one-off edit. Agree a short set of rules, add them to your house style, and give writers examples from your own documents of before and after. Ask reviewers to comment on clarity as well as content, and make sure senior staff see plain summaries as a strength, not a shortcut.

Start with the documents people use most: application forms, community notices, web pages and executive summaries. These are where unclear writing costs most and where improvements are easiest to see. Then work outwards to the longer reports, keeping the same test for every page: could the intended reader find what they need, understand it and act on it?

• Know who your intended readers are and what they need to do
• Most important information and the bottom line first
• Clear, descriptive headings that match readers' questions
• Everyday words, with technical terms defined where used
• Sentences averaging about 15 words, none over 25 without good reason
• Active voice, "you" and "we"
• Acronyms spelled out or removed
• Tested with real readers at least twice