When this skill is activated, always start your first response with the 🧢 emoji.
UX Research
UX research is the systematic study of target users to inform product design and business decisions. It bridges the gap between assumptions and evidence - replacing "we think users want X" with "users told us X because of Y." This skill covers the full research lifecycle: scoping a study, selecting methods, recruiting participants, collecting data, synthesizing findings, and communicating insights that drive action.
Good research is not about proving you are right. It is about reducing the cost of being wrong before you build. Five users in a moderated session will surface 80% of your usability problems for a fraction of what a failed launch costs.
When to use this skill
Trigger this skill when the user:
- Needs to plan a user research study or define research questions
- Wants to design or conduct user interviews or contextual inquiry
- Needs to run or script a moderated usability test
- Asks about creating user journey maps or experience maps
- Wants to design an A/B test, including hypothesis and sample size
- Needs to build a user survey or screener questionnaire
- Asks about creating personas from research data
- Wants to run card sorting or tree testing exercises
- Needs to synthesize qualitative data using affinity mapping
- Wants to write a research findings report or share-out
Do NOT trigger this skill for:
- Pure analytics or quantitative data analysis without a user behavior lens (use a data-analysis skill instead)
- UI/visual design decisions that are not grounded in a research question (use absolute-ui instead)
Key principles
- Research questions before methods - Define what decisions your research must
inform before choosing a method. "We will run interviews" is not a research plan. "We need to understand why users abandon the checkout flow" is.
- 5 users find 80% of issues - Jakob Nielsen's landmark finding still holds for
formative usability testing. Recruit 5 representative participants per distinct user segment. More sessions do not linearly increase insight - they surface the same issues repeatedly.
- Triangulate across methods - No single method answers everything. Pair
interviews (why) with analytics (how many) with usability tests (can they do it). Convergent findings across methods are high-confidence findings.
- Recruit representative users - Recruiting convenience samples (colleagues,
power users, friends) produces data that does not generalize. Screeners must filter for the behaviors and contexts that match your target segment, not just demographics.
- Synthesis is where value lives - Raw notes and recordings are not insights.
Value is created in the synthesis step: clustering observations into patterns, naming themes, and connecting evidence to design implications. Budget as much time for synthesis as for fieldwork.
Core concepts
Generative vs. evaluative research
| Type | Goal | When to use | Example methods | |---|---|---|---| | Generative | Discover problems, needs, and opportunities | Early in a project, before solutions exist | User interviews, diary studies, contextual inquiry | | Evaluative | Test whether a solution works for users | After a design exists, before or after launch | Usability tests, A/B tests, first-click tests |
Running evaluative research too early (testing mockups of unvalidated concepts) wastes cycles. Running generative research too late (interviewing users after building) surfaces insights you cannot act on.
Qualitative vs. quantitative
| Dimension | Qualitative | Quantitative | |---|---|---| | Question type | Why? How? What is the experience? | How many? How often? What percentage? | | Sample size | 5-20 participants | Hundreds to thousands | | Output | Themes, quotes, behavioral patterns | Statistics, rates, significance | | Risk | Hard to generalize; researcher bias | Misses "why" behind numbers |
Neither is superior. Qualitative research generates hypotheses; quantitative research tests them at scale.
Research ops
Research operations (ResearchOps) is the infrastructure that makes research repeatable: participant panels, consent templates, recording tools, repositories, and synthesis workflows. Without it, research knowledge lives in individual researchers' heads and dissipates when they leave.
Bias types to mitigate
| Bias | Description | Mitigation | |---|---|---| | Confirmation bias | Seeking evidence that supports existing beliefs | Define hypotheses before fieldwork; use a co-researcher to challenge interpretations | | Leading bias | Questions that suggest the desired answer | Use open-ended, neutral phrasing; pilot-test your guide | | Sampling bias | Participants who do not represent target users | Write behavioral screeners; recruit outside your network | | Social desirability bias | Participants saying what they think you want to hear | Ask about past behavior, not hypothetical preferences; observe over asking | | Recency bias | Over-weighting the last sessions in synthesis | Synthesize incrementally; weight all sessions equally |
Common tasks
Plan a research study
Use this template before any study begins:
RESEARCH PLAN
=============
Project: [Name]
Date: [Start - End]
Researcher: [Name]
RESEARCH QUESTIONS
1. [Primary question the research must answer]
2. [Secondary questions]
DECISIONS THIS RESEARCH INFORMS
- [Specific product/design/business decision]
METHOD
[Selected method and why it fits the research questions]
PARTICIPANTS
- Target segment: [Description]
- Number: [N per segment]
- Screener criteria: [Behavioral criteria, not just demographics]
TIMELINE
- Recruiting: [Dates]
- Fieldwork: [Dates]
- Synthesis: [Dates]
- Share-out: [Date]
MATERIALS NEEDED
- [Discussion guide / task scenarios / prototype / survey link]
SUCCESS CRITERIA
[How will we know the research answered the questions?]Conduct user interviews
Discussion guide structure:
- Warm-up (5 min) - Rapport-building; ask about their role and context. Never start with your main topic.
- Topic exploration (30-40 min) - Open-ended questions about behavior, not opinion.
- Specific scenarios (10-15 min) - "Tell me about a time when..." to get concrete stories.
- Wrap-up (5 min) - "Is there anything important I didn't ask about?"
Probing techniques:
| Probe | When to use | Example | |---|---|---| | The silent probe | After a short answer; pause 3-5 seconds | (silence) | | Echo probe | Repeat the last few words as a question | "You said it was confusing?" | | Elaboration probe | When an answer needs depth | "Can you tell me more about that?" | | Example probe | When an answer is abstract | "Can you give me a specific example?" | | Clarification probe | When a term is ambiguous | "When you say 'complicated,' what do you mean?" | | Impact probe | To understand consequences | "What happened as a result of that?" |
Rules for interviewers:
- Ask one question at a time. Never stack questions.
- Never suggest an answer in the question.
- Prioritize "what did you do?" over "what would you do?"
- Take sparse notes during the session; full notes immediately after.
Run moderated usability tests
Task design rules:
- Tasks must be scenario-based, not feature-based. "You want to send $50 to a friend" not "Use the transfer feature."
- Tasks must have a clear, observable completion state.
- Order tasks from low to high complexity.
- Include one task you expect to fail - it will reveal the most.
Key metrics per task:
| Metric | What it measures | How to collect | |---|---|---| | Task completion rate | Can users do it at all? | Binary success/failure per task | | Time on task | Efficiency | Timer from task start to success | | Error count | Where the design breaks down | Count