How to synthesize user interviews into findings

Synthesizing user interviews into findings takes four steps: code the raw quotes, group codes into themes, draw findings from themes, and for every finding note the participant count, representative quotes, and counterexamples. Findings built this way can be checked by others and turned directly into recommendations. After reading this, you'll be able to turn a batch of interview notes into a list of findings and prioritized recommendations.

From quotes to codes to themes to findings

1. Quotes: first transcribe the interviews and keep quotes by participant ID. Don't write summaries first; summaries already mix in the note-taker's interpretation.
2. Codes: read passage by passage and give each meaningful passage a short label, such as "Can't find the export option" or "Worried colleagues will see the data". Keep labels close to the quotes, and err on the side of more detail.
3. Themes: group codes with similar meanings and give each group a name that explains the issue, such as "Permission concerns when collaborating". A theme usually consists of several codes and involves multiple participants.
4. Findings: answer the research question by explaining what the theme means, backed by counts, quotes, and counterexamples.

Start the first two steps while interviews are still underway, synthesizing after every few sessions. This lets you adjust follow-up questions in time and judge whether themes have reached saturation.

Affinity diagram: grouping codes into themes

An affinity diagram is the most common way to group codes. Write each code, along with the participant ID, on a card (sticky notes or an online whiteboard both work). Then have a few people work together to group cards with similar meanings into piles, and name each pile.

• Place the cards first, name the piles later. Deciding on categories up front tends to force cards into them.
• If a pile has more than a dozen or so cards, see whether it can be split into two more specific themes.
• Don't rush to throw out a pile with just one card. It may be a rare but important issue; flag it separately.
• For each pile, count how many participants it comes from, not how many cards. Repeated comments from the same person count once.
• Ideally, include a colleague who didn't take part in the interviews in the grouping, to reduce the interviewer's preconceptions.

An example: from three quotes to one finding

The following example comes from interviews about a team document tool; participant IDs and counts are illustrative. Three participants said the following.

Here's how the synthesis went. Each quote gets a code: "Afraid to share the link, uses screenshots instead", "Manually deletes content before sharing", "Doesn't understand permission options, gives up on sharing". All three codes point to the same thing: users aren't sure what the other person will be able to see and do after sharing, so they work around it or give up. These go into the theme "Unsure about the consequences of permissions when sharing". Checking the other notes, suppose 4 more participants expressed something similar, while 2 participants said they only share within their own team and have never worried about permissions; those are recorded as counterexamples.

Example finding: in this example, 7 of 18 participants switched to screenshots, manually deleted content, or gave up on sharing because they weren't sure what permissions the other person would have; 2 participants who only share within their own team had no such concern. The representative quote is from Participant 07.

How to write each finding

A complete finding has four parts: a one-sentence finding, a participant count, representative quotes, and counterexamples. The finding should be specific about behavior and context, and the count should read "X of Y participants", not just "many users". Choose the one or two quotes that best illustrate the point and label them with participant IDs. For counterexamples, note who doesn't fit the finding and why; if you didn't find any, say that you checked.

Separate facts, interpretations, and recommendations

The most common mistake in synthesis is putting three different kinds of content into one sentence. A fact is what the participant said or did; an interpretation is what the person doing the synthesis thinks it means; a recommendation is what the team plans to do. Write them separately so readers can tell which step might be wrong.

Write recommendations and prioritize them

Every recommendation should trace back to one or more findings. Write recommendations concretely enough for the team to discuss directly: what to change, for whom, and what behavior change you expect. To prioritize, score on four factors: reach, meaning how many participants are affected and the size of the corresponding user group; severity, meaning whether it leads to abandonment or churn; strength of evidence, meaning support from counts, counterexamples, and behavior data; and implementation cost. Put high-impact, strong-evidence, low-cost items first. For high-impact items with weak evidence, validate first, then decide whether to do them.

Avoid overgeneralization and confirmation bias

Overgeneralization means treating what a few people said as widespread; confirmation bias means seeing only what supports your assumptions. Both make findings look clear when they don't actually hold up.

• Before synthesizing, write down the team's existing hypotheses, and look specifically for quotes that contradict them.
• Note counts and counterexamples for every finding. If only one or two people said something, mark it low confidence, however vivid it is.
• Check whether a finding comes only from participants in one group or one channel.
• Have someone who didn't take part in the interviews read the quotes and see whether they arrive at the same themes.
• Counts from qualitative interviews show coverage. For judgments about proportions and scale, validate with a survey or behavior data.