Short answer: to write a plain language summary, name your reader first, then state the question, what you did, what you found, how certain the finding is and what remains unknown, in short sentences with every technical term replaced or explained. Give numbers the reader can use, never claim more than the paper supports, and test the draft by asking two or three people from your intended audience to explain it back to you. A summary that sounds simple but is misunderstood has failed.
What is a plain language summary, and how is it different from an abstract?
A plain language summary is a short, non-technical account of what was asked, what was done, what was found and how certain the findings are, written for a defined non-specialist audience. It faces a different test from an abstract. The question is not whether the text sounds simple. It is whether the intended reader understands it.
Terminology varies. The Health Research Authority (HRA) writes "plain language (lay) summary" in its guidance (last updated 7 January 2025), and Taylor & Francis notes that plain language summaries are also called lay summaries in some subject areas. This article uses "plain language summary" throughout.
The audience differs as well as the name:
AGU
Intended reader: Readers with undergraduate-level science knowledge, including scientists from other fields, students, editors and journalists; not the general public
Length guidance: A single paragraph of no more than 200 words
Taylor & Francis
Intended reader: Someone unfamiliar with the subject should be able to grasp the study, conclusions and potential impact
Length guidance: 250 words or fewer for a text summary
HRA
Intended reader: A general audience, including participants, communities, professionals and policy makers
Length guidance: Sentences of about 20 words or fewer; paragraphs of about three sentences
So the abstract helps specialists judge a study, while the plain language summary succeeds only if a defined non-specialist reader understands it. For the abstract itself, see the SciCampus guide to the four-function abstract. Requirements for length, headings and content differ between funders and journals, so always follow the instructions of your target journal or funder (AGU, Taylor & Francis).
Who is your reader?
Decide this before writing a sentence. Different readers need different things from the same study.
Participants and patients: the HRA says findings should be available to those who took part, and its suggested content begins with a thank-you to participants. They need to know who was studied, what happened and what it means for people like them.
Policymakers and practitioners: these readers often have little time. Put the main finding, who it applies to, how confident you are and what remains unknown in the first few lines. (This is editorial advice, not a quoted rule.)
Researchers from other fields: AGU advises avoiding or carefully defining words that non-scientists may read differently, such as "uncertainty", "mean" and "signal". A colleague from another discipline may follow the grammar and still misread the term.
The general public: the HRA's principles include assuming no prior knowledge and choosing words suited to the reader. Explain a concept the first time it appears, even if it feels obvious to you.
How do you write a plain language summary, step by step?
Define the reader in one sentence. "A patient with the condition and no medical training" is usable; "the public" is not.
Put the main message first. A workable order is the question, what was done, what was found, how certain the findings are, and what comes next. Funders arrange this differently, so check yours.
Replace or explain every technical term. Use a plain word when it does the job. Define the term on first use when readers need it. Define every acronym, and keep acronyms to a minimum.
Keep sentences short. The HRA suggests about 20 words or fewer per sentence and about three sentences per paragraph. That is one body's advice, not a rule.
Give numbers in a usable form. A comparison such as "20 in 100 people compared with 30 in 100" is often easier to grasp than a percentage or a statistical term. State what is being compared.
Say what you do not know. Write limitations in plain words rather than technical labels.
Keep the wording neutral. Do not claim more than the paper supports, and do not tell readers what they should do unless the paper and your funder's rules allow it.
Test it with real readers (next sections).
What does a good plain language summary look like?
This example is invented for illustration. The study and numbers are hypothetical, and a real summary must use only what the paper reports.
Suppose a paper reports that text reminders were tested in a small study lasting three months: 20 of 100 participants who received reminders missed an appointment, compared with 30 of 100 who did not.
Before: "Participants receiving the reminder intervention demonstrated a statistically significant reduction in missed appointments relative to controls."
After: "In this study, 20 in 100 people who received text reminders missed an appointment, compared with 30 in 100 who did not. The study was small and lasted three months, so we do not know whether the difference would last longer or apply elsewhere."
The second version gives the number, the comparison and the limit, and every figure comes from the invented paper. It does not say whether anyone should adopt reminders.
Is there a simple template you can fill in?
Why we did this study: one or two sentences on the problem, for your named reader.
What we did: who or what was studied, how many, for how long.
What we found: the main result in numbers and plain words, with the comparison.
What this does not tell us: the main limitation, in plain words.
What happens next: only if the paper supports it.
Treat this as a starting structure, not a requirement. Funder and journal templates take precedence.
Is a readable summary the same as an understood one?
No, and there is evidence on this gap. Guo, Sohn, Leroy and Cohen studied plain language summaries of biomedical abstracts in a crowdsourced evaluation (arXiv preprint 2505.10409, 2025). They recruited 150 U.S. participants through Amazon Mechanical Turk, excluding people with medical training or advanced biology coursework. Participants rated summaries on qualities such as simplicity and coherence, answered multiple-choice questions and completed a recall task.
Participants rated LLM-generated summaries (made with GPT-4) similarly to human-written ones, but answered significantly fewer multiple-choice questions correctly after reading them. The recall differences were not significant. The authors also report that most common automated metrics, including BLEU, ROUGE and METEOR, did not reflect comprehension well.
The scope matters. This is one study, based on crowdsourced online participants, on health text, using one family of models. It does not show that human writing is always better or that LLMs cannot help, and it says nothing about any particular product. The practical lesson is narrower and still useful: how a summary feels to a reader is not the same as what the reader took from it, so fluency, readability formulas and automated scores are not evidence of comprehension.
How do you test whether readers understand your summary?
The AHRQ teach-back tool comes from patient care. It notes that people often say they understand when they do not, and that asking them to explain the information in their own words is the most reliable check. The same idea applies to summaries. AGU advises asking a colleague from outside your discipline to read the summary and explain your study back to you, and Taylor & Francis advises asking a non-specialist to read it and comment.
Choose two or three readers from the intended audience, not colleagues in your lab.
Ask them to read the summary, then explain in their own words the question, the finding and the limitation.
Note where they hesitate, reread or misstate something.
Revise those passages.
Check the revised text against the paper, so clarity has not cost accuracy.
A small informal round is far better than none. If your work involves patients or the public, the HRA also encourages involving them in developing or reviewing the summary.
Plain language summary checklist: where "no" means stop
If your answer to any item is "no" or "not sure", stop and check before you go on.
My target journal's or funder's instructions on length, headings and content are met.
I can name the intended reader in one sentence.
The key message appears in the opening lines, and any technical term in it is explained.
Each technical term is replaced or explained on first use.
Numbers are given in a form this reader can use, with the comparison stated.
The limitations are written in plain words.
Every claim matches what the paper supports, with no stronger wording.
At least two readers from the intended audience explained the question, finding and limitation correctly in their own words.
I checked the revised version against the paper after the last change.
Where a journal or funder has an AI policy, I have followed it and I take responsibility for the final text.
Can I use AI to write a plain language summary?
Some journals permit it under conditions. Taylor & Francis, for example, permits AI tools to help write a summary of the author's own work. Authors must keep the original and revised versions, include a declaration naming the tool and version, confirm that they verified originality and accuracy, and take full responsibility for the content. Follow your target policy; the SciCampus AI writing ethics guide covers disclosure in general. Whatever tool produced the draft, a fluent text still has to be tested with readers.
Where does a rewriting tool fit?
A rewriting tool belongs late, after you have written the summary yourself. The SciCampus Humanizer (currently in beta) lets you choose a style (Academic, Casual or Professional) and the extent of the rewrite (Light, Moderate or Heavy). You can paste text or upload a PDF or DOCX file, and the page lists its limits. Access is being introduced gradually, account by account, with a waitlist for updates. The page shows an example labelled as an illustration, and tells users to review the result for meaning, terminology and citations before using it.
One narrow use is to see alternative phrasings of an over-formal passage in a draft you have already written. Treat the output as a suggestion. Compare it with your original, check that terms and numbers still say what the paper says (the guide to semantic drift in paraphrasing shows how), and then put it in front of real readers. A rewriting tool does not test whether a reader understands your summary. Only readers can show that.
Before submission, the SciCampus AI Detector and Journal Finder are available for other checks.
Related reading
The Scientific Writing Roadmap: From a Research Idea to a Clear, Credible IMRAD Manuscript
The Funnel Formula: How to Structure an Introduction and Actually Find Your Research Gap
References
Health Research Authority. Writing a plain language (lay) summary of your research findings (updated 7 January 2025). hra.nhs.uk
AGU. Summarizing Your Science (plain language summary guidance). agu.org
Taylor & Francis Author Services. How to write and publish a Plain Language Summary. authorservices.taylorandfrancis.com
Guo, Y., Sohn, J. H., Leroy, G. & Cohen, T. (2025). Are LLM-generated plain language summaries truly understandable? A large-scale crowdsourced evaluation. arXiv:2505.10409. arxiv.org
AHRQ. Tool: Teach-Back, TeamSTEPPS. ahrq.gov
