The cautious admin, checked
A product director who doubts that the cautious admin behaves as described can open the interviews behind that persona and read several of them. The persona is then kept, sharpened or rewritten before the set is adopted.
Use caseBuild customer personas
Build personas around the decisions they have to inform, from onboarding design to the pricing page, and give each type a measured share of your base before anyone designs for it.
Three choices made before fieldwork decide whether a persona set gets used: what it is for, what it describes, and whom it covers.
List the calls the personas will inform, such as which segment the onboarding flow is built around or which buyer a pricing page speaks to, and the interviews probe the differences those calls depend on.
Age and job title seldom change a design decision. What people are trying to get done, the constraints they work under and how they choose between options usually do, so those carry the weight of each profile.
Decide whether the set covers current customers only or the buyers you want next as well. A persona drawn solely from today's base describes the company's past choices, which matters when a new segment is the strategy.
The world's most ambitious teams research with Pulse.
GrowwEach type becomes a short profile with a goal, a context, a frustration and a share of the base, written so a designer can read it in a minute.
Participants are clustered by what they are trying to achieve, their expertise and how they decide, and each cluster keeps the quotes that formed it, so a persona's traits come from people who said them.
A sorting survey run beside the interviews asks the questions that place people into types, which gives each persona a share of the base, and a type that is five percent of customers stops being designed for as if it were half.
A new segment, a pricing change or a major release can change who the customers are. The persona set gets a named owner and a review date tied to those events, so it is updated before it quietly goes stale.
A persona is a profile of one main type of customer, with its goals, behaviors, needs and frustrations, built from research with real people and detailed enough to guide design, marketing and service choices. Persona research starts from the decisions the set will inform, which sets what the interviews must uncover. Existing data, from analytics to support logs, shows known differences worth probing. Interviews, and observation where possible, cover goals, tasks, context and how people decide. Analysis looks for the variables that separate participants, such as expertise, frequency of use or motivation, and participants who cluster on them form a type. Each persona is written as a short narrative with goals, behaviors, frustrations and a representative quote, keeping demographic detail to what changes a decision. A survey that sorts a larger sample into the types shows how common each one is, and the set is revised when the product or the customer base shifts.
A product director who doubts that the cautious admin behaves as described can open the interviews behind that persona and read several of them. The persona is then kept, sharpened or rewritten before the set is adopted.
Personas drawn only from customers miss the buyer who evaluated the product and chose a competitor. Profile-based recruitment brings that buyer in, and sales gets a persona for someone it meets in late-stage deals and seldom wins.
Asked what they would like, people describe the user they intend to be. The brief asks about the last time each person faced the task, so a persona's habits come from what they did on a real Tuesday.