Clarify the task and decision
This guide turns choosing the right language mode into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
Use a four-factor decision: audience, task, consequence of misunderstanding, and review capacity.
Practical workflow
- 1
Define the audience with evidence, including reading experience, context, device, and support available.
- 2
Select one real task and state what a successful reader must understand or do.
- 3
Create the language version while preserving every decision-relevant fact, condition, date, and contact path.
- 4
Run specialist and editorial review with recorded acceptance criteria.
- 5
Test with members of the intended audience, record findings, revise, and approve the release.
Worked example or tool
A decision matrix turns four project facts into a documented mode choice. In the tool, also record the baseline, owner, decision, evidence, open issue, and approval date. Use a real page or transaction so the team sees dependencies, exceptions, and the maintenance work that follows release.
| Decision point | Record | Acceptance criterion |
|---|---|---|
| Baseline | Observed current state | Source and date recorded |
| Decision | Selected option and rationale | Risk and audience considered |
| Evidence | Test, document, or measure | Reviewable and version-specific |
| Approval | Name, role, and date | All mandatory criteria met |
Score four factors before selecting a mode
Use a short decision workshop with the service owner, editor, accessibility specialist, and a person who knows the audience. Score audience need, task complexity, consequence of misunderstanding, and available review capability from one to three. A high audience-need score means many intended readers encounter literacy, language, cognitive, or situational barriers. A high consequence score means misunderstanding can remove an entitlement, create a financial loss, or prevent completion of an essential service.
The total is a prompt for professional judgement, not an automatic classification. Scores of four to six normally support Plain Language with editorial review. Scores of seven to nine justify additional evidence, such as user testing or parallel formats. Scores of ten to twelve indicate a strong case for an Easy Language version with specialist and target-audience review. Record any decision that differs from the score, including the evidence and accountable approver.
| Factor | 1 point | 2 points | 3 points |
|---|---|---|---|
| Audience need | Broad audience with strong reading experience | Mixed audience or stressful context | Known group with substantial comprehension barriers |
| Task complexity | One familiar action | Several conditions or documents | Multiple dependent decisions and unfamiliar terms |
| Consequence | Minor inconvenience | Delay or avoidable support contact | Loss of rights, money, health, or access |
| Review capability | Editorial review available | Specialist advice available | Specialist review and audience testing available |
Apply the matrix to real service scenarios
A library opening-hours page serves a broad audience, has a familiar task, and carries a low consequence. Plain Language is normally sufficient. A housing-benefit application combines eligibility conditions, evidence requirements, deadlines, and financial consequences. The general service page should use Plain Language, while an additional Easy Language explanation may be necessary for people who otherwise cannot understand their options. The application itself still needs accessible form design and support because a language version cannot repair an inaccessible transaction.
For an emergency warning, the audience is broad and the consequence is high, but speed and precision dominate. Use short direct Plain Language, established warning vocabulary, multiple channels, and tested visual cues. Do not apply a long Easy Language production cycle to the initial alert. A prepared Easy Language explanation can follow for sustained incidents. These distinctions show why audience, task, risk, and operational capacity must be considered together.
Use a real page and a named audience, not an abstract content category.
Include the consequence of both misunderstanding and delayed publication.
Separate the information page, form, confirmation, and support channel in the assessment.
State whether a parallel version supplements or replaces existing copy.
Identify evidence that will confirm the choice after release.
Turn individual decisions into portfolio rules
After assessing representative services, define content classes with default modes. General navigation, status messages, and service summaries can default to Plain Language. High-impact benefit, health, migration, justice, and disability journeys can require an explicit Easy Language assessment. Campaign slogans and legal source documents should not be transformed without a defined purpose and owner. Defaults reduce repeated debate while preserving an exception route for unusual audiences or risks.
Store the selected mode as structured metadata in the CMS. Useful fields include audience, decision score, source owner, language standard, reviewer, review status, source version, next review date, and exception rationale. The metadata enables reporting and prevents an unreviewed generated draft from being published as if it had passed the correct process. It also allows the team to find high-risk content when a rule, service, or terminology decision changes.
- 1
Assess five to ten representative services with the four-factor matrix.
- 2
Group similar decisions into content classes and define a default mode.
- 3
Create an exception rule with an accountable approver.
- 4
Add decision and review fields to the CMS content model.
- 5
Review the portfolio rules quarterly against user evidence and support demand.
Confirm the choice with evidence
For Plain Language, test whether intended readers can find the relevant passage, state the correct answer, and complete the next action. For Easy Language, recruit people who actually represent the defined audience and involve a specialist who can distinguish linguistic compliance from genuine comprehension. Capture task success, critical misunderstandings, assistance requested, confidence, and the exact revision that participants saw.
The mode decision is confirmed when the selected version meets its task criteria without creating a new accuracy or maintenance risk. If readers still fail because the form, navigation, or process is complex, record that as a service-design issue rather than repeatedly shortening the text. Approve the language mode, content, and surrounding journey as separate decisions, with owners for every unresolved dependency.
Roles, evidence, and approval
Language quality is an operating responsibility. Give the source owner responsibility for factual accuracy, an editor responsibility for clarity, a specialist responsibility for accessibility rules, and a product owner responsibility for publication. The release record should identify the source version, language mode, reviewers, test evidence, approval date, and the event that triggers a new review.
Operations and maintenance
The work does not end at publication. Link the language version or configuration to its source, monitor quality and service measures, and define concrete review triggers. Triggers include source changes, legal changes, new audience needs, recurring support questions, technical changes, and incidents. A named owner evaluates the trigger, opens a new revision when needed, and records renewed approval.
Release checklist
The audience and task are explicit.
All legal and operational facts match the source.
Dates, amounts, conditions, and exceptions are complete.
Headings describe reader questions or actions.
Links and controls have meaningful labels.
Specialist terminology is explained consistently.
The intended audience has tested the critical journey.
Ownership and the next review trigger are recorded.