User Research Synthesis From Transcripts

Write your research question at the top of the page in one sentence, and keep it in view. Nielsen Norman Group, a UX research firm, warns that without goals for the analysis, researchers get absorbed in the detail and the research reports on the wrong thing¹.

Next, list your sessions, one row each: a participant ID such as P1, their role, the date and the length. Use the ID everywhere and keep names out of anything you share. Note any two people who aren’t independent, such as colleagues at one company, and any session that is missing or cut short.

Then check each transcript against its recording. If an automatic transcript mixes up who is speaking, fix the labels or mark the passage as uncertain. Sessions where people worked through set tasks call for a usability test report instead, which rates each problem by severity.

Coding means marking each passage that bears on your question with a short label for what it says. It is the second of six phases in thematic analysis, the method psychologists Virginia Braun and Victoria Clarke set out in a widely cited 2006 paper. The paper’s checklist asks whether each data item has been given equal attention² and warns against themes built from a few vivid examples.

Nielsen Norman Group notes that analysis is often done superficially, skimming topics, focusing on only memorable events and quotes, and missing large sections of notes¹.

Copy the words exactly. The UK government’s Service Manual asks teams to write down exactly what they saw or heard, not what they think it means³. Keep a line of context around each quote, and give a quote two codes if it says two things.

With every transcript coded, sort the codes into groups, on sticky notes or in the sheet. A group becomes a theme when one idea holds it together. Braun and Clarke’s own guidance says a theme tells the reader something about the shared meaning⁴ in the data. A topic summary just gathers what people said about one area.

The name gives it away. They call “Experiences of Y” and “Benefits of X” classic examples of topic-summary type theme names⁴. Reporting your interview questions as themes is the same mistake. Their 2006 paper says it means no analytic work has been done². Rewrite each topic as the claim your quotes support.

• “Onboarding” becomes “New customers stall because nobody owns a stuck request”
• “Experiences of approvals” becomes “Approvals feel like asking a favor, not a step”
• “Notifications” becomes “People check three tools to find out where a request is”

Test each theme against the whole set, not only the quotes you gathered for it. Reread a transcript you didn’t draw on and see whether the claim still holds. Note which interview each code first appeared in, too. If most came from the first session or two, check that the later interviews bear them out.

Braun and Clarke describe three ways to measure how common a theme is. You can count the data items it appears in (here, transcripts), the number of different speakers who raised it, or each individual occurrence². In one-to-one interviews each transcript is one person, so the real choice is people or mentions. The two can rank your themes in opposite orders.

Counts don’t settle importance on their own. Braun and Clarke’s paper also notes that more instances do not necessarily mean the theme itself is more crucial². A problem two people described in detail can matter more than one that eight mentioned in passing. Say why each theme matters, not only how often it came up.

Leave percentages out, since they imply a share of all your users. As Nielsen Norman Group’s Maria Rosala explains, interviews aim to understand experiences in detail, not to determine how many people have had a given experience⁵. For that, she points to a follow-up quantitative study.

When someone contradicts a theme, record their quote against it instead of dropping it as an outlier. Braun and Clarke put it plainly: it is important to retain accounts which depart from the dominant story². A theme with six supporters and two dissenters is a different finding from one with six and none.

A theme nobody contradicts deserves a second look, because dissent is easy to lose. Among the common problems of qualitative analysis, Nielsen Norman Group lists findings where viewpoints that don’t fit with the researcher’s belief are ignored¹.

State each finding as a claim. The UK government’s Service Manual gives examples such as “people think they can click the progress bar to navigate.”³ Under each claim, add its count out of the total and two to four quotes with participant IDs. Then add the view that contradicted it and what it means for the decision at hand.

Keep the readout short. The Service Manual suggests 1 or 2 slides on the research you did, 5 to 10 on findings, and 1 or 2 on what you’re doing next⁶. Order findings by the count you chose, say which on the first slide, and end with what this round couldn’t establish.

Describe your choices as choices. Braun and Clarke object to writing that themes “emerged,” calling it a passive account of the process of analysis². Say how you grouped and named them, and note the close calls.

A finding that survives the readout often becomes a requirement in a product requirements document, quotes and all. If the problem follows a sequence of steps, a user journey map template ties each step to its evidence. To skip the hand counting, the tool at the top of this page codes every transcript and counts each theme by people and by mentions.