Free Online Toolbox for developers

From recordings to decisions: What small teams get wrong about user interviews

You did the hard part. Twelve calls booked, twelve calls held, twelve recordings sitting in a folder. Three weeks later you can describe two of them from memory: the first one, and the one where somebody got angry. The other ten are a list of filenames.

That gap is where most small-team research dies. Not in the interviewing. In everything after it.

The recordings are the problem, not the research

A recording is a linear artifact. You can’t search it, you can’t put interview 3 and interview 9 side by side, and you can’t paste a sentence from one into a product spec. A 45-minute call gives up its contents at exactly one speed: 45 minutes per pass.

So the analysis falls back on memory. And memory doesn’t store what recurred – it stores what was vivid and what was recent. The participant who got frustrated gets remembered. The four people who each mentioned the same small thing in passing don’t, because no single one of them was memorable.

That’s the whole failure. You end up making a decision shaped by two interviews while believing it was shaped by twelve.

Step 1: Turn the recordings into text

Everything downstream is a text operation. Searching, comparing, counting, quoting. None of it runs on audio. The first move isn’t analysis. It’s conversion.

Two things matter here that don’t matter for other kinds of recordings.

The first is speaker separation. In an interview, roughly half the audio is you. If the transcript runs both voices together, your questions get folded into the participant’s answers. When you later count how many people raised pricing unprompted, you’ll be counting the times you brought it up yourself. Speaker labels aren’t a convenience. They’re what makes the counting mean anything.

The second is timestamps. Text strips tone. A line that reads flat on the page might have been the moment somebody got genuinely annoyed, and you’ll want to hear it again before deciding how much weight it carries.

Nielsen Norman Group’s guide to [thematic analysis of qualitative research data](https://www.nngroup.com/articles/thematic-analysis/) is worth reading before you start, since it sets out what a small qualitative sample can and can’t support.

Run each file through an audio to text converter. Let it labels each speaker separately, timestamps every line, and exports to TXT, DOCX or some other formats you need. 

NN/g’s [First Rule of Usability? Don’t Listen to Users](https://www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users/) is the other one to read early. It’s the clearest statement of why self-reported data needs handling with care.

Once all twelve are text, the folder stops being an archive and starts being a dataset.

Step 2: Read across, not down

Don’t read interview by interview. Read theme by theme.

Open all twelve transcripts and pull every passage about onboarding into one place. Then every passage about pricing. You’re building columns, not summaries.

This sounds obvious, and almost nobody does it, because it’s impossible with recordings. You’d be scrubbing twelve timelines hunting for a topic. In text it’s a search and a copy-paste. The method isn’t new. The reason it doesn’t happen is that most teams never convert the source material into something a search box can reach.

Reading down gives you twelve stories. Reading across gives you the thing you’re actually after: what showed up more than once.

Step 3: Tag in their words, then count what recurs

Don’t build categories first. Let them come out of the transcripts.

If three people say “I couldn’t tell if it saved,” don’t tag that as “UX friction.” You’ve just thrown away the specificity that would have told you what to fix. Tag it as “couldn’t tell if it saved.” Ugly labels are fine. Ugly labels are better.

Then count. Recurrence across independent interviews is the strongest signal a twelve-person sample can give you — nobody coordinated, and the same thing surfaced anyway.

But recurrence isn’t importance. Eight of twelve mentioning a minor annoyance doesn’t outrank two of twelve describing the thing that nearly made them leave. Frequency tells you what’s common. Severity tells you what’s expensive. Keep them in separate columns, and don’t let the bigger number win by default.

Step 4: Separate what they said from what they did

“I would definitely pay for that” isn’t data. “I paid for something like it last month” is.

Go through the transcripts and mark every future-tense claim as opinion, and every past-tense concrete action as evidence. Predictions about their own behaviour, enthusiasm for a feature that doesn’t exist yet, agreement with a leading question you asked – all opinion.

This pass is easy in text and impossible from memory, because what you remember is the enthusiasm, not the tense it was expressed in.

Then weight the two differently. Opinion tells you how somebody feels about an idea in the room. Evidence tells you what they’ve already been willing to do.

What goes wrong, and what to keep

Three failure modes account for most of it.

The loudest interview wins. One articulate, angry participant reshapes the roadmap while eleven milder observations get averaged into nothing.

You only talked to current users. They’re the ones who stayed. Whatever drove everybody else away won’t appear in your transcripts, and no amount of careful analysis will surface something nobody said.

The research turns into a document nobody reopens. A summary gets written, gets presented, and then can’t answer any question it wasn’t built to answer.

That last one is worth guarding against directly. Keep the transcripts, not just the conclusions. Six months from now somebody will question a decision, and you’ll want to check whether the evidence actually said what your summary claimed it said. Conclusions decay. The raw record doesn’t.

FAQs

How many user interviews are enough?

Enough is when new interviews stop producing new themes. For a narrow question that can happen around five or six; for a broad one, twelve won’t be enough. Track when you last heard something you hadn’t heard before. That’s a better stopping rule than a target number.

Do I need a dedicated research tool for this?

Not at the start. Transcripts, a spreadsheet with one row per tagged passage, and columns for frequency and severity will carry a small team a long way. Buy tooling when the spreadsheet actually breaks, not before.

Should I transcribe the interviews myself?

Transcribing by hand takes many times the length of the recording, and for internal research the accuracy gain over a good automatic transcript rarely earns that back. Correct the passages you plan to quote. Leave the rest as they came out.




Suggested Reads

Leave a Reply