How to Analyze User Interviews With Source-Linked Evidence

Start with the source, not the summary. Separate what you observed from what you concluded, group the moments that describe the same problem, and test the Finding against evidence that contradicts it. A transcript summary helps you navigate a recording; it is not the evidence a product decision needs.

UserTold preserves the Interview record and extracts Evidence after processing. Your job is to verify what those moments support before a draft Finding becomes a reviewed problem.

1. Check the source before the summary

Open the completed Interview and check the recording, the transcript, the page context, and the processing state. If capture was interrupted or evidence processing failed, carry that limitation into your analysis: missing Evidence is not proof that nothing went wrong.

Start with moments relevant to the Study's goal. Listen before and after a quote so that a clipped sentence does not reverse the participant's meaning. Where screen recording is available, compare the explanation with the actual workflow.

2. Keep three kinds of information separate

Kind	Example	What it supports
Participant report	“I thought inviting a teammate was required.”	The participant's stated understanding.
Observed behavior	The participant pauses on the invitation screen and leaves setup.	The captured sequence, not its hidden cause.
Interpretation	An optional invitation may appear mandatory.	A hypothesis to compare with the interface and other source moments.

If a quote is missing, do not turn an observed pause into “the user was confused.” If the page was not captured, do not describe an inferred interface state as something the recording proves.

3. Group by the problem, not just the wording

Compare task, user context, expected outcome, obstacle, and consequence. Two mentions of “setup” may describe unrelated problems. Different words can describe the same obstacle.

For example, an invitation screen that appears mandatory is different from an invitation email that never arrives. Grouping both as “fix invitations” hides the decision you need to make.

UserTold can group related Evidence into draft Findings. Open the linked moments and correct, split, or dismiss a grouping when the sources do not support one coherent problem. Repeated quotes from the same episode are not independent participants.

4. Look for counter-evidence

Review smooth completions as well as struggling moments. Ask:

• Did another participant understand the same screen?
• Were the users doing the same task, with the same permissions and product version?
• Did an earlier instruction influence what the participant expected?
• Is an existing product capability already solving the problem?
• Could a capture gap explain the apparent sequence?

Disagreement is useful. It may narrow a Finding to a specific situation instead of disproving the experience or justifying a broad redesign.

5. Write a Finding with a clear boundary

Use this review structure:

• Problem. What prevented the intended progress?
• Context. Who was doing which task, and under what conditions?
• Evidence. Source moments, quotes, behavior, and timestamps.
• Interpretation. What might explain those moments?
• Counter-evidence. Where did the workflow work, or the explanation differ?
• Unknowns. What does the record not establish?
• Next decision. Investigate further, defer, dismiss, or consider a change.

Do not treat an extraction confidence score as the probability that a proposed fix will work. It does not establish prevalence, revenue impact, or engineering priority.

6. Review before handing off

A person or a project-aware agent checks the Finding against its Evidence and against the product as it stands today. Marking it reviewed does not send it anywhere; sending it to Linear or GitHub is a separate, explicit decision.

See prioritizing fixes with evidence for that decision and interviews to issues for the handoff.

Questions about analysis

Can AI analyze the whole interview for me?

AI can help extract relevant moments and organize material. You still need to verify source attribution, ambiguous statements, grouping, and the resulting product interpretation. A good workflow makes that verification easy instead of hiding it behind a polished summary.

The AI interviewer also keeps a running evidence summary for the planned debrief. That drives follow-up questions during the session; the extraction described here happens afterwards and is a separate step.

What if I only have one interview?

Record the specific problem and its limits. One interview can expose a reproducible defect or an experience worth taking seriously; it cannot tell you that most users share it. Run another focused Study when the uncertainty matters to the decision, and use the research templates to choose the next task.

Help me apply this guide to my UserTold interviews. Review the source evidence with me and work from what it supports.

Read this guide first: https://usertold.ai/guides/analyze-user-interviews

Use my existing UserTold connection. If it is not connected, help me connect through https://mcp.usertold.ai/mcp and complete browser authorization. Ask for missing project details, use the available UserTold tools, and walk me through any steps that need the dashboard.