# Design Research > 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… - **Type:** Skill - **Install:** `agentstack add skill-mevans2120-design-suite-claude-skills-design-research` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [mevans2120](https://agentstack.voostack.com/s/mevans2120) - **Installs:** 0 - **Category:** [Data & Analytics](https://agentstack.voostack.com/c/data-and-analytics) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [mevans2120](https://github.com/mevans2120) - **Source:** https://github.com/mevans2120/design-suite-claude-skills/tree/main/design-research ## Install ```sh agentstack add skill-mevans2120-design-suite-claude-skills-design-research ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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 in … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [mevans2120](https://github.com/mevans2120) - **Source:** [mevans2120/design-suite-claude-skills](https://github.com/mevans2120/design-suite-claude-skills) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-mevans2120-design-suite-claude-skills-design-research - Seller: https://agentstack.voostack.com/s/mevans2120 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.