How to Create User Personas

Most personas are fictional. They have names like "Marketing Mary" and stock photos, but the underlying data is thin — often just assumptions dressed up as research. Those personas get pinned to a wall, admired for a week, and then ignored.

A useful persona is a synthesis of real research. Here's how to build one that actually influences decisions.

Why personas exist

The purpose of a persona isn't to describe a specific user. It's to help a team make decisions consistently about a type of user.

When a product team debates whether to add a feature, the question shouldn't be "do we like this?" It should be "does this help [persona name]?" A good persona makes that question answerable.

If your personas aren't being referenced in product and design discussions, they're not working. The goal is alignment, not documentation.

What to include (and what to skip)

Most persona templates include too much demographic information and not enough behavioral detail. Age and gender are rarely the deciding factors in product decisions. Goals and frustrations almost always are.

Include:

• Name and role: A memorable name and their job or context. "Alex, Operations Manager at a 50-person logistics company" is more useful than "Alex, 34."
• Primary goals: What are they trying to accomplish? 2–3 specific goals.
• Frustrations: What makes their job or task harder today? Be specific. "Can't see which team members are available without switching between three tools" beats "dislikes inefficiency."
• Behaviors: How do they currently solve the problem? What workarounds do they use? What tools are they already in?
• Context of use: Where and when do they use your product? Desktop only? On mobile while traveling? At a desk with multiple windows open?
• Key quote: One sentence synthesized from real interview data that captures their worldview. This makes the persona feel human.

Skip or minimize:

• Specific age (unless age is genuinely relevant to your product)
• Detailed family status, hobbies, or lifestyle details unrelated to the product
• Personality traits without behavioral evidence

How to get the data

Personas built on assumptions are worse than no personas — they make the team confident in wrong decisions.

User interviews: The highest-quality source. 30–45 minute conversations focused on understanding goals, current behavior, and pain points. Aim for 8–12 interviews per persona you're building.

Customer support tickets and NPS responses: What are users complaining about? What are they asking for? Support data reveals real frustrations in real words.

Product analytics: Behavioral data. Which features do power users rely on? Where do new users drop off? Analytics tell you what is happening; interviews tell you why.

Sales call recordings: If you have access, sales calls capture why prospects consider your product and what objections come up. Gong and Chorus make this searchable.

Avoid surveys for persona research. Survey data is too shallow — you get answers to your questions, not insight into what you didn't think to ask.

Building the persona

After 8–12 interviews, look for clusters. Don't try to create one persona that covers everyone — you'll end up with something so generic it's useless. Most products have 2–4 meaningfully different user types.

For each cluster:

1. List all the goals you heard across interviews
2. List all the frustrations
3. List observed behaviors and workarounds
4. Pull 5–10 direct quotes
5. Synthesize patterns into a coherent narrative

The synthesis step is where the work happens. "Three of five interviewees mentioned manually copying data between tools" becomes a frustration bullet. "Interviewees described themselves as reactive rather than proactive about X" becomes a behavior note.

Try Miro Free

Tools for building personas

Miro has persona templates in its template library. Good for collaborative creation — you can run an affinity mapping session in Miro to cluster interview data before building the persona. Invite your whole team to participate in the synthesis.

Figma for the final visual artifact. Design a persona card with your brand styles, export it as an image or PDF, embed it in documentation. The visual polish makes it more likely to be shared and referenced.

Notion for accessibility. A Figma design is great for a workshop; a Notion page is what gets referenced in day-to-day discussions. Create a Notion page per persona that includes the key details and links to source research (interview recordings, survey responses).

Making personas actually used

The graveyard of design artifacts is full of well-made personas. They're beautiful. Nobody looks at them.

To make yours stick:

Socialize them, don't just share them. Walk the team through them in a meeting. Explain where the data came from. Field questions.

Reference them in discussions. When a feature debate starts, say "let's look at this from [Persona's] perspective." Model the behavior you want the team to adopt.

Update them. Personas based on research from two years ago are worse than no personas. When you do new research, update the relevant details and re-share.

Keep them visible. Pin them to your Notion project space. Add them to the top of design briefs.

The best persona is the one on the tip of everyone's tongue when the team is making a decision. If you have to go looking for yours, it's not working.