How to develop and assess audience definition in AI-enabled work

Define the audience from evidence, not a persona label

GOV.UK service guidance recommends learning who likely users are, what they are trying to do, how they do it now, the problems they encounter, and what they need to reach an outcome. It also says teams should understand all kinds of users rather than only a typical user and treat unsupported stakeholder opinions as assumptions. Its user-research introduction adds that research should include disabled users and people who need support, continue through development, and focus on what works rather than what is merely popular.

For knowledge work, the equivalent is to define the reader through the decision and use context. “Executives” or “customers” is too broad to control what evidence, language, detail, format, or action the deliverable needs.

Build a READER audience card

Use READER before drafting or prompting an AI assistant:

| Field | Question | Evidence to retain | | --- | --- | --- | | Role | Who acts, who advises, who approves, and who is affected? | Named audience groups and decision rights | | End task | What must each group decide, understand, check, or do? | Observable use of the deliverable | | Access context | Where, when, and through which format will they use it? | Channel, time, device, accessibility, and confidentiality needs | | Domain baseline | What can they reasonably be expected to know? | Familiar terms, necessary definitions, and evidence source | | Evidence threshold | Which claims, figures, limitations, or provenance details do they need? | Decision stakes and verification requirement | | Response | What should happen after they use the artifact? | Action, owner, feedback route, or next decision |

Add an evidence status to each field: observed, reported, documented, or assumed. That status prevents a guessed preference from being presented as user knowledge. When groups have conflicting needs, create separate rows and decide whether one layered artifact, two versions, or another channel is appropriate.

AI can help generate questions, identify missing groups, or test whether language assumes specialist knowledge. It should not invent audience facts. A generated persona becomes useful only after its fields are replaced or qualified with task evidence.

Worked example: a synthetic policy-change briefing

Imagine a synthetic operations team preparing a briefing about a changed expense-approval rule. The source pack includes the policy, an implementation date, a manager message, and support-ticket excerpts. This example is invented and does not represent a Two Prune customer.

The first AI-generated draft targets “all staff.” It opens with policy history, uses finance terminology, and ends without a clear action. The participant builds three READER rows:

The revised output uses a short staff notice for the first group, a manager decision table for the second, and a linked support note for the third. The manager message is labelled as reported context because it does not override the policy. The team also flags an open question about claims submitted before but approved after the change date.

The artifact is now differentiated by reader task, not by superficial tone. A reviewer can trace each format and content choice to the audience card rather than accepting “make it executive” or “make it simple” as sufficient direction.

• Employees submitting expenses: need to know which claims change, what evidence to attach, and when the rule begins. They will scan an intranet notice, may be unfamiliar with approval codes, and need a link to accessible step-by-step guidance.
• Line managers approving claims: need to identify exceptions, apply the transition rule, and escalate ambiguous cases. They use a short briefing during team meetings and need decision examples plus the policy source.
• Finance support staff: need to answer questions consistently and log recurring problems. They require the full policy, exception definitions, and an owner for unresolved interpretations.

Practice with an audience-switch exercise

Give a learner one evidence pack and two readers who must take different actions. For example, ask for an incident update for an accountable owner and a separate handover for the team doing the repair. After the first draft, introduce a third audience with an access constraint or lower domain familiarity.

Require the learner to update the READER cards before revising the artifact. The useful behavior is not replacing words with simpler synonyms. It is reconsidering evidence depth, ordering, format, action, and limitations when the user and use context change.

A focused practice cycle should include:

• identifying primary, secondary, affected, and excluded audiences;
• separating audience evidence from stakeholder assumptions;
• naming the decision or action each group owns;
• checking accessibility, channel, time, and confidentiality constraints;
• testing terminology and evidence depth with a representative reader;
• recording why one artifact can serve several groups or why separate versions are needed.

Assess the framing decisions and the resulting artifact

In an assessment, provide incomplete and partly conflicting audience signals. Include a formal brief, a stakeholder request, evidence of how the artifact will be used, and one group that could be overlooked. Ask for a deliverable plus a compact audience record.

Score observable evidence such as:

Do not reward demographic detail that does not affect the work. Do not infer audience skill from a polished tone alone. A concise artifact may be appropriate for one use and dangerously incomplete for another.

• the participant identifies the actual user and decision rather than repeating a job label;
• audience claims are tied to source evidence or marked as assumptions;
• affected and support users are considered alongside the primary decision-maker;
• domain knowledge, access conditions, and evidence thresholds shape the design;
• conflicts between audience needs are resolved explicitly;
• AI-generated audience suggestions are checked rather than adopted as facts;
• reader feedback causes a relevant revision to content, structure, or channel.

Verify with task retrieval, not preference questions

Ask a representative reader to use the draft to complete the intended task. Can they find the decision, locate the evidence or limitation they need, and state the next action? Record retrieval failures and revise the READER field that caused them. A general question such as “Do you like this?” produces weaker evidence because approval does not show whether the artifact works.

Check excluded groups and edge conditions explicitly. Confirm that the chosen format is accessible in the actual channel and that necessary definitions do not rely on institutional knowledge unavailable to the reader. Preserve a short record of what remains assumed.

Audience definition is task-dependent. A participant may frame one audience well and miss another in a different context. In a Two Prune assessment, the audience card, source review, revisions, and final artifact can contribute bounded evidence about Context Framing, Judgment & Synthesis, and Communication & Delivery. They do not establish general interpersonal ability, future performance, or suitability for employment.

Sources

GOV.UK guidance on learning about users and their needs

• GOV.UK introduction to user research for government services

Sources: [1] [2]