Personas for grant users that stay honest about what the evidence shows

The phrase "buyer persona" is awkward for grants because an applicant is not buying the award. A better tool is an evidence-based user profile that describes a recognisable situation, task and barrier without pretending that a fictional character represents every business owner.

What to take away

• Use an evidence-based user profile that records a situation, task and barrier rather than a fictional buyer persona.
• Record the source for every profile point, because interview evidence, application data and official datasets answer different questions.
• Leave out invented names, photographs, quotations, salaries and family stories, which create false confidence and encourage stereotypes.
• Attach a short exceptions list showing which users do not fit and which evidence remains weak or open.
• Give every profile an evidence date and owner, and retire it when eligibility or behaviour changes.

What belongs in a profile

Include the business stage, English location, sector, project task, funding need, decision role, evidence available, access needs and likely service route. Record the source for each point. Interview evidence, application data and an official business dataset may all contribute, but they answer different questions.

The ONS business activity, size and location dataset can describe the VAT and/or PAYE-based enterprise population by region or industry. It cannot tell an editor what an individual owner thinks.

What to leave out

Do not invent a name, photograph, quotation, salary, family story or personality merely to make the profile memorable. Decorative details create false confidence and can encourage stereotypes. If age, ethnicity, disability or gender affects access to the programme, use properly gathered evidence and explain why the characteristic matters.

Avoid profiles such as "Ambitious Anna wants to scale her exciting brand". The wording is promotional, the motivation is assumed and the task is unclear.

Base profiles on behaviour

A useful profile might describe a director of a young manufacturing company who needs to compare a planned equipment purchase with a regional grant deadline, has accounts but no internal grant specialist, and must secure match funding. Each element points to a content or service requirement.

Research actual events. The GOV.UK Service Manual recommends learning who users are, what they are trying to do and how they currently complete the task. Its guidance on learning about user needs also recommends reviewing existing evidence before and during direct research.

Keep exceptions visible

Personas compress evidence, so they can hide variation. Attach a short exceptions list: which users do not fit, which evidence is weak and which questions remain open. Do not use a persona as a reason to exclude an eligible group from research.

Connect each profile to a decision

Add a short "therefore" statement to every profile. A business with no internal finance specialist may need a plain explanation of eligible costs before it sees the application form. A recipient waiting for reimbursement may need a cash-flow check before accepting the award. These are testable service decisions, not claims about personality.

Keep a traceability table with four columns: profile statement, supporting evidence, confidence and affected decision. If a statement has no source or no decision attached, remove it. If the evidence comes from one interview, describe it as an observation from that participant rather than a settled audience characteristic.

Profiles should also show the stage of the journey. The same director may act differently while discovering a scheme, assembling evidence and delivering an awarded project. A single static label can hide those changing tasks.

Protect participant privacy

Combine and anonymise findings so a profile cannot be traced back to one participant unless the person has given properly reviewed permission. The Service Manual's research privacy guidance says teams should collect only necessary data, restrict access and use research data within the purpose explained to participants.

Review and retire profiles

Give every profile an evidence date and owner. Revisit it when eligibility changes, a new application route launches or evidence shows different behaviour. Remove profiles that no longer inform a decision.

A profile earns its place when it changes a design, outreach or support decision. If it merely adds a name and stock photograph to a slide, delete it. This draft contains no live internal links and remains on hold for named review.

Before you act

• State the business stage, location, sector, task and funding need.
• Record the source for each point in the profile.
• Remove decorative details such as invented names and quotations.
• Add a therefore statement linking the profile to a decision.
• Keep a traceability table with evidence, confidence and affected decision.
• Anonymise findings and set an evidence date and owner.

Common questions

What should a grant user profile contain?

Include the business stage, English location, sector, project task, funding need, decision role, evidence available, access needs and likely service route. Record the source for each point, because interview evidence, application data and an official business dataset answer different questions.

Why are invented names and photographs a problem in profiles?

Decorative details create false confidence and can encourage stereotypes. The article says not to invent a name, photograph, quotation, salary, family story or personality merely to make a profile memorable. If age, ethnicity, disability or gender affects access, use properly gathered evidence and explain why the characteristic matters.

How should profiles handle variation and privacy?

Personas compress evidence, so attach a short exceptions list covering users who do not fit, weak evidence and open questions. Combine and anonymise findings so a profile cannot be traced to one participant unless that person has given properly reviewed permission, and collect only necessary data.