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