Interviewing As A Research Method

Interviewing As A Research Method

Most people think interviewing is just asking someone questions and writing down what they say. That's not how it works. The actual work happens in everything you do before and after the conversation. I've spent years conducting user interviews for product teams, and the people who actually get useful data treat the interview itself as the last 10% of the process, not the beginning. The core idea is straightforward: you learn things from talking to people that you cannot discover through surveys, analytics, or any other method. Surveys tell you what people do or what they think they want. Interviews tell you why. The gap between the two is usually where the actual insight lives, but only if you know how to look for it.

Setting Up Interviewing As A Research Method Properly

Before you ever schedule a participant, you need a research guide. This is not a script. A script makes you sound like a robot reading questions off a teleprompter, and participants notice. A research guide is a loose map of topics you want to cover, written as open-ended prompts that let the conversation go where it needs to go. You should have around eight to twelve topics. Some will come up naturally in the first ten minutes. Others might not come up at all, and that's fine because you move on. Recruiting matters more than anyone admits. I once ran a series of interviews for a fintech app where we screened for people who had used at least two competing budgeting apps in the past six months. The recruiter confirmed everyone checked that box. Four out of seven participants admitted during the interview that they had only downloaded the app, opened it once, and never used it again. They wanted to look good answering the screening question. If you're running your own recruitment, add a simple verification step: ask them to show you their app store history or recent activity log on camera at the start of the call. It takes thirty seconds and saves you from throwing away an entire interview session. Recording is non-negotiable. Take notes while you talk, but record the whole thing. Two people cannot simultaneously listen deeply and type comprehensive notes. The recording catches the stuff you miss when you're focused on formulating your next question. Get permission to record first. Say it plainly: "I'm going to record this so I don't miss anything you say. Is that okay?" Most people say yes. A few say no, and you either work around it or skip that participant. Don't pressure them.

What Actually Happens During The Interview

Your first question should be warm and easy. Ask about their day, their role, or something neutral. Then transition into the topic area. Don't lead with the hard question. People need thirty seconds to mentally shift gears, and if you ask something heavy immediately, you get clipped, defensive answers that aren't useful for anything. The single most important technique in this method is silence. When a participant finishes a sentence, wait. Count to three in your head before you respond. Most beginners fill that silence immediately with a follow-up question or a reassuring nod. The participant will often continue talking, and what they say in that extra window is usually more honest than anything they said before. People tend to edit themselves in real time. Silence removes the editor. When someone gives you a vague answer, don't accept it. "I usually manage my finances pretty well" is worthless. "Can you walk me through the last time you actually tracked your spending? Start from the beginning of that morning." Specific behavioral questions beat abstract opinion questions every time. People are bad at predicting their own behavior. They're also bad at summarizing their habits. Ask for the last concrete instance, not their general pattern.

There is a real tension between following your guide and going where the conversation takes you. Here's how I handle it: if a participant brings up something outside my guide that sounds relevant to the research goal, I drop the guide. The guide exists to serve the research, not the other way around. I note the topic change in the margins of my notes and circle back to it later if time allows. Missing a goldmine because you were sticking to your list is one of the most common beginner mistakes.

Common Pitfalls That Destroy Your Data

Leading questions are the easiest way to ruin an interview. "Don't you think the checkout process is confusing?" plants an idea in the participant's head. Rephrase it: "Tell me about your experience checking out." That's it. You're removing judgment from the question, not adding your own assumptions into it. The confirmation bias trap is unavoidable unless you actively fight it. After your third or fourth interview, you'll start feeling like you know the answer. You'll think you've figured out the main problem. This is usually wrong. The real problems tend to surface in interviews six through ten, not interviews one through five. Early interviews are noisy. You're still learning how to ask questions. Stop recruiting after ten participants unless you have a specific reason to go further. Ten well-conducted interviews will give you more signal than twenty mediocre ones. Here's something nobody warns you about: group interviews are almost never worth it. Focus groups sound efficient because you get five people in one hour. In practice, one loud participant dominates the conversation, everyone else stays quiet, and you end up with data from only one person. Individual interviews take longer per participant but produce significantly higher quality data. The time difference is roughly one hour per interview versus one hour for five people, but the data from the group session is often half as useful. Do individual sessions.

What To Do With The Recording After It Ends

Transcribe the recording as soon as possible. Within 48 hours or the data starts degrading in your memory. You'll remember the highlights and forget the nuances. Use a transcription tool if you have one. Otter.ai and similar services run about twenty dollars a month and cut transcription time from hours to minutes. I still listen to the full recording while reading the transcript because the tool misses tone, pauses, and emphasis, all of which carry meaning. Coding your transcript is where the actual analysis happens. Go through the transcript and tag sentences or paragraphs with labels that describe what's happening. "Pain point," "workaround," "misunderstanding," "workflow step." You'll accumulate maybe thirty to fifty codes across ten transcripts. Then group related codes together. That grouping is your theme. Themes are your findings. The finding isn't a quote. The finding is the pattern across multiple participants that a single quote couldn't show you. One specific workflow problem I ran into recently: a participant kept referring to "the thing that breaks when I export to PDF." The transcript didn't make it clear what "the thing" was. I went back to the recording at the exact timestamp and watched their screen share. It was a layout issue with tabular data, not a general export problem. Without the video, I would have coded this as a vague complaint about exporting and lost the specific detail that turned out to be the actual bug report. Always pair transcript coding with timestamped video review when possible.

When This Method Fails Completely

Interviewing as a research method does not work for questions that require quantitative answers. If you need to know how many people have a problem, how often it happens, or what percentage prefers option A over option B, interviews will give you anecdotes, not statistics. You need a survey or an A/B test for that. Interviews are exploratory. They generate hypotheses. They don't validate them at scale. The method also breaks down with participants who don't know their own behavior well enough to describe it. Young children, people with certain cognitive impairments, and users of highly automated systems where they never make conscious decisions are all problematic interview subjects. You'll get confused or contradictory answers not because they're being difficult but because the method assumes a level of self-awareness and articulateness that simply isn't there. There's also a real bottleneck around time. A well-run interview takes about forty-five minutes to an hour including setup and debrief. Scheduling alone can take as long as the interviews themselves because participants cancel, reschedule, or ghost you. Plan for a twenty percent no-show rate and design your timeline accordingly. Budget three weeks minimum from recruiting to final analysis report if you're doing this right. Anything faster means cutting corners on something.