Topic 3.1 — Content Design & Health Literacy

In health and care, the words and structure you put in front of a person are part of the treatment, so content that confuses, excludes, or misleads is a clinical-safety and equity failure, not a cosmetic one.

Why this matters in health and care#

Most of the digital health service a person actually experiences is content: a letter, a screen of instructions, an appointment reminder, a consent form, a set of medication directions, an error message when a booking fails. People do not experience your architecture, your data model, or your governance board. They experience the words, and whether those words help them do the thing they came to do — book, cancel, understand a result, prepare for a procedure, take a medicine safely, decide whether to seek help.

The stakes are high because the audience is, by definition, often unwell, anxious, tired, in pain, grieving, or in crisis. Comprehension drops under stress. A sentence that reads fine to a policy author in a quiet office can be unreadable to a frightened person at 2am. And the gap between how content is written and how people actually read is large. In England, around four in ten working-age adults struggle with health information that includes both text and numbers; that proportion rises sharply when numbers are involved. Much clinical content is written several reading ages above what a large part of the population can comfortably use.

This is not a minor usability point. Poor comprehension is linked to missed appointments, medication errors, avoidable admissions, failure to attend screening, and worse outcomes overall — and those harms fall hardest on people already facing disadvantage, deepening health inequalities rather than narrowing them. If someone cannot understand how to prepare for a colonoscopy, the clinical procedure is compromised before it begins. If a safety-netting message ("come back if you notice these symptoms") is buried in jargon, the safety net has holes. Content design is therefore inseparable from Topic 1.6 — Clinical Safety & Risk Management, from Topic 1.9 — Digital Inclusion & Accessibility, and from the research practice in Topic 3.0 — User Research & Service Design.

Core concepts#

Content design is a discipline, popularized by the UK Government Digital Service (GDS) and adopted by NHS Digital and NHS England, that treats writing as design: you decide what a person needs to complete a task, then choose the words, order, and format that meet that need in the simplest way — which is sometimes prose, but often a list, a table, a step-by-step, or no content at all. It starts from evidence about user needs rather than from what an organization wants to say.

Plain language — in English, plain English — is writing whose wording, structure, and design let the intended reader find what they need, understand it, and use it, on first reading. It is not "dumbing down"; it is precision that respects the reader's time and effort.

Readability is how easily a text can be understood, and it can be estimated with formulas such as the Flesch–Kincaid readability tests, which translate sentence length and word complexity into an approximate reading age or grade. These formulas are a useful signal, not a verdict — they measure surface difficulty, not whether the content is correct, findable, or usable.

Health literacy is a person's ability to find, understand, and use health information and services to make decisions and act. It is not a fixed trait of the person; it is a relationship between the demands your content makes and the skills, context, and state the person brings. Numeracy — the ability to reason with numbers, risks, doses, and dates — is a distinct and often weaker skill, which matters enormously when you communicate probabilities, results, or medication amounts.

Accessible content is content that works for people regardless of disability or communication need. It is governed by the Web Content Accessibility Guidelines (WCAG) for digital products, and in the NHS by the Accessible Information Standard, which is a legal requirement to identify, record, and meet the communication needs of patients and carers. Accessible formats include easy read (short sentences paired with images, for people with a learning disability), translations, large print, audio, and British Sign Language (BSL) video for Deaf people whose first language is BSL, not English.

Health equity is the principle that everyone has a fair opportunity to be as healthy as possible; content that only works for confident, digitally included, English-reading users actively widens the gap and is therefore an equity issue, tying this topic to web accessibility obligations that apply to all public sector bodies.

Best practices#

1. Start from the user need and the task, not the message. Before writing anything, be able to state, in one sentence, what the person is trying to do and what they need to know to do it. Content that exists to protect the organization, list every caveat, or reproduce a policy is content that fails the person. Design the smallest thing that lets them succeed, and cut everything that does not serve that task.

2. Write in plain language and check the reading age. Aim for short sentences, common words, active voice, and one idea per sentence. Use readability tools such as Flesch–Kincaid or SMOG as a quick signal, targeting roughly a reading age of nine to eleven for general public content, lower for high-stakes or crisis content. Treat the score as a smoke alarm, not a certificate — a text can score well and still be wrong, ambiguous, or missing the one thing the reader needed.

3. Front-load, chunk, and structure for scanning. People do not read health content linearly; they scan for the part that applies to them. Put the most important information first, use clear and honest headings, break content into short chunks, and prefer lists and step-by-steps over dense paragraphs. Structured content — content broken into consistent, reusable components — also makes information easier to translate, reuse across channels, and keep clinically accurate in one place.

4. Design numbers as carefully as words. Numeracy is weaker than literacy in the population, and numbers carry the highest-consequence content: doses, frequencies, risks, and results. Use natural frequencies ("about 1 in 10 people") rather than bare percentages where you can, keep denominators consistent, show absolute as well as relative risk, and never make the reader do arithmetic to stay safe. Test numerical content specifically, because a mis-read dose is a direct patient-safety harm.

5. Adopt a single content style and reuse content patterns. A shared style guide — the NHS digital service manual content style guide is the reference standard in this sector — settles thousands of small decisions (how to write dates, phone numbers, medication names, "GP" vs "doctor") so authors do not reinvent them and readers get consistency. Reusable content patterns for common situations (appointment reminders, results, safety-netting) raise quality and safety at scale and reduce the cost of getting each new page right.

6. Meet accessibility and the Accessible Information Standard by default, not on request. Build to WCAG 2.2 AA, and treat easy read, translations, BSL video, large print, and audio as part of the service, not an afterthought bolted on when someone complains. Under the Accessible Information Standard you must identify, flag, and meet communication needs and share those needs across care settings — so accessible content is a legal and clinical obligation, not a nice-to-have. Machine translation can help triage but is not safe for clinical content without human checking.

7. Write for people in stress, distress, or crisis. Someone reading about a cancer result, a mental health crisis, or a bereavement has less working memory and less patience for tone that is cheerful, bureaucratic, or vague. Use calm, direct, human language; say what is happening and what to do next; make the path to urgent help unmissable; and remove anything that adds cognitive load. Kind, plain content in these moments is a form of clinical care.

8. Test content with real and excluded users, and iterate. Content is a hypothesis about what helps until you watch real people use it. Run comprehension and task-based testing — ask people to tell you what a page means and what they would do — with a sample that deliberately includes people with low health literacy, low digital confidence, learning disabilities, and English as an additional language. This connects directly to Topic 3.0 — User Research & Service Design; content that has only been signed off by clinicians and lawyers has not been tested.

Questions to discuss with your team#

1. Do we actually know the reading age and comprehension of our highest-stakes content, or are we guessing? Most organizations cannot say what reading age their appointment letters, consent forms, or medication instructions are written at, let alone whether patients understand them. Pick your ten highest-consequence pieces of content — the ones where misunderstanding causes real harm — and measure them: run readability scores, but more importantly run comprehension testing with real users. Ask people to explain, in their own words, what the content means and what they would do next. You will usually find gaps between what the content says and what people take from it. Decide who owns closing those gaps, and how you will know they are closed. This is a clinical-safety exercise, not a copy-editing one.

2. Who is allowed to publish content, and what stops unsafe or inaccessible content going live? In many services, content is written by whoever happens to own the system — a developer, a clinician, an administrator — with no content design skill, no style guide, and no accessibility check. Discuss where content sits in your delivery lifecycle: is there a content designer involved, is there a shared style guide, is there a review step that checks plain language and accessibility before publish? Consider what your equivalent of a clinical-safety sign-off is for content, and whether it exists at all. Talk honestly about the trade-off between speed and safety, and about who is accountable when content causes harm. The goal is a repeatable path to good content, not heroics from individuals.

3. How do we serve the people our content currently fails, and are we measuring that? Averages hide exclusion: content that works for 80% of users can be completely failing the 20% who most need the service. Discuss which groups your current content excludes — people with low literacy or numeracy, Deaf BSL users, people who do not read English, people with learning disabilities, people in crisis — and whether you provide easy read, translations, BSL video, and alternative formats as standard. Ask whether you are meeting the Accessible Information Standard in practice, not just on paper. Consider how you would even detect that a group is being excluded, given they may simply drop out silently. Agree what you will measure and who represents these users when decisions are made, linking this to Topic 1.9 — Digital Inclusion & Accessibility.

4. When content and clinical accuracy pull in opposite directions, how do we decide? Plain language and clinical precision are usually allies, but sometimes they conflict: a clinician insists on a technical term for exactness, legal wants a caveat that lengthens and clouds the message, or a safety-netting instruction has to name a symptom the reader may not understand. If you always defer to the clinician or lawyer you will publish content people cannot use; if you always simplify you risk stripping out a distinction that keeps someone safe. Discuss how you resolve these tensions in practice — who is in the room, what evidence settles it, and whether comprehension testing is allowed to override an expert's preference. Consider concrete cases: rewording a medication instruction, softening a threatening non-attendance warning, or explaining a risk figure. An honest answer names a decision-making process, not a default winner, and shows that both comprehension and clinical correctness are treated as safety requirements rather than one being a nice-to-have.

5. Who owns content after it is published, and how do we keep it accurate as clinical guidance changes? Content is often treated as done at launch, but a medication direction, a screening interval, or a referral route can become dangerously wrong when clinical guidance or a pathway changes and nobody updates the words. Discuss whether every high-stakes piece of content has a named owner, a review cycle, and a way to find and fix all the places a fact appears — or whether the same statement is copied across letters, portals, and leaflets with no single source of truth. Ask what happens when a guideline changes: who is told, how quickly the content follows, and how you would even know a page had gone stale. Consider whether structured, reusable content would let you change something once rather than hunting for every copy. An honest answer confronts the unglamorous reality that most content decays silently, and sets out how you detect and prevent that decay.

6. Are we treating AI-generated and AI-translated content with the caution that patient safety demands? Teams are increasingly tempted to draft patient content, summarize clinical information, or translate at scale using large language models, because it is fast and cheap. The danger is that fluent, confident output masks errors that a stressed reader will act on — a wrong dose, an invented reassurance, a mistranslated instruction — and the English-speaking team never sees the mistake. Discuss where, if anywhere, you allow generated or machine-translated content, and what human clinical and linguistic checking is mandatory before it reaches a patient. Consider the difference between using AI to triage or draft internally and using it to publish unreviewed content that tells someone what to do about their health. An honest answer sets a clear line, names who is accountable for checking, and treats an unverified machine output the same way you would treat an unqualified person writing clinical instructions.

In practice: a health & care example#

An integrated care board is rolling out a digital service that lets patients book their own follow-up appointments after a hospital outpatient clinic. The first version is built quickly. The confirmation screen reads: "Your appointment request has been submitted and is pending clinical validation. Please note DNA policy applies." The reminder text message says: "You have an appt with the Ambulatory Care Unit re your recent attendance. Non-attendance may result in discharge per Trust policy."

Within weeks, the team notices a pattern. Attendance for this cohort is worse than for letters, not better. User researchers and a content designer sit with fifteen patients, deliberately including two people with a learning disability, one Deaf BSL user, one person who reads little English, and several older patients with long-term conditions. The findings are stark. Almost no one knows what "DNA" or "ambulatory" means; several assume "DNA" refers to a genetic test. "Pending clinical validation" makes people think the appointment is not confirmed, so they do not put it in their calendar. The threat about discharge frightens people without telling them what to do. The Deaf patient never engaged with the service at all, because there was no BSL video explaining it and the text assumed fluent written English.

The content designer rewrites against the NHS content style guide and tests each version. The confirmation becomes: "Your appointment is booked. We will send a reminder. If you need to change it, tap 'Change appointment' or call 0300 000 0000." The reminder becomes: "Reminder: your appointment is on Tuesday 12 August at 2pm at St Mary's Hospital, Clinic 4. If you cannot come, please tell us so we can offer the time to someone else: [link]." The reading age drops from around fifteen to around nine. The team adds an easy read version, a set of translated versions checked by human translators, and a short BSL video explaining how booking works. They add a clinical-safety review step for any content that tells a patient what to do about their health.

Three months on, non-attendance in the cohort has fallen below the letter baseline, complaints have dropped, and the Deaf patient has used the service independently for the first time. The clinical safety officer records the content changes as a risk control in the service's safety case. The words were the intervention.

Sector lenses#

Startup#

A health-tech startup can build content quality into its DNA cheaply, because it has no legacy content to unpick and can hire or contract a content designer early. The risk is that founders treat content as marketing copy — persuasive, on-brand, benefit-led — rather than as task-focused design for people who may be unwell. Adopt the NHS content style guide from day one, set a reading-age target, and put comprehension testing into your usability sessions from the first prototype. If you are pursuing NHS or public sector contracts, WCAG 2.2 AA and the Accessible Information Standard are entry requirements, not differentiators, so build to them now rather than retrofitting under procurement pressure.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a domiciliary-care agency, a single-site clinic, or a small health-tech supplier past the startup stage — has real patients and the same legal duties as a hospital trust, but no content designer, no style guide, and often one person doing IT alongside another job. The practical risk is that letters, consent forms, texts, and website content are written by whoever has time, in local jargon, and that easy read, translations, and BSL are simply not offered, quietly breaching the Accessible Information Standard. You do not need to build capability from scratch: adopt the free NHS content style guide and reuse its ready-made patterns rather than writing from a blank page, and use the NHS reading-age and accessibility guidance as your checklist. Prioritize your handful of highest-stakes items — medication instructions, appointment and safety-netting messages — and get those into plain language and accessible formats first, using community or voluntary-sector translators for your local languages rather than unchecked machine translation.

Enterprise#

A large provider or supplier has thousands of pieces of content spread across letters, portals, apps, leaflets, and third-party systems, written by many hands over many years with no shared style. The enterprise problem is consistency and governance at scale: the same medication or condition described five different ways, translations done ad hoc, easy read produced reactively. Invest in a single content style, a reusable content pattern library, a content design capability that supports delivery teams, and a publishing workflow with accessibility and clinical-safety checks built in. Treat high-stakes content — consent, medication, results, safety-netting — as a managed asset with named owners, version control, and a review cycle, the same way you would treat clinical protocols.

Government#

National and system bodies set the standards that everyone else inherits, so their content decisions are leveraged across millions of interactions. The GDS and NHS lineage — the service manual, the content style guide, the Accessible Information Standard, WCAG obligations under the Public Sector Bodies Accessibility Regulations — exists precisely so that quality and equity are baked into public services rather than left to chance. Government's job is to maintain these shared standards, provide reusable patterns and components, mandate accessible formats, and hold services to account through spend controls and assurance. The failure mode is issuing guidance without the capability, tooling, or funding for frontline teams to meet it, which produces compliant-on-paper content that still excludes people.

Common failure modes#

• Writing for the organization, not the reader. Content that lists every caveat, protects the institution, or reproduces policy, instead of helping the person complete their task.
• Jargon and unexplained acronyms. "DNA", "ambulatory", "triage", "referral pathway", "clinical validation" — insider language that readers either misunderstand or find alienating.
• Confusing the reader with numbers. Bare percentages, inconsistent denominators, relative risk without absolute risk, and doses or dates that force the reader to calculate.
• Accessibility as an afterthought. Easy read, translations, and BSL produced reactively, on request, or not at all — breaching the Accessible Information Standard and excluding the people who most need the service.
• No content design in the team. Content written by whoever owns the system, with no style guide, no plain-language skill, and no review, so quality depends on luck.
• Signed off but never tested. Content approved by clinicians and lawyers for accuracy and risk, but never watched in the hands of a real, non-expert, stressed user.
• Frightening people without helping them. Threats ("you may be discharged") and warnings with no clear, calm next action, especially damaging in distress or crisis.
• Machine translation used unchecked for clinical content, producing errors that are invisible to the English-speaking team that published them.

Maturity model#

Checklist#

• You can state the user need and task each piece of content serves in one sentence.
• Your highest-stakes content is written in plain English and checked against a reading-age target (around nine to eleven, lower for crisis content).
• Numbers, doses, risks, and dates are expressed so no reader has to calculate to stay safe.
• You use the NHS digital service manual content style guide (or a documented equivalent) and a reusable content pattern library.
• Content meets WCAG 2.2 AA and the Accessible Information Standard, with easy read, translations, BSL video, and alternative formats available as standard.
• Translations of clinical content are checked by qualified human translators, not machine translation alone.
• High-stakes content has a clinical-safety review step before it goes live.
• Content is comprehension-tested with real users, including people with low health literacy, low digital confidence, learning disabilities, and English as an additional language.
• There is a defined publishing workflow; not everyone can push content live unchecked.
• You measure whether content is excluding specific groups, and you have named owners for closing those gaps.

Key sources#

• NHS digital service manual — content style guide, accessibility guidance, and content patterns (service-manual.nhs.uk).
• GOV.UK content design guidance and the Government Digital Service style guide (gov.uk).
• NHS England — Accessible Information Standard (DCB1605), the legal standard for meeting patients' communication needs.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C Web Accessibility Initiative.
• Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
• Health Education England / NHS — health literacy resources and the "how to" guides on making information understandable.
• Institute of Medicine / WHO — foundational reports on health literacy and its link to outcomes and inequalities.
• British Sign Language Act 2022.

References#

1. Health literacy — Wikipedia — https://en.wikipedia.org/wiki/Health_literacy
2. Plain language — Wikipedia — https://en.wikipedia.org/wiki/Plain_language
3. Plain English — Wikipedia — https://en.wikipedia.org/wiki/Plain_English
4. Numeracy — Wikipedia — https://en.wikipedia.org/wiki/Numeracy
5. Readability — Wikipedia — https://en.wikipedia.org/wiki/Readability
6. Flesch–Kincaid readability tests — Wikipedia — https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests
7. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
8. Web accessibility — Wikipedia — https://en.wikipedia.org/wiki/Web_accessibility
9. Easy read — Wikipedia — https://en.wikipedia.org/wiki/Easy_read
10. British Sign Language — Wikipedia — https://en.wikipedia.org/wiki/British_Sign_Language
11. Government Digital Service — Wikipedia — https://en.wikipedia.org/wiki/Government_Digital_Service
12. Health equity — Wikipedia — https://en.wikipedia.org/wiki/Health_equity
13. NHS digital service manual — content style guide — NHS England — https://service-manual.nhs.uk/content
14. Content design: planning, writing and managing content — Government Digital Service — https://www.gov.uk/guidance/content-design
15. Accessible Information Standard (DCB1605) — NHS England — https://www.england.nhs.uk/about/equality/equality-hub/patient-equalities-programme/equality-frameworks-and-information-standards/accessibleinfo/
16. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/TR/WCAG22/
17. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — legislation.gov.uk — https://www.legislation.gov.uk/uksi/2018/952/contents/made
18. British Sign Language Act 2022 — legislation.gov.uk — https://www.legislation.gov.uk/ukpga/2022/34/contents