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:

# 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/

---

Content truncated.