Plain Language Writing Specification
1. What this document is for
This specification sets a default standard for writing that people can understand the first time they read it.
Use it for:
- public or civic education content
- how-to pages and documentation
- reference text that will be reused (including by automated systems)
This spec does not replace subject-matter review. It defines how to present correct information in a way that is usable.
2. What “plain language” means here
Plain language means the writing is:
- clear (the reader can tell what you mean)
- concise (you do not waste their time)
- well organized (they can find what they need)
- appropriate to the audience (you do not assume hidden knowledge)
Plain language does not mean you remove complexity. It means you make complexity navigable.
3. Default assumed audience
Unless a page says otherwise, assume this audience:
An adult reader with general literacy, no specialized background in the topic, and a practical reason for reading.
This audience may be distracted, stressed, or short on time. Write accordingly.
3.1 When you must declare a different audience
You MUST declare a different audience when any of these are true:
- the reader must already know a technical framework
- the reader’s role changes what they need to do (for example, applicant vs. administrator)
- the page is written for a specific community with shared vocabulary
- the page is meant to train a specialized user group
When you declare a different audience, you MUST also change your writing to match that audience.
3.2 How to declare a different audience
If a page is not for the default audience, it MUST include an “Assumed audience” section near the top that answers:
- Who is this for?
- What are they trying to do?
- What do they already know?
- What terms will you define?
Keep it short. Do not turn it into a biography.
4. The page contract
Every page MUST make these things obvious:
- What this page is about.
- Who it is for.
- What the reader will get from it.
- What the reader should do next (if anything).
This should be clear by the end of the first screen on a phone.
5. Structure and ordering
5.1 Put the point first
You MUST state the main point early.
- If the page is informational, the main point is the takeaway.
- If the page is procedural, the main point is what the reader needs to do.
- If the page is explanatory, the main point is what the reader will understand.
Do not start with history, context, or philosophy unless the reader cannot proceed without it.
5.2 Order information by reader need
You MUST put information in this order unless you have a strong reason not to:
- The outcome or answer.
- The steps or requirements.
- Examples and common cases.
- Exceptions and edge cases.
- Background and rationale.
If you lead with exceptions, readers will misapply them.
5.3 One purpose per section
Each section MUST have one job. If a section answers two different questions, split it.
5.4 Use headings as navigation
Headings are not decoration. They are the table of contents.
Headings MUST be specific and useful on their own. Prefer:
- question headings (“Who qualifies?”)
- task headings (“Apply in three steps”)
- statement headings (“You must submit these documents”)
Avoid vague headings like “Overview,” “General,” or “Information” unless they are followed immediately by a specific subheading.
6. Sentences and paragraphs
6.1 Keep sentences straightforward
A sentence MUST express one main idea.
You MUST NOT stack conditions and exceptions into a single long sentence when you can split it.
If you need “if,” “unless,” “except,” and “however” in the same sentence, rewrite.
6.2 Keep paragraphs short
A paragraph SHOULD cover one idea.
If a paragraph runs longer than 5–7 lines on a phone screen, consider splitting it.
6.3 Use active voice when responsibility matters
When it matters who does what, you MUST name the actor.
Prefer:
- “You must submit the form by Friday.”
- “We will email you within 10 business days.”
Avoid:
- “The form must be submitted by Friday.”
- “A response will be provided.”
Passive voice is allowed when the actor is unknown or irrelevant. Do not use it to hide responsibility.
6.4 Prefer verbs over abstract nouns
Prefer direct verbs and concrete nouns.
Avoid turning actions into vague nouns, such as:
- “make an application” instead of “apply”
- “conduct an assessment” instead of “assess”
- “provide assistance” instead of “help”
7. Word choice and terminology
7.1 Use familiar words
Prefer common words over official-sounding words.
If you can say the same thing in fewer, more familiar words, do it.
7.2 Define necessary technical terms once
You MAY use technical terms when they are necessary to be accurate.
If you use a technical term, you MUST:
- define it the first time you use it
- use it consistently afterward
Do not rotate synonyms for style. Repetition helps comprehension.
7.3 Avoid acronyms by default
You SHOULD avoid acronyms when writing for the default audience.
If you must use an acronym, you MUST define it on first use and then use it consistently.
If the acronym is not needed, remove it.
7.4 Avoid “noun stacks”
Noun stacks are strings of nouns used as adjectives.
If a noun stack has more than three words, you SHOULD rewrite it.
Instead of:
- “benefits eligibility determination process”
Prefer:
- “how we decide if you qualify for benefits”
8. Lists, tables, and examples
8.1 Use lists for steps and requirements
Use a numbered list for steps in order.
Use a bullet list for requirements, options, or items without a required order.
Lists MUST have parallel structure. Do not mix sentence fragments and full sentences in the same list unless you have a good reason.
8.2 Use tables for “if this, then that”
Use a table when readers need to match conditions to outcomes.
Tables SHOULD be simple:
- clear headers
- short cells
- no nested tables
If a table is complex, consider splitting it into multiple tables.
8.3 Use examples to support decisions
If the reader must decide what applies to them, you SHOULD include examples.
Examples MUST be realistic and typical. Label them clearly as examples so readers do not mistake them for requirements.
9. Links and references
9.1 Links support the page, they do not replace it
You MUST write the key information on the page itself.
Do not force the reader to click away to learn essential requirements, definitions, deadlines, or constraints.
9.2 Use descriptive link text
Link text MUST describe where the link goes.
Avoid “click here,” “read more,” or bare URLs.
9.3 Limit cross-references
You SHOULD avoid sending the reader through multiple pages to complete a simple task.
If the reader must follow a chain of pages, add a short “Where to start” section with the correct sequence.
10. Tone and trust
10.1 Be direct and honest
Do not oversell. Do not threaten. Do not perform friendliness.
Say what is true:
- what you know
- what you do not know
- what the reader can expect next
10.2 Avoid rhetorical filler
You MUST NOT add:
- dramatic openings
- inspirational language
- vague promises (“This changes everything”)
- unnecessary metaphors
If you need a metaphor to explain a concept, keep it short and test it with real readers.
11. Designing for accessibility
11.1 Write for scanning
Most people scan before they read.
You SHOULD:
- use short sections
- use headings that match user questions
- keep key terms visible and repeated
- place critical information near the top
11.2 Support assistive technologies
You MUST avoid structures that screen readers handle poorly:
- overly complex tables
- headings used only for styling
- text embedded in images
If an image contains essential information, you MUST provide the same information in text.
11.3 Respect cognitive load
When the topic is high stress (health, safety, legal, money), assume reduced attention.
In these cases, you SHOULD:
- keep instructions explicit
- use short steps
- repeat critical requirements
- include a summary
12. Testing and revision
Testing is part of writing.
12.1 When testing is required
A page MUST be tested before publication if it involves any of these:
- legal obligations
- financial eligibility or payments
- medical or safety guidance
- deadlines with consequences
- processes that readers frequently get wrong
12.2 A simple paraphrase test
Use this when you want to know if readers understand your meaning.
Protocol:
- Ask a reader to read a section.
- Ask them to explain it in their own words.
- Do not correct them while they explain.
- Record misunderstandings.
- Revise the text to remove the misunderstanding.
- Repeat with a new reader.
Six to nine readers will reveal most major problems.
12.3 A simple task test
Use this when the page asks readers to do something.
Protocol:
- Give the reader a realistic task.
- Watch them use the page to complete it.
- Note where they hesitate, re-read, or fail.
- Revise structure first, then wording.
- Repeat.
12.4 Comparative testing
Use this to compare two versions at the end.
Comparative testing can tell you which version works better. It will not reliably tell you why. Use paraphrase or task tests to learn why.
13. Publication checklist
Before publishing, confirm:
- The first screen says what the page is, who it is for, and what it helps with.
- The main point comes before exceptions.
- Headings are specific and form a clear hierarchy.
- Sentences are short enough to read easily.
- Responsibility is clear where it matters.
- Technical terms are defined once and used consistently.
- Lists and tables are used when they improve scanning.
- Links support the page rather than replacing it.
- The page has been tested when impact is high.
- The page does not rely on rhetorical filler.
14. Notes for durable reuse
This spec is meant to remain usable even if external guidance pages move or disappear.
When you adapt this spec, keep changes explicit:
- record what changed
- record why it changed
- record when it changed