Building Personas From Research, Not Assumptions

Why Invented Personas Fail

Most teams have seen a persona poster gathering dust on a wall — a name, a stock photo, a made-up list of hobbies, and a "goals and frustrations" section written from guesswork. These personas fail because they were never grounded in evidence. When a design decision is challenged, an invented persona has no data behind it to settle the argument, so it quietly stops being used.

A research-based persona is different. Every trait on it should trace back to something a real person said or did during an interview, a support ticket, or a usage log. That traceability is what makes a persona a decision-making tool instead of decoration.

From Interview Notes to Persona Traits

Once you've run five to eight interviews with a user segment, look for patterns rather than individuals. A persona is not a transcript of one interviewee — it's a composite of the behaviors, goals, and blockers that showed up repeatedly across multiple people. If only one person out of eight mentioned something, it belongs in your notes, not in the persona.

Organize what you find into three buckets: goals (what the person is trying to accomplish), behaviors (what they actually do today, including workarounds), and frictions (where the current process breaks down for them). These three buckets map directly onto design decisions later — goals become priorities, behaviors become the baseline you're improving on, and frictions become the problems your wireframes need to solve.

What a Useful Persona Actually Contains

Skip the biographical filler. A working persona needs:

• A short behavioral summary, not a life story
• The specific context in which they'd use the product (device, environment, time pressure)
• Their primary goal, stated as an outcome, not a feature request
• The two or three frictions that show up most often in your interviews
• A direct quote from research that captures their perspective in their own words

That last point matters more than it seems. A real quote keeps the persona anchored to an actual person instead of drifting back into fiction over time.

Practical Review Checklist

Before you consider a persona finished, confirm that you can:

• Point to specific interview notes behind every trait listed
• Explain which behaviors are shared across most interviewees, not just one
• State the persona's primary goal as an outcome rather than a feature
• Identify which of the persona's frictions your current design already addresses
• Name what would make this persona wrong, and how you'd notice

Conclusion

A persona earns its place on the wall by making a future argument shorter — "Would this actually help someone trying to do X under Y constraint?" is a much faster conversation than a generic debate about preferences. That only works if the persona is built from what real users said and did, not from what the team assumed.