Audience research
Part of Audience research for social scheduling in England, from sampling to the buying decision
Social scheduling persona hypotheses with contradictions and expiry dates attached
Build evidence-led social scheduling persona hypotheses for England with role, workflow, authority, contradictions, uncertainty and expiry fields.
Social media scheduling buyer personas are research hypotheses about roles and workflows. They are not fictional biographies and should never be presented as evidence that a type of buyer exists across England. A useful persona links each statement to eligible cases, contradictions and a review date.
What to take away
- Treat personas as hypotheses linking statements to eligible cases, contradictions and expiry dates.
- Separate participant statements, observable records, editorial inferences and supplier claims into distinct evidence types.
- Personas can become personal data, so remove names, restrict access and set deletion dates.
- Challenge patterns with a second analyst and preserve bounded hypotheses where cases split.
- Expire personas when permissions, authority, workflow or evidence base changes.
Use a role-and-work record
Begin with the decision, not a name or stock photograph. A persona card can contain:
Persona card required evidence
- Operating contextEngland geography rule, organisation unit
- Rolerecent preparation, approval, publishing, monitoring, buying task
- Triggerdated event prompting process review
- Authoritybudget, risk, account, supplier decision
- Present alternativenative, calendar, agency, software, none
- Acceptance evidenceobservable result before next decision
- Constraintspermissions, privacy, security, rights, contract, budget
| Field | Required evidence |
|---|---|
| Operating context | documented England geography rule and organisation unit |
| Role in the workflow | recent task showing preparation, approval, publishing, monitoring or buying |
| Trigger | dated event that caused the person to review the current process |
| Authority | budget, risk, account or supplier decision the person can actually make |
| Present alternative | native scheduling, shared calendar, agency, software or no recurring process |
| Acceptance evidence | observable result needed before the next decision |
| Constraints | platform permissions, privacy, security, accessibility, rights, contract or budget |
| Counter-evidence | eligible cases where the proposed pattern did not appear |
| Validity | supporting case count, field dates, owner and expiry trigger |
Do not infer motives from age, gender, disability, ethnicity or job title. Those attributes may be sensitive, irrelevant or misleading. Collect only what the question requires and obtain specialist equality and privacy review where personal characteristics matter.
Keep four voices apart
An operator might say an approval was late. The audit trail may show that the brief arrived after the deadline. A researcher might infer that hand-offs are unclear. A supplier might claim its queue solves the problem. Those are four different evidence types.
Four evidence types kept apart
Participant statement
- Example
- Approval was late
- Code as
- Statement
- Risk
- Taken as motive
Observable record
- Example
- Brief arrived after deadline
- Code as
- Record
- Risk
- Ignored
Editorial inference
- Example
- Hand-offs unclear
- Code as
- Inference
- Risk
- Universalised
Supplier claim
- Example
- Queue solves problem
- Code as
- Claim
- Risk
- Accepted as fact
Code them separately as participant statement, observable record, editorial inference and supplier claim. The persona should not convert any one of them into a universal motivation. No participant research was conducted for this article, so it reports no actual persona finding.
The Government Social Research ethical assurance guidance applies to government work, but its focus on sound interpretation, informed participation and minimising harm is a useful quality challenge. Commercial research still needs its own governance.
Protect the underlying records
Personas can become personal data when a small team or unusual incident makes someone identifiable. Remove names where they are not needed, restrict access and set a deletion date for recordings and source notes. The ICO's research safeguards guidance explains that anonymisation and pseudonymisation are different, and pseudonymous data remains within data-protection law.
Protect persona records
- Remove names where not needed
- Restrict access to source notes
- Set deletion date for recordings and notes
- Treat pseudonymous data as personal data
- Separate recruitment, research and marketing consent
Participation permission is not permission to contact someone with offers. Recruitment, research processing and later direct marketing require distinct decisions. The ICO's planning guidance for direct marketing is the publication-day starting point for the latter.
Challenge the pattern before naming it
Ask a second analyst to trace each persona statement back to the case matrix. Search deliberately for eligible cases that used a different approval route, solved the problem with native controls, or lacked buying authority.
A pattern supported only by the researcher's preferred recruits should not guide product design. Where cases split, preserve two bounded hypotheses or state that the evidence is inconclusive. Do not smooth disagreement into a more marketable story.
Publish the limits beside the persona
State the sampling frame, recruitment route, eligibility, interviews or survey completions, field dates and missing groups. Explain whether the evidence is England-only or contains labelled UK cases. Include awkward cases that challenge the pattern.
Expire a persona when platform permissions, buyer authority, workflow or the evidence base changes. If it cannot be traced back to real eligible records, label it an editorial scenario and keep it out of demand, pricing and product decisions.
Before you act
- Start with the decision, not a name or photo.
- Link each statement to eligible cases and contradictions.
- Code evidence types separately and avoid universal motives.
- Remove names and set deletion dates for records.
- Ask a second analyst to trace statements to cases.
- Publish sampling frame, field dates and missing groups.
Common questions
What evidence should a persona card include for operating context?
A documented England geography rule and organisation unit. The article states that operating context requires this evidence, alongside other fields such as role in the workflow, trigger, authority, present alternative, acceptance evidence, constraints, counter-evidence and validity.
How should a persona handle different types of evidence?
Code them separately as participant statement, observable record, editorial inference and supplier claim. The persona should not convert any one of them into a universal motivation. No participant research was conducted for this article, so it reports no actual persona finding.
When should a persona expire?
Expire a persona when platform permissions, buyer authority, workflow or the evidence base changes. If it cannot be traced back to real eligible records, label it an editorial scenario and keep it out of demand, pricing and product decisions.
