User Research Methods: When to Use Interviews, Surveys, and Video Feedback

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.

Nielsen Norman Group’s foundational research on this divergence is blunt: “Users’ self-reported behavior often contradicts what they actually 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–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. Users consistently underreport how much they read help documentation, how often they use workarounds, and how frequently they encounter specific errors.

Running a Good User Interview

The biggest interview mistake is asking leading questions. “Do you find the onboarding confusing?” will get you “yes” from people who want to be helpful, even if it’s not their primary issue. Better: “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 almost always misleading)
• Follow silence—users often 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–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 fewer than 50–100 respondents, most survey-level analysis isn’t statistically meaningful.

Survey Design Mistakes to Avoid

• Double-barreled questions: “How satisfied are you with our pricing and features?” cannot be accurately answered if the user is happy with pricing but unhappy with features.
• Leading scales: “How much did you enjoy this feature?” implies they enjoyed it at all. Use neutral framing: “How would you rate this feature overall?”
• Open-ended questions at scale: “What could we improve?” generates useful data in small batches; across 1,000 respondents, it generates unusable volume without text analysis tools.
• Survey fatigue: Surveys longer than 10 minutes show significant drop-off in completion rates and answer quality. Ask only questions where you have a clear plan for using the data.

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 defining characteristic is that you’re capturing real behavior—often spontaneous and unfiltered—rather than a constructed response to a question.

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–3 questions maximum. Each question should be answerable in 2–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.

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:

Research Question Type	Best Method	Secondary Method
“What are users trying to do?”	User interviews	Video feedback / session recording
“How many users have this problem?”	Survey	Analytics / product data
“Where exactly do users get stuck?”	Usability test / video recording	Session replay tools
“Did our change improve the experience?”	A/B test or survey (pre/post)	Usability test (qualitative)
“Why are users churning?”	Churn interviews + exit survey	Async video feedback
“What do users think of a new concept?”	Concept test / interview	Survey (after exposure)

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

Most 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 with the best research cultures also run continuous research: a rolling customer panel of 50–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. When a new question comes up, check the repository before launching new research. The answer may already exist.

Closing the Loop

Sharing research findings back with participants—even a brief “here’s what we learned and what we’re doing about it”—significantly increases future research participation rates. 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?

Research by Nielsen Norman Group suggests that 5 users uncover approximately 85% of usability problems in a product area. For generative research, 8–12 participants typically reaches saturation (you stop hearing new themes). For segmented research (different user types, different workflows), 8–12 per segment.

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 the bottleneck most teams underestimate. Options in order of typical effectiveness: 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.