What Is a Persona? Research-Based Creation, Example, and Review Checklist
Published:
Last Updated:
Category: Marketing Glossary
Authors: Shusaku Yosa
A persona is a fictional composite built from research patterns in people's goals, tasks, behavior, and constraints. It is not a copied individual or an imagined lifestyle assembled from age and occupation. First decide whose situation matters and which decision the persona will support.
Adding a name, photo, income, and family details does not make a profile evidence-based. Separate research observations, synthesized patterns, untested hypotheses, and unknowns. Use the result to develop ideas, then test those ideas with real people. This guide uses a fictional invoice-management example to show the process.
Personas, target segments, ICPs, and user stories
Organizations use these terms differently. The following distinctions clarify the unit and decision involved rather than prescribing the only valid terminology. Agree on the inputs and intended use within the team.
Concept | Typical input or unit | Main use | Limitation |
|---|---|---|---|
Target segment | A customer group with relevant shared conditions | Decide whom to serve | Members do not all behave alike |
Ideal customer profile | Company problems and operating conditions | Select suitable accounts | Company fit is not an individual's motivation |
Customer profile | Attributes, transactions, or account information | Describe and classify records | Define which fields and meanings are used |
Persona | Research patterns synthesized into a role or person | Share needs and evaluate ideas | Neither a real individual nor the whole market |
User story | A role, desired task, and purpose | Express a use case or requirement | Does not replace research |
Nielsen Norman Group's persona guidance explains research-based composites, relevant detail, and why personas do not replace user testing. The publisher's sample for Alan Cooper's book identifies the first-edition introduction in 1999. The practical importance is the research basis, not memorizing a historical label.
Start with a decision and distinguish roles
Choose a question such as how to present invoice-checking tasks or what to explain during onboarding. A persona intended to answer every marketing and product question tends to contain unnecessary detail and weak assumptions.
In B2B, the user, buyer, budget owner, approver, and technical reviewer may differ. Combining their authority and needs into one fictional person can create a product or message that fits nobody. Account-based planning maps actual people and confirmed roles separately from persona research.
Do not set the number of personas from a fixed demographic formula. Look for differences in goals, actions, constraints, and evaluation criteria that would change a decision. Profiles with different names but the same practical needs may not need to remain separate.
Design research and record its bias
Existing customers alone may miss people who could not get started, left, rejected the offer, or chose alternatives. Define the relevant differences, recruitment conditions, methods, dates, and exclusions. Consider access needs and operating environments where they affect the task.
- Define the decision, workflow, situation, and relevant roles.
- Choose necessary comparisons, including lost or non-customer perspectives where appropriate.
- Combine interviews, observation, support questions, and behavioral records.
- Ask about actual recent situations rather than leading people toward a preferred feature.
- Record who was missing and which conditions remain untested.
“Wouldn't useful automation help?” is leading. “What did you check at the last month-end, and what happened when work stopped?” invites more specific evidence. When stated preferences and observed behavior differ, investigate the context rather than discarding whichever contradicts the team's idea.
CRM represents people with recorded contact, logs represent measurable activity, and surveys represent respondents. Their populations, missing data, anonymity, and self-selection differ. GA4 or an NPS score cannot alone establish an individual's motives or the whole market's needs.
A fictional research example
The following records are fictional illustrations. A and B are invoice-operations users; C is an approver. Three people are not claimed to represent a market. The example shows how evidence and roles remain distinct.
Evidence ID and role | Fictional statement or observation | Candidate pattern | Unknown |
|---|---|---|---|
A: operations user | Reconciles several sheets at month-end and tracks missed checks separately | Checking work concentrates near a deadline | Whether other months behave similarly |
B: operations user | Work stops when the person responsible for a correction is unclear | Ownership visibility may matter | Effects of organization and permission differences |
C: approver | Final approval requires supporting evidence and change history | Approvers may need traceable checks | Required records and responsibility boundaries |
A and B can inform a candidate operations persona. Do not give that persona C's approval authority. Nor should a team infer social-media habits, income, or preferences from the person's age or role without relevant evidence.
Retain contradictions. If one participant uses paper and another uses spreadsheets, investigate whether the same underlying need exists under different constraints. Do not select only convenient similarities to make a polished profile appear coherent.
An evidence-linked persona worksheet
This is a candidate composite from the fictional research above. Names, ages, and photos are optional memory aids, not mandatory fields. There is no need to reproduce real names or irrelevant personal information in the working artifact.
Field | Fictional entry | Evidence status |
|---|---|---|
Role | Operations employee performing month-end invoice checks | Candidate based on A and B |
Goal | Complete necessary checks before the deadline | Synthesized from statements and work |
Current behavior | Compare sheets and ask owners about corrections | Observed in A and B |
Constraints | Concentrated workload and unclear ownership or permissions | Limited to observed conditions |
Evaluation criterion | Seeing unchecked items and owners may help | Hypothesis to test |
Other roles | Final approval may belong to someone else | Keep C and account-specific checks separate |
Unknowns | Access environment, exceptions, support needs | Further research required |
Maintenance | Evidence IDs, dates, owner, validation date | Retain for review |
“Adding a check screen will increase satisfaction” does not follow as a confirmed fact. It is an idea to test: can people find missing work, identify responsibility, and proceed without new burdens? A persona should make such questions clearer, not make the result predetermined.
Apply the persona and validate with real people
A persona is a shared thinking tool. Saying “this person would like it” in a meeting adds no evidence. Record the selected and rejected ideas, the research used, and what could disprove the hypothesis.
Decision log | Example entry | What to test |
|---|---|---|
Decision | How to show pending checks and owners | Understanding in a real task |
Evidence | Statements and observations from A and B | Relevance under other conditions |
Alternatives | A list, staged screens, or current workflow | Information and interaction burden |
Hypothesis | Clear ownership may reduce questions | Actual confusion and support needs |
Result | Findings, counterexamples, changes | Continue, revise, or decline |
In user testing, recruit real people with relevant conditions rather than asking someone to act out the persona. If observed work contradicts the profile, revise the profile. It is not ground truth simply because it has been documented and approved.
Use PEST analysis for macro changes and 3C analysis for customer, competitor, and company relationships. Those frameworks do not directly prove individual behavior either. If using AIDMA, keep psychological stages as hypotheses rather than inferring them conclusively from clicks or opens.
Update, merge, or retire a persona
Review when customer composition, the product, operating environments, loss reasons, or support issues change. A yearly update can be a routine choice, but it is not the only valid trigger. Keep the last verification date and evidence behind material claims.
- Have demographic attributes been used to invent behavior?
- Are users, buyers, and approvers distinct where necessary?
- Are observations, patterns, hypotheses, and unknowns labeled?
- Are recruitment bias, exclusions, and counterexamples visible?
- Is every personal detail relevant to the decision?
- Is an owner responsible for validation with real people?
Merge or retire profiles that duplicate one another or no longer affect decisions. More interviews alone are not a completion criterion: identify what remains uncertain and which decision it affects. Creating a persona does not guarantee revenue or satisfaction improvements.
Xtrategy's features include project ownership and budget-versus-actual management that can help organize the resulting initiatives and tests. Use that structure to share evidence, decisions, implementation, and learning, rather than treating a generated profile as automatic knowledge of customers.
