Claude Code Plugins

Community-maintained marketplace

Feedback

user-research-and-validation

@tachyon-beep/skillpacks
1
0

Test designs and validate decisions with systematic user research methods

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name user-research-and-validation
description Test designs and validate decisions with systematic user research methods

User Research and Validation

Overview

This skill teaches systematic user research methodology across all project phases, from initial discovery through post-launch optimization. Use when you need to understand users, test designs, or validate design decisions with evidence.

Core Principle: Design decisions based on user evidence are more successful than decisions based on assumptions, intuition, or stakeholder opinions alone.

When to Use

Load this skill when:

  • Starting a new project (need to understand users first)
  • User asks: "How do I test this design?", "Will users understand this?"
  • Validating design decisions before development
  • Post-launch evaluation and optimization
  • User mentions: "research", "testing", "validation", "users", "interviews", "usability"

Don't use for: Pure design specification (use visual/interaction/IA skills), technical implementation


The User Understanding Model

A systematic 5-phase approach matching project lifecycle:

Phase 1: DISCOVERY - Understand users, context, problems Phase 2: GENERATIVE - Explore possibilities, ideate solutions Phase 3: EVALUATIVE - Test designs, identify usability issues Phase 4: VALIDATION - Confirm design meets user needs Phase 5: POST-LAUNCH - Measure impact, identify improvements

Each phase has specific methods, research questions, and deliverables.


Phase 1: Discovery Research

Purpose

Understand users deeply before designing solutions. Answer: Who are the users? What problems do they face? What's their current workflow?

When to use: Project kickoff, redesign, entering new market, foundational understanding

Research Methods

Method 1: User Interviews (Contextual Inquiry)

Setup:

  • 5-8 participants (representative sample)
  • 30-60 minutes per interview
  • User's environment (office, home, wherever they'd use product)
  • Record with permission (audio/video)

Script structure:

  1. Introduction (5 min) - Build rapport, explain purpose
  2. Background (10 min) - Demographics, tech comfort, role
  3. Current workflow (20 min) - "Walk me through how you currently..."
  4. Pain points (15 min) - "What's frustrating about this?"
  5. Goals and motivations (10 min) - "What would success look like?"

Key questions:

  • "Tell me about the last time you [did task]..."
  • "What's the hardest part of [workflow]?"
  • "If you could wave a magic wand, what would you change?"
  • "What workarounds have you developed?"

Good practices:

  • Ask open-ended questions ("Tell me about..." not "Do you like...?")
  • Follow up with "Why?" to understand motivations
  • Observe actual behavior (not just self-reported)
  • Stay neutral (don't lead toward your preferred solution)

Anti-patterns:

  • Leading questions ("Don't you think X would be better?")
  • Only talking to power users (miss mainstream needs)
  • Interviewing in artificial settings (miss real context)
  • Pitching your solution (you're here to learn, not sell)

Method 2: Field Observations (Ethnographic)

Setup:

  • Observe users in natural environment
  • 2-4 hours per observation
  • Take notes on context, workarounds, interruptions
  • Minimal intervention (be a fly on wall)

What to observe:

  • Physical environment (lighting, noise, space constraints)
  • Tools they use (software, hardware, paper notes)
  • Workarounds (sticky notes, spreadsheets, manual steps)
  • Interruptions (calls, colleagues, notifications)
  • Emotional reactions (frustration, confusion, satisfaction)

Documentation:

  • Photos of workspace (with permission)
  • Video of workflows (if allowed)
  • Detailed field notes
  • Artifacts (forms they fill, outputs they create)

Benefits:

  • See actual behavior (not self-reported)
  • Discover unarticulated needs
  • Understand real context (messy reality, not ideal)

Method 3: Diary Studies

Setup:

  • Users log experiences over time (1-4 weeks)
  • Mobile app, Google Form, or notebook
  • Daily or event-triggered entries
  • Minimal burden (3-5 minutes per entry)

Entry prompts:

  • "What task did you complete?"
  • "Rate difficulty (1-5)"
  • "What went well? What was frustrating?"
  • "Photo of situation (optional)"

When to use:

  • Longitudinal behavior (patterns over time)
  • Infrequent tasks (happens weekly, not daily)
  • Context variety (different locations, times)

Method 4: Analytics Review (Quantitative Baseline)

Data to gather:

  • Usage patterns (feature adoption, frequency)
  • Drop-off points (where users abandon)
  • Error rates (where things break)
  • Time on task (efficiency baseline)
  • Device/browser distribution

Tools:

  • Google Analytics, Mixpanel (web)
  • Firebase Analytics (mobile)
  • Hotjar, FullStory (session recordings)
  • Server logs (API usage, errors)

Look for:

  • High-traffic flows (optimize these first)
  • Abandonment funnels (usability issues)
  • Feature deserts (built but not used)
  • Error spikes (technical or UX problems)

Research Questions to Answer

User Characteristics:

  • Who are they? (demographics, role, tech comfort)
  • What's their experience level? (novice → expert)
  • What devices do they use? (mobile, desktop, tablet)
  • What's their context? (office, home, on-the-go, distractions)

Goals and Motivations:

  • What are they trying to accomplish?
  • Why is this important to them?
  • What's their success criteria?
  • What would make them switch to competitor?

Current Workflow:

  • How do they accomplish task today?
  • What tools do they use?
  • What steps are involved?
  • How long does it take?

Pain Points:

  • What's frustrating about current approach?
  • Where do they get stuck?
  • What errors do they encounter?
  • What workarounds have they developed?

Mental Models:

  • How do they think about the problem space?
  • What terminology do they use?
  • What categories make sense to them?
  • What analogies do they use?

Deliverables

User Personas

Structure:

  • Name and photo (humanize)
  • Demographics (age, role, tech comfort)
  • Goals (what they want to accomplish)
  • Pain points (current frustrations)
  • Behaviors (how they work today)
  • Quote (memorable user voice)

Example:

Sarah - The Efficiency-Focused Manager

Age: 35 | Role: Marketing Manager | Tech Comfort: Medium

Goals:
- Monitor campaign performance at a glance
- Quickly generate reports for executives
- Collaborate with team on content calendar

Pain Points:
- Data scattered across 5 different tools
- Takes 2 hours to build executive report
- Can't see real-time campaign status

Behaviors:
- Checks dashboard 3-4 times per day
- Works primarily on laptop, occasionally mobile
- Prefers visual summaries over detailed tables

Quote: "I just want to see what's working and what's not, without digging through spreadsheets."

Good practices:

  • Base on real research (not assumptions)
  • 3-5 personas (not 10+, too many to use)
  • Focus on behaviors and goals (not just demographics)
  • Include primary persona (design for this one first)

Anti-patterns:

  • Marketing personas (not UX personas - different goals)
  • Stereotypes without research basis
  • Too many personas (design becomes unfocused)
  • Perfect users (no pain points or constraints)

Journey Maps

Structure:

  • Phases (stages of user journey)
  • Actions (what user does at each stage)
  • Thoughts (what they're thinking)
  • Emotions (how they feel - graph line)
  • Pain points (frustrations encountered)
  • Opportunities (where design can help)

Example: E-commerce Purchase Journey

Phase 1: DISCOVERY
Actions: Search, browse categories, filter results
Thoughts: "Do they have what I need?"
Emotions: Curious → Frustrated (can't find it)
Pain points: Unclear categories, too many results
Opportunities: Better search, faceted filtering

Phase 2: EVALUATION
Actions: Compare products, read reviews, check specs
Thoughts: "Is this the right choice? Can I trust this?"
Emotions: Analytical → Uncertain
Pain points: Missing spec comparisons, conflicting reviews
Opportunities: Comparison tool, verified reviews

Phase 3: PURCHASE
Actions: Add to cart, enter shipping, payment
Thoughts: "Is this secure? What if I need to return it?"
Emotions: Cautious → Anxious
Pain points: Unexpected shipping costs, unclear return policy
Opportunities: Transparent pricing, clear return policy upfront

Good practices:

  • Based on real user journeys (not ideal path)
  • Include emotional arc (highs and lows)
  • Highlight pain points (design opportunities)
  • Show cross-channel journeys (mobile → desktop)

Research Insights Report

Structure:

  1. Executive Summary (1 page)
  2. Methodology (who, how, when)
  3. Key Findings (5-10 insights with evidence)
  4. User Personas (detailed profiles)
  5. Journey Maps (visual workflows)
  6. Opportunity Areas (prioritized design implications)
  7. Appendix (raw data, interview transcripts)

Key Findings Format:

Finding 3: Users abandon checkout due to unexpected costs

Evidence:
- 67% of users mentioned shipping costs as frustration (8/12 interviews)
- Analytics show 43% cart abandonment at shipping step
- "I hate when they hide the total cost until the end" - multiple quotes

Implications:
- Show estimated total early in flow
- Be transparent about shipping costs upfront
- Consider free shipping threshold

Priority: HIGH (affects 43% of users at critical conversion point)

Phase 2: Generative Research

Purpose

Explore possibilities and generate solutions collaboratively with users. Answer: How do users think about organizing this? What solutions resonate with them?

When to use: After discovery, during ideation, before committing to specific design direction

Research Methods

Method 1: Card Sorting

Purpose: Understand how users mentally organize information

Types:

Open Card Sorting (exploratory):

  • Users create their own categories
  • Reveals mental models
  • Use for new IA, unclear structure

Closed Card Sorting (validation):

  • Users place cards in predefined categories
  • Tests proposed structure
  • Use to validate IA decisions

Setup:

  • 15-30 participants (for statistical validity)
  • 40-60 cards (content items, features)
  • Online tools: OptimalSort, UserZoom
  • Physical cards: 3x5 index cards

Process:

  1. Participant gets stack of cards (each = content item)
  2. "Group these in a way that makes sense to you"
  3. "Name each group you created"
  4. (Optional) "Describe your thinking"

Analysis:

  • Cluster analysis (which cards grouped together frequently)
  • Category names (user terminology)
  • Patterns across participants (consensus vs diversity)

Deliverables:

  • Dendrogram (tree showing card relationships)
  • Category labels (from user language)
  • IA recommendations (structure that matches mental models)

Good practices:

  • Use actual content (not generic labels)
  • Test with representative users (not internal team)
  • Mix easy and ambiguous items (find the edge cases)

Anti-patterns:

  • Too many cards (>60 = cognitive overload)
  • Cards that overlap (confuses participants)
  • Only testing with 3 users (not statistically valid)

Method 2: Co-Design Workshops

Purpose: Generate solutions collaboratively with users

Setup:

  • 6-10 participants (representative users)
  • 2-3 hours
  • Materials: paper, markers, sticky notes, templates
  • Facilitators: 1 lead, 1 note-taker

Activities:

Brainstorming:

  • "How might we [improve X]?"
  • Quantity over quality (defer judgment)
  • Build on others' ideas
  • 10-15 minutes of rapid ideation

Sketching:

  • Low-fidelity sketches (no art skills needed)
  • 8-12 frames (crazy eights method)
  • Focus on flows, not pixel perfection
  • 5 minutes per sketch round

Dot Voting:

  • Participants vote on favorite ideas
  • 3 dots per person
  • Can cluster votes or spread them
  • Reveals group priorities

Storyboarding:

  • Map ideal user journey
  • Before/during/after scenarios
  • Show context and emotions
  • Identify key moments

Benefits:

  • Users feel heard (buy-in)
  • Uncover unarticulated needs
  • Generate diverse ideas
  • Validate assumptions early

Method 3: Concept Testing

Purpose: Test early ideas before investing in high-fidelity design

Format:

  • Sketches, wireframes, or paper prototypes
  • 5-8 participants
  • 15-30 minutes per session
  • Show concept, gather reactions

Questions:

  • "What do you think this does?"
  • "How would you use this?"
  • "What's unclear or confusing?"
  • "How does this compare to current approach?"
  • "Would you use this? Why or why not?"

Variations:

A/B Concept Testing:

  • Show two different approaches
  • Ask which they prefer and why
  • Not a vote (understand reasoning)

Desirability Study:

  • Show concept
  • "Pick 5 words that describe this" (from 60-word list)
  • Reveals emotional response and brand perception

Benefits:

  • Fail fast (before development)
  • Understand reactions (not just usability)
  • Compare directions (which resonates)

Method 4: Affinity Mapping (Synthesis)

Purpose: Synthesize research findings into insights

Process:

  1. Write each observation on sticky note (from interviews, studies)
  2. Put all notes on wall
  3. Group similar observations together
  4. Name each group (theme)
  5. Identify patterns across themes

Example themes:

  • "Users struggle with navigation" (12 notes)
  • "Price transparency is critical" (8 notes)
  • "Mobile experience is frustrating" (15 notes)

Deliverables:

  • Thematic clusters (key insights)
  • Priority order (by frequency or impact)
  • Design implications (what to do about it)

Good practices:

  • Involve cross-functional team (diverse perspectives)
  • Use actual user quotes (not interpretations)
  • Look for patterns (not one-off comments)
  • Connect to business goals (not just user wants)

Deliverables

Information Architecture Proposals:

  • Sitemap (navigation structure)
  • Category labels (user terminology)
  • Justification (based on card sorting, mental models)

Low-Fidelity Concepts:

  • Paper sketches (workflow options)
  • Wireframes (structure, no visual design)
  • Flow diagrams (user paths)

Feature Prioritization:

  • MoSCoW method (Must/Should/Could/Won't)
  • Impact vs effort matrix (quick wins vs long-term)
  • User priority (from co-design voting)

Phase 3: Evaluative Research

Purpose

Test designs to identify usability issues before development. Answer: Can users complete tasks? Where do they struggle?

When to use: Mid-design, after wireframes/prototypes created, before high-fidelity investment

Research Methods

Method 1: Usability Testing (Moderated)

Purpose: Watch users attempt tasks, identify friction points

Setup:

  • 5-8 participants (Nielsen: 5 users find 85% of issues)
  • 45-60 minutes per session
  • Prototype (clickable wireframes or mockups)
  • Think-aloud protocol (narrate thoughts)

Test structure:

  1. Introduction (5 min)

    • Explain purpose: "Testing design, not you"
    • Ask to think aloud
    • Remind: no wrong answers
  2. Warm-up task (5 min)

    • Easy task to practice thinking aloud
    • Builds comfort
  3. Core tasks (30 min)

    • 5-7 realistic tasks
    • Specific, scenario-based
    • "You need to [goal]. Show me how you'd do that."
  4. Post-task questions (10 min)

    • "What was confusing?"
    • "What would you change?"
    • "How does this compare to current approach?"
  5. Wrap-up (5 min)

    • Overall impressions
    • Thank participant

Good task examples:

  • "You need to change your shipping address. Show me how." (specific goal)
  • "Find the return policy for this product." (findability)
  • "Compare the features of these two plans." (information clarity)

Bad task examples:

  • "Click the settings button" (too specific, not realistic)
  • "What do you think of this page?" (not a task)
  • "Do you like the blue button?" (leading, not behavioral)

What to observe:

  • Task success (completed, partial, failed)
  • Time on task (efficiency)
  • Errors (wrong clicks, backtracking)
  • Confusion (hesitation, pauses, "hmm...")
  • Workarounds (unexpected paths to goal)
  • Emotional reactions (frustration, delight)

Note-taking:

  • Use observer template (task, time, success, notes, severity)
  • Record session (with permission)
  • Tag issues (navigation, labeling, feedback, visual hierarchy)

Good practices:

  • Don't help (unless completely stuck)
  • Probe for understanding ("What are you thinking?")
  • Stay neutral (no leading)
  • Test realistic tasks (not feature tours)

Anti-patterns:

  • Leading users ("Try clicking the blue button")
  • Defending design ("But that's obvious, isn't it?")
  • Testing with 1-2 users only (not enough)
  • Testing final-stage designs (too late to fix major issues)

Method 2: Unmoderated Remote Testing

Purpose: Scale testing across more users, faster

Tools:

  • UserTesting.com
  • Maze
  • Lookback
  • UsabilityHub

Setup:

  • 10-20 participants (broader sample)
  • 15-20 minutes per test
  • Pre-recorded task instructions
  • Automated metrics

Advantages:

  • Faster turnaround (hours, not weeks)
  • Larger sample size (statistical confidence)
  • No scheduling logistics
  • Users in natural environment

Disadvantages:

  • Can't probe ("Why did you do that?")
  • Technical issues harder to diagnose
  • Less nuanced observations

When to use:

  • Quick validation (A vs B)
  • Large sample needed
  • Limited budget/time
  • Simple task flows

Method 3: Tree Testing

Purpose: Validate information architecture (findability)

Setup:

  • Text-only hierarchy (no visual design)
  • 15-30 participants
  • 5-8 findability tasks
  • Online tool: Treejack (Optimal Workshop)

Process:

  1. Show text sitemap (categories and subcategories)
  2. Task: "Where would you look to find [X]?"
  3. Participant clicks through hierarchy
  4. Success or failure recorded

Metrics:

  • Task success rate (found correct location)
  • Directness (straight path vs backtracking)
  • Time to complete
  • First click (did they start in right direction?)

Analysis:

  • Which categories are clear vs confusing?
  • Where do users go wrong? (misleading labels)
  • Which content is hard to find? (IA gaps)

Benefits:

  • Tests IA without visual design (pure structure)
  • Identifies labeling issues
  • Fast to run and analyze

Method 4: First-Click Testing

Purpose: Validate if users can start tasks correctly

Setup:

  • Screenshot or prototype
  • "To accomplish [task], what would you click first?"
  • One click per task
  • 15-30 participants

Analysis:

  • Heat map (where users clicked)
  • Success rate (clicked correct element)
  • Misclicks (where they went wrong)

Insight:

  • First click predicts task success (if first click right, 87% complete task successfully)
  • Identifies unclear navigation
  • Tests visual hierarchy (do important elements get clicked?)

Research Questions to Answer

Usability:

  • Can users complete core tasks?
  • How long does it take? (efficiency)
  • What errors do they make?
  • Where do they get stuck?

Findability:

  • Can users locate features/content?
  • Do labels make sense?
  • Is navigation intuitive?
  • Do search results match expectations?

Comprehension:

  • Do users understand what elements do?
  • Is feedback clear?
  • Are error messages helpful?
  • Is terminology familiar?

Satisfaction:

  • Is the experience pleasant?
  • What delights users?
  • What frustrates them?
  • Would they recommend it?

Deliverables

Usability Findings Report

Structure:

  1. Executive Summary

    • Overall success rates
    • Top 5 critical issues
    • Recommendations priority
  2. Methodology

    • Participants (who, how recruited)
    • Tasks tested
    • Test environment
  3. Findings by Task

    • Task description
    • Success rate (5/8 completed)
    • Time on task (average)
    • Key issues observed
    • Severity rating
  4. Issue Details

    • Issue description (what went wrong)
    • Severity (critical/high/medium/low)
    • Evidence (quotes, clips, frequency)
    • Recommendation (how to fix)
    • Affected users (5/8 participants)
  5. Prioritized Recommendations

    • Quick wins (high impact, low effort)
    • Critical fixes (before launch)
    • Future improvements (next iteration)

Issue Severity Scale:

  • Critical: Blocks task completion, affects all users
  • High: Major friction, affects most users
  • Medium: Slows users down, workarounds exist
  • Low: Minor annoyance, rare occurrence

Example Finding:

Issue #3: Users can't find the "Save" button (HIGH SEVERITY)

Observed: 6/8 participants looked around screen for 10+ seconds before finding save button in bottom-right corner. Two gave up and asked for help.

Quotes:
- "Where's the save button? I keep looking for it..."
- "Oh, it's way down there. I didn't see it."

Recommendation: Move save button to top-right (expected location) OR make it a prominent floating action button. Consider adding keyboard shortcut (Cmd+S) for power users.

Priority: Fix before launch (blocks core workflow)

Task Success Rates

Metrics table:

Task Success Partial Failed Avg Time Notes
Change shipping address 7/8 (88%) 1/8 0/8 45s Easy
Find return policy 4/8 (50%) 2/8 2/8 2m 15s Label unclear
Compare pricing plans 2/8 (25%) 3/8 3/8 3m 30s Table confusing

Benchmark targets:

  • Core tasks: >80% success rate
  • Secondary tasks: >60% success rate
  • Average task time: <2 minutes for common tasks

Issue Severity Ratings:

  • Critical: 5 issues (must fix)
  • High: 8 issues (should fix)
  • Medium: 12 issues (consider)
  • Low: 6 issues (backlog)

Phase 4: Validation Research

Purpose

Confirm design meets user needs and follows best practices before launch. Answer: Is design ready to ship?

When to use: Pre-launch, final design validation, quality assurance

Research Methods

Method 1: Heuristic Evaluation (Expert Review)

Purpose: Expert applies usability principles to find violations

Framework: Nielsen's 10 Usability Heuristics

  1. Visibility of system status - Users know what's happening
  2. Match system and real world - Familiar language and concepts
  3. User control and freedom - Undo/redo, escape hatches
  4. Consistency and standards - Patterns match conventions
  5. Error prevention - Design prevents mistakes
  6. Recognition over recall - Minimize memory load
  7. Flexibility and efficiency - Shortcuts for power users
  8. Aesthetic and minimalist - No unnecessary information
  9. Error recovery - Help users fix mistakes
  10. Help and documentation - When needed, accessible

Process:

  1. Expert walks through interface
  2. Evaluates against each heuristic
  3. Documents violations (with severity)
  4. Provides recommendations

Severity scale:

  • 0 = Not a problem
  • 1 = Cosmetic (fix if time)
  • 2 = Minor usability issue
  • 3 = Major usability issue (priority)
  • 4 = Usability catastrophe (must fix)

Benefits:

  • Fast (1-2 days)
  • Cheap (expert time only, no users)
  • Finds 30-40% of issues
  • Good for catching obvious violations

Limitations:

  • Expert opinions (not user behavior)
  • Misses novel issues (not covered by heuristics)
  • Should complement user testing (not replace)

Method 2: Cognitive Walkthrough

Purpose: Step through tasks to find learning barriers

Process:

  1. Define user persona and goals
  2. List task steps
  3. For each step, ask:
    • "Will user know what to do?"
    • "Will user see how to do it?"
    • "Will user understand the feedback?"
    • "Will user know they're making progress?"

Example walkthrough: Change password

Step 1: User needs to find settings
→ Will user know settings exist? (Yes, common pattern)
→ Will user see settings menu? (Yes, in top-right nav)
→ Issue: None

Step 2: User needs to find "Change Password"
→ Will user know it's in Account section? (Maybe - test)
→ Will user see it in the list? (Yes, clear label)
→ Will user understand it's clickable? (Yes, styled as link)
→ Issue: None

Step 3: User needs to enter current password
→ Will user understand why? (Yes, security explained)
→ Will user remember current password? (Maybe - offer "Forgot?" link)
→ Issue: Add "Forgot password?" link

Deliverable: Step-by-step analysis with identified learning barriers

Method 3: Accessibility Audit (WCAG Compliance)

Purpose: Ensure design is accessible to people with disabilities

Standards: WCAG 2.1 Level AA (minimum legal requirement)

Automated checks (tools: Axe, Lighthouse, WAVE):

  • Color contrast (4.5:1 for text, 3:1 for UI elements)
  • Alt text on images
  • Form labels
  • Heading hierarchy
  • Link text (not "click here")

Manual checks:

  • Keyboard navigation (Tab, Enter, Esc, arrows)
  • Focus indicators visible (2px outline)
  • Skip links (bypass navigation)
  • Screen reader compatibility (NVDA, JAWS, VoiceOver)
  • Semantic HTML (button, nav, main, article)
  • ARIA labels where needed

Test scenarios:

  • Navigate entire flow with keyboard only (no mouse)
  • Turn on screen reader, close eyes, complete task
  • Zoom to 200%, verify no content loss
  • Toggle high contrast mode, verify readable
  • Test with colorblind simulator (Stark plugin)

Deliverable: Accessibility audit report

  • Issues found (with WCAG reference)
  • Severity (A, AA, AAA)
  • Recommendations (how to fix)
  • Priority (critical before launch vs future improvement)

Integration: Reference accessibility-and-inclusive-design skill for detailed evaluation framework

Method 4: Beta Testing

Purpose: Validate in real-world conditions with real users

Setup:

  • Invite 50-200 users (representative sample)
  • 1-4 weeks of use
  • Production or staging environment
  • Feedback channels (in-app, survey, support)

Data to collect:

  • Usage metrics (adoption, frequency)
  • Error rates (crashes, bugs)
  • Support tickets (what confuses users)
  • Satisfaction survey (NPS, satisfaction ratings)
  • Feature requests (what's missing)

Benefits:

  • Real workflows (not test scenarios)
  • Real data (not lab environment)
  • Uncovers edge cases (not anticipated)
  • Validates at scale

Risks:

  • Can't fix major issues this late (should be polished already)
  • Users frustrated if too buggy (damages trust)
  • Sensitive to first impressions

When to skip:

  • High-stakes launches (financial, medical)
  • Critical bug risk (test more before beta)
  • No time to act on feedback (too close to launch)

Deliverables

Heuristic Evaluation Report:

  • Violations by heuristic (grouped)
  • Severity ratings (prioritized)
  • Screenshots (annotated)
  • Recommendations (actionable)

Accessibility Audit:

  • WCAG compliance status (pass/fail per criterion)
  • Issues by severity (critical → low)
  • Remediation steps (how to fix)
  • Re-test checklist (verify fixes)

Beta Feedback Synthesis:

  • Quantitative metrics (usage, errors, satisfaction)
  • Qualitative themes (from support tickets, feedback)
  • Priority issues (blockers vs nice-to-haves)
  • Go/no-go recommendation (ready to launch?)

Phase 5: Post-Launch Research

Purpose

Measure impact and identify next improvements. Answer: Is it working? What should we optimize next?

When to use: After launch, ongoing optimization, annual reviews

Research Methods

Method 1: Analytics Analysis (Behavioral Data)

Purpose: Understand actual usage patterns at scale

Metrics to track:

Adoption:

  • New users per week/month
  • Feature usage (% of users who tried feature)
  • Repeat usage (% who return)
  • Power users (top 10% usage)

Engagement:

  • Sessions per user (frequency)
  • Session duration (time spent)
  • Actions per session (depth)
  • Retention (day 1, day 7, day 30)

Performance:

  • Task completion rate (% who finish flow)
  • Time to complete (efficiency)
  • Error rate (% who encounter errors)
  • Drop-off points (where users abandon)

Conversion:

  • Funnel conversion (% through each step)
  • Drop-off analysis (where and why)
  • Assisted conversions (multi-touch attribution)

Tools:

  • Google Analytics 4 (web)
  • Mixpanel, Amplitude (product analytics)
  • Firebase (mobile)
  • Hotjar, FullStory (session recordings)

Analysis techniques:

  • Cohort analysis (compare user groups over time)
  • Funnel analysis (conversion optimization)
  • Path analysis (common user journeys)
  • Segmentation (power users vs casual)

Method 2: Surveys (Satisfaction Data)

Purpose: Measure user satisfaction and sentiment

Types:

NPS (Net Promoter Score):

  • "How likely are you to recommend [product] to a friend?" (0-10)
  • Detractors (0-6), Passives (7-8), Promoters (9-10)
  • NPS = % Promoters - % Detractors
  • Follow-up: "Why did you give that score?"

CSAT (Customer Satisfaction):

  • "How satisfied are you with [feature/experience]?" (1-5)
  • Measure specific interactions (support, checkout, onboarding)
  • Benchmark: >80% satisfied (4-5 rating)

CES (Customer Effort Score):

  • "How easy was it to [complete task]?" (1-7)
  • Predicts loyalty (ease → retention)
  • Target: <2 average effort score

Custom surveys:

  • Feature-specific questions
  • Usability self-assessment
  • Priorities for improvement
  • Open-ended feedback

Best practices:

  • Short surveys (5 questions max)
  • In-context (after completing task)
  • Right timing (not too frequent)
  • Follow up on negative scores (reach out, fix issues)

Method 3: Session Recordings (Qualitative Observation)

Purpose: Watch real users interact with live product

Tools:

  • Hotjar (web)
  • FullStory (web)
  • Lookback (mobile)
  • Microsoft Clarity (free)

What to look for:

  • Rage clicks (rapid clicking on unresponsive element)
  • Confusion (hesitation, backtracking, random clicks)
  • Error encounters (how users recover)
  • Workarounds (creative solutions to design gaps)
  • Unexpected paths (users find their own way)

Analysis:

  • Tag sessions by behavior (errors, success, confusion)
  • Watch sample of sessions per segment (new users, power users, churned)
  • Identify patterns (common issues affecting multiple users)
  • Prioritize fixes (high-impact, high-frequency)

Benefits:

  • See actual behavior (not self-reported)
  • Discover unknown issues (not in hypothesis)
  • Empathy building (watch real struggles)

Limitations:

  • Time-consuming (manual review)
  • Privacy concerns (anonymize, get consent)
  • Sampling bias (recorded sessions may not be representative)

Method 4: Support Ticket Analysis

Purpose: Find pain points users report

Process:

  1. Export support tickets (last 1-3 months)
  2. Categorize by issue type (bug, question, request, complaint)
  3. Tag by product area (checkout, navigation, settings)
  4. Quantify frequency (which issues are common)
  5. Identify patterns (related issues clustering)

Insights:

  • Usability gaps (repeated "how do I..." questions)
  • Confusing flows (users need help to complete)
  • Missing features (workaround requests)
  • Error messaging (unclear error explanations)

Integration with design:

  • High support volume = design issue (not just support issue)
  • FAQ content becomes in-app help/tooltips
  • Common questions reveal discoverability problems

Deliverables

Usage Metrics Dashboard:

  • Weekly active users (trend)
  • Feature adoption (% using each feature)
  • Task completion rate (success %)
  • Drop-off points (where users abandon)
  • Top user paths (common journeys)

Satisfaction Scores:

  • NPS trend (month over month)
  • CSAT by feature (which are well-received)
  • Verbatim feedback (user quotes)
  • Sentiment analysis (positive vs negative themes)

Improvement Roadmap:

  • Priority 1 (critical issues, launch blockers)
  • Priority 2 (high-impact improvements)
  • Priority 3 (nice-to-haves, future enhancements)
  • Justification (data supporting each priority)

Example roadmap item:

Improvement: Redesign checkout flow

Evidence:
- 38% cart abandonment at shipping step (analytics)
- "Checkout is too long" - 47 support tickets (3 months)
- NPS detractors cite checkout complexity (12/20 mentions)
- Session recordings show 2m 45s average (benchmark: 1m 30s)

Impact: HIGH
- Directly affects revenue (38% abandonment)
- Frequent user complaint (47 tickets)
- Competitive disadvantage (competitors faster)

Recommendation: Reduce checkout from 4 steps to 2, streamline form fields, add guest checkout option

Expected outcome: Reduce abandonment to <25%, increase conversion by 13%

Priority: P1 (next quarter)

Integration with Design Skills

Research informs and validates design decisions:

Discovery Research → Design Skills

Findings feed into:

  • information-architecture - Mental models inform IA structure
  • visual-design-foundations - Understand user context (lighting, device, distractions)
  • interaction-design-patterns - Learn user workflows and expectations
  • accessibility-and-inclusive-design - Identify user needs (disabilities, constraints)

Example: Discovery reveals users frequently switch between mobile and desktop → Design must prioritize responsive consistency and cross-device sync

Generative Research → Design Skills

Card sorting informs:

  • information-architecture - Navigation structure and labels

Co-design feeds:

  • visual-design-foundations - User preferences for layout and hierarchy
  • interaction-design-patterns - Expected interactions and feedback

Evaluative Research → Design Skills

Usability testing validates:

  • visual-design-foundations - Is hierarchy clear? Do users notice CTAs?
  • information-architecture - Can users find content? Are labels clear?
  • interaction-design-patterns - Do interactions feel responsive? Are affordances clear?
  • accessibility-and-inclusive-design - Can users with disabilities complete tasks?

Example: Testing reveals users miss "Save" button → Visual design needs higher contrast or better placement

Post-Launch Research → All Design Skills

Analytics and feedback identify:

  • High-friction flows (redesign with all skills)
  • Underused features (discoverability issue → IA)
  • Frequent errors (interaction design → better feedback)
  • Accessibility complaints (audit and fix)

When to Use Which Phase

Starting New Project

Phase 1: DISCOVERY (understand users, context, problems) → Phase 2: GENERATIVE (explore solutions, ideate) → Design phase (apply visual/IA/interaction skills) → Phase 3: EVALUATIVE (test designs) → Phase 4: VALIDATION (pre-launch check) → Launch → Phase 5: POST-LAUNCH (measure impact, optimize)

Redesigning Existing Product

Phase 1: DISCOVERY (understand current pain points) → Phase 3: EVALUATIVE (test current design, identify issues) → Design improvements (apply skills) → Phase 3: EVALUATIVE (test improvements) → Phase 4: VALIDATION (pre-launch check) → Launch → Phase 5: POST-LAUNCH (measure improvement)

Optimizing Live Product

Phase 5: POST-LAUNCH (identify issues from analytics/support) → Phase 3: EVALUATIVE (test hypothesized improvements) → Design iteration (apply skills) → Phase 3: EVALUATIVE (validate improvements) → Launch → Phase 5: POST-LAUNCH (measure impact)

Adding New Feature

Phase 2: GENERATIVE (co-design, concept testing) → Design feature (apply skills) → Phase 3: EVALUATIVE (test with users) → Phase 4: VALIDATION (pre-launch check) → Launch → Phase 5: POST-LAUNCH (measure adoption)


Research Methods Catalog

Qualitative Methods (Understanding Why)

Method Phase Purpose Participants Duration
User Interviews Discovery Understand needs, context 5-8 30-60 min
Field Observations Discovery See real workflows 3-5 2-4 hours
Diary Studies Discovery Longitudinal behavior 10-15 1-4 weeks
Card Sorting Generative Mental models, IA 15-30 20-30 min
Co-design Workshops Generative Generate solutions 6-10 2-3 hours
Concept Testing Generative Test early ideas 5-8 15-30 min
Usability Testing Evaluative Find usability issues 5-8 45-60 min
Cognitive Walkthrough Validation Learning barriers 2-3 experts 2-4 hours
Session Recordings Post-Launch Real user behavior Sample 5-10 min/session

Quantitative Methods (Measuring What)

Method Phase Purpose Sample Size Analysis
Analytics Review Discovery Usage patterns All users Descriptive
Tree Testing Evaluative IA validation 15-30 Success rate
First-Click Testing Evaluative Visual hierarchy 15-30 Heat map
A/B Testing Evaluative Compare designs 100+ per variant Statistical
Surveys (NPS, CSAT) Post-Launch Satisfaction 50-200 Descriptive
Funnel Analysis Post-Launch Conversion All users Drop-off %

Validation Methods (Quality Assurance)

Method Phase Purpose Evaluators Time
Heuristic Evaluation Validation Usability principles 3 experts 1-2 days
Accessibility Audit Validation WCAG compliance 1-2 specialists 2-4 days
Beta Testing Validation Real-world validation 50-200 1-4 weeks

Deliverable Templates

User Persona Template

[Name] - [Role/Archetype]

Photo: [Realistic stock photo]

Demographics:
- Age: [Range]
- Role: [Job title or context]
- Tech Comfort: [Novice/Intermediate/Expert]
- Location: [Context for usage]

Goals:
1. [Primary goal]
2. [Secondary goal]
3. [Tertiary goal]

Pain Points:
1. [Current frustration #1]
2. [Current frustration #2]
3. [Current frustration #3]

Behaviors:
- [How they work today]
- [Tools they use]
- [Frequency of use]
- [Device preferences]

Quote: "[Memorable statement that captures their perspective]"

Scenario: [Day-in-the-life narrative showing context]

Journey Map Template

Journey: [User goal - e.g., "Purchase product online"]

Phase 1: [STAGE NAME]
├─ Actions: [What user does]
├─ Thoughts: [What they're thinking]
├─ Emotions: [How they feel - rate 1-10]
├─ Pain Points: [Frustrations]
└─ Opportunities: [Design improvements]

Phase 2: [STAGE NAME]
[Repeat structure]

Emotion Graph: [Visual line showing emotional highs and lows across journey]

Key Insights:
- [Overall pattern]
- [Critical moments]
- [Design opportunities]

Usability Findings Template

Issue #[X]: [Brief description]

Severity: [Critical / High / Medium / Low]

Frequency: [X/Y participants affected]

Description:
[What went wrong in detail]

Evidence:
- Observation: [What you saw]
- Quotes: "[User statement]"
- Metrics: [Time, clicks, errors]

Impact:
[How this affects users and business goals]

Recommendation:
[Specific, actionable fix with rationale]

Priority: [P0/P1/P2/P3]
- P0 = Blocker (must fix before launch)
- P1 = Critical (fix ASAP post-launch)
- P2 = Important (next sprint)
- P3 = Backlog (future improvement)

Related Issues: [Links to other findings]

Common Patterns

Pattern 1: Research-Driven Design Process

Discovery (understand) → Generative (ideate) → Design (create) → Evaluative (test) → Validation (quality check) → Launch → Post-Launch (optimize)

Pattern 2: Lean Validation

Evaluative (test current state) → Design iteration → Evaluative (test improvement) → Launch if better

Pattern 3: Continuous Improvement

Post-Launch (identify issues) → Design fixes → Evaluative (test fixes) → Launch → Post-Launch (measure impact) → Repeat

Pattern 4: Feature Development

Generative (co-design) → Design feature → Evaluative (usability test) → Validation (QA) → Launch → Post-Launch (adoption metrics)


Red Flags & Anti-Patterns

Anti-Pattern 1: Skipping Discovery

Problem: Designing without understanding users Consequence: Build wrong thing, wasted effort Fix: Always start with discovery (even if brief)

Anti-Pattern 2: Testing Too Late

Problem: Usability testing after development complete Consequence: Expensive to fix, must ship with known issues Fix: Test wireframes/prototypes before development

Anti-Pattern 3: Testing with Wrong Users

Problem: Using internal team or unrepresentative users Consequence: Miss real user issues, false confidence Fix: Recruit actual target users (representative sample)

Anti-Pattern 4: Ignoring Negative Feedback

Problem: Dismissing usability issues ("Users will learn it") Consequence: Poor user experience, churn, support burden Fix: Take all feedback seriously, prioritize based on severity and frequency

Anti-Pattern 5: Over-Relying on Quantitative Data

Problem: Only looking at analytics, no qualitative insight Consequence: Know what's broken, not why or how to fix Fix: Combine quant (what) with qual (why) methods

Anti-Pattern 6: Research Without Action

Problem: Conducting research but not using findings Consequence: Wasted time, frustrated participants Fix: Only research what you can act on, prioritize findings, implement changes

Anti-Pattern 7: One-Time Research

Problem: Research once, never again Consequence: Design becomes outdated as users evolve Fix: Establish continuous research cadence (quarterly pulse checks)

Anti-Pattern 8: Confusing Preference with Usability

Problem: "Users said they like blue, so we made it blue" Consequence: Aesthetic preference doesn't equal usability Fix: Test behavior (can they complete tasks?), not opinions (do they like it?)


Related Skills

Core UX Skills:

  • lyra/ux-designer/information-architecture - Research validates IA structure (card sorting, tree testing)
  • lyra/ux-designer/accessibility-and-inclusive-design - Research with users with disabilities, accessibility audits
  • lyra/ux-designer/visual-design-foundations - Research informs visual hierarchy, usability testing validates designs
  • lyra/ux-designer/interaction-design-patterns - Research validates interaction clarity and feedback

Meta Skills:

  • lyra/ux-designer/using-ux-designer - Routes to this skill when research/validation needed
  • lyra/ux-designer/ux-fundamentals - Explains research terminology and principles

Platform Extensions:

  • All platform skills benefit from research findings (validates platform-specific patterns)

Cross-Faction:

  • muna/technical-writer/* - Research methods apply to documentation usability testing