Clarify the task and decision
This guide turns target-audience testing into a reviewable operating workflow. It connects domain decisions, ownership, evidence, and acceptance so the result continues to work in production.
Test whether people can complete a real task, explain the result, and identify their next action without coaching.
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 five-participant service test combines observation, comprehension questions, and confidence scoring. 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 |
Recruit for the actual barriers and task
Write a recruitment profile from the service audience, not from a generic demographic label. Include reading experience, familiarity with the service, language background, cognitive or learning disability where relevant, device use, and whether support is normally available. Exclude people who helped create the content. For an Easy Language test, recruit through trusted self-advocacy groups or specialist partners and compensate participants fairly for preparation, participation, and travel.
Five participants can reveal major task failures in a focused formative round, but the number is not a universal proof of quality. Run additional rounds when audiences differ materially, tasks contain several decision paths, or critical issues persist. Record the recruitment criteria, who was represented, who was absent, and why. This lets decision-makers understand what the findings support and where more evidence is required.
Recruit people who match the intended readers and their service context.
Provide accessible invitations, consent information, venue, and technology.
Pay participants and support persons under a published arrangement.
Avoid collecting health or disability details that are not needed for the test.
Report relevant gaps in representation.
Test decisions and actions, not opinions
Build each task around a realistic situation. Instead of asking ‘Is this text easy?’, say: ‘You moved to this city yesterday. Use this page to find what you must do, what you need to bring, and when you need to act.’ Define the correct answer, acceptable partial answer, critical error, and expected next action before sessions begin. Use the published interface or a faithful prototype so navigation and presentation are included.
Ask participants to work without coaching. The facilitator can remind them to continue thinking aloud but must not explain a term or point toward the answer. After the task, ask neutral comprehension questions: ‘What happens next?’, ‘Who must do this?’, ‘When would this rule not apply?’, and ‘Where would you get help?’ Request an explanation in the participant’s own words rather than a yes or no confirmation.
- 1
Choose the three highest-impact reader tasks.
- 2
Write a realistic scenario without repeating the answer wording.
- 3
Define success, partial success, critical failure, and assistance rules.
- 4
Pilot the script with one person and remove accidental clues.
- 5
Use the same core protocol for every participant in the round.
Combine observation, comprehension, and confidence
For every task, record whether the participant found the relevant content, reached the correct understanding, completed the action, requested assistance, and expressed confidence. Use a three-point result: 2 for correct independent completion, 1 for partial completion or non-leading assistance, and 0 for failure or a critical misunderstanding. Confidence is recorded separately because a confident wrong answer is a serious design risk, not a near success.
Tag the point where each issue occurred and quote only short phrases needed to explain the observation. Do not treat every hesitation as a copy problem. A failure may originate in navigation, form design, missing service policy, unfamiliar identification requirements, or inaccessible controls. Assign each finding to the responsible discipline and retain the connection to the tested revision.
| Measure | Evidence | Release expectation |
|---|---|---|
| Findability | Participant reaches the relevant section | No critical path depends on search or facilitator help |
| Comprehension | Participant explains rule in own words | No critical misunderstanding |
| Task success | Participant identifies and completes next action | Critical tasks completed independently |
| Confidence | Participant rates certainty after answering | Wrong high-confidence answers resolved before release |
Revise, retest, and make a release decision
Hold an evidence review within one working day while observations are fresh. Group issues by root cause, severity, and affected audience. Critical findings are wrong decisions, missed mandatory actions, unsafe behaviour, or abandonment of an essential task. Revise those first and retest the changed path with new or returning participants. Cosmetic preferences do not outweigh repeated successful comprehension.
The release record should state the tested revision, participants and relevant characteristics in anonymised form, task protocol, results, changes made, unresolved findings, and approver. Accept the page when every critical task can be completed, no critical misunderstanding remains, and major issues have owners and deadlines. Schedule a follow-up test after material source, process, navigation, or audience changes.
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.