Customer Persona: Separate Buyers From Users
Your team is about to rewrite a product page. Sales says buyers want reassurance about implementation. Product says users care about speed. Marketing has a slide showing a smiling “ideal customer,” complete with a name, age, and favorite social network. None of those details settles what the page should say first. The useful question is narrower: whose decision must this page help, and what do we actually know about that person’s situation?
A customer persona should make that choice easier. It is a compact, research-based account of a kind of customer, buyer, or user in a defined market. The person on the page is fictional; the goals, behavior, and circumstances should come from people studied in that market. Digital.gov describes user personas in terms of real users’ goals, behavior, and pain points, while HubSpot describes a buyer persona as a fictional summary built from market research and customer data. Those are related uses of the same device, with different decisions in view. Digital.gov’s guide to user profiles HubSpot’s buyer persona definition
My rule is to write a persona only when it will change a specific decision. A profile that helps a writer decide which concern belongs above the fold, or helps a designer see why a task is difficult, earns its place. A profile that merely makes an audience sound vivid is expensive decoration. The cost of a useful persona is the time spent talking to customers, comparing what they say with what they do, and revising the summary when the market changes. That cost is justified when the alternative is making repeated choices from unexamined assumptions.
Decide whether you need a buyer, a user, or both
“Customer persona” is a broad term. For a purchase decision, a buyer persona should describe what starts the search, what the person wants to achieve, what concerns could stop the purchase, and what part that person plays in approval. For a product decision, a user persona should describe the work the person is trying to complete, the context of use, and where the product helps or gets in the way. Design literature includes several approaches to personas, including ones centered on users’ goals and interactions with a product; no single format serves every decision. The Encyclopedia of Human-Computer Interaction’s discussion of personas
Consider an illustrative company selling scheduling software to field-service businesses. A dispatcher might use the software throughout the day to reassign jobs when a technician is delayed. An operations manager might seek a product because missed appointments are creating complaints. A finance lead might authorize the expense after asking what the subscription replaces. These are hypothetical roles, not findings about a real market. They show why one polished “customer” can hide three different questions: Can I do my work? Will this solve an operating problem? Is the purchase worth approving?
If the immediate task is to improve the dispatch screen, start with the dispatcher’s work. If the task is to write a comparison page for a buying team, learn how the operations manager and finance lead reach a decision. The buyer and user may be the same person in another market. Do not split them just to fill a template. Likewise, do not collapse them because both work at the same company. HubSpot’s buyer-persona workbook explicitly recognizes multiple influencers and decision makers in a purchase, a reminder that the person who first encounters a product may not authorize it. HubSpot’s inbound marketing workbook
Start with the decision the persona must improve
Before interviewing anyone, write down the choice the team faces. “Who is our customer?” is too wide to guide research. “Which concern should the first screen of our product page answer for an operations manager comparing scheduling tools?” gives you a person, a moment, and an action. It also shows what information would be useful: the problem that prompted the search, alternatives under consideration, objections, and the manager’s role in the purchase.
This scope prevents a common mismatch. A team may collect age, hobbies, and a stock photo, then still know nothing about why someone would switch providers. Those details are not inherently forbidden. They belong in the profile when they explain an actual choice, such as a meaningful access need or a constraint on how the person uses the product. Otherwise, the space is better used for the task, the trigger, and the trade-off the person is facing. A specific job title can matter in a business purchase because it may indicate responsibility or approval authority; it should not substitute for learning what that person actually decides.
Define the market and the period too. A persona for people buying scheduling software for small local service firms should not silently stand for every employer using field staff. A description drawn from current customers may miss buyers who considered the product and walked away. A description of enthusiastic users may miss the approver who blocked renewal. The profile represents the people studied, in their circumstances at the time; it does not speak for every individual who resembles them. This limit matters whenever a team is tempted to treat the fictional character as a universal customer.
Gather accounts of real decisions and real use
Customer interviews are valuable when they get beyond preferences stated in the abstract. Ask a recent buyer what started the search, who joined the discussion, what alternatives remained at the end, and what nearly stopped the choice. Ask a user to describe a recent task and the conditions under which it became hard. The question “What did you do next?” often reveals more than asking what a person generally likes. These are questions to investigate, not facts to fill in from imagination. HubSpot’s buyer guidance points to motivations and concerns along the purchase journey, and its workbook specifically suggests learning who participates in and authorizes a purchase. HubSpot’s buyer persona definition HubSpot’s inbound marketing workbook
Look for behavior as well as reported motives. If people say a feature is essential, examine how they currently handle the task and whether that feature affected their recent choice. If customers say price was decisive, ask what other concerns they weighed and who made the final call. A stated reason can be sincere without being a complete account of the decision. Digital.gov’s profile guidance calls for research into goals, motivations, behavior, pain points, and context; that range keeps a persona from becoming a collection of attractive quotations. Digital.gov’s guide to user profiles
Use more than one view of the market when it is available. Interviews can explain why a choice felt difficult. Surveys or customer data can help show whether a pattern appears beyond the people interviewed. Qualitative and quantitative work can both inform personas, but each inherits the limits of who was included and how the information was gathered. A support queue, for example, shows people who contacted support; it cannot by itself describe everyone who struggled and gave up. The design literature’s role-based approach ties persona descriptions to both qualitative and quantitative material, with a clear connection between the source material and the profile. The Encyclopedia of Human-Computer Interaction’s discussion of personas
Do not wait for a perfect research program before making a decision. If all you have is a few interviews, say so inside the working profile and keep the claims narrow. If you have only internal opinions, call the document a hypothesis and use it to decide whom to speak with next. The distinction is practical: a team can challenge an uncertain statement when it can see where that statement came from; a confident-looking fictional biography invites people to repeat guesses as if they were customer facts.
Group people by differences that change the work
Once you have notes, look for recurring goals, constraints, and behaviors. People may share an industry and job title yet differ in whether they initiate a purchase, use the product every day, or sign the contract. Conversely, people with different titles may face the same task and need the same explanation. Create separate personas when those differences would lead you to change a message, a sales conversation, or a product choice. If the same decision follows from two profiles, they may not need to be separate.
For the illustrative scheduling company, imagine that conversations revealed two operations managers. One is replacing spreadsheets because dispatch changes have become difficult to track. The other already has software but cannot get timely updates from the field. Their titles match, yet the first might need to see how setup works, while the second might need to see how information moves between office and technicians. This is a hypothetical way to decide whether to split a profile. Actual research would have to show that these patterns recur in the market before the company treated them as customer personas.
The opposite problem is over-segmentation. It is easy to create a persona for every interesting interviewee. A name and backstory make each one feel distinct, but a set of profiles should represent meaningful patterns rather than preserve every personal detail. Digital.gov advises identifying recurring goals, motivations, behaviors, and pain points before creating user types. The resulting profile is a summary, so keep variation that could reverse a choice visible rather than forcing all customers into one average. Digital.gov’s guide to user profiles
Put the decision-making facts on the page
A useful persona can be brief. Give the profile a clear role name and state the market and period it covers. Then write the situation that brings the person to the product, the outcome the person needs, what they do now, what makes that approach difficult, what they can decide, and what they need from others. Add the source of each important claim or a pointer to the underlying research. If a detail is uncertain, mark it as uncertain. Digital.gov recommends linking personas to the research behind them so that a team can challenge a description that may stereotype a user. Digital.gov’s guide to user profiles
Here is a compact illustration, with every premise invented for explanation: “Operations manager at a local field-service firm considering scheduling software. A rise in last-minute job changes has made the existing spreadsheet hard to coordinate. The manager wants dispatchers and technicians to see the same updated schedule. The manager recommends a tool but needs finance approval. A product page must show how a changed job reaches the field and what the team must do to start using the system.” Nothing in that paragraph should be presented as a finding about actual buyers. Its value is that it gives a writer and a product team concrete questions to answer. A name, photo, and hobbies would add little to those questions.
This example also exposes a missing fact. The manager’s concern about setup may be central, or it may be a guess. Before making it the headline, ask people in the defined market what made adoption difficult and compare that with the questions that came up during actual purchases. If another concern dominates, the message should change. That is how a persona stays connected to a choice instead of becoming a story the team protects.
Use the profile at the moment of choice
Bring the persona into a real brief. For a product page, state which persona the page serves and which buying question it answers. If the page is for the illustrative operations manager, the lead might explain how dispatch changes reach technicians; a finance concern about contract value may belong later or on a separate page. If the manager is only an influencer and finance initiates the search, that order may reverse. The profile helps the team make a choice, but it does not eliminate the need to see how people respond to the actual page.
For product design, use the user profile to describe the task rather than treating a fictional person as a specification. A dispatcher’s need to reassign a job during a delay suggests testing the steps involved in finding the job, changing the assignment, and seeing whether the update reached the technician. The persona explains why that sequence matters; observing users work through it tells you where the interface fails. Design guidance treats personas as aids to decisions grounded in users’ goals and contexts, not as a substitute for seeing people use a service. Digital.gov’s guide to user profiles The Encyclopedia of Human-Computer Interaction’s discussion of personas
In a sales conversation, a persona should prompt better questions, not provide a script to recite at someone. The sales representative can ask an operations manager how schedule changes are handled today and who else would review a new system. The answer may reveal that the person does not fit the profile, or that the purchase has a different shape than expected. A customer is allowed to contradict the persona. The document summarizes a pattern; it has no claim over the individual in front of you.
Keep the profile small enough to change
Revisit a persona when the decision it supports starts producing surprises. Buyers may raise concerns absent from the profile; users may work around a feature in a way the team did not anticipate; a new kind of approver may enter the purchase. Record the new account, look for recurrence, and revise the summary when the pattern is clear. A routine calendar review can help, but an interval alone cannot tell you whether the market or the product has changed. HubSpot recommends revisiting buyer personas as new customer information arrives; the reason is to keep marketing choices tied to the people they are meant to serve. HubSpot’s buyer persona definition
Keep the profile’s reach modest. A persona cannot tell you how many customers share a concern unless your research can support that claim. It cannot settle what an individual buyer will do. It can also conceal people who were missing from the research, especially when a team relies only on its easiest customers to reach. Digital.gov’s user-profile guidance explicitly asks teams to consider who is included, who is overlooked, and whether a profile could flatten users into a stereotype. Those questions are part of making a useful customer description, because an excluded need can lead directly to a poor product or message choice. Digital.gov’s guide to user profiles
The strongest customer persona is therefore not the most detailed fictional life. It is the shortest honest account that lets a team say, “For this buyer or user, in this situation, here is the choice we should make and why.” Write down the limits of what you know, make the choice, and return to customers when the answer no longer fits. A persona has done its job when it changes a decision and remains open to correction.