design-ux-researchUse this skill when planning UX research, user research, usability testing, user interviews, personas, user journeys, information architecture, or card sorting. This skill enforces: method selection (generative vs evaluative), structured interview protocols, usability test plans, persona templates, journey mapping, and synthesis frameworks. Do NOT use for: …
Independent GitHub snapshot · Automated classification · Original documentation governs
Design and execute UX research with method selection, structured protocols, and systematic synthesis. Covers generative and evaluative methods, user interview protocols, moderated and unmoderated usability testing, data-driven persona creation, journey mapping, and findings synthesis frameworks. The goal is to reduce design risk by validating assumptions with real user data.
Exact user phrases: "UX research", "user research", "usability testing", "user interview", "persona", "user journey", "information architecture", "card sorting", "research plan", "research method", "user study", "affinity mapping", "thematic analysis", "moderated test", "unmoderated test", "NPS", "SUS", "CSAT".
Before activating, verify:
UX research plan with method selection, interview or test protocol, and synthesis framework.
150 lines of plan and protocol.
Business Problem
↓
Research Goal (what we need to know)
↓
Research Question (specific, answerable question)
↓
Method Selection (generative vs evaluative)
↓
Study Design (participants, protocol, metrics)
↓
Data Collection (sessions, surveys, observations)
↓
Analysis & Synthesis (patterns, themes, insights)
↓
Reporting (findings, recommendations, next steps)
| Stage | Question Type | Primary Methods | Secondary Methods | Output |
|---|---|---|---|---|
| Discovery | What should we build? | Generative interviews, diary studies, field observation | Competitive analysis, contextual inquiry | Problem space definition, user needs |
| Alpha | Does this concept work? | Concept testing, prototype feedback, co-creation | Card sorting, tree testing | Concept validation, IA direction |
| Beta | Can users use this? | Moderated usability testing, A/B testing | Surveys, analytics review | Usability issues, metrics baseline |
| Live | Should we change this? | Unmoderated testing, surveys, analytics | Longitudinal studies, log analysis | Optimization opportunities, satisfaction data |
| Method | Type | Phase | Data | Participants | Cost |
|---|---|---|---|---|---|
| User interviews | Generative | Discovery | Qualitative | 5-8/segment | Medium |
| Diary study | Generative | Discovery | Qualitative | 8-12 | High |
| Field observation | Generative | Discovery | Qualitative | 5-10 | High |
| Card sorting | Generative | Alpha | Mixed | 20-50 | Low |
| Contextual inquiry | Generative | Discovery | Qualitative | 5-8 | High |
| Concept testing | Evaluative | Alpha | Qualitative | 5-8 | Medium |
| Moderated usability | Evaluative | Beta | Mixed | 5-8 | Medium |
| Unmoderated usability | Evaluative | Beta | Quantitative | 20-50 | Low |
| Tree testing | Evaluative | Alpha/Beta | Quantitative | 20-50 | Low |
| A/B testing | Evaluative | Live | Quantitative | High volume | Medium |
| Surveys | Evaluative | Any | Quantitative | 50-500 | Low |
| Analytics | Evaluative | Live | Quantitative | All users | Low |
| Customer feedback | Generative | Live | Qualitative | Variable | Low |
Strongest insights come from combining multiple methods:
Qualitative (why?)
+ Quantitative (how many?)
+ Behavioral (what do they actually do?)
= Triangulated Insight (confident, actionable understanding)
Example: Low NPS score (quantitative) → User interviews (qualitative) reveal top frustration → Session replays (behavioral) confirm frequency → Triangulated insight: specific feature redesign needed.
Format: "How do [users] currently [task] and what prevents them from [desired outcome]?" Hypothesis: "We believe [proposed solution] will [outcome] because [reason]."
Align question with product stage:
| Stage | Question Type | Method |
|---|---|---|
| Discovery | Open-ended exploration | Interviews, diary studies |
| Alpha | Concept validation | Concept testing, prototypes |
| Beta | Usability validation | Moderated/unmoderated testing |
| Live | Satisfaction/retention | Surveys, analytics |
Research question quality checklist:
| Method | Type | Participants | Best For |
|---|---|---|---|
| User interviews | Generative | 5-8 per segment | Deep understanding, problem discovery |
| Diary study | Generative | 8-12 | Longitudinal behavior tracking |
| Usability testing (moderated) | Evaluative | 5-8 | In-depth usability issues |
| Usability testing (unmoderated) | Evaluative | 20-50 | Scale, task completion metrics |
| Survey | Evaluative | 50-500 | Satisfaction, NPS, feature prioritization |
| Card sorting | Generative | 20-50 | Information architecture validation |
| Tree testing | Evaluative | 20-50 | Navigation findability |
Define screener criteria: demographics, behavior (frequency of use, tool familiarity), attitudinal (openness to change).
| Channel | Cost | Speed | Best For |
|---|---|---|---|
| Existing user base | Low | Fast | Current users |
| Panels (UserTesting, etc.) | Medium-High | Fast | General population |
| Social media | Low | Medium | Niche audiences |
| Intercept/on-site recruitment | Low | Slow | In-product users |
Incentives: $50-100/hr for professionals, gift cards for consumers.
Screener best practices:
| Section | Duration | Content |
|---|---|---|
| Introduction | 5 min | Consent, recording, "there are no wrong answers" |
| Warm-up | 5 min | Background, current tools, role |
| Main tasks | 20-30 min | Scenarios, observe don't guide, think-aloud |
| Debrief | 5 min | Reflection, "anything we missed?" |
Question types:
Avoid: leading questions, hypotheticals ("would you use..."), double-barreled questions.
Probing techniques:
Tasks should be scenario-based: "You need to find a specific order from last week. Please try to do that now." Measure: task completion (pass/fail), time-on-task, error rate, satisfaction rating. After each task: Single Ease Question (SEQ) — "Overall, how difficult was this task?" (1-7).
Moderator best practices:
| Method | Output | Tool |
|---|---|---|
| Affinity mapping | Themed clusters | Miro, Mural, FigJam, physical sticky notes |
| Persona creation | Data-driven archetype | Template with goals, frustrations, behaviors |
| Journey mapping | Visual timeline | Miro, Smaply, LucidChart |
Affinity mapping process:
Persona template: Name, role, photo, bio (2-3 sentences), goals (primary + secondary), frustrations (3-5), behaviors, quote.
Persona quality criteria:
Journey mapping stages:
Structure: executive summary → method overview → participant profile → 3-5 key findings (each with evidence, severity) → opportunities/recommendations → appendix.
Every finding links to source evidence (participant quote, task metric, screenshot).
Finding severity classification:
| Severity | Definition | Action Required |
|---|---|---|
| Critical | Users cannot complete core task | Fix immediately |
| Major | Users can complete but with significant friction | Fix before next release |
| Minor | Users complete but experience frustration | Address in near term |
| Suggestion | Improvement opportunity | Prioritize against other work |
| Pitfall | Description | Prevention |
|---|---|---|
| Leading questions | "How would you improve X?" assumes they should | "Tell me about your current process" |
| Hypotheticals | "Would you use this feature?" unreliable | Observe behavior with a prototype |
| Confirmation bias | Asking questions to prove a hypothesis | Listen for disconfirming evidence |
| Small sample for surveys | <50 responses not statistically significant | Don't report percentages from small samples |
| Personas based on assumptions | No research behind persona attributes | Every attribute must trace to research data |
| Ignoring edge cases | Only studying mainstream users | Recruit power users and non-users |
| No pilot test | Protocol bugs discovered during real sessions | Always pilot with 1-2 internal participants |
| Solutioneering | Participants become feature request machines | Redirect: "Tell me what you're trying to do" |
| Culture of agreement | Participants want to be helpful, give positive feedback | Normalize criticism: "We need your honest feedback to improve" |
| Analysis delay | Waiting too long to synthesize between sessions | Synthesize within 48 hours of each session |
| Practice | Why |
|---|---|
| 5 participants per segment | Catches ~85% of usability issues (Nielsen Norman) |
| Pilot test your protocol | Catches ambiguous questions, timing issues |
| Record sessions | Enables post-hoc analysis and quote extraction |
| Mix qualitative and quantitative | Qualitative explains why, quantitative confirms patterns |
| Include a debrief question | "Is there anything we should have asked?" catches blind spots |
| Take individual notes before group synthesis | Prevents groupthink in analysis |
| Share raw data alongside synthesized findings | Allows others to verify your conclusions |
| Timebox synthesis sessions | Prevents analysis paralysis: 2x research time |
| Present findings as opportunities, not just problems | Drives action, not blame |
| Research repository enables longitudinal insights | Prevents re-studying known issues |
Project: {project name}
Date: {date}
Researcher: {name}
Stakeholders: {names}
Research Question: {question}
Decision: {what we will decide based on findings}
Method: {method name}
Participants: {N} from {segment}
Session Length: {minutes}
Timeline: {start} to {end}
Protocol Sections:
1. {section} — {duration} — {purpose}
2. {section} — {duration} — {purpose}
Metrics (evaluative only):
- Task completion: target >{X}%
- SEQ: target >{X}
- SUS: target >{X}
Outputs:
- {artifact}
- {artifact}
Task {N}: {scenario description}
Scenario: "{realistic scenario text}"
Success Criteria: {what counts as task completion}
Measurement:
- [ ] Task completed (first attempt)
- [ ] Task completed (with help)
- [ ] Task failed
- Time on task: {measurement}
- Errors: {count and describe}
Post-task: SEQ score: {1-7 scale}
Post-task: Any comments: {open text}
Observer Notes:
{observations during task}
/research
/{year}-{project-name}
/raw-data
session-recordings/
transcripts/
survey-responses.csv
/analysis
affinity-map.{tool}
themes.md
personas.md
/reports
findings-report.{format}
presentation.{format}
/artifacts
consent-form.pdf
screener.pdf
protocol.pdf
| Activity | Tools |
|---|---|
| Session recording | Zoom, Lookback, UserTesting, Riverside |
| Transcripts | Dovetail, Otter.ai, Rev, Descript |
| Affinity mapping | Miro, Mural, FigJam, Excel |
| Survey | Typeform, SurveyMonkey, Google Forms |
| Card sorting | OptimalSort, UserZoom, Miro |
| Tree testing | Treejack, UserZoom |
| Prototype testing | Maze, UserTesting, Lookback |
| Research repository | Dovetail, Condens, Aurelius, Airtable |
A collaboration SaaS assumed users worked in linear project phases (plan, execute, review). A 2-week diary study with 10 project managers showed that work was actually highly iterative and non-linear with frequent context switching. The study uncovered that the product's linear workflow was the #1 cause of user frustration. Redesigning for non-linear workflows reduced task completion time by 35% and improved satisfaction by 40%.
Method: 14-day diary study with 10 project managers, daily prompts + weekly interviews Key insight: User workflow was non-linear and iterative, opposite of product design assumption Impact: Task completion time -35%, satisfaction +40%
An e-commerce platform needed to test a redesigned checkout flow. Using an unmoderated testing platform, they collected data from 45 participants in 3 days (vs 2-3 weeks for moderated). The study identified 7 critical issues and 12 minor issues. The critical issues included: unclear shipping cost display, confusing payment options, and a non-obvious "apply coupon" interaction. Fixing these issues recovered an estimated 8% in checkout conversion.
Method: Unmoderated usability testing (45 participants, 3 days) Key insight: Cost-effective scale unmoderated testing catches issues quickly Impact: 8% checkout conversion recovered by fixing critical issues
A B2B analytics platform had a single dashboard design for all users. UX research involving 18 interviews and a 200-person survey revealed 4 distinct user types with fundamentally different needs. The "Executive" persona needed high-level KPIs and trends; the "Analyst" persona needed raw data exploration and export. Creating persona-specific dashboards increased daily active usage by 45% and reduced support tickets by 30%.
Method: 18 interviews + 200-response survey → 4 validated personas Key insight: One-size-fits-all design was serving no segment well Impact: DAU +45%, support tickets -30%
design-prototyping for interactive prototypes based on research insights.
Carry forward: research findings, persona profiles, journey maps.
No preamble. No postamble. No explanations. No filler/hedging/transitions. Compress output — why use many token when few do trick.
` interface EventObserver { onEvent(event: T): Promise; }
class EventBus { private observers: Set<EventObserver> = new Set(); subscribe(observer: EventObserver): void { this.observers.add(observer); } unsubscribe(observer: EventObserver): void { this.observers.delete(observer); } async emit(event: T): Promise { const results = Array.from(this.observers).map(o => o.onEvent(event)); await Promise.allSettled(results); } } `
config: defaults: timeout: 30s retryCount: 3 overrides: production: timeout: 60s retryCount: 5 development: timeout: 300s retryCount: 1
| Metric | Threshold | Severity | Action |
|---|---|---|---|
| Error rate | > 1% over 5min | Critical | Page on-call |
| p99 latency | > 2s over 5min | Warning | Investigate |
| Throughput drop | > 50% over 1min | Critical | Check upstream |
| Queue depth | > 1000 over 1min | Warning | Scale consumers |
| Disk usage | > 85% | Warning | Clean or expand |
| Memory usage | > 90% heap | Critical | Restart or scale |
| Anti-Pattern | Symptom | Root Cause | Solution |
|---|---|---|---|
| Premature optimization | Complex code for no measured benefit | Guessing instead of profiling | Measure first, optimize based on data |
| Copy-paste reuse | Duplicate code across codebase | Lack of abstraction | Extract shared logic into libraries |
| Gold-plating | Features with no current requirement | Over-engineering | YAGNI — build what's needed now |
| Magical thinking | Assumptions without validation | Skipping error handling | Handle all failure modes explicitly |
Cache hierarchy: L1 (in-memory local) → L2 (distributed Redis/Memcached) → L3 (CDN/Edge). Cache invalidation: TTL-based (simple, stale), event-based (complex, fresh), write-through (consistent, higher write latency), write-behind (fast writes, eventual consistency).
What phase is the product in? ├── Discovery → Generative research (interviews, diary studies, field observation) ├── Definition → Descriptive research (surveys, competitive analysis, analytics) └── Evaluation → Evaluative research (usability testing, A/B testing, tree testing) What is the research question type? ├── Behavioral (what users do) → Analytics, usability testing, field studies └── Attitudinal (what users say) → Surveys, interviews, focus groups Required confidence level? ├── High (statistically significant) → Quantitative (surveys, A/B tests, analytics) └── Medium (directional) → Qualitative (interviews, usability tests, diary studies)
Who are the target users? ├── Existing customers → In-app recruitment, CRM outreach, email lists └── New/prospective users → Third-party panels (UserInterviews, Respondent), social media How many participants needed? ├── Qualitative (5-8 per segment) → Saturated insights, detailed feedback └── Quantitative (100+ per segment) → Statistical significance, segmentation analysis Budget for incentives? ├── Yes → Professional recruiting with screened participants └── No → Internal recruiting, friends-and-family, social media