Plain Language Rewrites With AI
Most nonprofit intake forms, eligibility notices, and consent documents are written several grade levels above the people expected to read them. That gap costs you completed applications, accurate data, and trust. AI can rewrite a document at a target reading level in seconds, which makes it the cheapest fix available for a problem organizations have tolerated for decades, and also the fastest way to accidentally change what a legally binding form actually says.
Take any document your organization hands to a client and read the first paragraph out loud. If it contains a sentence longer than about twenty-five words, a noun made out of a verb, or a term that only makes sense if you already work in the sector, you have found the reason your intake staff spend so much time explaining forms line by line. This is not a failure of effort. Most of these documents were assembled over years by people who were legitimately worried about legal exposure, funder requirements, and getting the details right. Readability was never the constraint anyone was optimizing for.
The cost shows up everywhere except in a line item. Applications come back incomplete because the applicant guessed at what a question meant. Eligibility notices generate phone calls that a caseworker has to field. Consent forms get signed by people who could not accurately describe what they consented to, which is a problem both ethically and in any subsequent dispute. Program materials that were expensive to produce go unread. In organizations serving people with limited formal education, recent immigrants, older adults, or anyone reading in a second language, the effect compounds.
Plain language work has been a known best practice for a long time. Federal agencies have operated under the Plain Writing Act of 2010, and public health communicators have pushed for materials written well below high school level for longer than that. The reason most nonprofits never did the work is not disagreement. It is that rewriting forty documents is a multi-week project nobody has budget for, and the first draft of a rewrite is the slowest part.
That is exactly the part AI removes. A language model can produce a competent plain language draft of a dense paragraph almost instantly, and can do it consistently across an entire document library. What it cannot do is decide which meaning is load-bearing, notice when a simplification quietly narrowed a legal right, or confirm that the new wording matches what your program actually does. This article covers how to run the work so the speed is real and the risk is contained: what readability metrics actually measure, which documents to start with and which to leave alone, how to prompt for a genuine rewrite rather than a thesaurus pass, and the review process that keeps a simplified form accurate.
Unreadable Forms Are an Operations Problem, Not a Writing Problem
It helps to stop thinking of this as an editorial nicety and start counting what it costs you. Every question that a client misunderstands produces one of three outcomes, all of them expensive. The client leaves it blank, which means someone follows up. The client answers wrong, which means bad data enters your system and may travel into a grant report. Or the client abandons the form, which means a person who needed a service did not get it and you never learn why.
The data consequences are the ones organizations underestimate. A poorly worded demographic question does not fail loudly. It produces a field that looks complete and is quietly wrong, and that field may end up in your outcomes reporting, your funder dashboards, and your annual report. Teams that have invested in cleaning up their CRM data often discover that a meaningful share of the mess originated at the point of collection, in a question that nobody outside the organization could parse.
There is a staff cost too. When forms do not explain themselves, explanation becomes a job. Front-line staff and volunteers spend hours a week walking people through documents, which is time not spent on the service itself. In organizations with high volunteer turnover, that verbal explanation also drifts, so different clients receive different accounts of the same form. The written document is supposed to be the control that prevents exactly that, and when it is unreadable it stops functioning as one.
Finally there is the dignity dimension, which is harder to quantify and matters more than the rest. Handing someone a document they cannot read and asking them to sign it communicates something about how the organization sees them. Programs that have thought carefully about this treat readable materials as part of service quality rather than as a communications task. If your organization has been working through accessibility audits of your website and materials, reading level belongs on the same list as alt text and contrast ratios.
What unreadable documents cost
The expenses that never appear in a budget
- Incomplete applications that require staff follow-up
- Inaccurate data that flows into funder reports
- Abandoned applications from people who qualified
- Staff hours spent verbally translating your own forms
- Consent that is technically obtained but not meaningfully informed
Who is most affected
Reading load falls unevenly
- People reading in a second or third language
- Adults with interrupted formal education
- Older adults navigating benefits and medical paperwork
- Anyone in crisis, where comprehension drops sharply
- People with cognitive disabilities or reading on a phone screen
Readability Scores Are a Useful Thermometer and a Terrible Target
Before you start rewriting, it is worth understanding what readability formulas actually do, because AI tools will happily optimize against them and produce something worse. Flesch-Kincaid Grade Level, the most widely used measure, is essentially arithmetic on two variables: average sentence length and average syllables per word. It has no idea what your words mean. It cannot tell whether a sentence is logically ordered, whether a term is familiar to your readers, or whether the document answers the question a reader actually has.
This produces a specific and common failure. Ask an AI tool to lower the grade level of a paragraph and it may chop long sentences into short fragments and swap multi-syllable words for shorter near-synonyms. The score drops. Comprehension does not improve, and sometimes it gets worse, because the connective tissue that explained how the ideas relate has been deleted. A document full of choppy declaratives with no transitions scores beautifully and reads like an instruction manual translated twice.
Use the score the way you would use a thermometer. It tells you when something is clearly wrong. A consent form scoring at fourteenth grade is a problem regardless of context, and knowing that is genuinely useful when you are triaging forty documents and need to know where to start. But moving a document from grade nine to grade eight is not automatically an improvement, and treating the number as the goal will produce worse writing.
Public health communicators generally aim for materials well below high school level, often in the sixth to eighth grade range for general audiences and lower for materials aimed at people with limited literacy. Those targets are reasonable starting points for nonprofit client-facing documents. The more useful test, though, is behavioral: can someone in your actual audience read the document once and correctly tell you what it asks of them and what happens next. That test catches problems no formula will.
What readability formulas miss entirely
All of these can be wrong in a document scoring at fifth grade
- Jargon made of short words, such as "case closed" or "in kind" or "sliding scale"
- Information presented in an order that does not match how a reader thinks about the task
- Missing context, where the sentence is simple but the reader has no idea why it matters
- Passive constructions that hide who has to do the thing
- Layout problems, including dense blocks, tiny type, and forms that do not work on a phone
- Cultural assumptions about family structure, employment, or housing that make a question unanswerable
Sort Your Documents Before You Rewrite Any of Them
The instinct is to start with whichever document annoys you most. A better approach is to inventory everything a client might receive and sort it into three groups, because the three groups need genuinely different handling and mixing them up is how organizations get into trouble.
The first group is material you fully control and that carries no legal weight: program descriptions, welcome letters, appointment reminders, eligibility explainers, service guides, FAQs. This is where AI rewriting is close to risk-free and where you will get most of your value. You can move fast here, and you should. A well-run session can produce plain language drafts of a dozen of these in an afternoon.
The second group is documents you control but that carry consequences: intake forms, consent documents, releases, grievance procedures, program rules that determine whether someone stays enrolled. These can and should be rewritten, but every change needs a substantive review by someone who understands what the original language was protecting. A simplification that turns "you may request a review within thirty days" into "you can ask us to look at it again" has quietly deleted a deadline that mattered.
The third group is language you do not control at all. Funder-required notices, statutory language, HUD or HHS required disclosures, insurance wording, and text your attorney specified all fall here. You cannot rewrite these. What you can do is wrap them, adding a plain language summary above the required text that explains what it means, clearly labeled as a summary and not a replacement. This is a well-established pattern and it is often the single highest-value change available, because these are usually the densest documents in the stack.
Rewrite freely
Low risk, high volume
Program descriptions, welcome and appointment letters, FAQs, service guides, outreach materials, website copy explaining how to apply. Review is editorial, not legal. Start here and build confidence in the process.
Rewrite carefully
Requires substantive review
Intake and eligibility forms, consent and release documents, grievance and appeal procedures, program participation agreements. Every rewrite gets checked against the original for changed obligations, deadlines, and rights.
Do not rewrite
Summarize alongside instead
Statutory notices, funder-mandated language, insurance terms, attorney-specified clauses. Add a labeled plain language summary above the required text. Never edit the required text itself, however awkward it reads.
Prompting for a Real Rewrite Rather Than a Thesaurus Pass
The default output you get from asking a model to "simplify this" is usually mediocre, because the request is underspecified. The model does not know your audience, does not know which parts of the document are legally load-bearing, and does not know whether it is allowed to reorganize. Give it all three and the quality changes substantially.
Start by describing the actual reader. Not "a general audience" but something concrete: an adult applying for rental assistance, likely reading on a phone, possibly in a second language, probably under financial stress and short on time. That description does more work than any instruction about grade level, because it tells the model what to assume and what to explain.
Then state the constraints explicitly. Tell it which terms must be preserved verbatim, whether it may change the order of sections, whether every original requirement must survive, and what the document needs the reader to actually do. If a deadline or a right or a dollar figure appears in the original, say that these must appear unchanged in the rewrite. Models are considerably better at following a stated constraint than at inferring one.
Finally, ask for the reasoning alongside the output. Requesting a list of what was changed and why, and specifically a list of anything the model was unsure about, turns an opaque rewrite into a reviewable one. This single addition is what makes the review step fast enough to actually happen. The same discipline applies across AI-assisted writing work generally, and it echoes the approach in our guide to creating an audit trail for AI-assisted decisions.
A prompt structure that works
Six elements worth including every time
- The reader: a concrete description of who receives this and in what circumstances
- The job: what the reader must understand or do after reading it
- Protected content: terms, figures, deadlines, and rights that must survive verbatim
- Permission to restructure: whether reordering and adding headings is allowed
- Voice: address the reader as "you", say who does what, use active verbs
- A change log: what was altered, what was cut, and what the model was uncertain about
One technique worth adopting is the two-pass approach. In the first pass, ask the model only to explain the document back to you in plain language, as if to a colleague, without producing a rewrite. This surfaces ambiguity immediately. If the model's explanation is wrong, or hedged, or it produces two possible readings of a sentence, then that sentence is ambiguous to human readers too and needs a decision from a person before any rewriting happens. Only in the second pass do you ask for the actual replacement text.
Another is reverse-testing. Take the rewritten version, start a fresh session with no access to the original, and ask the model to answer specific questions using only the new text. What is the deadline? Who is eligible? What happens if the reader does nothing? If the rewritten document cannot answer those questions, information was lost in translation, and you have found it before a client did.
The Specific Ways Simplification Goes Wrong
Most AI plain language failures are not dramatic. They are small, plausible-looking edits that changed meaning in a way nobody noticed at review because the new sentence read well. Knowing the recurring patterns makes them much easier to catch.
The most common is quantifier drift. Original text says a decision will be made "within ten business days"; the rewrite says "in about two weeks". Both sound reasonable, and only one of them is a commitment you can be held to. The same thing happens with "must" becoming "should", "any" becoming "some", "including but not limited to" becoming a closed list, and specific dollar thresholds becoming vague descriptions of cost.
The second is scope collapse. Legal and program language often contains deliberate breadth, and simplification tends to narrow it. A clause covering "your household members and anyone who regularly stays at the residence" may come back as "the people who live with you", which is a different and smaller set. Where the original was carefully broad, the rewrite is confidently specific.
The third is invented reassurance. Language models trained to be helpful will sometimes add a friendly line that was not in the source, along the lines of "don't worry, this won't affect your benefits" or "most people are approved". These sentences are commitments your organization did not make and may not be able to keep. They are also easy to miss in review precisely because they sound like something a caring organization would say.
The fourth is the disappearance of the unpleasant part. Documents often contain a paragraph that exists specifically to be clear about something uncomfortable: that services may end, that information may be shared with a funder, that a decision can be appealed but only once. Simplification passes have a tendency to soften or shorten these. If your rewrite is meaningfully shorter than the original, check what left, because it is disproportionately likely to be the part the reader most needed.
Consent documents deserve particular attention here. A shorter, friendlier consent form that no longer clearly states what data is collected and who sees it is worse than the dense version, even though it tests better on every readability metric. Our discussion of informed consent when client data meets AI systems covers what those documents need to preserve.
A reviewer's checklist for any rewritten form
Run these against the original, not against the new version alone
- Every number, date, deadline, and dollar figure appears unchanged
- Every "must" is still a "must", and no obligation became a suggestion
- No category was narrowed, and no open list became a closed one
- Nothing reassuring was added that the original did not promise
- Every right, appeal path, and adverse consequence survived the edit
- Required verbatim language is intact and visually distinguished from your summary
Plain Language First, Then Translation
If your organization produces materials in more than one language, the sequencing matters more than most teams realize. Translating a dense, jargon-heavy English document produces a dense, jargon-heavy document in the target language, and often something worse, because sector-specific English terms frequently have no clean equivalent and translators are forced to improvise. The compounding effect is that your Spanish or Vietnamese or Haitian Creole materials end up harder to read than the English original, for readers who may already be navigating an unfamiliar system.
Rewriting into plain English before translating fixes this at the source and reduces cost, because shorter sentences with common words translate more reliably in both machine and human workflows. It also makes the translation itself easier to check. A reviewer confirming a translated document against a plain English original has a far easier job than one working from the legalistic version.
A caution worth stating plainly: readability targets do not transfer across languages. Flesch-Kincaid was built for English and its syllable-counting logic produces meaningless numbers elsewhere. Do not set a grade level target for a translated document and do not let a tool report one to you as though it means something. Evaluation of translated materials needs a fluent human reader, ideally one from the community you serve. Our guide to reviewing machine translation quality goes deeper on how to structure that check, and organizations serving newly arrived communities will find related material in our overview of AI in refugee and immigrant services.
One more sequencing note. If you are producing both a plain language rewrite and translations, version control becomes a real risk. Organizations routinely end up with an updated English form and translations that still reflect last year's wording, which means different clients are agreeing to different things. Decide up front who owns the master document and how translation updates get triggered, before you generate forty new files.
Running the Project Without It Stalling at Document Six
Plain language projects tend to die the same way. Someone rewrites a handful of documents, the rewrites sit waiting for legal or executive review, momentum evaporates, and eight months later the old forms are still in the filing cabinet. The AI part is not what fails. The approval path is.
The fix is to decide the review requirement per document category before you start drafting, rather than routing everything to the same overloaded reviewer. Group one documents need one program person to sign off. Group two needs program plus whoever owns the legal or compliance risk. Group three needs no rewrite approval at all, because you are only adding a summary alongside untouched required text, though the summary itself should be checked. Making this explicit at the start converts a vague approval bottleneck into a set of small, bounded asks.
Batch by document type rather than by program. Rewriting all eleven of your appointment and reminder letters in one sitting is far faster than rewriting one letter, one consent form, and one program guide, because you build a consistent voice and reuse the same prompt structure. It also makes review faster, since the reviewer is checking eleven similar things against the same criteria rather than context-switching.
Test with actual readers before you roll anything out widely. This does not require a research budget. Ask five people who use your services to read the new version and tell you, in their own words, what it is asking them to do. Five people will find nearly everything that matters. Front-line staff are a useful second panel, because they know which questions clients always ask, and if the new version does not preempt those questions it has not solved the problem.
Finally, treat this as a maintenance commitment, not a one-time project. Forms change when programs change, when funders change requirements, and when law changes. Whoever owns document updates should now own the plain language standard as well, and new documents should be drafted to it rather than retrofitted later. Organizations that have built broader AI literacy across their teams tend to find this sticks, because staff can run a rewrite themselves rather than queueing it with communications.
A realistic first month
Enough to prove the value without stalling
- Week one: inventory every client-facing document and sort into three groups
- Week two: rewrite the entire low-risk group in batches by document type
- Week three: test with five clients and five front-line staff, revise
- Week four: publish the low-risk set, start the highest-volume intake form
Who needs to be involved
Small group, clear roles
- One owner who runs the rewrites and holds the standard
- A program lead who confirms the new text matches what the program does
- A compliance or legal reviewer, but only for the middle group
- Front-line staff and a handful of clients as the reality check
Conclusion
Plain language has always been the right thing to do and has almost never been the affordable thing to do. The economics have genuinely changed. A task that used to mean weeks of skilled writing time now means an afternoon of drafting and a structured review, which puts it within reach of organizations that could never have justified the project before.
What has not changed is that these documents carry obligations. The value of AI here is that it removes the drafting bottleneck, not that it removes the need to know what your forms actually commit you to. Sort your documents by risk, rewrite the safe ones fast, review the consequential ones properly, and never touch the language you do not control. That sequence is what separates a plain language project that ships from one that generates a folder of unreviewed drafts.
The measure of success is not a readability score. It is whether a person can read your form once, understand what you are asking and what happens next, and answer accurately without needing a staff member to sit beside them. Test for that, and the score will take care of itself.
Make Your Documents Work for the People Who Read Them
We help nonprofits put AI to work on the practical problems that slow service delivery down, with the controls that keep the work defensible.