The English Tutorial Lesson No.0051 | From Complex to Clear — Plain Language, Jargon Control, Readability, Accessibility, Frontloading and User-Centred Writing

English Tutorial Lesson No.0020 · English Tutorial Lesson No.0045 · English Tutorial Lesson No.0048

Part I — What plain language is

1. Plain language begins with user need

The Office for National Statistics writing guidance starts from the user’s task: what does the reader need to know or do? That question changes writing before vocabulary is touched. A page for someone downloading data should make the download route visible. A notice about a deadline should state the deadline early.

Plain language therefore begins with prioritisation, not synonym replacement. If the writer includes five pages of accurate but irrelevant background before the answer, the content remains difficult even if every sentence is short.

User need is the governing criterion.

2. Plain language is not baby language

Experts also benefit from clear writing because expertise does not eliminate time pressure or working-memory limits. ONS guidance notes a strong preference for plain language even among specialist users, particularly when the issue is complex.

The goal is not to remove concepts the reader needs. It is to remove unnecessary linguistic friction around those concepts.

Complexity should remain where the subject is genuinely complex.

3. Plain language is not merely short sentences

Short sentences can still be vague, badly ordered or conceptually dense. Long sentences can be clear when relationships are well controlled.

Sentence length is one tool among many: information order, familiar vocabulary, explicit actors, stable terminology, headings and examples also matter.

Readability emerges from the system, not one metric.

4. Plain language is not casual language

A legal notice, scientific report or professional email can be formal and plain simultaneously. Formality concerns social register; plainness concerns accessibility and cognitive effort.

“Applicants must submit the signed form by 5 p.m. on 17 September” is formal and clear. “Submission of duly executed documentation is mandated prior to the stipulated temporal deadline” is formal and unnecessarily difficult.

Precision does not require ceremony.

5. Plain language is not loss of precision

If a technical term carries an exact meaning, keep it and explain it. Replacing precise terms with vague familiar words can make the text easier to read and less accurate.

The goal is accurate understanding. Sometimes the plainest sentence includes one necessary specialist term plus a clear definition.

Clarity and precision should reinforce each other.

6. Plain language is an accessibility practice

Clear headings, predictable structure, descriptive links and straightforward sentences help readers with cognitive, visual and language-access needs. Home Office accessibility guidance treats semantic headings as navigation aids, including for screen-reader users.

Accessibility is broader than plain language, but the two overlap strongly.

Writing choices affect who can use information independently.

Part II — User-centred writing

7. Define the reader by task, not stereotype

“General public” is too broad. A better user description is “parents trying to find the registration deadline” or “students checking whether a source is acceptable”.

Task-based audience definitions help decide what information belongs first.

User stories convert abstract audience into action.

8. Ask what the reader already knows

Experts need less background but may still need definitions for unfamiliar institutional terms. Novices need orientation but not every historical detail.

Do not assume knowledge merely because a term is common inside the writer’s organisation.

Expertise is domain-specific.

9. Ask what the reader needs next

After the first paragraph, what decision or action follows? The writing should support that next step.

This creates reader-centred sequence.

Information architecture becomes practical.

10. Separate reader need from writer interest

Writers know many fascinating details. Not all deserve publication on every page.

ONS content guidance emphasises prioritising user needs rather than telling users everything.

Relevance is a plain-language skill.

11. Use real questions from users

Support emails, teacher questions, search terms and observed confusion can reveal what readers actually struggle with.

Design headings and explanations around those needs where appropriate.

Plain language improves through evidence about users.

12. Test assumptions about users

Acronyms and internal terms may feel obvious to the writer. Ask a first-time reader to explain them.

If the reader must guess, define or replace.

Expert blindness is a major source of unclear writing.

Part III — Frontloading

13. Put the main answer early

Online readers often scan and may not reach late sections. ONS guidance recommends frontloading important information.

If the page answers “When do applications close?”, state the deadline before institutional history.

Priority should be visible in position.

14. Frontload headings too

“Download the dataset” is more task-oriented than “Dataset”. “Apply for financial support” is clearer than “Financial Support Applications”.

Starting with the reader’s action improves scanning.

Headings are navigation commands.

15. Frontload calls to action with verbs

Download, submit, contact, check, read, compare. Verbs tell users what they can do.

Noun-heavy labels often hide action.

Microcopy benefits from strong verbs.

16. Frontload the condition when it determines relevance

“If you are under 18, ask a parent or guardian to…” tells readers immediately whether the instruction applies.

Do not make people read a full paragraph before learning it is irrelevant.

Conditional relevance can be frontloaded.

17. Frontload exceptions when consequences are high

If one group must follow a different deadline or process, surface the exception early enough to prevent wrong action.

Plain language is not only about sentence ease; it is about decision safety.

Important exceptions deserve visibility.

18. Frontload conclusions in executive writing

Decision-makers may need recommendation, evidence and implications before methodological detail.

Technical support can follow.

Reader route determines order.

Part IV — Jargon control

19. Jargon is not automatically bad

Specialist terms can compress complex concepts among knowledgeable readers. The problem occurs when jargon exceeds audience knowledge or hides simple actions.

Ask whether the term is necessary for precision or merely customary inside the organisation.

Jargon should earn its place.

20. Replace unnecessary jargon with ordinary words

Use instead of utilise when no technical distinction exists. Before instead of prior to. Help instead of facilitate where meaning is unchanged.

Short familiar words reduce decoding cost.

Plain does not mean informal.

21. Keep necessary technical terms and define them

If learners need the concept nominalisation, name it and explain: turning a verb or adjective into a noun, such as decide → decision.

Removing the term entirely can block later learning.

Definition creates access.

22. Explain terms at first use

Do not make readers search a glossary before they can understand the sentence.

Provide a short local definition, then use the term consistently.

Just-in-time explanation supports flow.

23. Use glossaries for dense domains

When many technical terms recur, a glossary provides re-entry and search support.

Do not use a glossary as permission to make every sentence jargon-heavy.

Reference tools supplement clear prose.

24. Expand acronyms at first use

Write the full term and acronym, then use the acronym if repetition justifies it.

ONS guidance recommends avoiding assumptions that internal abbreviations are known externally.

Acronyms trade space for memory.

25. Too many acronyms create a decoding system

A paragraph with five abbreviations becomes a memory test.

Use the full term if the acronym appears only once or twice.

Writer convenience should not dominate reader effort.

26. Internal organisation language needs translation

Team names, programme codes and bureaucratic labels may matter to staff and mean nothing to users.

Lead with the public-facing function; include internal labels only where necessary.

Plain language crosses institutional boundaries.

Part V — Sentence design

27. Use active voice when it makes the actor clear

ONS guidance recommends active voice where possible because it tends to shorten sentences and clarify responsibility.

“The school will email your result” is clearer than “Your result will be emailed” when the actor matters.

Active voice is a tool, not a law.

28. Passive voice can be plain when actor is irrelevant

“The samples were stored at 4°C” may be clearer in a scientific method because the process matters more than the researcher.

Do not convert every passive mechanically.

Information focus governs voice choice.

29. Put subject and verb close together

Long insertions between actor and action increase processing load.

“The committee, after months of consultation with several departments and external organisations, approved…” can often be split.

Core syntax should remain visible.

30. Use one main relationship per sentence when possible

Long sentences are difficult when they contain several conditions, exceptions and consequences.

Split where relationships can stand independently.

Do not split so aggressively that causal links disappear.

31. Avoid noun stacks

“Student performance improvement programme evaluation framework” forces readers to reconstruct relationships.

Use prepositions or clauses: “framework for evaluating the programme to improve student performance”.

English can unpack compressed noun phrases.

32. Reduce nominalisation when it hides action

“Implementation of the revision of the policy was undertaken” becomes “The team revised and implemented the policy.”

Verbs reveal action and actor.

Nominalisation remains useful when concepts need to become objects of discussion.

33. Put conditions near the action they govern

“Submit the extra form if you changed address” is easier than separating the condition by several clauses.

Locality reduces working-memory load.

Sentence architecture can support action.

34. Use parallel structure for parallel ideas

“Check the source, verify the date and record the URL.” Parallel grammar helps readers see the list as one category.

Broken parallelism adds unnecessary processing.

Structure can signal relationship.

Part VI — Paragraph design

35. One paragraph should have one main job

ONS editing guidance recommends one topic per paragraph. For complex writing, “topic” is better understood as one local purpose.

When a paragraph defines a term, gives a history, states an exception and issues an instruction, readers struggle to predict its direction.

Paragraph boundaries should reflect conceptual shifts.

36. Put the main point early

Online readers scan. A paragraph that begins with background and reveals the key message in sentence six may lose them.

Lead with the claim or action, then explain.

Frontloading works at paragraph scale.

37. Keep supporting detail subordinate

Examples, qualifications and evidence should support the main point rather than compete with it.

If an example grows into a new argument, give it a new paragraph.

Hierarchy supports comprehension.

38. Use short paragraphs online when the logic permits

Mobile screens make dense paragraphs feel longer. Break at genuine idea boundaries.

Do not produce one-sentence paragraphs merely for visual effect everywhere.

Conceptual structure should drive layout.

39. Paragraph transitions should name relationships

However is useful only when the next idea genuinely contrasts. Avoid decorative connectors.

Plain writing makes the logic itself clear.

Transition words cannot manufacture coherence.

40. Examples should be close to the concept

Readers should not have to remember a definition across several paragraphs before seeing an example.

Use local illustration.

Concrete support reduces abstraction load.

Part VII — Headings and scanning

41. Headings are navigation, not decoration

Home Office accessibility guidance notes that clear, semantically structured headings help users navigate, including screen-reader users and readers who struggle with dense text.

Headings should describe the content beneath them.

Navigation is part of comprehension.

42. Keep headings short and relevant

A heading should let readers predict the section quickly.

Move nuance into the first sentence.

Scanning should remain fast.

43. Use semantic heading levels

Do not choose heading styles merely for visual size. Heading levels represent hierarchy.

Assistive technologies use this structure.

Formatting has meaning.

44. Avoid skipped hierarchy where possible

Jumping from a major heading directly to a deeply nested level can make structure confusing.

Use a consistent outline.

Visual and logical hierarchy should align.

45. Frontload heading keywords

Put the task or concept early: “Apply for support” rather than “Support: how to apply”.

This helps scanning and search.

Readers often see only the first words.

46. Avoid clever headings that hide the topic

“A Road Through the Fog” may sound elegant and fail readers looking for “How to verify a source”.

Creative language can appear inside the section.

Findability usually outranks wit.

Part VIII — Lists and tables

47. Use bullets for parallel information

Bullets work for options, criteria, examples and short non-sequential items.

Each item should be grammatically parallel where possible.

Lists make category structure visible.

48. Use numbered lists for sequence

If order matters, numbers communicate dependency better than bullets.

Do not number items merely because there are several.

List type should encode relationship.

49. Keep lead-ins meaningful

“You will need:” prepares the reader for materials. “Important points include:” may be too vague.

Lead-ins should name the list’s function.

Lists need context.

50. Avoid lists inside lists unless hierarchy is real

Deep nesting can become harder to scan than prose.

Use headings or tables when relationships become complex.

Representation should simplify.

51. Use tables for genuine comparison

Rows and columns work when items share dimensions. A table can clarify eligibility criteria, options or before/after states.

Do not force complex prose into tiny cells.

Tables are relational tools.

52. Provide textual context around tables

Explain what readers should notice and how the table is organised.

Accessibility may require captions and structured headers.

Visual structure should be interpretable.

Part IX — Readability and its limits

53. Readability formulas measure proxies

Many formulas use sentence length and word length. They can identify dense prose but cannot determine conceptual clarity, accuracy or audience fit.

A short sentence with unexplained jargon can be harder than a longer clear sentence.

Scores are signals, not verdicts.

54. Do not write to game a readability score

Splitting every sentence and replacing precise terms with vague short words may raise a numerical score while damaging quality.

Use metrics alongside human review.

Comprehension is the real target.

55. Technical terms can inflate scores unfairly

Necessary multisyllabic terms make text appear more difficult by formula. Keep them when readers need them and explain clearly.

Domain knowledge matters.

Metrics lack full context.

56. Short sentences can still overload concepts

“Inflation fell. Real wages rose. Monetary policy tightened.” Each sentence is short; a novice may still need definitions and relationships.

Plain language includes conceptual scaffolding.

Syntax is only one layer.

57. Longer sentences can clarify relationships

“Although prices continued to rise, the rate of increase slowed” expresses contrast efficiently.

Splitting into two sentences may require another connector anyway.

Use length as a design choice.

58. Read aloud to find friction

ONS editing guidance recommends reading aloud to catch complexity. Breathlessness, repeated nouns and buried verbs become audible.

Then revise the cause rather than applying arbitrary sentence limits.

Sound can support editing.

Part X — Active voice and responsibility

59. Active voice names responsibility

“We will reply within five days” tells users who acts.

Passive “A reply will be provided” may sound less accountable.

Actor visibility matters in service content.

60. Passive voice can protect focus appropriately

“The application is reviewed in two stages” may be suitable if the review process matters more than the staff role.

Plain language is not ideological about grammar.

Use the voice that makes the important relationship easiest to understand.

61. Passive voice can hide blame

“Errors were made” omits who made them. Sometimes that is deliberate rhetoric.

Critical readers should ask whether actor omission matters.

Plain language also supports accountability.

62. “We” and “you” can simplify relationships

Government and service guidance often addresses users directly: “You can apply…” “We will contact you…”

This makes actor and action explicit.

Use direct address when tone and context permit.

Part XI — Information density

63. Dense noun phrases slow decoding

Academic and bureaucratic writing compresses relationships into nouns. Unpack where the audience benefits.

“Post-submission eligibility verification requirements” becomes “What we check after you submit”.

Function can replace compression.

64. Dense abstraction needs examples

“Institutional resilience” may be necessary. Follow with a concrete case showing what counts as resilience in this document.

Abstract language becomes usable through examples.

Plain language supports concept formation.

65. Numbers can increase or reduce density

“About one in four” may be more intuitive than “24.7%” for some public contexts. In technical reporting, exact percentage may be necessary.

Choose representation according to audience and purpose.

Numerical plainness is contextual.

66. Parentheses can overload sentences

Multiple asides interrupt the main route. Move essential information into the sentence and non-essential detail elsewhere.

One pair of parentheses can be useful.

Layering should not fracture flow.

67. Footnotes can preserve depth without blocking flow

Specialist caveats or references may sit in notes where genre allows.

Do not hide information essential to safe action in a footnote.

Information priority governs placement.

68. Layered information supports mixed audiences

Summary first, details later, technical appendix where needed.

Readers can choose depth.

Plain language does not require one flat level.

Part XII — Consistent terminology

69. Use one term for one concept

ONS guidance emphasises consistent language because interchangeable terms can confuse users. “Children”, “young people” and “students” may refer to different populations.

Choose canonical wording.

Consistency reduces interpretive load.

70. Synonym variety can harm instructions

Calling the same button “Submit”, “Send” and “Complete” makes readers wonder whether they are different actions.

Procedural content values lexical stability over style variation.

Repeated key words can be good writing.

71. Definitions should remain stable

If “eligible applicant” is defined early, do not subtly change the category later.

Update the definition explicitly if needed.

Conceptual drift undermines trust.

72. Terminology can be audience-layered

“Heart attack (myocardial infarction)” gives ordinary and technical terms together.

Later specialist sections may use the technical term.

Layered vocabulary supports learning.

Part XIII — Links and calls to action

73. Link text should describe destination

“Read the eligibility criteria” is more useful than “click here”.

Screen-reader users often navigate links out of surrounding context.

Descriptive links support accessibility.

74. Calls to action should use clear verbs

Download, register, compare, contact, submit. Avoid vague labels such as “More” when the action is known.

Readers should predict consequence before clicking.

Microcopy is part of plain language.

75. Do not overload paragraphs with links

Every link creates a possible exit. Keep essential routes and sources.

Link density affects attention.

Navigation should support the user’s task.

76. External links need context

Tell readers when a link leaves the site or opens an authoritative source where relevant.

They should know why they are being sent elsewhere.

Links should have jobs.

Part XIV — Accessibility and inclusive content

77. Semantic headings help screen readers

Heading hierarchy allows assistive technology users to navigate sections. Visual bold text is not a substitute.

Content structure should be encoded as structure.

Accessibility begins in authoring.

78. Alt text should communicate image purpose

Describe information needed for the task rather than every visual detail.

Decorative images may need empty alt text under appropriate web standards.

Image accessibility is contextual.

79. Do not rely on colour alone

If red means “required”, add text or symbol. Colour-vision differences and monochrome printing can erase the signal.

Redundant cues improve robustness.

Important distinctions need more than colour.

80. Use descriptive labels for form fields

Persistent labels help users remember what information is required.

Placeholder text alone may disappear.

Forms are reading environments.

81. Error messages should explain repair

“Enter a date in DD/MM/YYYY format” is more useful than “Invalid”.

Plain language supports recovery.

Accessibility includes error states.

82. Link purpose should be clear without surrounding prose

Assistive technology may present a list of links. Repeated “read more” links become indistinguishable.

Name the destination.

Context should travel with the link.

83. Avoid unnecessary idioms in high-access content

Idioms can confuse multilingual readers and literal interpreters.

Use transparent wording when broad comprehension matters.

Figurative language is a choice, not default quality.

84. Cultural references need context

A local joke or institution may be obvious to one audience and opaque to another.

Explain where necessary.

User-centred writing anticipates knowledge differences.

Part XV — Technical and scientific writing

85. Simplify language, not method

A scientific explanation can keep sample size, uncertainty and method while using clearer sentences.

Do not remove caveats merely because they are difficult.

Accuracy remains the floor.

86. Define technical concepts through category and distinction

“A confidence interval is a range calculated from sample data under a statistical method…” can then be expanded according to level.

Definitions should not rely on equally difficult jargon.

Technical plain language requires conceptual work.

87. Use examples after definitions

An example can show how the term functions, but should not replace the definition where precision matters.

Readers need both concept and case.

Layered explanation supports understanding.

88. Keep uncertainty visible

Plain-language summaries often become overconfident because caveats are removed.

Translate uncertainty; do not delete it.

“The study suggests” may be plain and accurate.

89. Explain units and denominators

Public-facing statistics need enough context for readers to interpret magnitude.

“5 cases per 100,000 people” is clearer than “rate 5”.

Plain data language needs context.

90. Use charts when they reduce text burden

A simple chart can show trend more efficiently than a paragraph of numbers.

Provide accessible textual interpretation and source.

Mode choice supports clarity.

Part XVI — Legal and policy language

91. Plain language can coexist with legal accuracy

Legal obligations may require precise terms. Explain them rather than replacing them inaccurately.

Public guidance can place plain-language explanation beside formal wording.

Layering preserves both accessibility and authority.

92. Separate legal rule from explanatory guidance

Readers should know which text is legally controlling and which is an explanation.

Do not let simplified paraphrase silently replace authoritative wording when stakes are high.

Source status matters.

93. Name actors and obligations

Who must do what by when? Legalistic passive chains often hide responsibility.

Plain summaries can foreground actor, action, condition and consequence.

Obligation should be findable.

94. Define exceptions locally

If a rule has important exceptions, place them near the relevant summary or link clearly to them.

Over-simplified rules can mislead.

Plain language must preserve scope.

Part XVII — Educational writing

95. Instructions should be simpler than the learning task

Do not make a complex comprehension exercise harder with complex instructional sentences.

Use clear action verbs and sequence.

Cognitive challenge should live in the target skill.

96. Explanations should move from known to new

Connect unfamiliar concepts to prior knowledge, then introduce technical vocabulary.

Plain language supports conceptual bridges.

It is not merely editing after the fact.

97. Worked examples should expose the decision

Do not simply show the final answer. Explain the key move in clear language.

Readers learn process, not only product.

Clarity supports transfer.

98. Feedback should identify next action

“Unclear” is weak feedback. “Name the source before using ‘this’ in sentence three” is actionable.

Plain feedback is specific.

Learning improves when language controls behaviour.

Part XVIII — Multilingual and global audiences

99. Plain English helps multilingual readers

Transparent vocabulary, explicit subjects and consistent terminology reduce unnecessary decoding.

This does not mean avoiding all advanced vocabulary.

Teach necessary terms with context.

100. Avoid culture-bound idioms where broad access matters

“Move the goalposts” or “ballpark figure” may be familiar to some readers and opaque to others.

Use literal wording unless the idiom adds real value.

Global communication rewards transparency.

101. Sentence structure can create translation difficulty

Nested clauses, ambiguous pronouns and noun stacks are harder for both humans and machine translation.

Clear source text supports downstream translation.

Plain language can improve multilingual pipelines.

102. Do not erase local terms when they are precise

A local institutional term may be the correct noun. Define it for external readers.

Global plain language is not cultural flattening.

Precision can remain local.

Part XIX — Numbers, dates and time

103. Use concrete dates where ambiguity matters

“Next Friday” can age badly in durable content. Use exact dates for deadlines.

Relative dates work in live contexts with shared time.

Temporal clarity is user-centred.

104. Use consistent date formats

International readers may interpret 03/04 differently. Spell months where ambiguity matters.

Follow local style where appropriate.

Consistency reduces error.

105. Put units with numbers

“10” is not meaningful without minutes, dollars, kilograms or percentage.

Keep units visible.

Numbers need language context.

106. Explain percentages with bases when needed

“50% more” can sound dramatic. Provide original values if readers need magnitude.

Plain language includes quantitative context.

Clarity prevents statistical rhetoric from misleading.

Part XX — Plain-language editing workflow

107. First pass: user need

Delete or move information that does not serve the page’s main user task.

Do not start with word-level edits.

Structural relevance produces the largest gains.

108. Second pass: frontloading

Move key answer, action or conclusion earlier.

Check every major section.

Important information should not be buried.

109. Third pass: structure

Give sections clear headings and paragraphs one job.

Reorder by reader need.

Architecture supports comprehension.

110. Fourth pass: jargon and terminology

Replace unnecessary terms, define necessary ones and make terminology consistent.

Build a glossary only if useful.

Vocabulary becomes managed.

111. Fifth pass: sentence design

Find buried verbs, noun stacks, ambiguous pronouns and overloaded clauses.

Rewrite without changing meaning.

Syntax should expose relationships.

112. Sixth pass: actions and links

Check calls to action, deadlines, form labels and link text.

Can readers predict what happens next?

Plain language is operational.

113. Seventh pass: accessibility

Heading hierarchy, alt text, colour reliance, link purpose, labels.

Use relevant accessibility standards.

Clarity should work across access modes.

114. Eighth pass: factual and technical accuracy

Confirm that simplification did not change scope, obligation or uncertainty.

Subject experts may need to review.

Plain language must remain true.

Part XXI — Testing with users

115. Ask readers to find, not admire

Instead of “Is this clear?”, ask “When is the deadline?” “What do you do if the form fails?”

Successful retrieval is stronger evidence than general approval.

User tests should mirror tasks.

116. Observe where readers hesitate

Pauses, rereads and wrong clicks reveal friction.

Do not explain immediately; record the failure first.

Behaviour is evidence.

117. Ask readers to paraphrase

Can they explain the rule in their own words without changing meaning?

Paraphrase reveals hidden misunderstanding.

Comprehension becomes observable.

118. Test with intended audiences

Colleagues who know the jargon may not reveal novice problems.

Include representative users where possible.

Expert review and user review answer different questions.

119. Test on mobile where mobile use matters

ONS research highlights substantial mobile access and different scanning patterns. Dense content can become harder on small screens.

Device context belongs in testing.

Plain language interacts with medium.

120. Test recovery from errors

Do not test only ideal paths. Give users a wrong form entry or missed step and see whether the content helps them recover.

Error states reveal clarity.

Usability includes failure.

Part XXII — Primary progression

121. Primary 3–4: clear sentence rewriting

Give a long teacher-written sentence and ask children to split or reorder it without losing meaning.

Focus on subject, verb and action.

Clarity can be taught early.

122. Primary 3–4: familiar versus unfamiliar words

Compare “purchase” and “buy”, “commence” and “start”. Discuss when each might appear.

Do not teach that long words are bad.

Word choice depends on function.

123. Primary 5–6: user-centred notices

Students rewrite a school notice so deadline, place and action appear early.

Classmates test whether they can find information quickly.

Plain language becomes practical.

124. Primary 5–6: glossary design

Choose three necessary subject terms and explain each in one sentence plus example.

Technical vocabulary becomes accessible without disappearing.

Definition is a skill.

Part XXIII — Secondary progression

125. Secondary 1–2: jargon audit

Students highlight terms an outsider may not know. They classify necessary technical term, replaceable jargon or acronym.

Then revise.

Audience awareness becomes systematic.

126. Secondary 1–2: frontload a web page

Given a dense page, students move the key answer and task links upward.

They justify the new order from user needs.

Information hierarchy becomes explicit.

127. Secondary 3–4: technical-to-public translation

Rewrite a short scientific or policy paragraph for a general audience while preserving uncertainty and key terms.

Compare with source for lost meaning.

Simplification becomes disciplined.

128. Secondary 3–4: accessibility review

Students audit headings, links, labels and image descriptions on a fictional page.

They learn that clarity includes navigation.

Writing and design interact.

Part XXIV — JC progression

129. JC: explain complex concepts to non-specialists

Students write a 200-word explainer of an advanced concept for an informed public reader.

They must keep one technical term and explain it rather than removing it.

Precision and access are balanced.

130. JC: plain-language abstract

Translate a research abstract into a public summary while preserving population, method, result and limitation.

Then compare sentence by sentence with the source.

Academic literacy becomes mediation.

131. JC: policy summary

Identify who must do what by when and under what conditions.

Separate legal wording from explanatory paraphrase.

High-stakes plain language requires source discipline.

132. JC: data narrative

Explain a chart in plain language without losing denominator or uncertainty.

Use SETC-ETL-0043 principles.

Quantitative clarity transfers.

Part XXV — Common failures

133. Failure: synonym swapping only

Writer replaces hard words but leaves poor order and dense structure.

Repair: return to user need and architecture.

Plain language is not thesaurus work.

134. Failure: oversimplification

Caveats, exceptions or definitions disappear.

Repair: restore necessary precision in clearer form.

Simple but wrong is failure.

135. Failure: short-sentence staccato

Every sentence is tiny. Relationships become implicit and prose feels robotic.

Repair: combine where contrast, cause or condition should be explicit.

Clarity includes connection.

136. Failure: active-voice dogma

Every passive is converted even where actor is irrelevant.

Repair: choose voice by information focus.

Plain language is functional.

137. Failure: jargon purge

Necessary specialist terms disappear, making later discussion less precise.

Repair: define and retain core vocabulary.

Access should support learning.

138. Failure: fake friendliness

Casual jokes and exclamation marks are added to make content “easy”.

Repair: focus on respect, clarity and task.

Tone is separate from plainness.

139. Failure: too many headings

Every paragraph becomes a headed fragment.

Repair: group related material into sections.

Navigation needs hierarchy.

140. Failure: headings as labels only

“Information”, “Details”, “Other”.

Repair: name the user’s question or action.

Headings should predict content.

141. Failure: readability-score worship

Writer removes precise terms to hit a target number.

Repair: test with actual users and preserve technical accuracy.

Metrics support, not govern.

142. Failure: no user testing

Experts declare the text clear because they understand it.

Repair: observe intended users finding and applying information.

Clarity is empirical.

143. Failure: hidden call to action

Reader learns background but cannot find what to do.

Repair: frontload action with verb and deadline.

Content should complete the user task.

144. Failure: inconsistent terms

The same group is called students, learners, candidates and participants without intentional distinction.

Repair: choose canonical language.

Variation can reduce clarity.

Part XXVI — Resident learners

145. Maren writes elegantly but buries the answer

Her introductions build atmosphere before telling readers what they need.

Her intervention is frontloading: answer first, context second, elegance where it helps.

She learns that clarity can still sound good.

146. Iona deletes every technical word

She believes plain language means avoiding advanced vocabulary.

Her intervention is keep-and-define: retain the precise term, explain it, then use it consistently.

Access becomes learning.

147. Leonie trusts readability tools

Her scores improve while meaning gets flatter.

Her intervention is user testing plus source comparison.

Metrics become secondary evidence.

Part XXVII — A 120-minute plain-language tutorial

148. Core studio

1. 10 minutes: identify user and task.
2. 15 minutes: mark key information and current position.
3. 15 minutes: frontload answer and action.
4. 15 minutes: restructure headings and paragraphs.
5. 15 minutes: audit jargon and terminology.
6. 15 minutes: simplify sentences while preserving meaning.
7. 10 minutes: accessibility and link audit.
8. 15 minutes: user test with find-and-use questions.
9. 10 minutes: repair from observed failure.

The final judgement is whether readers can find, understand and act accurately.

Part XXVIII — Practice labs

149. Practice Lab: frontload the deadline

Give a 300-word notice where deadline appears in paragraph four. Students rewrite first 60 words.

Classmates have ten seconds to find required action and date.

Speed becomes evidence.

150. Practice Lab: jargon triage

Highlight twenty specialist terms. Classify as necessary, replaceable or define-once.

Rewrite only after classification.

Jargon control becomes reasoned.

151. Practice Lab: noun-stack repair

Rewrite phrases such as “programme eligibility criteria review process”.

Students identify relationships before rewriting.

Unpacking preserves meaning.

152. Practice Lab: active/passive choice

For ten sentences, choose which voice is clearer and explain why.

No blanket rule allowed.

Grammar becomes user-centred.

153. Practice Lab: technical definition

Explain one technical term to Primary, Secondary and adult specialist audiences.

Keep concept stable while changing support.

Audience adaptation becomes visible.

154. Practice Lab: heading scan

Give headings only. Can readers predict the page and find a task?

Rewrite vague labels.

Navigation is tested without body text.

155. Practice Lab: link-text audit

Replace “click here”, “read more” and bare URLs with descriptive links.

Read the links as a standalone list.

Accessibility becomes practical.

156. Practice Lab: acronym overload

Give a paragraph with eight acronyms. Remove low-value abbreviations and expand necessary ones.

Measure how much memory load falls.

Compression should serve the reader.

157. Practice Lab: mobile rewrite

Take a dense desktop paragraph and restructure for narrow-screen scanning using genuine idea boundaries.

Do not turn it into fragments.

Medium influences presentation.

158. Practice Lab: plain-language data summary

Translate a technical statistical sentence into accurate public language.

Preserve denominator and uncertainty.

Clear data remain truthful.

159. Practice Lab: legal rule plus explanation

Give formal policy wording. Students write a plain explanation and label which text is authoritative.

Compare for scope loss.

High-stakes simplification is disciplined.

160. Practice Lab: error message

Rewrite “invalid input” into actionable guidance.

Test whether a user can recover without external help.

Plain language includes failure states.

161. Practice Lab: form labels

Audit fictional form labels for ambiguity, format and required status.

Another learner completes the form.

User performance tests microcopy.

162. Practice Lab: expert blind spot

An expert writes instructions containing internal acronyms. A novice marks every unknown term.

The expert revises without removing necessary domain concepts.

Audience evidence defeats assumption.

163. Practice Lab: simplify without shortening

Rewrite a 120-word dense paragraph into roughly the same length but clearer structure.

This proves plain language is not merely deletion.

Organisation can create clarity.

164. Practice Lab: shorten without losing

Reduce 200 words to 120 while preserving all decision-critical information.

Mark what was deleted and why.

Concision becomes evidence-based.

165. Practice Lab: user-story rewrite

Write “As a…, I need…, so that…” for a page and restructure content around that task.

Compare with original writer-centred order.

User stories guide architecture.

166. Practice Lab: reading-aloud friction

Read a dense paragraph aloud and mark where syntax becomes hard to track.

Repair causes rather than simply cutting at breaths.

Sound supports editing.

167. Practice Lab: consistency search

Search document for synonyms of one key concept. Decide which are intentional distinctions.

Standardise the rest.

Terminology becomes managed.

168. Practice Lab: accessibility heading tree

List headings by level and inspect hierarchy.

Correct skipped or decorative heading use.

Semantic structure becomes visible.

Part XXIX — Transfer tests

169. Transfer Test: specialist to public

Rewrite a short technical paragraph for general readers.

Subject expert checks accuracy; novice checks comprehension.

Both reviews are required.

170. Transfer Test: public to specialist

Expand a plain summary into a more technical version for experts without making it ceremonious.

Add precision where useful.

Plain language principles still apply.

171. Transfer Test: print to mobile

Adapt a report section for online mobile reading.

Reorder, heading and link decisions change.

Medium changes user behaviour.

172. Transfer Test: prose to form

Convert application instructions into field labels, help text and confirmation messages.

Meaning must survive compression.

Plain language crosses formats.

173. Transfer Test: familiar topic to unfamiliar topic

Use the same user-first process on content outside the learner’s expertise.

They must identify terms requiring subject review.

Clarity cannot substitute for knowledge.

174. Transfer Test: no readability score

Remove automated metrics. Learner must use user needs, structure and testing.

Can they still improve clarity?

Tools should not become crutches.

175. Transfer Test: misleading simplification

Give a plain but inaccurate summary. Students compare with source and restore lost caveats.

Ease is not enough.

Accuracy governs.

176. Transfer Test: accessibility constraint

Design a page that cannot rely on colour, hover or visual heading size alone.

Semantic structure must carry meaning.

Robust content survives access differences.

Part XXX — Personal toolkit

177. The user card

Who is the reader? What are they trying to do? What do they know? What is the consequence of misunderstanding?

Answer before drafting.

User need drives plainness.

178. The frontloading card

What is the most important answer, action, deadline or decision? Is it visible in the first useful screen or paragraph?

Move it if not.

Position communicates priority.

179. The jargon card

Necessary technical term? Replaceable jargon? Acronym? Internal label? Define, replace or remove.

Every difficult word gets a reason.

Vocabulary becomes deliberate.

180. The sentence card

Actor visible? verb visible? one main relationship? condition local? pronoun clear?

Use for dense passages.

Syntax becomes inspectable.

181. The paragraph card

One job? main point early? support relevant? length appropriate to medium?

Paragraphs should be scannable and coherent.

Local structure supports the user.

182. The heading card

Predictive? short? plain? frontloaded? correct semantic level?

Headings are navigation infrastructure.

Do not choose by appearance alone.

183. The accessibility card

Semantic headings, descriptive links, alt text, labels, colour independence, error recovery.

Use relevant standards for publication.

Access is quality.

184. The accuracy card

Did simplification change obligation, scope, uncertainty, technical meaning or exception?

Compare with source.

Plain language must remain faithful.

185. The testing card

Can users find the answer, explain it and perform the task?

Observe behaviour.

Clarity is tested, not declared.

186. What progress looks like

The learner increasingly begins with user need, prioritises information before editing sentences, frontloads answers and actions, controls jargon rather than simply avoiding it, uses consistent terminology, builds descriptive heading hierarchies, writes manageable sentences and one-job paragraphs, preserves technical accuracy, considers accessibility and tests whether real readers can find, understand and use the information.

Complex information becomes clear not because complexity disappears, but because the writer carries more of the organisational burden so the reader carries less.

Where this tutorial connects inside SETC

• English Tutorial Lesson No.0020 — Purpose to Register
• English Tutorial Lesson No.0045 — Instructions to Action
• English Tutorial Lesson No.0048 — Paragraph to Longform
• English Tutorial Lesson No.0043 — Data to Language

External research and professional references

• Office for National Statistics — Plain Language
• ONS — Writing for Users
• ONS — How People Read Online
• UK Home Office — Accessible Heading Structure

Final tutorial challenge

Give the learner a 700-word page written by a fictional institution. It contains a buried deadline, six acronyms, two noun stacks, inconsistent terminology, a passive sentence hiding responsibility, vague link text, one technically necessary specialist term, three paragraphs with mixed jobs and one important caveat near the end. The learner must identify the user’s task, restructure the page, frontload the answer, simplify language without losing the caveat, create an accessible heading hierarchy and test the result on a new reader who has thirty seconds to find the deadline and explain the next action.

The final judgement is not based on whether the revision is shorter. It is based on whether the intended reader can find, understand and use the information more accurately with less unnecessary effort.

English Learning Library · Primary English · Secondary English · Advanced English / General Paper

Return to practice, feedback and tutorial design: English Practice, Model Answers and Feedback.