# Design Research

> Design - Research

- Skill: `mevans2120/design-research` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mevans2120/design-research`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mevans2120/design-research/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: mevans2120 (https://skillmd.com/u/mevans2120)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mevans2120/design-research

---


# 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:
```markdown
# 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:
```markdown
# 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`

```markdown
# [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**:
```markdown
## 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)
```markdown
## 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