Buyer Persona: Build a Profile from Research, Not Guesswork

A marketing team may have a beautifully designed card for its ideal customer: a name, a photograph, an age, a job and a list of favourite apps. Yet when the designer asks what should appear before the purchase button, or a salesperson asks why the buyer hesitates, the card offers no answer. The problem is not a shortage of colour or detail. The persona was never built to support a specific decision, and it does not distinguish information gathered from people from details invented by the team.

A buyer persona is a tool for organising our understanding of a recurring pattern of needs, behaviours and constraints around a purchase decision. In this lesson, we turn reviewable evidence into a useful persona, then translate it into a message, an experience and a test. All names, organisations, quantities and results in the examples below are hypothetical teaching material. They do not describe real customers, market averages or guaranteed future performance.

What is a buyer persona, and how is it different from a segment?

A segment is a group we distinguish for a strategic reason, such as a different need, use case or ability to access an offer. A persona is a focused description that helps a team understand a pattern within its audience: the task people are trying to accomplish, what prompts their search, how they compare alternatives and what prevents progress. A segment may contain several personas when these differences genuinely change the marketing decision.

A persona does not represent every detail of a real person's life, nor should it be an arithmetic average of unlike customers. Consider a shop serving both an urgent gift buyer and someone furnishing a home gradually. Combining them into “a customer who cares about price and quality” removes the useful distinction. The gift buyer needs a dependable delivery date and suitable wrapping; the home buyer needs comparisons, measurements and coordinated options. Here, the shorter description provides less practical guidance.

A buyer persona also differs from a user persona. A procurement department may purchase software used by an operations team, while another manager approves the budget. Buying questions concern comparison, contracting and risk; usage questions concern completing everyday work. One person may perform both roles, but do not assume this. Similarly, a business-to-business ideal customer profile usually describes the type of organisation that fits the offer, whereas personas describe the needs of people and roles within that organisation.

Origins and the limits of attribution

The development of personas in interaction design is associated with Alan Cooper's work. He explained how imagining a specific user and that user's goals helped guide design decisions. This does not mean he invented every modern marketing template, or that one universal persona card should be copied everywhere. The idea has travelled into different applications, and research and marketing teams have developed formats suited to their particular decisions.

The teaching materials from Jenna Tiffany's lectures present four dimensions, with examples and adaptable cards. We will explain those dimensions and then explicitly separate evidence, interpretation and hypothesis. That separation is an original teaching structure used in this article, not a model whose invention we attribute to the lecturer. A persona's name or photograph is only a memory aid: neither makes the information credible nor compensates for missing research.

Start with the decision, not the card

Define a practical question the team can act on. Perhaps you want to improve a training-course page because visitors cannot tell whether the course suits their level, or reduce withdrawals after customers receive a quotation. “We want to understand our audience” is too broad to determine what to collect. Instead ask: what information does the buyer need to decide confidently, and where does our current experience fail to provide it?

Define the boundaries of use as well: the product, the market you can serve, the journey stage and the period described by the data. A card about buying a first subscription does not automatically explain renewal, because the customer now has direct experience. The same person's needs may differ when buying a service for work and choosing it for personal use. Put the scope at the top of the card so it cannot quietly migrate into another context without review.

Decide what will make the card useful before producing it. It should change an identifiable decision: the order of information, the explanation of value, the assistance offered, the offer's terms or where a message is tested. If you add a detail but cannot explain which decision it might affect, it may be unnecessary. This does not remove human empathy; it prevents empathy from becoming a lengthy fictional biography that helps neither the customer nor the team.

The four dimensions: what do we need to know?

The demographic dimension describes characteristics relevant to the question, such as career stage or the language used for the task. Do not automatically collect age, gender or education just because a template contains those boxes. If understanding the language of instruction affects product use, that is relevant. Assuming everyone of the same age prefers the same platform, however, turns a broad description into an untested causal explanation.

The psychographic dimension concerns the values, priorities and motivations people express in the decision context. A buyer may care about avoiding surprises or demonstrating the value of the choice to colleagues. Do not infer this from a photograph or job title, and do not assign a “fear” or “ambition” score that looks scientific without a defined measure. Record what was said and what happened, then explain the limits of your interpretation.

The behavioural dimension asks what people do: how they search and compare, which tools they use, when they seek help and where they stop. Observing a page visit does not reveal the visitor's purpose. An abandoned basket might be saved for comparison rather than rejected because of price. When you need an explanation, connect the behaviour to a question, interview or task test, keeping the observation separate from its presumed cause.

The environmental dimension describes the conditions of use and purchase: location, time, devices, participants and constraints. It does not refer only to concern for sustainability. Someone reviewing an offer on a phone between tasks needs a different experience from a team comparing documents on a large screen. In either case, a difficult circumstance is not proof of personal inability; the problem may lie in service design or communication timing.

The status of information matters more than its appearance

Nielsen Norman Group distinguishes proto-personas built from team assumptions, personas based on qualitative research, and personas informed by qualitative and quantitative work and statistical analysis. The choice depends on the purpose and available data. Above all, do not present a hypothetical card as a research finding or infer a group's market size from a few interviews. A proto-persona can be a useful beginning if its assumptions remain visible and open to revision.

Use three written labels: “evidence”, “interpretation” and “hypothesis”. Evidence is a documented observation with a source, date and context. Interpretation is an explanation that brings observations together and may have alternatives. A hypothesis is a claim you intend to test that the data have not yet established. Add “unknown” when information is insufficient. This is a useful answer because it prevents a gap from being filled with a guess that looks final.

For example, “four participants asked about the start date” is evidence within particular interviews. “Schedule clarity matters during comparison” is a preliminary interpretation. “Putting the date near the top of the page will increase registrations” is a hypothesis requiring a test. Do not compress all three into “the customer wants speed”. That wording might encourage shorter explanations when people actually wanted a clear timetable.

Reading the diagram: Read the cards from top to bottom. An arrow indicates movement to a level that requires interpretation or testing; it does not mean the conclusion is certain. This is an original teaching structure, and the preceding paragraphs contain the same information. Open the SVG version to enlarge it.

Gather evidence from people who bought and people who did not

Begin by reviewing what you already have: support questions, reasons for lost orders, sales notes, usability-test findings and aggregated journey data. Check the definition of each record. Ten support requests might come from one person, and a page visit is not an independent customer. Do not combine different sources into a single denominator or confuse the number of conversations with the number of people experiencing a problem.

Plan interviews covering varied experiences relevant to the decision, such as recent buyers, people who compared and chose an alternative, and people who stopped after an initial trial. Do not rely only on your happiest customers or the easiest people to reach. Record whom you reached and who is missing: an absent group may explain an absent need on the card. Participant selection is part of evidence quality.

Ask participants to describe a recent, actual experience. What happened that started the search? Which alternatives did they compare? What information could they not find? Who participated in the decision? What made them continue or stop? Questions about past behaviour provide clearer material than asking people to imagine their future actions. Even so, memory has limits, and an account may differ from recorded behaviour.

Avoid questions that supply the answer, such as “Wasn't the price too high?” Ask “How did you assess the cost?” and then clarify what they compared it with. Do not turn the interview into a sales presentation in which you defend the product. Its purpose is learning, including hearing explanations that do not support your favourite idea. Explain the purpose and use of the notes, and collect only what you need.

Then organise statements by topic: the trigger for searching, the desired outcome, selection criteria, barriers and required assistance. Keep each observation connected to its anonymised internal source. If two team members interpret it differently, discuss the original statements rather than voting for the most attractive persona. Disagreement may indicate two patterns or insufficient data.

A complete example: a hypothetical training platform

Imagine a platform called Khatwa, meaning “Step”, offering a short practical workshop on preparing reports. The team notices frequent questions before payment about the workshop's level and timetable. Its decision is how to reorder the workshop page and enquiry messages so suitable buyers can assess the fit. We will not assume every question signals weak interest, or that increasing registrations is the only outcome that matters.

In this hypothetical example, the team conducts twelve interviews: six people who registered, four who compared but did not register, and two who cancelled after registering. It also reviews forty support conversations from one month, removing repeated mentions within each conversation, and three hundred qualified visits to the workshop page. These are different sources. Adding them together and claiming a study of 352 customers would be invalid: the people may overlap, and the units of measurement differ.

Seven interviews reveal a need to understand whether the prerequisites are suitable; five mention concern about clashes with work; and four identify a practical example as a comparison factor. One person can mention several topics, so these counts need not sum to twelve. Twelve interviews do not establish that seven out of every twelve people in the market share the same need.

The team also finds that twenty-four of the forty conversations include a question about level or schedule. That is 60% of the reviewed conversations under this definition, not 60% of website visitors or the market. Its frequency could reflect inadequate information on the current page rather than a permanent buyer characteristic. The distinction matters: some questions may disappear when the page improves.

The team develops a preliminary pattern called “the learner who needs clarity before committing”. This is a functional description, not a judgement about intelligence or personality. The learner's goal is to produce a report usable at work. The main criteria are an appropriate level and a timetable they can commit to. The barrier being investigated is insufficient information before payment. We do not add age, income or marital status because the example contains no evidence linking these to the decision.

Under evidence, we record topic counts, their sources and the hypothetical review date. Under interpretation, we propose that an example of the output and clear entry requirements could make evaluation easier. Under hypothesis, we propose that presenting this information before the registration invitation will increase suitable completions and reduce cancellations caused by misunderstanding. Under unknowns, we record the pattern's prevalence beyond the sample and the effect of price independently of offer clarity.

The card becomes actionable when we add a decision and an owner. The page editor will provide a short example of the resulting report and clearly explain prerequisites and expected time commitments. The training lead will check that the promises are accurate. Customer support will use a consistent answer pointing to the same information. These actions support understanding; they do not require pretending the platform knows a visitor's thoughts or private circumstances.

Reading the diagram: The card summarises the hypothetical example, not a real study's findings. Read the goal and barrier, then review the information's source before acting. The counts refer to this example's interviews and do not measure market size. Open the SVG version to enlarge it.

From a card to a clear test and calculation

Design a hypothetical teaching experiment comparing two versions of the workshop page during the same period, with appropriate random allocation of qualified visitors. Each arm receives five hundred visitors, with comparable offer conditions and measurement. The intended variable is how fit and timetable are explained, not simultaneous changes to price, instructor and advertising. Changing all these elements together would make the result difficult to interpret even if the headline number improved.

Suppose thirty of five hundred visitors register in the first version and forty of five hundred in the second. The rates are 6% and 8%, a difference of two percentage points. The relative increase is two divided by six, approximately 33.3%. Do not describe the difference ambiguously as “a 2% increase”, or treat this amount of data alone as sufficient evidence of a stable effect or guaranteed future result.

Also review suitability after registration. If six of the first arm's thirty registrants cancel and four of the second arm's forty cancel, twenty-four and thirty-six remain respectively. Retained registrations as a share of original visitors are 4.8% and 7.2%. Cancellation rates among registrants are 20% and 10%. Changing the denominator changes the number's meaning, so present the definition and observation period alongside every percentage.

These calculations are not enough to declare definitive success or make broad causal claims. Review allocation integrity, overlapping visits, the predetermined observation period, uncertainty and the quality of learning once the workshop begins. A commercially stronger version might recruit unsuitable people if its description overpromises. Use the persona to improve the customer's decision, then test the effect; do not select flattering results to decorate the persona.

If completion does not improve, do not immediately conclude that the persona does not exist. Perhaps the information was already clear, or the problem is the actual timetable, prerequisite or payment process. Revisit the specific hypothesis tested. One test does not invalidate the entire card, just as a rising metric does not validate every detail. Retain learning supported by the evidence and revise parts that need a different explanation.

How does a persona become a message and an experience?

Start the message with the task and information that help someone choose: “See an example report, and check the prerequisites and timetable before registering.” This is a teaching suggestion for the example, not a guaranteed sales formula. Avoid exploiting anxiety by implying that anyone who does not register will fail professionally. A good message helps suitable people recognise the fit and lets unsuitable people decide without misleading pressure.

On the page, the persona may call for a genuine example of the output, an explanation of the effort required, the limits of what the workshop provides and information on requesting help. In communication, do not choose a channel simply because its name appears on the card. Investigate whether people use it to learn, compare or obtain support, and whether you can appropriately reach them there. An audience's presence somewhere does not make every message appropriate for that setting.

After purchase, the priority shifts from resolving uncertainty about the choice to helping the learner begin. A clear onboarding message, a link to prerequisites and a route to human assistance may help. This connects marketing with customer experience. Do not create separate departmental personas carrying contradictory assumptions. Share definitions and evidence while allowing each team to contribute reviewable observations.

A second application: when an entire team buys

Imagine a hypothetical company evaluating software for managing maintenance requests. The employee using it wants to log and track requests easily. The operations manager wants visibility into responsibilities and delays. Procurement wants clear terms, while the technical lead wants to understand integration and permissions. These are possible roles for teaching purposes, not a rule that every organisation contains the same people or that the most senior title decides alone.

Begin by understanding how decisions actually happen in the cases you study. Who defines the problem, suggests alternatives, tests them and approves the choice? One person may hold several roles, and participation may change with contract value. If you create only an “ideal manager” card, you may deliver a commercially persuasive presentation that leaves user needs or implementation requirements unanswered, blocking the decision later.

Here you can create short cards for roles whose needs genuinely differ and connect them through one buying-process map. Offer the user a task-based demonstration, the supervisor an example of tracking work, procurement a clearly scoped proposal and the technical lead suitable verification information. Not every objection is an obstacle to overcome: it may reveal a genuine requirement the product cannot honestly claim to meet. The persona should support truthful dialogue between participants.

Mistakes that make a persona misleading

The first mistake is inventing details and treating them as findings. A photograph, name and attractive quotation can imply an interview that never happened. If you write a phrase to summarise a teaching idea, label it as illustrative wording rather than attributing it to an anonymous customer. When using a real quotation in your work, preserve its context and appropriate use instead of turning one sentence into the opinion of the whole audience.

The second mistake is converting broad characteristics into stereotypes: “young people want speed” or “managers do not read details”. The task may produce exactly the opposite need. Test reading, time and assistance requirements in the intended situation. Do not let the card justify ignoring differences in access, ability or language. People outside the main pattern may still be legitimate members of the service's audience.

The third mistake is creating so many personas that every customer has a separate card. Create a new distinction when a stable, supported difference leads to a different decision, not simply when a name or age changes. Conversely, do not combine conflicting needs into one persona merely to make the document look simple. Explain why you split or combined patterns and what evidence could change that choice later.

The fourth mistake is inferring motivation from a platform, willingness to pay from income, or conviction from a click. These relationships require testing and context. The fifth is leaving the card without a date or owner. Services, alternatives and people's experiences change. The team must know when the information was gathered, who reviews it and which events should trigger new research.

Use AI without inventing customers

A language tool can help organise anonymised notes, suggest follow-up questions and flag statements that appear to be unsupported interpretations. It can also fill gaps with a linguistically plausible story. Ask it to connect each claim to an original observation and leave unknowns blank, then check those connections yourself. Fluent wording is not evidence that a description is accurate or representative of reality.

Do not treat a conversation with an automatically generated “virtual customer” as a field interview or add its replies to participant counts. You may use it to rehearse a question's clarity or imagine an objection before research, clearly labelling the exercise. Avoid entering unnecessary personal data or using recordings and information in services unsuitable for the agreed purpose and permissions. Good personas reduce the need to expose individual identities.

How do you know a persona needs revision?

Give every claim testable boundaries. Instead of “does not like calls”, write “participants in these interviews preferred reviewing a written proposal before a call”. The second statement specifies the context without preventing an offer of a call when helpful. You may later discover that the issue was missing price details in the first conversation, not a dislike of calls themselves. Revise the interpretation while retaining the original observation on which it was based.

Deliberately look for contradictory cases. In the training-platform example, someone may register quickly without reading the timetable because they know the instructor from an earlier workshop. Do not remove that person from the analysis because they do not fit the card. Examine the effect of previous experience. You may need to distinguish first-time and returning buyers, or add this condition to the existing pattern. An exception does not ruin research; it prevents an absolute description that ignores context.

When behavioural data and interviews disagree, do not automatically select the source that supports your plan. People may say they compare content while visits appear concentrated on the pricing page. This does not prove dishonesty or establish price as the only cause. They may have read the content elsewhere or returned later to confirm the cost. Check observation timing, session definitions and what each source can actually reveal before combining findings.

Similarly, attention to the timetable may result from page design rather than a stable difference between people. If everyone understands it after the presentation improves, you do not need a permanent persona called “the person who asks about dates”. Retain the useful need—clarity about the commitment—and monitor whether it still distinguishes a pattern requiring a particular decision. This prevents temporary product weaknesses from becoming permanent characteristics attached to customers.

Which fields make the card ready to hand over?

Begin with a title describing the task rather than judging the person, followed by scope, review date and owner. State the buyer's desired outcome in plain language, the event that starts the search, comparison criteria and barriers. Add the information or assistance used at the decision point, identifying the source of each part. Do not make demographic information the first thing colleagues see if it does not change how the service should be presented.

Leave a short space for contrary evidence and unknowns, then connect the card to one action, an owner and a measure. A finding may be supported within the sample while its prevalence remains unknown. Do not reduce quality to a green indicator or an undefined confidence score. Explain, for example, that the pattern appeared in recent interviews but has not been measured across the customer base, and that the next application is a limited, reversible experiment.

When handing the card to a writer, ask which detail changed the headline or explanation. Ask a designer which barrier they addressed in the interface. Ask sales for a better question that helps understand the actual situation. If everyone derives conflicting decisions, revisit ambiguity in the card. Sharing a file alone does not establish shared understanding or a commitment to implementation.

Practical steps for a small team

Start with one page defining the decision, scope, what you know and what you need to learn. Gather existing observations, check duplication and definitions, and select relevant participants with different experiences. Ask neutral questions and organise answers by task, goal, barrier and selection criterion. Do not wait for a perfect picture, but document the limits of what you have instead of hiding them beneath additional detail.

Write an initial one-page card covering the functional pattern, goal, context, behaviour, criteria, barrier, evidence source, interpretation and next hypothesis. Review it with customer-facing colleagues and, where available, the researcher or data owner. Ask about contradictory cases, not whether they like the persona. Then select a limited change that can be tested and a metric reflecting the outcome you want to improve.

Assign an owner and a review date suited to the pace of change, or specify a trigger such as a new offer or changing cancellation reasons. Keep dated versions and the reason for each revision. Remove information that proves irrelevant to decisions. Add newly observed needs with their sources and limits. A persona is an evolving thinking tool, not a certificate that ends the need for research once approved.

Reader exercise: a card whose evidence you can defend

Choose a service you know and identify one decision needing improvement. Write three real observations available to you without exposing the people involved, then separate what you infer from what you do not know beneath each observation. If you have no data, label the card an “initial hypothesis” and write a collection plan instead of inventing interviews. Identify two conventional template details you can remove because they do not serve the decision, and explain why.

Create a one-page card, a short message and one experience change. Specify the outcome metric and denominator, a measure protecting experience quality, and a result that could make you reconsider the hypothesis. Give the card to a colleague who did not prepare it. Can they identify the source of every claim? Do they understand what they would do differently? If they must guess either answer, the card needs further editing.

For calculation practice, suppose twelve of thirty conversations contain a delivery question. That is 40% of the reviewed conversations, not all potential customers. If task completion rises from fifteen to twenty-one in two groups of one hundred participants each, the difference is six percentage points and the relative increase is 40%. The meaning of the difference still depends on test design and measurement quality, not correct division alone.

Sources and attribution

The user-supplied teaching materials for Jenna Tiffany's lectures at the London School of Business Administration are: “Explanation of Introduction to Digital Marketing”, PDF pages 114–120, with repeated references on pages 18, 143, 207–208 and 221; “Explanation of Digital Marketing Strategy”, pages 100–109, together with 98, 115, 144–145, 150 and 223; and “Explanation of Digital Customer Experience”, pages 56, 123 and 137. These English descriptions identify the Arabic-titled supplied files; page numbers refer to their PDF order. The underlying article's source review examined the text and key slides visually and consolidated repetition without presenting example prices or percentages as current market data.

For historical attribution, see Alan Cooper, The origin of personas, a copy of the author's article. For persona types and limits of inference, see Page Laubheimer at Nielsen Norman Group, Three Persona Types. Strategy slide 101 attributes a customer-discovery steps diagram to Loktionova, 2021; that diagram has not been copied or presented here as a separate model. The four dimensions explain the course presentation, while the examples, calculations, evidence diagram and persona card are original teaching material.

This article does not treat the “ideal customer” as one person representing everyone, assume the chief executive always makes the decision, or suggest that more data automatically guarantee accuracy. It does not treat AI-generated content as field research. The examples support learning; every real application needs research appropriate to its own audience and context.