User Research Methods: Interviews, Surveys and Video

The biggest user research mistake isn’t doing too little research. It’s asking the wrong method the wrong question.

A survey can tell you that 73% of users struggle with onboarding. It cannot tell you why: whether it’s confusing copy, a missing explainer, a cognitive mismatch between your mental model and theirs, or something they simply can’t articulate in a checkbox. An interview can surface that nuance. But an interview with 8 people can’t tell you whether the onboarding problem affects your power users or your trial users, your mobile users or your desktop users.

The research method shapes the answer. Choosing the right method means knowing what kind of answer you actually need, and what you’ll do with it.

The Core Distinction: Attitudes vs. Behaviors

Before choosing a method, clarify whether you’re trying to understand what users think or what they do. This distinction, attitudes vs. behaviors, shapes everything.

Attitudes are what users say: their opinions, preferences, frustrations, and stated needs. Interviews and surveys capture attitudes well.

Behaviors are what users actually do: which features they use, which paths they take, where they get stuck, and when they abandon. Observational methods (usability testing, session recordings, video feedback) capture behaviors. Importantly, behavioral data often contradicts attitudinal data: users say they want simplicity but build complex workflows; they say they read the documentation but click through without reading it.

Foundational usability guidance on this divergence is blunt: “Do not believe what people say they do.” Good research programs build in both methods to triangulate.

User Interviews: When to Use Them

User interviews are structured or semi-structured conversations with individual users, typically 30 to 60 minutes, designed to surface deep qualitative insight about needs, mental models, and experiences.

What They’re Good For

• Generative research: Before you have a hypothesis. “What is it about our billing process that’s frustrating?” before you know whether it’s the invoice format, the timing, the payment options, or something else entirely.
• Exploratory discovery: Understanding a user’s full workflow (not just the moments where your product touches it) to identify unmet needs or adjacent opportunities.
• Why behind the data: When quantitative data signals a problem (drop-off at step 3, low feature adoption) and you need to understand the human story behind the number.
• Building empathy: Getting the product team in front of real users regularly, even when you don’t have a specific research question, to prevent the gradual drift toward building for internal assumptions rather than real users.

What They’re Not Good For

• Determining prevalence. “5 of my 8 interviewees struggled with X” is not the same as “63% of users struggle with X.” Interview findings are directionally important, not statistically representative.
• Making binary product decisions. “Should we build A or B?” answered by interviews is more susceptible to recency bias and sample skew than a properly designed survey or A/B test.
• Anything users can’t accurately recall or articulate. Things like how much users read help documentation, how often they use workarounds, and how frequently they encounter specific errors are hard to report accurately from memory.

Running a Good User Interview

Ask this instead:

Walk me through the last time you tried to [achieve goal]. What happened?

Key principles:

• Ask about past behavior, not hypothetical futures (“Would you use feature X?” is often misleading)
• Follow silence: users can give their most honest answers after a pause, when they realize you’re actually listening
• Ask “what happened next?” more than “why?”: why forces rationalization; what happened next reveals actual sequence
• Record with consent and have a dedicated note-taker so the interviewer can focus on listening

Surveys: When to Use Them

Surveys are structured questionnaires distributed to a large sample of users, designed to measure, track, or compare at scale.

What They’re Good For

• Measurement: NPS, CSAT, feature satisfaction scores across your full user base
• Segmentation: Understanding how different user groups differ in their needs or experiences
• Validation: After interviews surface a hypothesis (“users struggle with X”), surveys can determine whether that’s true for 10% or 80% of your user base
• Tracking: Running the same survey quarterly to see whether a change improved (or didn’t improve) the experience

What They’re Not Good For

• Understanding nuance. “Rate your satisfaction with onboarding on a scale of 1 to 5” doesn’t tell you what specifically is frustrating.
• Novel questions. If you don’t know what to ask yet, surveys are premature: you’ll design questions around your assumptions rather than your users’ actual experience.
• Small populations. With few respondents, percentages swing widely and differences between groups are hard to tell apart from noise.

Survey Design Mistakes to Avoid

Video Feedback: When to Use It

Video feedback encompasses a range of methods: recorded usability sessions, async video responses to product questions, screen-recorded bug reports, and AI-analyzed customer testimonials. The evidence depends on the task: a recorded answer captures stated experience, while a recording of someone completing a task captures observed behavior. Video is a format, not a guarantee that the response is behavioral evidence.

What It’s Good For

• Usability testing: Watching users navigate your product while narrating their experience surfaces friction points that users wouldn’t think to report in a survey and can’t accurately recall in an interview.
• Authentic customer voice: A user explaining their workflow in a 2-minute self-recorded video is more nuanced than anything they’d type in a survey field. Video captures tone, emphasis, and context that text strips away.
• Distributed research: Async video collection lets you gather research from users in different time zones, in different contexts (at their actual desk, in their actual workflow), without synchronous scheduling.
• Stakeholder communication: A 90-second clip of a real user getting confused at the same step that product leadership thought “is fine” is more persuasive than a slide with 7% on a confusion metric.

What It’s Not Good For

• Statistical measurement at scale (though AI transcription and analysis tools are narrowing this gap)
• Standardized comparison across large groups (qualitative by nature)
• Situations where you need immediate, real-time response: async video has a lag

Collecting Video Feedback Effectively

The key to useful video feedback is context and structure, without making it feel like homework.

• Give users a specific prompt, not a generic one. “Tell me about your experience with our product” yields general responses. “Walk me through the last time you tried to export a report. What happened step by step?” yields actionable ones.
• Keep prompts to 2 to 3 questions maximum. Each question should be answerable in 2 to 3 minutes. Users who are given the option to talk forever will either say too much or freeze up entirely.
• Provide an example of the format you’re looking for: “Something like this: ‘I was trying to do X, and the thing that slowed me down was Y.'”
• Use incentives that match the ask. A $20 gift card is appropriate for 15 minutes of video feedback; $5 is not.

Copy and adapt this prompt and example for your own video feedback request:

Walk me through the last time you tried to [export a report]. What happened step by step?

Something like this: "I was trying to do X, and the thing that slowed me down was Y."

For focused qualitative prompts, adapt these video survey questions to the research decision.

The Decision Framework: Which Method When

Here’s a practical decision framework for product teams trying to choose the right method for a given research question:

Use customer feedback analysis to code, segment and compare the evidence after the study.

Building a Research Program, Not Just Running Research

Isolated research studies answer isolated questions. A research program (a continuous, systematic approach to understanding users) answers the questions you don’t know to ask yet.

Continuous vs. Project-Based Research

Many teams run research project-by-project: a study when launching a feature, an NPS survey once a quarter, a usability test when something feels broken. This approach is reactive.

Teams that want a steady flow of insight also run continuous research, for example a rolling customer panel of 50 to 100 users who respond to monthly video questions, a persistent in-app survey asking rotating questions, a bi-weekly user interview cadence that runs regardless of whether there’s a specific product question pending.

The continuous approach surfaces problems before they become crises and builds institutional empathy (the product team’s ambient sense of who they’re building for) that project-based research can’t fully replicate.

Research Repository

Research that isn’t findable doesn’t exist. Build a lightweight repository (a shared folder, a Notion database, a dedicated tool like Dovetail) where all research artifacts (interview recordings, survey data, video feedback) are stored with consistent tagging.

Closing the Loop

Sharing research findings back with participants, even a brief “here’s what we learned and what we’re doing about it”, gives participants a reason to take part again. Users are more likely to give you an hour of their time if they believe it was useful the last time they did.

FAQs About User Research Methods

How many user interviews do I need?

For usability testing, published usability research suggests that 5 users uncover about 85% of the usability problems in a product area. For generative research, a systematic review found that most interview studies reached saturation (you stop hearing new themes) within 9 to 17 interviews, mainly with fairly similar participants and narrow objectives. For segmented research (different user types, different workflows), plan enough interviews for each segment rather than for the study as a whole.

When should I use unmoderated vs. moderated usability testing?

Moderated testing (researcher present) is better for complex tasks, exploratory research, and follow-up questions. Unmoderated testing (user completes tasks independently, recorded) is better for simple tasks, large sample sizes, and time-zone-distributed participants. Both are valid; the choice depends on what depth of follow-up you need.

How do I get users to participate in research?

Recruitment is an often underestimated bottleneck. Common options: in-app recruitment (the fastest, but biased toward active users), customer success/sales referrals, customer panel programs, external research panels (UserTesting, Respondent), and social media outreach. Match your recruitment channel to the type of user you need: in-app recruitment misses churned users, for example.

Should research always drive product decisions?

No, and confusing “should inform” with “should determine” is a common trap. Research reduces uncertainty; it doesn’t eliminate the need for judgment. A product leader who builds only what research explicitly validates will miss the adjacent innovations that users couldn’t articulate they wanted. The goal is informed judgment, not research-determined decisions.