Landing page software buyer personas: the evidence card method, with a worked hypothetical example

What decision can an evidence card support?

An evidence card should justify a bounded research or product decision, not a claim about every buyer. No landing page, lead-capture or funnel software buyers were interviewed for these claims, so no England-specific persona is validated; the card is a research protocol, not a finding.

Name a choice that new evidence could alter, such as required form fields, published page content or information passed to a CRM. Connect each proposed requirement to a task rather than an assumed preference. Research around a decision keeps the work connected to an action the team can take.

Who belongs inside the research boundary?

Set the organisation, England connection and participant role before recruitment. A screening rule determines who qualifies, while a recent task explains why those people are relevant to the decision. Keep these limits clear so a job title or personal profile does not stand in for task evidence.

Record the recruitment frame, field dates and completed participants, with invitations, refusals, withdrawals and non-response where available. These details show how the sample was formed; they do not establish that it represents people who were not studied. Keep the operating context attached to each task rather than assuming it applies beyond the recorded group.

A page event during a stated period can inform a task, but a name, photograph or job label does not establish a need. Record what the participant did or described and the period concerned. That distinction helps reviewers see what the evidence says without turning an operational context into a buyer biography.

What needs to be written on each card?

Record the population, sample, recent task, repeated pattern, variation, contrary case, unknowns, decision use and expiry.

Link entries to research material where possible, and leave gaps visible rather than filling them with a plausible story. This makes the limits and intended use inspectable by people who did not conduct the research.

The hypothetical example further down is a record-keeping illustration, not proof of wider behaviour. It describes in-house page operators at a multi-site retailer with an England trading presence, discussing regulated product pages. Its record includes approval checks and a contrary case involving a minor copy edit.

Use participant codes and evidence references instead of names. Keep what someone said distinct from what a researcher observed and what the team inferred. A manager describing an operator is indirect evidence unless that operator was also studied; make the distinction clear when other people review the card.

How does a set of cards become a buyer persona?

The example below is invented to show the steps; it is not research and names no real buyer. Suppose the team holds four cards from in-house page operators, coded O1 to O4, and one from a compliance approver, coded A1.

The persona has codes beside every line and an expiry date, so a reviewer can check it. A named character with a photograph would not offer that.

How far can a small sample take the conclusion?

A qualitative sample can reveal recurring behaviour, but it cannot show how common a need is unless selection and counting support that conclusion. Keep interview patterns apart from population estimates, and do not extend a repeated observation to all English buyers.

For each study, record the recruitment frame, field dates and completed participant count. Include invitations, refusals, withdrawals and non-response where available, so readers can see how the group was formed. These details describe the evidence boundary; they do not make a limited sample representative of people who were not studied.

Avoid percentages when the eligible denominator or counting method cannot support them; the key metrics guide shows how to define each one. A repeated pattern is not a population estimate, and a changed denominator can alter the meaning of a reported rate. Check denominator changes before converting interview notes into numerical claims.

How should identity, access and research notes be handled?

Ask about access needs in relation to the session or product task, and use the participant's own language.

Do not infer protected or sensitive traits from a name, image, postcode, device or browsing history. Recruitment choices can also affect who appears in the evidence, so record the boundary of the sample.

The Equality Act 2010 applies in England; consult a qualified reviewer about duties relevant to the actual case. Section 20, on reasonable adjustments, is a sensible starting point when planning access for participants. Interview notes and recordings also contain personal information, so plan their handling before collection.

Document the lawful basis, access rules and retention period. Use participant codes, remove direct identifiers from extracts shared more widely, and restrict access. These steps do not replace a review of the research data or its processing; consider role-specific data handling and ICO impact assessment guidance where an assessment is relevant.

When should a card be checked again?

Give each record an owner, version, evidence cut-off and change log. Recheck its basis when the supplier, workflow, regulation or eligible organisation changes. Retire it if the sample cannot be traced, the eligibility rule has shifted or contrary evidence weakens its use.

Keep each conclusion within the evidence. A bounded finding might describe sampled page operators needing clearer approval state during a stated period; it should not claim that all English buyers share the need or that the pattern proves willingness to purchase. Start wider research with a recent decision and keep measurement definitions stable when judging results.

What should I do first?

Name the decision that research could change, then set the group and task boundaries before collecting evidence. Make the first card open to challenge by recording uncertainty, contrary cases and an expiry trigger alongside any repeated pattern.