What actually happens when you run a semi-structured interview
You show up with a list of core questions, maybe 5 to 8, and you sit across from someone who has spent years dealing with whatever problem you're trying to understand. They answer your questions, but they also bring up things you never asked about. Those tangents are where the real data lives. The structure keeps you from drifting entirely off course. The semi part lets the conversation actually go somewhere useful. I spent three years running these for organizational psychology research, and the biggest mistake people make is treating the question guide like a script. It isn't. It's a checklist of topics you need to cover. If the person you're talking to starts explaining something right out of the gate that's directly relevant to question number four, you skip ahead. You don't power through questions one through three just because they're printed first on your page.
Examples Of Semi Structured Interviews
Here are some actual setups I've seen work, from real projects: Tech product adoption study — A software company wanted to understand why employees resisted switching from legacy tools to a new platform. The interview guide had questions about daily workflow pain points, past tool failures, and what would make a switch feel safe. During the interviews, several participants brought up manager pressure as the #1 blocker. That wasn't on the guide. We added a follow-up probe about organizational incentives and found the resistance was less about the tool and more about performance metrics tied to old habits. That pivot changed the entire recommendation the company made afterward. Patient care experience research — A hospital network interviewed people who had been through a specific outpatient procedure. Questions covered waiting times, communication with staff, and post-procedure follow-up. One participant started describing how the discharge instructions were written in language she couldn't understand. That led to a deeper conversation about health literacy across the whole sample. The hospital ended up rewriting their discharge materials, not because of any survey data, but because the interviews kept surfacing the same gap.
Educational program evaluation — Researchers looked at how a mentorship program affected early-career teachers. The guide asked about onboarding support, mentor availability, and classroom confidence. Nearly every participant brought up something about administrative pushback. That wasn't part of the original framework. It shifted the analysis toward institutional barriers rather than just program quality. Consumer behavior investigation — A retail brand interviewed customers about why they stopped buying a particular product line. Questions covered price sensitivity, changing needs, and brand perception. The surprising thread was that several people mentioned a competitor's packaging innovation. The research team had been focused on internal product changes, but the interviews pointed to an external design factor they'd completely missed.
Get the Full Details
How to actually construct the question guide
Start with your research objective and work backward. If you're studying why users churn from a service, your questions should trace the path from first use to last interaction. Open with something broad like "Walk me through when you first started using the product" and gradually narrow down. The transition questions matter most. You want to move from general experience into specific moments without making it feel like an interrogation. I usually aim for about 75 minutes per interview. Anything shorter and you're skimming. Anything longer and people get fatigued, which means their answers get thinner. You'll spend roughly 10 minutes on rapport building before you hit the first real question. Then you move through your guide, probably spending five to eight minutes per core question, with follow-up probes taking another two to three minutes each where they're needed. The probes are what separate a good semi-structured interview from a bad one. A probe is just a gentle nudge like "Can you tell me more about that?" or "What did that look like in practice?" You're not leading the witness. You're asking the person to go deeper on something they already introduced. If you're doing more than two follow-up questions on a single point, you've probably gone off track and need to loop back to your guide.
Write your questions in plain language. If you're asking about "organizational synergy," you're not doing qualitative research, you're doing a buzzword exercise. People should understand every question without needing it translated. I've seen interview guides that used terms like "stakeholder alignment" and "value proposition" in studies with non-corporate participants. It sounds funny now, but those guides produced data that was useless because the respondents were guessing at what the questions meant instead of answering them.
What nobody tells you about the actual execution
Recording quality matters more than most people think. I once spent four hours transcribing an interview only to realize the audio had a hum that made about 30 percent of the responses unintelligible. I had to call the participant back and re-record half the conversation. Use a decent external microphone. Phone recordings are barely acceptable. Laptop built-in mics are worse. A $60 USB mic will save you hours of wasted time. Here's something that came up in a project I ran a while back that I still think about: I was interviewing frontline healthcare workers about burnout, and I had built a really solid guide around workload, staffing, and emotional impact. Halfway through the second interview, the participant asked me directly, "Do you think I'm being dramatic?" I didn't have a good answer for that in the moment. What I should have said was something like "I'm here to understand your experience, not judge it." The participant then opened up about something much deeper than anything in the guide. If you can't handle that kind of moment gracefully, the interview falls apart. Another thing: don't try to cover every question with every participant. If you ask 8 core questions and three of them naturally come up in the first 15 minutes of conversation, you don't need to go back to them later. That's efficient interviewing. Going back to re-ask things you've already covered just makes the person feel like you're ticking boxes.
Analysis: where most people stall out
The interviews themselves are the easy part. Analysis is where projects die. You'll have hours of audio, maybe transcribed, maybe not. Thematic analysis is the standard approach. You code the data by identifying recurring patterns, then group those patterns into themes. It's iterative. You don't do it linearly. You read through a few interviews, note what's coming up, go back and re-read with those notes in mind, then keep refining. I use a mix of manual coding and software like NVivo or Dedoose. For small projects under 20 interviews, manual coding with highlighters and a spreadsheet works fine. Beyond that, you'll need the software. The cost is worth it at that scale because the search and categorization features save you from going crazy trying to find every mention of a particular concept across dozens of transcripts. Here's a counter-intuitive point: sometimes the most valuable data comes from the interviews where the participant talked the least about your research topic and the most about something tangential. I had one interview with a teacher who spent most of the session talking about how the mentorship program changed her relationship with her department head. That wasn't on the guide. But it turned out to be the single most important finding of the entire study because it revealed that informal relationships mattered more than the structured program design. If I'd stuck rigidly to the guide, I would have missed it.
When semi-structured interviews are the wrong tool
They don't work when you need numbers. If your stakeholder asks "what percentage of users" or "how much did satisfaction change," this method won't give you a clean answer. Use a survey for that. They also fall apart when you're dealing with a population that has very little to say about your topic. If you're researching something niche and your sample size is 10 people, the findings won't generalize. You'll have depth, not breadth. That's fine if that's what you signed up for, but don't pretend it's the same thing as statistical significance. Time is another constraint. A single well-run semi-structured interview, including recruitment, scheduling, the interview itself, transcription, and analysis time, can take 8 to 12 hours of work. If you need 20 interviews for a study, you're looking at 160 to 240 hours. That's not a small project. If your timeline is six weeks and you have one person doing the work, you're not going to make it. Plan accordingly or use a shorter format like structured interviews instead. The other limitation is interviewer effect. The person conducting the interview shapes the data. Your tone, your reactions, the way you phrase probes all influence what the participant says. This isn't a flaw in the method, it's just a fact. If you're new to this, pair up with someone experienced for your first few interviews. Having a second person observe and give feedback on your technique will save you from developing bad habits that creep into your data.
A practical workflow you can steal
Week one: write the guide, pilot it with two people who aren't part of your actual study, revise based on what felt confusing or where the conversation went nowhere. Week two and three: run the interviews, aiming for one every other day so you have time to debrief and adjust between sessions. Week four: transcription. Week five and six: coding and thematic analysis. Week seven: write up the findings with direct quotes to anchor each theme. That's a realistic six-week timeline for a solid qualitative study using semi-structured interviews. Something I learned the hard way: always over-recruit by two or three participants. People cancel. Someone shows up and is uninterested. Audio fails. Having a buffer means you're not scrambling at the last minute to fill slots you should have already secured.
