Audience research
Licensing buyer personas that separate applicant, payer and operator roles
Build evidence-based buyer personas for England business-licensing services, separating applicant, payer and operator roles while avoiding invented detail.
A useful buyer persona for licensing work describes a real task, authority boundary and decision role. It does not need a fictional name, stock photograph or invented salary. If a detail does not change content, service design or purchasing, leave it out.
What to take away
- A licensing persona describes a real task, authority boundary and decision role, not a fictional name or invented salary.
- Map four rolesuser, applicant, payer and operator, because one founder may hold all four while larger venues divide them.
- Tag each persona field as observed in several cases, observed once or inferred for testing, so weak parts are easy to challenge.
- Attach at least one design decision and one measure to each persona so it earns its place in the work.
- Review the persona after new interviews, service changes or expansion to another licensing family, and date the evidence.
Base the persona on observed cases
Interview people who recently handled the target task and review application forms, decision notices and internal approval emails they can lawfully share. Government Digital Service guidance on planning user research recommends linking participant groups and methods to service decisions. Record which observations support each element of the persona and how many cases were involved.
Separate direct evidence from inference. An applicant who says they were confused by a field supports a comprehension finding. It does not prove that every applicant is confused or that the authority designed the field poorly.
Map four roles before writing
The user completes the task. The applicant is named on the form or makes the declaration. The payer approves spending on support. The operator implements conditions after a decision. A founder may hold all four roles, while a larger venue may divide them between finance, property, operations and an external adviser.
Map four roles
| Role | Decision | Artefact | Typical holder |
|---|---|---|---|
| User | Completes the licensing task | Service session or task list | Front-line manager or administrator |
| Applicant | Signs the declaration and accepts legal responsibility | Application form or declaration | Founder, licensee or named officer |
| Payer | Approves spend on support | Budget approval or purchase order | Finance director or owner |
| Operator | Implements conditions after a decision | Decision notice and conditions handover | Venue manager or supervisor |
Four licensing roles compared
User
- What they do
- Completes the task
- Who holds it
- Founder
- Larger venue
- Operations
- Key question
- Who acts?
Applicant
- What they do
- Named on form
- Who holds it
- Founder
- Larger venue
- Property
- Key question
- Who declares?
Payer
- What they do
- Approves spending
- Who holds it
- Finance
- Larger venue
- Finance
- Key question
- Who pays?
Operator
- What they do
- Implements conditions
- Who holds it
- Operations
- Larger venue
- External adviser
- Key question
- Who complies?
GOV.UK's council finder uses the relevant postcode to identify a local authority website. Include location responsibility in the persona where the service routes local licences. Someone coordinating several premises has a different problem from a person opening one site, even if their job titles match.
Give the persona a licensing task
Describe the activity, site, journey stage, deadline source, evidence and authority contact. For a premises case, GOV.UK's premises licence record routes applications to the relevant local authority in England and Wales and identifies covered activities. It can anchor the scenario without pretending that one generic form applies everywhere.
Premises licence task journey
- Identify council route by postcode
- Coordinate plans and internal approvals
- Understand what remains conditional
- Hand granted conditions to supervisors
A concise persona might therefore describe an operations manager adding regulated entertainment at an existing English venue. The manager must identify the council route, coordinate plans and internal approvals, understand what remains conditional and hand granted conditions to supervisors. That task description can guide navigation, document storage and alerts.
A fully worked example with evidence tags:
Persona field / Example value
- Role
- Operations manager who also acts as applicant and operator; finance director acts as payer · Observed once
- Task
- Add regulated entertainment at an existing English venue · Observed in several cases
- Site
- Single existing premises with a premises licence · Observed in several cases
- Journey stage
- Pre-application planning through to conditions handover · Inferred for testing
- Deadline source
- Event date and council processing time · Observed once
- Authority contact
- Local council licensing team found by postcode · Observed in several cases
- Evidence
- Plans, operating schedule and internal approval email · Observed once
- Authority boundary
- Manager may submit; finance director approves spend · Observed once
- Constraint
- Time pressure before season and no dedicated licensing lead · Observed once
- Design decision
- Test council route finder and labels that distinguish submission from approval · Inferred for testing
- Measure
- Share of users who find the correct council route and know submission is not approval · Inferred for testing
Interview prompts: What task triggered the licence work? Who signs the declaration? Who approves spending? Which artefacts record the decision? What would make you stop or restart?
Include constraints that affect design
Record access to records, authority to make declarations, digital confidence, assistive technology needs, language and time pressure only where research shows an effect. Avoid decorative assumptions about hobbies, personality or income. Note disagreements between the person using the service and the person accepting risk.
Make the persona earn its place
Attach at least one design decision and one measure. Government Digital Service guidance on using data to improve a service supports linking measures to user needs and improvement decisions. For the venue manager, the team might test whether users can find the correct council route and identify that submission is not approval.
Keep more than one evidence level
Tag each persona field as observed in several cases, observed once or inferred for testing. This makes weak parts easy to challenge. Preserve a short note about conflicting evidence, such as one manager wanting central control while another delegates each premises. Do not smooth the disagreement into an invented average person.
A working minimum is three independent interviews or artefacts for a field that guides a regulated decision, or two sources plus a documented test for low-risk language. A single observation is a hypothesis, not a persona field.
Review the persona after new interviews, service changes or expansion to another licensing family. Remove unsupported details, date the evidence and keep local experience labelled. Note the researcher and latest review decision on the working record. Keep the working synthesis dated and linked to the evidence record.
Before you act
- Interview people who recently handled the target task and review application forms, decision notices and internal approval emails they can lawfully share.
- Separate direct evidence from inference and record how many cases support each element.
- Map the user, applicant, payer and operator roles before writing the persona.
- Describe the licensing task, site, journey stage, deadline source, evidence and authority contact.
- Record only constraints that research shows affect design, such as access to records or digital confidence.
- Tag each field by evidence level and note conflicting evidence rather than smoothing it.
Common questions
What should a licensing buyer persona contain?
It should describe a real task, authority boundary and decision role. It does not need a fictional name, stock photograph or invented salary. If a detail does not change content, service design or purchasing, leave it out. Base it on interviews and lawful artefacts such as application forms, decision notices and internal approval emails.
Why map four roles before writing the persona?
The user completes the task, the applicant is named on the form or makes the declaration, the payer approves spending on support, and the operator implements conditions after a decision. A founder may hold all four roles, while a larger venue may divide them between finance, property, operations and an external adviser.
How should evidence levels be handled in a persona?
Use the tags and threshold in "Keep more than one evidence level". Record sample counts, dates and disagreements there, not as a second rule.
