--- id: sm-user-research-synthesis name: "user-research-synthesis" url: https://skills.yangsir.net/skill/sm-user-research-synthesis author: anthropics domain: product tags: ["user-research", "qualitative-data-analysis", "affinity-mapping", "persona-development", "ux-insights"] install_count: 418 rating: 4.20 (26 reviews) github: https://github.com/anthropics/knowledge-work-plugins --- # user-research-synthesis > 擅长综合用户研究，将原始定性和定量数据转化为结构化洞察，以推动产品决策。 **Stats**: 418 installs · 4.2/5 (26 reviews) ## Before / After 对比 ### 转化用户研究为产品洞察 ## Readme # 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: - **Familiarization**: Read through all the data. Get a feel for the overall landscape before coding anything. - **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. - **Theme development**: Group related codes into candidate themes. A theme captures something important about the data in relation to the research question. - **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? - **Theme refinement**: Define and name each theme clearly. Write a 1-2 sentence description of what each theme captures. - **Report**: Write up the themes as findings with supporting evidence. ### Affinity Mapping A collaborative method for grouping observations: - **Capture observations**: Write each distinct observation, quote, or data point as a separate note - **Cluster**: Group related notes together based on similarity. Do not pre-define categories — let them emerge from the data. - **Label clusters**: Give each cluster a descriptive name that captures the common thread - **Organize clusters**: Arrange clusters into higher-level groups if patterns emerge - **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: - **Identify behavioral patterns**: Look for clusters of similar behaviors, goals, and contexts across participants - **Define distinguishing variables**: What dimensions differentiate one cluster from another? (e.g., company size, technical skill, usage frequency, primary use case) - **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 - **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 Weekly Installs407Repository[anthropics/know…-plugins](https://github.com/anthropics/knowledge-work-plugins)GitHub Stars9.9KFirst SeenJan 31, 2026Security Audits[Gen Agent Trust HubPass](/anthropics/knowledge-work-plugins/user-research-synthesis/security/agent-trust-hub)[SocketPass](/anthropics/knowledge-work-plugins/user-research-synthesis/security/socket)[SnykPass](/anthropics/knowledge-work-plugins/user-research-synthesis/security/snyk)Installed onopencode345codex339gemini-cli332github-copilot320cursor308kimi-cli302 --- *Source: https://skills.yangsir.net/skill/sm-user-research-synthesis* *Markdown mirror: https://skills.yangsir.net/api/skill/sm-user-research-synthesis/markdown*