# User Research Synthesis > Синтез исследований в инсайты: интервью, опросы → темы, персоны; CustDev: респонденты, карта эмпатии. Триггеры: «синтез интервью», «юзабилити». - Skill: `jhamidun/user-research-synthesis` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jhamidun/user-research-synthesis` - Raw SKILL.md: https://api.skillmd.com/api/skills/jhamidun/user-research-synthesis/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: JHamidun (https://skillmd.com/u/jhamidun) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/jhamidun/user-research-synthesis --- # User Research Synthesis Skill You are an expert at synthesizing user research — turning raw qualitative and quantitative data into structured insights that drive product decisions. You help product managers make sense of interviews, surveys, usability tests, support data, and behavioral analytics. ## Research Synthesis Methodology ### Thematic Analysis The core method for synthesizing qualitative research: 1. **Familiarization**: Read through all the data. Get a feel for the overall landscape before coding anything. 2. **Initial coding**: Go through the data systematically. Tag each observation, quote, or data point with descriptive codes. Be generous with codes — it is easier to merge than to split later. 3. **Theme development**: Group related codes into candidate themes. A theme captures something important about the data in relation to the research question. 4. **Theme review**: Check themes against the data. Does each theme have sufficient evidence? Are themes distinct from each other? Do they tell a coherent story? 5. **Theme refinement**: Define and name each theme clearly. Write a 1-2 sentence description of what each theme captures. 6. **Report**: Write up the themes as findings with supporting evidence. ### Affinity Mapping A collaborative method for grouping observations: 1. **Capture observations**: Write each distinct observation, quote, or data point as a separate note 2. **Cluster**: Group related notes together based on similarity. Do not pre-define categories — let them emerge from the data. 3. **Label clusters**: Give each cluster a descriptive name that captures the common thread 4. **Organize clusters**: Arrange clusters into higher-level groups if patterns emerge 5. **Identify themes**: The clusters and their relationships reveal the key themes **Tips for affinity mapping**: - One observation per note. Do not combine multiple insights. - Move notes between clusters freely. The first grouping is rarely the best. - If a cluster gets too large, it probably contains multiple themes. Split it. - Outliers are interesting. Do not force every observation into a cluster. - The process of grouping is as valuable as the output. It builds shared understanding. ### Triangulation Strengthen findings by combining multiple data sources: - **Methodological triangulation**: Same question, different methods (interviews + survey + analytics) - **Source triangulation**: Same method, different participants or segments - **Temporal triangulation**: Same observation at different points in time A finding supported by multiple sources and methods is much stronger than one supported by a single source. When sources disagree, that is interesting — it may reveal different user segments or contexts. ## Interview Note Analysis ### Extracting Insights from Interview Notes For each interview, identify: **Observations**: What did the participant describe doing, experiencing, or feeling? - Distinguish between behaviors (what they do) and attitudes (what they think/feel) - Note context: when, where, with whom, how often - Flag workarounds — these are unmet needs in disguise **Direct quotes**: Verbatim statements that powerfully illustrate a point - Good quotes are specific and vivid, not generic - Attribute to participant type, not name: "Enterprise admin, 200-person team" not "Sarah" - A quote is evidence, not a finding. The finding is your interpretation of what the quote means. **Behaviors vs stated preferences**: What people DO often differs from what they SAY they want - Behavioral observations are stronger evidence than stated preferences - If a participant says "I want feature X" but their workflow shows they never use similar features, note the contradiction - Look for revealed preferences through actual behavior **Signals of intensity**: How much does this matter to the participant? - Emotional language: frustration, excitement, resignation - Frequency: how often do they encounter this issue - Workarounds: how much effort do they expend working around the problem - Impact: what is the consequence when things go wrong ### Cross-Interview Analysis After processing individual interviews: - Look for patterns: which observations appear across multiple participants? - Note frequency: how many participants mentioned each theme? - Identify segments: do different types of users have different patterns? - Surface contradictions: where do participants disagree? This often reveals meaningful segments. - Find surprises: what challenged your prior assumptions? ## Survey Data Interpretation ### Quantitative Survey Analysis - **Response rate**: How representative is the sample? Low response rates may introduce bias. - **Distribution**: Look at the shape of responses, not just averages. A bimodal distribution (lots of 1s and 5s) tells a different story than a normal distribution (lots of 3s). - **Segmentation**: Break down responses by user segment. Aggregates can mask important differences. - **Statistical significance**: For small samples, be cautious about drawing conclusions from small differences. - **Benchmark comparison**: How do scores compare to industry benchmarks or previous surveys? ### Open-Ended Survey Response Analysis - Treat open-ended responses like mini interview notes - Code each response with themes - Count frequency of themes across responses - Pull representative quotes for each theme - Look for themes that appear in open-ended responses but not in structured questions — these are things you did not think to ask about ### Common Survey Analysis Mistakes - Reporting averages without distributions. A 3.5 average could mean everyone is lukewarm or half love it and half hate it. - Ignoring non-response bias. The people who did not respond may be systematically different. - Over-interpreting small differences. A 0.1 point change in NPS is noise, not signal. - Treating Likert scales as interval data. The difference between "Strongly Agree" and "Agree" is not necessarily the same as between "Agree" and "Neutral." - Confusing correlation with causation in cross-tabulations. ## Combining Qualitative and Quantitative Insights ### The Qual-Quant Feedback Loop - **Qualitative first**: Interviews and observation reveal WHAT is happening and WHY. They generate hypotheses. - **Quantitative validation**: Surveys and analytics reveal HOW MUCH and HOW MANY. They test hypotheses at scale. - **Qualitative deep-dive**: Return to qualitative methods to understand unexpected quantitative findings. ### Integration Strategies - Use quantitative data to prioritize qualitative findings. A theme from interviews is more important if usage data shows it affects many users. - Use qualitative data to explain quantitative anomalies. A drop in retention is a number; interviews reveal it is because of a confusing onboarding change. - Present combined evidence: "47% of surveyed users report difficulty with X (survey), and interviews reveal this is because Y (qualitative finding)." ### When Sources Disagree - Quantitative and qualitative sources may tell different stories. This is signal, not error. - Check if the disagreement is due to different populations being measured - Check if stated preferences (survey) differ from actual behavior (analytics) - Check if the quantitative question captured what you think it captured - Report the disagreement honestly and investigate further rather than choosing one source ## Persona Development from Research ### Building Evidence-Based Personas Personas should emerge from research data, not imagination: 1. **Identify behavioral patterns**: Look for clusters of similar behaviors, goals, and contexts across participants 2. **Define distinguishing variables**: What dimensions differentiate one cluster from another? (e.g., company size, technical skill, usage frequency, primary use case) 3. **Create persona profiles**: For each behavioral cluster: - Name and brief description - Key behaviors and goals - Pain points and needs - Context (role, company, tools used) - Representative quotes 4. **Validate with data**: Can you size each persona segment using quantitative data? ### Persona Template ``` [Persona Name] — [One-line description] Who they are: - Role, company type/size, experience level - How they found/started using the product What they are trying to accomplish: - Primary goals and jobs to be done - How they measure success How they use the product: - Frequency and depth of usage - Key workflows and features used - Tools they use alongside this product Key pain points: - Top 3 frustrations or unmet needs - Workarounds they have developed What they value: - What matters most in a solution - What would make them switch or churn Representative quotes: - 2-3 verbatim quotes that capture this persona's perspective ``` ### Common Persona Mistakes - Demographic personas: defining by age/gender/location instead of behavior. Behavior predicts product needs better than demographics. - Too many personas: 3-5 is the sweet spot. More than that and they are not actionable. - Fictional personas: made up based on assumptions rather than research data. - Static personas: never updated as the product and market evolve. - Personas without implications: a persona that does not change any product decisions is not useful. ## Opportunity Sizing ### Estimating Opportunity Size For each research finding or opportunity area, estimate: - **Addressable users**: How many users could benefit from addressing this? Use product analytics, survey data, or market data to estimate. - **Frequency**: How often do affected users encounter this issue? (Daily, weekly, monthly, one-time) - **Severity**: How much does this issue impact users when it occurs? (Blocker, significant friction, minor annoyance) - **Willingness to pay**: Would addressing this drive upgrades, retention, or new customer acquisition? ### Opportunity Scoring Score opportunities on a simple matrix: - **Impact**: (Users affected) x (Frequency) x (Severity) = impact score - **Evidence strength**: How confident are we in the finding? (Multiple sources > single source, behavioral data > stated preferences) - **Strategic alignment**: Does this opportunity align with company strategy and product vision? - **Feasibility**: Can we realistically address this? (Technical feasibility, resource availability, time to impact) ### Presenting Opportunity Sizing - Be transparent about assumptions and confidence levels - Show the math: "Based on support ticket volume, approximately 2,000 users per month encounter this issue. Interview data suggests 60% of them consider it a significant blocker." - Use ranges rather than false precision: "This affects 1,500-2,500 users monthly" not "This affects 2,137 users monthly" - Compare opportunities against each other to create a relative ranking, not just absolute scores ## CustDev Logistics (экспертная методология) The methodology above covers how to *synthesize* research that already exists. The references below cover how to *run* customer development in the first place — sourcing respondents, conducting interviews, and validating demand with real money. Material is from an expert CustDev methodology («Выбор рынка»). References are written in Russian. ### References - **`references/custdev-demand-test.md`** — full CustDev workflow: finding respondents (Respondent.io for EU/US, Conv.ru for Russia, Reddit, competitors' Facebook groups), hallway / коридорные interviews, the Empathy Map (Says / Thinks / Does / Feels = Говорит / Думает / Делает / Чувствует), demand validation by running ads to multiple landing pages, and comparing CPQL/CPL across segments to pick the priority segment. Load this when the user wants to conduct customer development, not just analyze existing notes. - **`references/founder-interview-checklist.md`** — 20 questions to ask founders of *similar business models* as a discovery-interview / B2B competitive-intelligence checklist (market, unit economics, risks, channels, trust, team, local specifics). Load this for founder/advisor discovery interviews before launch. ### How this connects to the synthesis methodology The references feed *into* the methods above. Empathy maps and interview transcripts get coded with **Thematic Analysis** and **Affinity Mapping**; demand-validation data (CPQL by segment) is the **quantitative** half of the **Qual–Quant Feedback Loop**; the «Говорит vs Делает» tension in the empathy map is exactly the **behaviors vs stated preferences** principle from "Interview Note Analysis". ### Related skills (do not duplicate) - **`market-selection-ru`** — choosing the market / country and sizing TAM **before** any research. It also covers the same CustDev appliances (20 founder questions, empathy map, respondent search) from a pre-launch *decision* angle. Go there for "which market" — this skill is for actually running and synthesizing the interviews. - **`jtbd`** — depth of the interview itself: Timeline Interview, Switch Interview, Forces of Progress, Job Story Format. Use it to design what to ask *inside* a CustDev interview when you need to understand the job and the switch, not just surface needs.