---

name: design-research description: Conducts user experience research and analysis to inform design decisions. Use when user says "user research", "persona", "personas", "who are our users", "target audience", "customer segments", "design principles", "user needs", "pain points", "jobs to be done", "JTBD", "user interviews", "discussion guide", "research plan", "competitive analysis", "understand the users", "user data", "analytics review", "component research", "pattern audit", "accessibility requirements for [component]", or "how do others design [component type]". Reviews first-party and third-party user data, analyzes industry trends from UX and visual design perspectives, and plans user research studies. Also conducts component-level research: auditing existing patterns, accessibility requirements, interaction best practices, and content structure analysis to inform component design within an existing design system. Creates personas, customer segments, design principles, design roadmaps, research discussion guides, and component research audits. Do NOT use when already have approved personas, in implementation/coding phase, need visual mockups (use design-concepts), or designing components (use design-components).

Design - Research

This skill guides Claude through comprehensive UX research processes using Jobs-to-be-Done (JTBD) methodology to understand user needs, behaviors, and contexts that inform design decisions.

Core Methodology

Jobs-to-be-Done Framework

Every research activity focuses on understanding what "job" users are hiring a product to do. Research uncovers:

• Functional jobs: The practical tasks users need to accomplish
• Emotional jobs: How users want to feel or avoid feeling
• Social jobs: How users want to be perceived by others
• Context: The circumstances that trigger the job

Research Process

1. Scoping & Planning: Define research questions, identify what needs to be learned
2. Data Collection: Gather existing data (analytics, support tickets, reviews) and plan new research
3. Analysis: Identify patterns, pain points, and opportunities using JTBD lens
4. Synthesis: Create actionable artifacts (personas, principles, roadmaps)
5. Validation: Test assumptions and refine understanding

Tool Usage Patterns

Initial Information Gathering

Step 1: Inventory Available Resources Before starting research, Claude should:

1. Ask user what materials they have:
   - Existing user data (analytics, surveys, interviews)
   - Competitor research or industry reports
   - Current product/website/app to review
   - Business requirements or constraints

2. Use `view` to check uploaded files
3. Use `web_search` for industry trends and competitor analysis
4. Use `web_fetch` to analyze competitor websites and apps

Step 2: Create Research Plan Document what needs to be learned and how:

# Research Plan
## Research Questions
- What jobs are users trying to accomplish?
- What are current pain points and workarounds?
- What contexts trigger the need for this solution?

## Data Sources
- [ ] Analytics review (if provided)
- [ ] User interviews (plan discussion guide)
- [ ] Competitor analysis
- [ ] Industry trend research

## Timeline & Deliverables

Data Analysis Workflow

When reviewing user data:

1. Quantitative First: Look at analytics, usage data, conversion metrics

   • Use view to read CSV/Excel files
   • Create summary analysis in markdown
   • Identify behavioral patterns

2. Qualitative Second: Review interviews, support tickets, reviews

   • Extract direct user quotes (always cite source)
   • Identify recurring themes
   • Map to JTBD framework

3. Competitive Analysis: Research how others solve similar jobs

   • Use web_search for competitors: "best [category] apps 2025"
   • Use web_fetch to analyze specific competitor sites
   • Screenshot key interactions (if user provides URLs)
   • Document strengths/weaknesses relative to user jobs

Creating Discussion Guides

For planning user research studies:

# User Interview Discussion Guide

## Introduction (5 min)
- Thank participant
- Explain purpose and format
- Get consent to record

## Context Questions (10 min)
[Ask about their current situation and job-to-be-done]
- Walk me through the last time you [relevant activity]
- What triggered you to start looking for a solution?
- What alternatives have you tried?

## Deep Dive (30 min)
[Focus on specific jobs and contexts]
- What would make this task easier/faster/better?
- What's frustrating about current solutions?
- What would success look like?

## Closing (5 min)
- Anything else important we should know?
- Thank participant

Component Research

When research is feeding into design-components (designing within an existing design system), the research focus shifts from "who are the users" to "what does this component need to do well." This is a faster, more focused research mode.

When to Use Component Research

• Before designing a new component type that doesn't exist in the project yet
• When a component redesign needs evidence beyond "it doesn't look right"
• When accessibility or interaction requirements are unclear for a component type
• When the team disagrees about how a component should behave

Component Research Process

1. Internal Pattern Audit Read the project's existing codebase to understand established patterns:

- What similar components already exist? How are they structured?
- What design tokens are in use? (globals.css, tailwind.config, component library)
- What interaction patterns are established? (hover, focus, animation conventions)
- What states do existing components handle? (empty, loading, error, etc.)
- Are there documented conventions? (docs/design/, style guides, CLAUDE.md)

2. Accessibility Requirements Research WCAG requirements specific to the component type:

web_search: "[component type] WCAG accessibility requirements"
web_search: "[component type] aria roles and attributes"
web_search: "[component type] keyboard navigation pattern"

Document:

• Required ARIA roles and attributes
• Keyboard interaction expectations (Tab, Enter, Escape, Arrow keys)
• Screen reader announcements for state changes
• Color contrast requirements beyond the 4.5:1 baseline
• Motion/animation considerations (prefers-reduced-motion)

3. Interaction Pattern Best Practices Research how well-designed implementations handle this component:

web_search: "best [component type] UX patterns 2025"
web_search: "[component type] interaction design examples"
web_fetch: specific component libraries (Radix, Headless UI, Ark UI) for reference implementations

Focus on:

• What information users need first vs. on-demand
• Common interaction mistakes for this component type
• Mobile vs. desktop behavior differences
• Edge cases (overflow, long content, missing data, many items)

4. Content & Data Structure Understand what the component will actually contain:

• What data types and ranges? (short labels vs. long descriptions, 3 items vs. 300)
• What's required vs. optional?
• What content causes layout problems? (long names, missing images, zero states)
• How does the content change over time? (real-time updates, stale data)

Component Research Deliverable

File: {component-name}-component-audit.md

# [Component Name] — Research Audit

## Internal Patterns
- **Existing similar components**: [what already exists and how it works]
- **Design system tokens**: [key tokens relevant to this component]
- **Established conventions**: [patterns this component should follow]

## Accessibility Requirements
- **ARIA**: [required roles, attributes, live regions]
- **Keyboard**: [expected keyboard interactions]
- **Screen reader**: [announcement expectations for states]
- **Motion**: [animation considerations]

## Interaction Patterns
- **Best practices**: [what works well for this component type]
- **Common mistakes**: [what to avoid]
- **Mobile considerations**: [touch targets, gestures, viewport]

## Content Analysis
- **Data shape**: [what content this component handles]
- **Edge cases**: [overflow, empty, error, extreme values]
- **Dynamic behavior**: [how content changes over time]

## Recommendations
[Key insights that should inform the component design]

Quality Criteria

Excellent Personas Include:

• Name and photo (AI-generated or stock image)
• Demographics: Age, location, role (only if relevant to JTBD)
• Jobs to be done: 3-5 primary jobs they're trying to accomplish
• Pain points: Current struggles and workarounds (with real quotes)
• Goals & motivations: What success looks like for them
• Context: When/where they experience the need
• Tech comfort level: Relevant for product complexity decisions

Avoid: Generic personas that don't tie to specific jobs, fictional fluff that doesn't inform design decisions

Excellent Design Principles:

• Specific to the project: Not generic ("be simple"), but contextual ("Prioritize speed over options for first-time setup")
• Actionable: Designers can use them to make decisions
• Tied to research insights: Each principle comes from user data
• Memorable: Short, clear, possibly with a tagline
• 3-7 principles: Enough to guide, not so many they're ignored

Example Format:

## Design Principles

### 1. Progressive Disclosure Over Feature Parity
*Show what users need now, not everything we can do*
**Insight**: 73% of users abandoned setup because they felt overwhelmed by options they didn't understand yet.

### 2. Forgiveness Over Prevention
*Make it easy to undo, not hard to do wrong*
**Insight**: Users expressed anxiety about "breaking things" - they want to explore confidently.

Excellent Customer Segments:

• Behavioral-based: Grouped by how they use product, not just demographics
• JTBD-aligned: Each segment has distinct primary jobs
• Sized: Approximate % of user base (if data available)
• Named meaningfully: "Power Users" not "Segment A"
• Actionable: Each segment suggests different design approaches

Excellent Design Roadmaps:

• Insight-driven: Each initiative ties to research finding
• Prioritized: Uses framework (Impact/Effort, RICE, etc.)
• Timeline: Realistic phases (Discovery → Concept → Build)
• Success metrics: How we'll know if it worked
• Dependencies noted: What needs to happen first

Deliverable Formats

File Organization

IMPORTANT: Organize all deliverables by feature/assignment in dated folders.

Each research project should be saved in its own folder with the feature name: docs/design/{feature-name}-research-{MMDDYY}/

Feature Name Guidelines:

• Use kebab-case (lowercase with hyphens)
• Examples: checkout-flow, user-profile, dashboard-redesign, search-filters
• Ask the user for the feature name if not provided
• Suggest a name based on their description if needed

Examples:

• Checkout flow research on Oct 24, 2025: docs/design/checkout-flow-research-102425/
• Dashboard redesign research on Nov 1, 2025: docs/design/dashboard-redesign-research-110125/
• User profile iteration on Nov 15, 2025: docs/design/user-profile-research-111525/

Rationale:

• Immediate clarity: Know what feature each file relates to
• Version history: Same feature can have multiple dated iterations
• No conflicts: Different features can have same-named files
• Organized: Related research artifacts stay together

Folder structure:

docs/design/{feature-name}-research-{MMDDYY}/
├── {feature-name}-personas.md
├── {feature-name}-customer-segments.md
├── {feature-name}-design-principles.md
├── {feature-name}-design-roadmap.md
├── {feature-name}-research-discussion-guide.md
└── {feature-name}-component-audit.md          (for component research)

Personas

Location: docs/design/{feature-name}-research-{MMDDYY}/ File: {feature-name}-personas.md Format: Markdown with clear sections for each persona Include: Photo/avatar, quote, jobs-to-be-done, pain points, goals, context

Customer Segments

Location: docs/design/{feature-name}-research-{MMDDYY}/ File: {feature-name}-customer-segments.md Format: Markdown table + detailed descriptions Include: Segment name, size, primary jobs, characteristics, design implications

Design Principles

Location: docs/design/{feature-name}-research-{MMDDYY}/ File: {feature-name}-design-principles.md Format: Markdown with principle + insight + example Include: 3-7 principles, each with rationale from research

Design Roadmap

Location: docs/design/{feature-name}-research-{MMDDYY}/ File: {feature-name}-design-roadmap.md Format: Markdown with timeline visualization Include: Prioritized initiatives, rationale, timeline, success metrics

Research Discussion Guide

Location: docs/design/{feature-name}-research-{MMDDYY}/ File: {feature-name}-research-discussion-guide.md Format: Markdown with timing and question flow Include: Sections for intro, context, deep dive, closing

Examples

Good Research Question Progression

❌ Poor: "What do users want?" ✅ Better: "What job are users hiring our checkout for, and what's preventing them from completing it?"

❌ Poor: "Is the UI confusing?"
✅ Better: "At what point in the flow do users get stuck, and what are they trying to accomplish when it happens?"

Good Persona Example (Excerpt)

## Sarah Chen - The Efficiency Seeker

![Photo: Professional woman, 30s, laptop]

> "I need to get in, get my answer, and get back to my actual work. Every extra click costs me time I don't have."

**Role**: Marketing Manager at mid-size SaaS company
**Primary Jobs**:
1. Quickly generate reports for stakeholder meetings (weekly)
2. Compare campaign performance across channels (daily)
3. Identify trending content topics (monthly)

**Pain Points**:
- Current tool requires 8 clicks to get to the data she needs
- Switching between multiple dashboards wastes 15+ minutes per session
- Can't customize views, so she recreates the same reports manually

**Success Looks Like**: 
"Open app, see my key metrics immediately, export what I need in under 2 minutes."

Common Pitfalls to Avoid

❌ Research Without Clear Questions

Problem: Gathering data without knowing what decisions it should inform Instead: Start with "What do we need to decide?" then ask "What must we learn to decide?"

❌ Personas That Are Just Demographics

Problem: "Sarah, 34, lives in Seattle, likes yoga" tells designers nothing useful Instead: Focus on jobs, contexts, pain points, and goals that inform design decisions

❌ Analysis Paralysis

Problem: Spending weeks analyzing data without creating actionable insights Instead: Set a timebox, create initial insights, plan to validate and refine

❌ Ignoring Negative Data

Problem: Only highlighting findings that support existing assumptions Instead: Actively look for disconfirming evidence and edge cases

❌ Generic Design Principles

Problem: Principles like "Be simple" or "User-friendly" that could apply to anything Instead: Create specific principles tied to your research insights and project context

❌ Creating Artifacts That Don't Get Used

Problem: Beautiful personas that sit in a deck and never inform decisions Instead: Make artifacts scannable, actionable, and reference them in design reviews

❌ Skipping Context

Problem: Understanding what users do without understanding when/why Instead: Always ask about the circumstances that trigger the job-to-be-done

Integration Points

Inputs from Other Teams

• Product/PM: Product requirements, business goals, success metrics
• Data/Analytics: Usage data, conversion metrics, user behavior patterns
• Support/Sales: Customer pain points, common questions, feature requests

Outputs for Other Skills

• Design Concepts: Personas, design principles, key insights to inform new visual directions
• Design Components: Component audits, accessibility requirements, interaction patterns to inform component design within existing systems
• Product/PM: Prioritized opportunities, user segments, roadmap recommendations
• Engineering: Context on user needs that inform technical decisions

Tips for Best Results

1. Always start by asking what the user already has - don't recreate existing research
2. Use real user quotes liberally - they bring insights to life and build empathy
3. Create visual representations when possible - journey maps, flow diagrams
4. Tie everything back to jobs-to-be-done - this keeps research actionable
5. Be specific about confidence levels - note when insights need more validation
6. Make artifacts scannable - use headers, bullets, bold key insights
7. Include "So what?" - always answer why each insight matters for design

Validation Checklist

Before delivering research artifacts, verify:

• Each insight ties to specific user data or quotes
• Personas represent distinct jobs-to-be-done, not just demographics
• Design principles are specific enough to resolve design debates
• Roadmap priorities are justified by research findings
• All deliverables are in markdown format in the project's docs/design/ directory
• Artifacts are scannable and actionable for designers
• Sources are cited for all data and quotes
• Next steps or open questions are clearly identified