| name | user-research-methods |
| description | Qualitative and quantitative user research synthesis techniques. Use when processing raw user interviews, survey data, usability tests, support tickets, or app reviews into structured insights. |
User Research Methods
Turning raw user data into product decisions requires systematic synthesis — not just reading through notes and summarizing impressions. This skill covers the core methods for processing different research types into structured, actionable artifacts.
When to Use This Skill
- Synthesizing interview transcripts into themes
- Analyzing open-ended survey responses
- Processing usability test session notes
- Extracting patterns from support tickets or app store reviews
- Combining multiple research sources into a unified findings document
- Assessing whether existing research is sufficient to make a decision
Core Concepts
1. Separate Observations from Interpretations from Recommendations
The most common research synthesis error is conflating these three layers:
- Observation: "5 of 8 participants clicked the wrong button on the checkout screen"
- Interpretation: "Users don't understand that the primary CTA is the blue button"
- Recommendation: "Make the primary CTA visually distinct from the secondary action"
Keep them separate. Observations are facts. Interpretations can be wrong. Recommendations follow from valid interpretations.
2. What Users Say vs. What Users Do
Self-reported behavior in interviews often contradicts observed behavior in usability tests. When there's a conflict, behavioral data wins. Flag the contradiction — it's a finding in itself.
3. Frequency × Impact Prioritization
Not every theme deserves equal weight. Score themes on two axes:
- Frequency: How many participants raised this theme?
- Impact: How much does this theme affect their core goal?
A theme raised by 2 participants that blocks task completion outweighs a theme raised by 8 participants that's mildly inconvenient.
Interview Synthesis
Affinity Mapping Process
- Extract raw observations — one observation per note (quote, behavior, or reaction)
- Group by similarity — cluster observations that describe the same underlying phenomenon
- Name each cluster — give each group a label that describes the pattern, not the observation
- Count frequency — how many participants does each cluster represent?
- Assess impact — for each cluster, what's the consequence for the user's goal?
Theme Extraction Template
Theme: [Name]
Frequency: [X of N participants]
Impact: [Critical / Major / Minor]
Representative quote: "[verbatim quote from participant]"
Supporting observations:
- [Participant A]: [observation]
- [Participant B]: [observation]
Interpretation: [What this means for the product]
Contradiction Identification
When analyzing multiple interviews, actively look for:
- Participants who said the opposite of the majority
- Cases where the same participant said one thing but described doing another
- Themes that appear in interviews but not in behavioral/analytics data
Flag contradictions explicitly — they often reveal the most important design tensions.
Survey Analysis
Open-Ended Response Coding
- First pass: Read all responses without categorizing
- Define code categories: Identify 5–10 recurring themes from the first pass
- Code each response: Assign one or more codes per response
- Count by code: What percentage of responses mention each theme?
- Pull representative quotes: Find the clearest example of each code
Sample Size Guidance
| Sample | Confidence Level |
|---|
| < 30 responses | Directional only — flag explicitly |
| 30–100 responses | Moderate confidence on major themes |
| 100–300 responses | Good confidence on themes > 10% frequency |
| 300+ responses | Statistically meaningful for most segment analysis |
Always report sample size alongside findings. "Most users want X" is meaningless without "N=47."
Usability Research
Severity Classification
| Severity | Definition | Example |
|---|
| Critical | Blocks task completion | User cannot complete checkout |
| Major | Causes significant struggle or abandonment risk | User spends 3+ minutes confused before proceeding |
| Minor | Causes mild friction but task completes | User hesitates briefly before clicking |
| Cosmetic | Polish issue only | Icon doesn't match the action perfectly |
Task Completion Analysis
For each task in a usability test, record:
- Completion rate: X of N participants completed successfully
- Mean time on task: Average time to complete (for successful completions)
- Error rate: Average number of errors per session
- Drop-off point: Where did non-completions abandon?
Structured Output Artifacts
Research Summary
# Research Summary: [Study Name]
## Study Overview
- Method: [interviews / survey / usability / mixed]
- Participants: [N] [describe sample]
- Date: [when conducted]
- Confidence: [high / medium / low — with rationale]
## Top Findings
1. [Finding 1] — [Frequency] — [Impact]
2. [Finding 2] — [Frequency] — [Impact]
3. [Finding 3] — [Frequency] — [Impact]
## Key Quotes
> "[Quote]" — [Participant descriptor]
## Gaps
- [What this research doesn't answer]
- [Additional research recommended]
Research Gap Assessment
Before proceeding to product decisions, flag if any of the following are unresolved:
- The research is more than 12 months old for a fast-moving market
- Sample size is below 30 for the primary segment
- The research covers what users say but not what they do
- A critical user segment is unrepresented in the sample
Best Practices
- Document methodology — how participants were recruited, what they were asked
- Preserve verbatim quotes — always keep the original language, not your paraphrase
- Flag confidence levels — be explicit about thin vs. strong evidence
- Separate segments — findings for power users may not apply to new users
- Connect to decisions — every finding should map to a product question it answers
- Identify research debt — what questions still need answering before the next major decision?
