Where personas came from
Personas come from software design, not marketing. Alan Cooper made them popular in his 1999 book The Inmates Are Running the Asylum1. His target was what he called the elastic user: a vague "user" that the team could stretch to justify whatever feature someone wanted. His fix was to design for a specific, named person with clear goals, and to pick one primary persona the product must satisfy first1.
Two ideas from that start still matter. First, a persona is defined by goals and behavior, not by age, income or a stock photo. Demographics belong to market segments, which answer a different question. Second, a persona is a tool for making decisions. If it never changes a decision, it is decoration.
In 2003, John Pruitt and Jonathan Grudin described how teams at Microsoft had used personas for three years. They found personas engaged teams well, and they stressed that a persona should carry real data, both interviews and numbers, rather than stand in for it2.
A drafted persona is a hypothesis, not research
The personas this tool writes are built from your description of the product and a language model's general knowledge. No one was interviewed. They are a useful first guess about who might use the product and why. They are not evidence that those people exist, or that they want what you are building.
That matters because personas are persuasive. A named person with a quote feels real, and teams start to treat the guess as fact. Christopher Chapman and Russell Milham made this critique in 2006, in the Proceedings of the Human Factors and Ergonomics Society3. They argued it is hard to know how many real users, if any, a persona represents, and that a persona cannot be proven true or false. They advised against treating personas as a way to communicate data until those problems are solved3.
A 2012 study at the CHI conference by Tara Matthews, Tejinder Judge and Steve Whittaker interviewed experienced design practitioners. They used personas mostly to communicate, not to design, and found them abstract, impersonal, misleading and distracting. The authors concluded that personas "cannot replace immersion in actual user data"4.
How to turn the draft into something you can trust
- Mark every line as a guess. Treat each goal and frustration as a claim to check, not a finding.
- Talk to real people who match the role. Ask about the last time they faced the problem: what they did, what it cost, what they tried. Past behavior tells you more than "would you use this?"
- Keep what you heard, cut what you did not. Replace invented details with things people actually said or did. If no one you talk to matches a persona, drop it.
- Note the source. Write under each persona how many people it rests on and when you spoke to them. A persona built on no interviews should say so.
How to write a persona a team will use
Lead with the goal and the situation. What is this person trying to get done, and what is going on in their life when they reach for a product like yours?
Make frustrations specific. "Finds budgeting hard" fits everyone. "Stopped using two budgeting apps because logging each coffee felt like homework" points at a design choice.
Cut details that do not change a decision. A favorite band or a pet makes a persona vivid, but Matthews and her co-authors found such details can mislead and distract4. Keep a detail only if it would change what you build.
Keep the set small. Two to four personas, with one primary. If everyone is a target, no one is.
A weak persona and a stronger one
This rewrites the budgeting app example shown above. The product, the person and the interview notes are invented for illustration.
| Weak | Stronger | |
|---|---|---|
| Who | Maya, 26, young professional, likes travel and yoga | A first-time saver in her first salaried job, paid monthly, rent due on the 1st |
| Goal | Wants to save more money | Build a 3-month emergency fund by next summer after a surprise vet bill went on a credit card |
| Frustration | Budgeting apps are confusing | Quit two apps within a month because they asked her to log every purchase by hand |
| Evidence | None stated | Draft from the persona tool, then checked in six interviews; four matched, two did not |
The stronger version tells a designer what to build (automatic tracking, a savings goal with a date) and what to avoid (manual logging). It also says what it rests on.
Where personas struggle, and what to pair them with
A persona describes who. It is weaker at explaining why someone switches to a product. Clayton Christensen and his co-authors argued in the Harvard Business Review in 2016 that companies lean too much on customer traits and too little on the "job" a customer hires a product to do5. Two very different people can hire the same product for the same job, and one person can hire different products for different jobs.
The two work well together. Use the persona to picture the person, and add one line for the job: "When [situation], I want to [progress], so I can [outcome]." For Maya: "When a surprise bill hits, I want to know I can cover it, so I stop borrowing on a card."
What personas do not answer:
- How many of these people exist. A persona is not a market size. Count with real data.
- What to offer them. Turn the goals and frustrations into a promise with the value proposition generator.
- Whether the product works for them. Only watching real people use it answers that.
Frequently asked questions
- What is a user persona?
- A user persona is a fictional but realistic profile of a target user (their role, goals, and frustrations) that helps a team design for real needs instead of a vague "average user".
- What should a user persona include?
- At minimum a name and role, their goals, their frustrations or pain points, and a representative quote. The point is empathy: enough detail to picture a real person.
- How many personas should you have?
- Usually 2 to 4 primary personas. Too many and they lose their power to focus the team. This tool generates two to start.
- Who invented user personas?
- Alan Cooper made personas popular in his 1999 book The Inmates Are Running the Asylum1. He used them to stop teams designing for a vague "user" who could be stretched to fit any feature, and to design instead for a specific person with clear goals. In 2003, John Pruitt and Jonathan Grudin described how Microsoft teams extended the method and used personas to carry real research data2.
- Can AI create user personas?
- AI can draft a persona, but the draft is a hypothesis, not research. No real user was asked. Chapman and Milham argued in 2006 that personas are hard to verify and can hide how few real users they represent3, and a 2012 study found practitioners saw personas as misleading when they were not tied to real data4. Use the draft to decide who to interview, then keep only what real people confirm.
- How do you validate a user persona?
- Interview people who match the persona's role and ask about the last time they faced the problem: what they did, what it cost and what they tried. Replace invented details with what they actually said and did, drop any persona no one matches, and write under each persona how many people it rests on and when you spoke to them.
- What is the difference between a persona and jobs to be done?
- A persona describes who the user is: their goals, situation and frustrations. Jobs to be done describes why someone picks a product: the progress they are trying to make in a given situation. Clayton Christensen and his co-authors argued in the Harvard Business Review in 2016 that companies focus too much on customer traits and too little on that job5. Many teams use both: a persona to picture the person, and a job line to explain the choice.
Sources
- Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity, Sams, 1999.
- John Pruitt and Jonathan Grudin, "Personas: practice and theory," Proceedings of the 2003 Conference on Designing for User Experiences (DUX), ACM, 2003, pp. 1 to 15. doi.org
- Christopher N. Chapman and Russell P. Milham, "The Personas' New Clothes: Methodological and Practical Arguments against a Popular Method," Proceedings of the Human Factors and Ergonomics Society Annual Meeting 50(5), 2006, pp. 634 to 636. doi.org
- Tara Matthews, Tejinder Judge and Steve Whittaker, "How do designers and user experience professionals actually perceive and use personas?" Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12), ACM, 2012, pp. 1219 to 1228. doi.org
- Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan, "Know Your Customers' 'Jobs to Be Done'," Harvard Business Review, September 2016. hbr.org
Written by Tom Olajide, Founder. Last reviewed September 24, 2026.