UX Research

Plan and execute user research that produces decisions, not just decks. Stack-agnostic. Tool-agnostic.

This skill is for generative and discovery research. For testing existing designs, use usability-testing. For mapping the full customer experience, use journey-mapping.

When to use

• Starting a new product or major feature without sufficient user understanding
• Diagnosing why something isn't working without clear data signals
• Generating new opportunity hypotheses
• Validating a strategic direction before significant investment
• Building empathy across a team that's drifted from users
• Translating "we should talk to users" intent into a real plan

When NOT to use

• Testing a specific design or prototype (use usability-testing)
• Mapping the full journey of an existing experience (use journey-mapping)
• Quantitative measurement (use analytics-strategy)
• Conversion testing (use cro-optimization)

Required inputs

• The research question(s) - what you need to answer
• Stakeholder buy-in (who needs the findings, what decisions hinge on them)
• Access to users (current customers, prospects, lapsed users, target segments)
• Timeline and budget
• Any prior research to build on

The framework: 6 phases

1. Frame the question

Bad questions produce bad research. Spend disproportionate time on framing.

Good research questions:

• Specific (not "How do users feel about our product?")
• Open-ended (not "Do users like feature X?")
• Decision-relevant (the answer changes what gets built)
• Researchable (can be answered through user contact, not just analysis)

Examples:

| Weak question | Better question | |---|---| | "Do users like our onboarding?" | "Where in onboarding do new users feel uncertain about whether to continue?" | | "What features should we build?" | "What unmet needs do current users have when specific job]?" | | "Why is conversion low?" | "What's the user mental model when they reach the pricing page, and where does it diverge from our intent?" |

2. Choose the method

The method follows the question.

Generative methods (what's true?):

• In-depth interviews. 60 minutes, 5 to 15 participants. Best for understanding context, motivation, mental models.
• Contextual inquiry. Observe users in their environment doing their work. Best for workflow understanding.
• Diary studies. Participants log their experience over days/weeks. Best for behaviors that don't manifest in a single session.
• Field research. Spend time where users live/work. Best for cultural and contextual understanding.
• Surveys (qualitative-heavy). When you need broad signal with open-ended responses.

Validation methods (is this hypothesis right?):

• Concept testing. Show a description, mockup, or prototype. Get reactions.
• Card sorts. Validate information architecture.
• Tree tests. Validate findability without visual design influence.

(For testing usability of working designs, see usability-testing.)

3. Recruit

The recruit makes or breaks the research.

Recruit criteria:

• Match the audience the research targets (not "anyone willing")
• Mix of behaviors (active users, lapsed users, never-users)
• Mix of demographics where relevant
• Excludes friends, family, employees (biased)
• Excludes professional research participants if possible (different population)

Recruit channels:

• In-product recruiting (intercept current users)
• Email outreach to user segments
• Recruiting platforms (UserInterviews, Respondent, etc.)
• Customer support team referrals
• Field intercept for in-person

Incentive: Pay participants. Standard rates: $50 to $150 for 60 minutes, more for executives or specialized professions.

Recruit volume: Plan for 20 to 30 percent no-show. Recruit 7 to schedule 5.

4. Conduct

The interview or session itself.

Pre-interview:

• Send confirmation 24 hours and 1 hour before
• Test recording setup (audio quality is non-negotiable)
• Prepare interview guide (see template)
• Have a notetaker if possible (frees the interviewer to focus)

During the interview:

• Record video and audio (with consent)
• Open with rapport-building, not the research questions
• Use open-ended questions ("Tell me about the last time...")
• Use silence (let participants fill it; don't rush to the next question)
• Ask "why" but not too many times in a row (becomes interrogation)
• Ask for specifics and examples ("Can you walk me through what you did?")
• Probe contradictions gently ("Earlier you said X, now you're saying Y; help me understand")
• Watch for moments of emotion (often signal something important)
• Don't sell or convince - this is listening, not pitching

Anti-patterns:

• Leading questions ("Don't you find this confusing?")
• Hypothetical questions ("Would you use a feature that...?") - poor predictor of behavior
• Multiple questions at once
• Interrupting
• Filling silence
• Interviewing your hypothesis (only asking questions that confirm what you already think)

5. Synthesize

Notes don't become insights automatically.

The synthesis process:

1. Capture observations. From recordings, notes, transcripts. Each observation is a single data point: a quote, a behavior, an emotion, a moment.
2. Affinity mapping. Cluster observations into themes. Physical sticky notes or digital equivalents.
3. Find patterns. Themes that appear across multiple participants are signal. One-off observations are interesting but weaker.
4. Identify insights. An insight is more than a theme. It's a non-obvious finding that explains a why or implies a so what.
5. Test the insight against the data. If the insight only fits some interviews, it's a hypothesis, not an insight.
6. Distinguish signal from noise. A belief that 1 of 8 participants holds may be noise. A belief 6 of 8 hold is signal.

Heuristics for strong insights:

• They surprise the team (insights you already knew aren't insights)
• They explain a "why" the team has been guessing about
• They imply specific actions (so what?)
• They hold up across multiple data points
• They can be stated in one or two sentences

6. Communicate

Findings die in slide decks. Plan distribution.

Outputs that work:

• Top-line insights document. 5 to 10 insights, clearly stated, with supporting quotes.
• Highlight reels. Edited 5 to 10 minute video of key participant moments. More persuasive than any document.
• In-room workshops. Walk stakeholders through the synthesis themselves. They internalize when they participate.
• Per-stakeholder briefs. Different audiences need different framings. CEO wants strategic implications. Designers want pain points. Engineers want use cases.

Outputs that fail:

• 80-slide decks that get skimmed
• Reports that no one reads past the executive summary
• Verbose narrative summaries
• Insights that sit in a doc no one re-opens

Workflow

1. Frame the research question. With stakeholders. Multiple iterations.
2. Pick the method. Match to the question.
3. Plan logistics. Timeline, budget, recruit, tools, team.
4. Recruit. Start early. Slow recruits delay everything.
5. Pilot. Run 1 to 2 sessions before the main batch. Refine the guide.
6. Conduct. Stay disciplined to the guide while staying open to surprises.
7. Synthesize. Don't wait until all sessions are done; start mid-way.
8. Communicate. Multiple formats. Multiple audiences.
9. Track impact. Did decisions change because of the research? If not, the research failed regardless of quality.

Failure patterns

• Research without a decision. Findings have no home. Effort wasted.
• Vague research questions. Bad questions produce uninterpretable answers.
• Recruiting "anyone willing." Sample doesn't match audience.
• Over-recruiting professional participants. Pattern-matched answers, not real users.
• Leading questions in the guide. Findings reflect the researcher, not the user.
• Skipping synthesis. Notes alone aren't insights.
• Insights that confirm the team's existing beliefs. Suspect those especially.
• Findings that never ship. Research findings that don't change product decisions are decoration.
• Single research project for years of decisions. Research has a shelf life. Refresh.
• Research as one-time project. Continuous discovery beats episodic research.

Output format

Default outputs:

1. Research plan (before research starts) - research-plan-[topic].md
2. Interview guide - interview-guide-[topic].md
3. Findings doc (after synthesis) - research-findings-[topic].md
4. Highlight reel (video, separately produced)

Findings document structure:

markdown
# [Topic] research findings

## Question we set out to answer
[Specific question]

## Method
[Approach, sample size, dates]

## Top insights
1. [Insight, stated in one sentence]
   - Supporting evidence: [Quotes, behaviors, or state the gap per the data-availability rule]
   - Implication: [What this means for product/strategy]
2. [Insight 2]
   ...

## Themes (less prominent than top insights, still worth noting)
[List]

## Outliers worth investigating
[Single-participant observations that may be signal in disguise]

## Recommended next steps
[Specific actions]

If required data is unavailable

This skill's output depends on data, measurements, or tool results it cannot generate on its own. When a required input, tool, or data source is unavailable or unverifiable, the sanctioned output is the deliverable with the gap stated: what was needed, what was actually obtained or verified, and which parts of the output are affected. Fabricating, estimating, or interpolating a required number to complete the deliverable is never sanctioned. A stated gap is a complete answer.

Reference files

• references/interview-guide-template.md - Structured interview guide template with example openings, probes, and closes.