The Research Problem
Here's the dirty secret of most personas: they're fiction. Not the useful kind — grounded in patterns and evidence. The lazy kind. Someone in a conference room says, "I think our users are probably like this," everyone nods because lunch is in twenty minutes, and a persona is born from pure imagination.
Personas without research aren't personas. They're assumptions with a stock photo attached.
You already know this. Your team skipped research last time not out of ignorance but logistics. Research sounds expensive, slow, and like something requiring a dedicated researcher and a five-figure budget. By the time you could arrange all that, the product decision was already made.
That's a real problem. But it's solvable.
Good persona research doesn't require a lab or a massive budget. It requires curiosity, a system, and the discipline to talk to actual humans before designing for imaginary ones.
The methods below are your toolkit. Some cost nothing. Some take an afternoon. The best approach combines several — but even one method, done honestly, produces a persona ten times more useful than anything invented in a brainstorm.
| Method | Best For | Sample Size | Cost | Time |
|---|---|---|---|---|
| User Interviews | Deep motivation & context | 5–12 | $0–$300 | 1–2 weeks |
| Surveys | Validating patterns at scale | 100–500+ | $0–$200 | 3–7 days |
| Analytics Review | Real behavior & usage clusters | All users | $0 | 2–4 hours |
| Contextual Inquiry | Environment & workarounds | 3–6 | $0–$500 | 1–3 days |
| Support Ticket Analysis | Real language & recurring pain | 50–200+ tickets | $0 | 2–4 hours |
Let's walk through each one.
User Interviews: The Foundation
If you do one thing on this list, do interviews. Nothing else comes close.
Surveys give you numbers. Analytics give you patterns. But sitting across from someone and hearing them describe their frustrations and the weird workarounds they've invented? That's where personas come to life. That's where you learn things you didn't even know to ask about.
Quick Reference: User Interviews
How many interviews do you need?
Fewer than you think. Eight to twelve per persona segment usually reveals the major patterns. Around interview five or six, something interesting happens: people start saying the same things. Different words, same underlying story. That's saturation. That's when you know you're onto something real.
Three interviews is better than zero. Don't let "we can't do twelve" become an excuse for doing none.
How to recruit participants
This is where most teams stall. Don't overthink it.
If you have an existing product, email your users. Not a mass blast — a personal note. "We're trying to understand how people like you use [product]. Would you have 30 minutes for a conversation? We'll send you a $25 gift card." Response rates will surprise you. People like being asked their opinion.
If you don't have users yet, go where your target audience already hangs out. LinkedIn groups. Slack communities. Reddit. Industry forums. You're looking for people who have the problem you're trying to solve, not people who've heard of your product.
Avoid recruiting friends, coworkers, or your mom. They'll tell you what you want to hear. You need people who'll tell you the truth.
How to structure the conversation
Don't write a script. Write a guide. Five to seven open-ended questions that explore the person's context, goals, frustrations, and behaviors. Then let the conversation breathe.
The single most powerful question in user research is: "Tell me about the last time you..."
Not "What do you usually do when..." — that invites generalization. People are terrible at describing their "usual" behavior. They idealize it. They smooth over the messy parts. But when you ask about a specific recent instance, they relive it. Details pour out. The workarounds. The emotions. The moment they almost gave up.
Key insight: Steve Portigal, author of Interviewing Users, calls follow-up questions "the art of the interview." Someone says "It was frustrating." Don't nod and move on. Say, "Frustrating how?" or "What did you do next?" or simply, "Tell me more about that." Most interviewers accept the first answer. The real insight is always in the second or third layer.
"Tell me about the last time you tried to onboard a new team member."
"Tell me about the last time you had to pull together a report under a deadline."
"Tell me about the last time you switched tools."
What to listen for
You're not listening for feature requests. You're listening for patterns of behavior, recurring pain points, underlying motivations, and the language people actually use to describe their world. Write down their exact words. That language will show up in your persona examples and eventually in your product copy, your UI labels, your marketing.
"A good interview feels like a conversation, not an interrogation. Your job is to create space for someone to tell you things they've never been asked about." — Steve Portigal, Interviewing Users
Record every interview (with permission). You'll miss things in the moment. The best insights often surface on the second listen, when you're not busy thinking about what to ask next.
Surveys: Breadth Over Depth
Surveys and interviews aren't interchangeable. They're complementary. Interviews go deep. Surveys go wide.
Quick Reference: Surveys
Here's when to use a survey: after you've done interviews. Not before. Not instead of. After.
Why? Because you don't know what questions to ask until you've talked to people. A survey sent before interviews will ask the wrong questions, offer the wrong multiple-choice options, and collect data that confirms your assumptions rather than challenging them.
Interviews reveal patterns. Surveys validate those patterns at scale. "Seven out of eight people mentioned struggling with data imports" is a hypothesis. "72% of 300 survey respondents rank data import as their top frustration" is evidence.
How to write questions that get real answers
Keep the survey under ten questions. Every question beyond ten drops your completion rate. A half-finished survey is worse than none — it biases your data toward people with more time and patience, which is probably not your core user.
Use a mix of closed and open-ended questions. Closed questions (multiple choice, rating scales) give you quantifiable data. Open-ended questions ("What's the most frustrating part of [process]?") give you the words and stories that make personas feel human.
Avoid leading questions. "How much do you love our new feature?" is not a survey question. It's a plea for validation. "How often do you use [feature]?" followed by "Why or why not?" — that gets you somewhere.
Common survey mistakes
Asking two things at once. "How satisfied are you with the speed and design of the dashboard?" What if they love the design and hate the speed? You've just collected noise.
Using jargon your users don't use. You call it "the admin console." They call it "that settings page." Use their language. Another reason to interview first.
Making every question required. If someone doesn't have an answer, forcing them to pick one creates garbage data. Let people skip.
Typeform, Google Forms, SurveyMonkey all work fine. The tool matters less than the questions.
Behavioral Analytics: What People Actually Do
People lie. Not on purpose. Not maliciously. They just can't help it.
Quick Reference: Behavioral Analytics
In interviews, people tell you what they think they do. In surveys, they tell you what they wish they did. Analytics show you what they actually did. The gap between those three is where the interesting stuff lives.
Product analytics, heatmaps, session recordings — these are your reality check. They won't tell you why someone did something, but they'll tell you what happened with unflinching precision.
What to look at
Usage patterns. Who uses your product daily versus weekly versus once-and-never-again? These clusters often map directly to persona segments. The daily power user and the once-a-month casual user are fundamentally different people with different needs.
Drop-off points. Where do people leave? Where do they get stuck? Heatmaps and funnel analytics reveal friction your users are too polite to mention — or so accustomed to that they don't even notice.
Feature adoption. Which features do different segments actually use? You think everyone uses the advanced filter. The data says 8% do. That tells you something important about who your real users are.
Session recordings. Watch five. Just five. Watch people hesitate. Watch them click the wrong thing, click back, try again. Watch the pause before they give up. You'll learn more from those five sessions than from any dashboard.
How to use data without being used by it
Data is not neutral. It answers the questions you ask and is silent on the ones you don't. If your analytics track one workflow, you'll know a lot about that workflow and nothing about the three other ways people are (mis)using your product.
Key insight: Use analytics to challenge your assumptions, not confirm them. When the data contradicts what users told you in interviews, don't dismiss either source. Investigate the gap. That gap is usually where the most important persona insight is hiding.
Contextual Observation
There's a version of user research no interview, survey, or dashboard can replace: watching someone use your product in their actual environment.
Quick Reference: Contextual Inquiry
Not a usability lab. Not a screen-share where they know you're judging. The real thing. Their desk. Their twelve open browser tabs, Slack interruptions every three minutes, Post-it notes stuck to the monitor, the coworker who leans over mid-task.
This is contextual inquiry. The closest thing to a superpower in user research.
Why observation reveals what interviews miss
People can't describe their environment because they don't see it anymore. A fish doesn't know it's in water. Your user doesn't mention switching between your app and a spreadsheet forty times a day because that's just how work works. They won't mention the sticky note with their password on it. They won't mention your app only works well on one of their two monitors.
You have to see these things yourself.
"You do not learn about people by asking them what they think about things. You learn about them by observing what they do." — Erika Hall, Just Enough Research
Even three observation sessions will reveal things that twenty interviews miss. Three. That's a single afternoon if your users are local, or three video calls where you ask, "Can you share your screen and do your normal work for twenty minutes while I watch?"
What to watch for
Workarounds. How people compensate for what your product doesn't do. These are persona gold — they reveal unmet needs users have already solved in hacky, improvised ways.
Context switches. How often they leave your product. Where they go. What they're doing there. This maps the real ecosystem your persona lives in, not the idealized one on your product roadmap.
Emotions. The sigh before a task. The frown when something loads slowly. The relief when something works the first time. These micro-reactions don't show up in surveys. They're the texture of your persona's experience.
Remote version: If you can't visit in person, ask users to record a short Loom video of their typical workflow. You'll lose some environmental context, but you'll still catch the workarounds and context switches that interviews miss.
Social Listening and Support Tickets
The research method that costs zero dollars and requires zero scheduling: mine the data you already have.
Quick Reference: Support Ticket Analysis
Your support inbox is a persona research goldmine. Every ticket is an unfiltered expression of frustration, confusion, or unmet need. These people aren't performing for a researcher. They're telling you — in their own words — exactly where your product fails them.
What to mine
Support tickets and chat logs. Look for recurring themes, not individual complaints. One person says the export feature is confusing — anecdote. Thirty people say it in different ways over three months — persona insight. Pay attention to who submits which types of tickets. New users hit different walls than experienced ones. Admins have different frustrations than end users. These clusters become your persona segments.
Social media and forums. Search Twitter, Reddit, LinkedIn, and niche communities for your product name, your competitor's name, and the problem you solve. People say things in public they'd never say in an interview. More honest, more emotional, more blunt.
App store and G2/Capterra reviews. Both yours and competitors'. One-star reviews tell you what's broken. Three-star reviews tell you what's mediocre. Five-star reviews tell you what people love — and more importantly, why, which reveals the job they're hiring your product to do.
Sales call notes and CRM data. If your sales team keeps notes, you have a library of prospect questions, objections, and decision criteria. These map directly to persona motivations and pain points.
The real language advantage
The biggest gift this data gives you isn't the insights themselves. It's the language. Real people describing real problems in real words. When you build your personas, use this language verbatim. Not sanitized corporate summaries. The actual words your users use. That's what makes a persona feel true.
The Research Funnel
No single method gives you the full picture. The best research narrows from broad quantitative data down to deep qualitative understanding. Here's how the methods layer together:
Start wide. Narrow systematically. Each layer adds depth and confidence. Even if you only do two of these, you'll build a persona grounded in reality rather than assumption.
Combining Methods: The Research Stack
No single method gives you the full picture. Interviews reveal motivation but miss behavior. Analytics reveal behavior but miss context. Surveys reveal breadth but miss depth. Observation reveals environment but is hard to scale.
You need a stack. How tall depends on what you can afford — in money, time, and effort.
The bootstrap stack ($0)
No budget, limited time. Start here:
1. Mine support tickets and reviews (2–3 hours). Read the last three months of support conversations and public reviews. Note recurring themes, common language, and distinct user types.
2. Conduct 3–5 informal interviews (3–5 hours). Email existing users or reach out in communities. Twenty-minute conversations. Use "tell me about the last time." No gift cards needed, though they help.
3. Review your analytics (1–2 hours). Identify two or three distinct usage patterns. Cross-reference with what you heard in interviews.
Total: one to two days. Cost: nothing. You'll have enough to build a first-draft persona grounded in reality. That's a massive upgrade from where most teams start.
The lean stack (~$500)
Small budget, a week or two. Add these to the bootstrap stack:
1. Eight structured interviews with gift cards. Budget $25 per participant. Consistent interview guide so you can compare responses. Record everything.
2. A short validation survey (under 10 questions). Send to your user base to test the patterns from interviews.
3. Three contextual observation sessions. Remote is fine. Ask participants to share their screen and walk through their typical workflow. Watch, don't guide.
Total: about two weeks part-time. This produces solid, defensible personas that hold up when someone on leadership asks, "Where did this come from?"
The thorough stack ($2,000+)
Building personas to serve a large team for a year or more. Invest accordingly:
1. Twelve to fifteen interviews across multiple segments. Professional recruiting if needed. Longer sessions (45–60 min). Consider hiring a moderator.
2. A robust survey with segmentation questions. Slice results by user type, company size, experience level. Aim for 200+ responses.
3. Deep analytics review. Work with your data team to build cohort analyses. Identify behavioral clusters. Map feature adoption across segments.
4. Five or more contextual observations, including on-site visits if possible.
5. Stakeholder interviews. Sales, customer success, and support teams know things about your users that never make it into a database.
Total: three to four weeks. This produces personas with real depth — foundational artifacts your team references for years.
Key insight: The bootstrap stack is infinitely better than nothing. You can always layer on more research later. The worst research plan is the one you never execute because it felt too ambitious. Do what you can. Start now. As Erika Hall writes in Just Enough Research: "You don't need all the research. You need just enough to make a better decision than you would have otherwise."
Research Planning Checklist
Before you start recruiting participants, run through this list. It takes ten minutes and saves days of wasted effort.
✅ Pre-Research Checklist
- Define your research questions. What do you need to learn? "Understand our users" is too vague. "Identify what triggers small-team leads to look for project management tools" is actionable.
- Choose your methods. Match methods to questions. Motivation questions → interviews. Scale validation → surveys. Behavior questions → analytics.
- Set your sample size. 5–8 interviews per segment minimum. 100+ survey responses for confidence. 3+ observation sessions.
- Write your screener. Who qualifies? Be specific. "Small business owner" is too broad. "Founder or ops lead at a 5–30 person company who manages projects" is recruitable.
- Prepare your discussion guide. 5–7 open-ended questions. Lead with "tell me about the last time..." and leave room for follow-ups.
- Set up recording and note-taking. Get consent forms ready. Assign a note-taker if possible. Don't rely on memory.
- Plan your synthesis. How will you turn raw notes into persona insights? Affinity mapping, thematic coding, or even a shared spreadsheet — decide before you start, not after.
- Schedule a readout. Book a meeting to share findings before you start research. Deadlines create accountability. And knowing someone is waiting for results keeps momentum alive.
What Comes Next
Research is the input. The persona is the output. Once you've done the work — even the bootstrap version — you need a structured way to turn what you've learned into a tool your team can actually use.
That's the persona creation process: synthesizing research into patterns, then shaping those patterns into a document that's clear, memorable, and actionable.
A few things to keep in mind as you move from research to persona:
Let the data surprise you. If your research confirms every assumption you had going in, you either got very lucky or you weren't listening closely enough. Good research should challenge at least one thing you believed about your users.
Don't average your findings. If half your users are power users and half are beginners, you don't have one "intermediate" persona. You have two very different personas. Averaging obscures the patterns that make personas useful.
Use their words, not yours. When you write personas, use the language your users actually used. Not internal jargon. Not polished marketing speak. The raw, real language from interviews and support tickets. That's what makes a persona believable — and useful for everyone from marketing to product to engineering.
"The goal of research is not to prove you're right. It's to reduce the risk of being wrong." — adapted from Nielsen Norman Group research guidelines
You've got the toolkit. Now go use it. Start with a single conversation. One interview. One honest conversation with a real user. That's the smallest viable research project, and it's more than most teams ever do.
Your personas will thank you. More importantly, your users will — because you'll finally be building for who they actually are, not who you assumed they were.
Ready to turn your research into real personas? Grab our free persona template, or start building in Userforge and bring your research to life.