How to synthesise user research: from interview evidence to useful findings

To synthesise user research, review the source material, record individual observations, group related evidence, test your interpretations against exceptions, and turn the strongest findings into decisions or further questions. Keep a route back to the interview or observation that supports each claim. A polished summary without that route is difficult to challenge and easy to overread.

This guide focuses on qualitative product research: customer interviews, exploratory conversations and the spoken parts of usability sessions. It gives you a practical way to work across recordings without treating an AI summary, a popular quote or a wall of sticky notes as a finished finding. It is not a substitute for the methodological requirements of an academic, clinical or regulated study.

What research synthesis should produce

The useful output is an explanation that helps someone make a decision. For example: which part of onboarding needs investigation, why a workaround exists, or what the team should test before building a requested feature.

Analysis breaks the material into manageable pieces. Synthesis examines relationships between those pieces. In practice you move between them: a possible pattern sends you back to an interview, where a qualification changes the pattern. GitLab describes its research synthesis process as organising evidence into themes and relating the resulting insights to the original research questions and hypotheses. GitLab research handbook

Keep four things distinguishable in your working notes:

• Evidence: what someone said or what an observer saw, with its source.

• Interpretation: what you think that evidence means.

• Uncertainty: what is missing, ambiguous or contradicted.

• Proposal: what you suggest doing next.

These are useful working distinctions, not a compulsory taxonomy. Their purpose is to stop a suggestion such as “build an approval dashboard” being mistaken for something participants requested or research proved.

Before you start: define the question and the material

Write down the decision this research is meant to inform. “Understand our users” gives you little guidance when every conversation contains something interesting. “Understand why first-time administrators hesitate before inviting colleagues” gives you a boundary you can use.

Then make a simple inventory of the sessions you intend to review. Record the participant identifier, date, relevant role or context, and which materials exist. You might have audio, a transcript, observer notes and a session summary. Mark incomplete recordings and missing notes before drawing conclusions across the set.

An interview tells you what a person reported. A usability observation can tell you what they did in that particular session. Neither automatically establishes what all customers do in normal use. Keep the evidence type visible so you do not turn “I usually ask my manager” into an observed behaviour.

If you have several sessions with one person, preserve that relationship. Five similar excerpts from one participant are five excerpts, not five independent participants. Also note changes in the product or research question between sessions; otherwise you may combine experiences of different interfaces as if they were the same problem.

Use only material you are authorised to analyse and share. Decide which identifiers the working group needs, who can open the originals, and whether the intended analysis tool is appropriate for those recordings. Preparing an anonymised-looking report does not automatically make its underlying audio anonymous.

1. Review each session before comparing sessions

Start with one complete session at a time. Read the notes and transcript, then return to the recording wherever wording, attribution or context matters. If you still need a transcript, use the separate guide to transcribing a research interview.

Capture enough context to explain an extract later. A useful observation includes what was happening, what the participant said or did, and where you can find it again. Avoid clipping a sentence so tightly that a qualification in the next sentence disappears.

For instance, “I would never use that” may refer to a proposed workflow shown moments earlier, not to the whole product. A summary can lose that distinction. Check the surrounding exchange before presenting the sentence as evidence against a feature.

The GOV.UK Service Manual recommends making recordings available during analysis so people can confirm observations and exact quotations. It also separates what was seen or heard from what the group thinks it means. GOV.UK: analyse a research session

At the end of each review, write a brief session-level account: the participant's context, the issues relevant to your question, and anything that challenges your early assumptions. This gives you something to compare without flattening the whole person into isolated fragments.

2. Capture small observations with traceable sources

Use one idea per observation. A spreadsheet row, a sticky note or a research tool can all work. The important property is traceability, not the software.

Consider this fictional interview note:

Participant P03, finance administrator, 14:20: reports exporting the same report twice because the first export does not show whether approval is complete. Has done this during the last two monthly reviews. We did not observe the export happening.

That note preserves the context, source location and evidence boundary. “Reporting is confusing” loses almost everything you would need to evaluate it. “Needs a dashboard” goes further and replaces the evidence with a solution.

If an excerpt contains unclear audio, mark the uncertainty. If you paraphrase, label it as a paraphrase. Do not tidy a machine transcript and place the repaired wording in quotation marks as though you verified it. Names, quantities and negations deserve particular attention because a small transcription error can reverse the interpretation.

Keep your original source intact. Put your interpretation in a separate field or note so another reviewer can disagree without losing the evidence you both started from.

3. Group by the question, then look for differences

Bring the observations together and form provisional groups. Depending on your question, you might group by a task, a point in the journey, an obstacle or a workaround. Give each group a descriptive name that says something about the experience.

“Onboarding” is a topic. “Administrators delay invitations until they understand what colleagues can see” is a proposed finding. You may start with the topic, but you need evidence before you can use the stronger statement.

GitLab's published method uses affinity grouping, then discussion and revision of the groups. It also recommends challenging emerging insights by looking for an opposing interpretation. GitLab's analysis and synthesis guidance

Treat grouping as a way to inspect evidence, not a vote in which the largest pile wins. A repeated minor annoyance and one serious barrier call for different judgements. Record both frequency within your reviewed sample and the consequence described or observed. Do not infer market prevalence from a small qualitative sample.

Look for differences within a group. New administrators may need an explanation of permissions; experienced administrators may understand permissions but be waiting for a colleague's approval. Those experiences can produce the same visible delay for different reasons. Combining them into one generic “confusing onboarding” finding would hide useful work.

4. Challenge every important interpretation

Before calling a pattern a finding, try to make it fail. This does not require an elaborate scoring system. Ask concrete questions:

• Which reviewed sessions support this interpretation?

• Which sessions contradict it or suggest a different explanation?

• Did every participant have an opportunity to discuss or encounter this issue?

• Are several excerpts repetitions from the same person?

• Did our question introduce the idea rather than elicit it?

• Does the recording support the wording we plan to use?

If someone never reached the invitation screen, their silence about permissions is not evidence that permissions were clear. If a participant mentions an issue repeatedly, that may indicate importance to that person; it does not increase the participant count.

Keep exceptions attached to the finding. An exception may define the boundary that makes the finding useful. “First-time administrators in the reviewed sessions” is narrower and more defensible than “users”. Where evidence remains thin, call it a hypothesis for the next round rather than polishing it into certainty.

5. Write the finding before choosing the solution

A useful finding explains the context, the pattern and its consequence. Add the evidence that supports it and the qualification that limits it. Keep the proposed action visibly separate.

Here is a fictional worked example, not a Weeve customer result:

Research question: Why do first-time administrators postpone inviting colleagues?

Evidence reviewed: Two participants reported checking visibility settings before sending invitations. A third invited a colleague immediately and explained that they had used a similar product before. One other session did not cover invitations.

Finding: In these sessions, uncertainty about what an invited colleague could see was a barrier for two first-time administrators. The experienced participant's immediate invitation suggests familiarity may matter, but this small set does not establish the cause of every delay.

Proposed next step: Test a clearer permissions preview with first-time administrators. Observe whether they can explain access correctly before inviting anyone.

Open question: Is waiting for internal approval a separate barrier in larger organisations?

Notice what the example does not claim: a percentage of the market, proof that a specific interface change will work, or a request for a dashboard. The next step is proportionate to the evidence and can itself be checked.

6. Use AI to help review recordings, with source checks

AI can help assemble passages for review, compare accounts and draft a preliminary explanation. It can also omit a relevant session, misread a qualification or produce a convincing pattern that your material does not support. Make the scope and review requirements part of the task.

In Weeve Chat, you can ask questions across saved recordings and narrow the material by people, projects or dates. The research-interview analysis workflow explains the supported use: exploring recorded material and checking cited sources. It does not provide a validated qualitative coding framework, inter-rater reliability or proof of saturation.

A useful request is: “Review the onboarding interviews in this project. Identify passages about inviting colleagues. Keep each participant's account separate, cite the sources, include conflicting accounts, and say which requested material you could not review.” Adjust the request to the recordings actually in your library.

Read the coverage notice and open the sources behind important claims. For supported timed passages, retained audio can help you check what was said. A cited summary is still a summary; inspect the transcript and audio when exact wording or attribution affects your conclusion.

A genuine Weeve interface capture with demonstration content, illustrating source review rather than the fictional research example above.

Local chat processes recording text on your Mac. Choosing an optional cloud provider changes that processing boundary: relevant text is sent to the selected provider. Check the provider choice against the permissions for your research material. Keep AI-generated interpretations provisional until a person has checked the evidence.

7. Share a decision-ready account and preserve the trail

Lead the report with the question, the strongest findings and the decisions they inform. Give readers enough supporting evidence to assess the argument without requiring them to replay every session. Include the sample context, missing material, contradictory evidence and the questions that remain open.

For each proposed action, state what you expect to learn or change and how you will check it. “Improve onboarding” is difficult to evaluate. “Test whether administrators can correctly explain colleague access before sending an invitation” gives the next study a concrete task.

Keep a source reference beside every important finding in your working report. Share excerpts only with the appropriate audience and access. If you use interview highlights, check that the excerpt retains the qualification and does not identify someone unexpectedly through its content.

The final review is simple: can a colleague follow the path from conclusion to evidence, explain the limits, and tell a proposed solution from an observed fact? If they can, the synthesis is ready to inform the next discussion. If they cannot, return to the unclear link in that chain before adding more polish.