software-ux-research

What this skill does

# Software UX Research Skill — Quick Reference

Use this skill to identify problems/opportunities and de-risk decisions. Use `software-ui-ux-design` to implement UI patterns, component changes, and design system updates.

---

## Mar 2026 Baselines (Core)

- **Human-centred design**: Iterative design + evaluation grounded in evidence (ISO 9241-210:2019) https://www.iso.org/standard/77520.html
- **Usability definition**: Effectiveness, efficiency, satisfaction in context (ISO 9241-11:2018) https://www.iso.org/standard/63500.html
- **Accessibility baseline**: WCAG 2.2 is a W3C Recommendation (12 Dec 2024) https://www.w3.org/TR/WCAG22/
- **WCAG 3.0 preview**: Working Draft published Sep 2025; introduces Bronze/Silver/Gold conformance tiers and enhanced cognitive accessibility; not expected before 2028-2030 https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/
- **EU shipping note**: European Accessibility Act applies to covered products/services after 28 Jun 2025 (Directive (EU) 2019/882) https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019L0882

## When to Use This Skill

- Discovery: user needs, JTBD, opportunity sizing, mental models.
- Validation: concepts, prototypes, onboarding/first-run success.
- Evaluative: usability tests, heuristic evaluation, cognitive walkthroughs.
- Quant/behavioral: funnels, cohorts, instrumentation gaps, guardrails.
- Research Ops: intake, prioritization, repository/taxonomy, consent/PII handling.
- **Demographic research**: Age-diverse, cultural, accessibility participant recruitment.
- **A/B testing**: Experiment design, sample size, analysis, pitfalls.
- **Non-technical user research**: Digital literacy assessment, simplified-flow validation, low-tech-confidence usability testing.

## When NOT to Use This Skill

- **UI implementation** → Use [software-ui-ux-design](../software-ui-ux-design/SKILL.md) for components, patterns, code
- **Analytics instrumentation** → Use [marketing-product-analytics](../marketing-product-analytics/SKILL.md) for tracking plans and [qa-observability](../qa-observability/SKILL.md) for implementation patterns
- **Accessibility compliance audit** → Use accessibility-specific checklists (WCAG conformance)
- **Marketing research** → Use [marketing-social-media](../marketing-social-media/SKILL.md) or related marketing skills
- **A/B test platform setup** → Use experimentation platforms (Statsig, GrowthBook, LaunchDarkly)

---

## Operating Mode (Core)

If inputs are missing, ask for:

- Decision to unblock (what will change based on this research).
- Target roles/segments and top tasks.
- Platforms and contexts (web/mobile/desktop; remote/on-site; assisted tech).
- Existing evidence (analytics, tickets, reviews, recordings, prior studies).
- Constraints (timeline, recruitment access, compliance, budget).

Default outputs (pick what the user asked for):

- Research plan + output contract (prefer [../software-clean-code-standard/assets/checklists/ux-research-plan-template.md](../software-clean-code-standard/assets/checklists/ux-research-plan-template.md); use [assets/research-plan-template.md](assets/research-plan-template.md) for skill-specific detail)
- Study protocol (tasks/script + success metrics + recruitment plan)
- Findings report (issues + severity + evidence + recommendations + confidence)
- Decision brief (options + tradeoffs + recommendation + measurement plan)

### Required Output Sections

Every research output — plans, protocols, evaluations, reports — must include these sections. They represent the skill's core value beyond standard UX knowledge: governance, confidence calibration, and ethical research practice.

1. **Method Justification**: Name the chosen method AND explain why alternatives were rejected. Do not just describe the method; explain why it was selected over at least 2 alternatives given the specific context (stage, timeline, sample, question type).

2. **Confidence & Triangulation Assessment**: Tag every recommendation or finding with a confidence level:

   | Confidence | Evidence requirement | Use for |
   |------------|----------------------|---------|
   | High | Multiple methods or sources agree | High-impact decisions |
   | Medium | Strong signal from one method + supporting indicators | Prioritization |
   | Low | Single source / small sample | Exploratory hypotheses only |

3. **Consent & Data Handling**: Include a PII/consent section in every plan or protocol. Research that involves participants requires explicit attention to:
   - Minimum PII collection
   - Identity stored separately from study data
   - Name/email redaction before broad sharing
   - Recording access restricted to need-to-know
   - Consent, purpose, retention, and opt-out documented

4. **Decision Framework**: For evaluations and analysis outputs, provide a structured decision table with options, confidence levels, timelines, and risks — not just a single recommendation.

5. **Pre-Decision Checklist**: For experiment evaluations (A/B tests, etc.), include a verification checklist of confounds and data quality checks to complete before any ship/kill decision.

---

## Method Chooser (Core)

### Decision Tree (Fast)

```text
What do you need?
  ├─ WHY / needs / context → interviews, contextual inquiry, diary
  ├─ HOW / usability → moderated usability test, cognitive walkthrough, heuristic eval
  ├─ WHAT / scale → analytics/logs + targeted qual follow-ups
  └─ WHICH / causal → experiments (if feasible) or preference tests
```

When selecting a method, always justify the choice by explaining why 2+ alternatives were rejected given the user's specific context. This is a key differentiator — generic "we'll do interviews" without justification is insufficient.

---

## Research by Product Stage

### Stage Framework (What to Do When)

| Stage | Decisions | Primary Methods | Secondary Methods | Output |
|-------|-----------|-----------------|-------------------|--------|
| Discovery | What to build and for whom | Interviews, field/diary, journey mapping | Competitive analysis, feedback mining | Opportunity brief + JTBD + Forces of Progress |
| Concept/MVP | Does the concept work? | Concept test, prototype usability | First-click/tree test | MVP scope + onboarding plan |
| Launch | Is it usable + accessible? | Usability testing, accessibility review | Heuristic eval, session replay | Launch blockers + fixes |
| Growth | What drives adoption/value? | Segmented analytics + qual follow-ups | Churn interviews, surveys | Retention drivers + friction |
| Maturity | What to optimize/deprecate? | Experiments, longitudinal tracking | Unmoderated tests | Incremental roadmap |

### Discovery Outputs: Beyond Basic JTBD

Discovery research should produce more than job statements. Include:
- **Forces of Progress diagram**: Map the four forces acting on switching behavior — Push (current pain), Pull (new solution appeal), Anxiety (fear of change), Habit (inertia). These forces explain why users do or don't adopt, which directly informs positioning and onboarding.
- **Pain Point Severity Matrix**: Score each pain point by Frequency × Impact × Breadth to prioritize objectively. A pain that affects 3 roles weekly outranks one that affects 1 role monthly, even if the single-role pain feels more dramatic in interviews.

---

## Research for Complex Systems (Workflows, Admin, Regulated)

### Complexity Indicators

| Indicator | Example | Research Implication |
|-----------|---------|----------------------|
| Multi-step workflows | Draft → approve → publish | Task analysis + state mapping |
| Multi-role permissions | Admin vs editor vs viewer | Test each role + transitions |
| Data dependencies | Requires integrations/sync | Error-path + recovery testing |
| High stakes | Finance, healthcare | Safety checks + confirmations |
| Expert users | Dev tools, analytics | Recruit real experts (not proxies) |

### Evaluation Methods (Core)

- Contextual inquiry: observe real work and constraints.
- Task anal