ux-design-sprint

Design Sprint Sub-Skill

Version: 1.1.0 Framework: Jerry User-Experience -- Design Sprint 2.0 Constitutional Compliance: Jerry Constitution v1.0 Parent Skill: /user-experience (skills/user-experience/SKILL.md) Wave: 5 (Process Intensives) Project: PROJ-022 User Experience Skill | GitHub Issue #138

Document Sections

Section	Purpose
Document Audience	Triple-Lens audience guide
Purpose	Sub-skill overview and key capabilities
When to Use This Sub-Skill	Activation triggers and scope boundaries
Available Agents	Single agent with role, model, and output location
P-003 Compliance	Worker agent hierarchy position
Invoking the Agent	Invocation via ux-orchestrator
Methodology	AJ&Smart Design Sprint 2.0 four-day process with detailed phase activities
Output Specification	Output location, L0/L1/L2 structure, required sections
Routing	Keywords and lifecycle-stage routing integration
Cross-Framework Integration	Handoff from JTBD/heuristic evaluation and to Lean UX/HEART metrics
Synthesis Hypothesis Confidence	Confidence classifications for Design Sprint outputs
Quality Gate Integration	S-014 scoring and H-13 threshold enforcement
Degraded Mode Behavior	Operation when Figma or Miro MCP unavailable
Wave Architecture	Wave 5 entry criteria, bypass conditions
Constitutional Compliance	Governing principles and AI-facilitated sprint limitations
Registration	H-26 parent-routed registration model and AGENTS.md confirmation
Deployment Status	Wave 5 stub agent status and implementation timeline
Quick Reference	Common workflows and agent selection hints
References	Full repo-relative paths, requirements traceability, external citations

Document Audience (Triple-Lens)

This SKILL.md serves multiple audiences:

Level	Audience	Sections to Focus On
L0 (Stakeholder)	Product managers, designers, sprint participants	Purpose, When to Use This Sub-Skill, Quick Reference
L1 (Developer)	Engineers invoking the agent	Invoking the Agent, Methodology, Output Specification
L2 (Architect)	Workflow designers, skill maintainers	Cross-Framework Integration, Synthesis Hypothesis Confidence, Degraded Mode Behavior

---

Purpose

The Design Sprint sub-skill provides structured facilitation for the AJ&Smart Design Sprint 2.0 process -- a four-day compressed format (Courtney, 2019) adapted from the original Google Ventures five-day Design Sprint (Knapp, Zeratsky & Kowitz, 2016). It targets tiny teams (1-5 people) who need to rapidly move from a design challenge to a tested prototype without committing months to development.

This sub-skill is part of Wave 5 (Process Intensives), requiring Wave 4 completion before standard deployment. It provides the most intensive, end-to-end design validation process in the /user-experience skill, producing high-confidence synthesis signals from direct user testing on Day 4. A wave bypass condition allows teams at product inception ("don't know what to build") to access Design Sprint without completing prior waves.

Key Capabilities

• Day 1: Map -- Facilitates challenge definition, user journey mapping, expert interview structuring, sprint question formulation, and target selection (user + key moment). Produces a shared map of the problem space that aligns the sprint team.
• Day 2: Sketch -- Guides lightning demo research, facilitates the four-step sketch process (Notes, Ideas, Crazy 8s, Solution Sketch), and structures Art Museum voting. Produces individual solution sketches with structured selection rationale.
• Day 3: Decide -- Facilitates straw poll voting, supervote decision-making, winning sketch selection, assumption identification, and prototype storyboard creation. Produces a detailed storyboard ready for prototype construction.
• Day 4: Test -- Guides realistic prototype construction, structures interviews with 5 representative users (Nielsen, 2000), facilitates observation and note-taking, and identifies thematic patterns across interviews. Produces validated findings with HIGH synthesis confidence.
• Cross-Framework Synthesis -- Sprint findings feed directly into /ux-lean-ux (hypothesis generation from validated learnings), /ux-jtbd (validated job stories from user interviews), and /ux-heuristic-eval (post-sprint evaluation of the prototype).

---

When to Use This Sub-Skill

Activate when:

• The team does not know what to build and needs a structured process to go from challenge to tested prototype
• A critical design challenge requires rapid validation before committing development resources
• The team needs to test a product concept with real users within a compressed timeframe
• Stakeholder alignment is needed around a shared understanding of the problem and solution direction
• Multiple competing solution ideas exist and the team needs a structured selection and testing process
• Starting a new product or feature initiative and wanting to validate assumptions early
• Transitioning from discovery research (JTBD) into concrete solution exploration
• A cross-functional team needs to align around a single prototype direction

Do NOT use for:

• Evaluating an existing interface against usability heuristics -- use /ux-heuristic-eval (Nielsen's 10) instead. Use heuristic evaluation for existing products; Design Sprint is for new concepts and major redesigns.
• Building or auditing a component library -- use /ux-atomic-design (Atomic Design) instead.
• Accessibility compliance auditing -- use /ux-inclusive-design (WCAG 2.2) instead.
• Measuring quantitative UX health metrics -- use /ux-heart-metrics (Google GSM) instead. Use HEART after the sprint to measure the validated concept.
• Understanding user motivations at the job level -- use /ux-jtbd (Jobs-to-Be-Done) instead. JTBD identifies what users want; Design Sprint tests specific solutions.
• Diagnosing behavioral bottlenecks in existing products -- use /ux-behavior-design (Fogg B=MAP) instead.
• Iterating on hypotheses through build-measure-learn cycles -- use /ux-lean-ux (Lean UX) instead. Lean UX iterates; Design Sprint validates a single prototype in 4 days.
• Prioritizing features by user satisfaction impact -- use /ux-kano-model (Kano) instead.
• Security-focused interface review -- use /eng-team instead.
• General research without UX design sprint focus -- use /problem-solving instead.

---

Available Agents

Agent	Role	Tier	Mode	Model	Output Location
ux-sprint-facilitator	AJ&Smart Design Sprint 2.0 facilitation	T4	Systematic	Opus	projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-sprint-facilitator-{topic-slug}.md

STUB: The agent definition file (skills/ux-design-sprint/agents/ux-sprint-facilitator.md) is pending Wave 5 Phase 2 implementation as part of PROJ-022 EPIC-005. The SKILL.md specifies the methodology and output contract that the agent will implement.

Tool tier: T4 (External) = Read, Write, Edit, Glob, Grep, Bash + WebSearch, WebFetch, Context7 MCP. T4 access is required because Design Sprint facilitation benefits from external research during Day 1 expert interviews and Day 2 lightning demos (competitive analysis, industry precedent research). See .context/rules/agent-development-standards.md [Tool Security Tiers].

The agent produces output at three levels per AD-M-004:

• L0 (Executive Summary): Sprint challenge statement; winning solution summary; Day 4 test results (pass/fail per sprint question); top validated findings; recommended next steps.
• L1 (Technical Detail): Full four-day sprint artifact set: challenge map, expert interview notes, sprint questions, solution sketches with selection rationale, storyboard, prototype specification, structured interview findings with per-user pattern analysis.
• L2 (Strategic Implications): Sprint learning synthesis; validated vs. invalidated assumptions; product strategy implications; recommended follow-up activities (Lean UX cycles, heuristic evaluation, development planning); organizational sprint maturity assessment.

---

P-003 Compliance

The /ux-design-sprint sub-skill contains a single worker agent. It is invoked by the ux-orchestrator (T5) via the Agent tool. The agent does NOT have Agent tool access and MUST NOT spawn sub-agents.

MAIN CONTEXT (user request)
    |
    v
ux-orchestrator (T5, Opus, Integrative) -- parent orchestrator
    |
    +-- ux-sprint-facilitator (T4, Systematic, Opus) -- THIS sub-skill's worker
    +-- [other sub-skill workers...]

Enforcement:

• disallowedTools: [Agent] declared in skills/ux-design-sprint/agents/ux-sprint-facilitator.md frontmatter
• P-003 prohibition in skills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml capabilities.forbidden_actions
• CI gate validates no sub-skill agent has Agent access (documented in skills/user-experience/rules/ci-checks.md)

---

Invoking the Agent

This is a sub-skill invoked by the ux-orchestrator, not directly by users. Users interact with the parent /user-experience skill, which routes to this sub-skill based on lifecycle-stage triage.

Via Natural Language (to parent skill)

"We don't know what to build -- help us figure it out"
"Run a design sprint for the new mobile navigation"
"We need to validate our checkout redesign concept with real users"
"Facilitate a 4-day design sprint to explore our onboarding problem"
"Help us go from idea to tested prototype for the dashboard feature"
"Our team has 3 competing ideas for the settings page -- which one works?"

Via Explicit Agent Request (to parent skill)

"Use ux-sprint-facilitator to facilitate a design sprint for the new payment flow"
"Have ux-sprint-facilitator run a Design Sprint 2.0 for our mobile app onboarding"

Via Agent Tool (orchestrator internal)

The ux-orchestrator invokes the agent via the Agent tool:

Agent(
    description="ux-sprint-facilitator: Design Sprint 2.0 for mobile navigation redesign",
    subagent_type="jerry:ux-sprint-facilitator",
    prompt="""
## UX CONTEXT (REQUIRED)
- **Engagement ID:** UX-0012
- **Topic:** Mobile Navigation Redesign Design Sprint
- **Product:** [product name, domain, and current navigation description]
- **Target Users:** [user segments and behavioral context]
- **Sprint Challenge:** [the big challenge or question the sprint aims to answer]
- **Sprint Questions:** [2-5 specific questions to answer by end of sprint]
- **Existing Research:** [upstream JTBD job statements, heuristic findings, user interviews]
- **MCP Availability:** Figma=[available/unavailable], Miro=[available/unavailable]

## TASK
Facilitate a complete AJ&Smart Design Sprint 2.0 for mobile navigation redesign.
1. Day 1 (Map): Define challenge, map user journey, identify target user + key moment, structure expert interviews, set sprint questions
2. Day 2 (Sketch): Conduct lightning demos, facilitate 4-step sketch (notes, ideas, crazy 8s, solution sketch), run Art Museum voting
3. Day 3 (Decide): Facilitate straw poll, supervote, select winning sketch, identify assumptions, create storyboard
4. Day 4 (Test): Specify realistic prototype, structure interviews with 5 users, analyze patterns, synthesize findings

## MANDATORY PERSISTENCE (P-002)
Create file at: projects/${JERRY_PROJECT}/engagements/UX-0012/ux-sprint-facilitator-mobile-navigation.md
"""
)

Governance codification (AD-M-007): The session_context contract (on_receive/on_send) is specified in ux-sprint-facilitator.governance.yaml per AD-M-007. Fields are enumerated below:

on_receive fields:

Field	Type	Required	Description
engagement_id	string	Yes	UX engagement identifier (format: UX-{NNNN})
product_context	string	Yes	Product name, domain, current state, and target user description
sprint_challenge	string	Yes	The big question or problem the sprint aims to solve (e.g., "How might we reduce checkout abandonment for first-time buyers?")
sprint_questions	array	No	2-5 specific questions to answer by end of sprint; if absent, Day 1 generates them
upstream_artifacts	array	No	File paths to upstream handoff artifacts (JTBD job statements, heuristic evaluation findings, prior research)
mcp_availability	object	No	MCP tool availability: figma (boolean), miro (boolean); determines degraded mode behavior

on_send fields:

Field	Type	Required	Description
sprint_day_completed	integer	Yes	Last completed sprint day (1-4); 4 indicates full sprint completion
challenge_statement	string	Yes	Finalized challenge statement from Day 1
prototype_fidelity	enum	Yes	high (Figma interactive), medium (static mockups), low (paper/whiteboard)
interview_count	integer	Yes	Number of user interviews completed (target: 5 per Nielsen, 2000)
theme_strength	enum	Yes	strong (identified by >= 3 of 5 users), moderate (2 of 5), weak (1 of 5)
usability_findings_count	integer	Yes	Total usability findings from Day 4 interviews
sprint_questions_answered	array	Yes	Each sprint question with pass/fail/partial verdict and supporting evidence
winning_sketch_summary	string	Yes	Description of the selected solution direction from Day 3
validated_assumptions	array	Yes	Assumptions confirmed by Day 4 testing
invalidated_assumptions	array	Yes	Assumptions disproven by Day 4 testing
synthesis_judgments	array	Yes	AI judgment calls with confidence classification and rationale

---

Methodology

AJ&Smart Design Sprint 2.0

The AJ&Smart Design Sprint 2.0 (Courtney, 2019) compresses the original Google Ventures five-day Design Sprint (Knapp, Zeratsky & Kowitz, 2016) into four days by combining the original Day 1 (Understand) and Day 2 (Diverge) into a single Day 1 (Map), and merging the original Day 3 (Decide) with Day 4 (Prototype) into Day 3 (Decide + Storyboard). This produces a more intensive but faster sprint cadence while preserving the core methodology.

Sprint Day	GV Equivalent	Primary Activity	Key Output
Day 1: Map	GV Days 1-2	Challenge definition, journey mapping, expert interviews, sprint questions, sketching	Challenge map, sprint questions, solution sketches
Day 2: Sketch	GV Day 2 (cont.)	Lightning demos, 4-step sketch, Art Museum voting	Individual solution sketches with vote data
Day 3: Decide	GV Days 3-4	Straw poll, supervote, winning sketch, storyboard, prototype specification	Storyboard, prototype plan
Day 4: Test	GV Day 5	Prototype construction, 5-user interviews, pattern analysis	Validated findings, sprint verdict

Day 1: Map

Purpose: Align the sprint team around the challenge, map the problem space, gather expert knowledge, and set measurable sprint questions.

Activities:

1. Challenge Definition -- Articulate the sprint challenge as a "How Might We" (HMW) question (IDEO design thinking technique, Brown, 2009; adopted in Sprint methodology per Knapp et al., 2016, Chapter 4). The challenge should be specific enough to test in 4 days but broad enough to allow creative solutions. Example: "How might we reduce first-time buyer checkout abandonment from 68% to under 40%?"

2. Long-Term Goal -- Define what success looks like 6-12 months from now. This anchors the sprint against strategic objectives, not just tactical improvements.

3. Sprint Questions -- Formulate 2-5 specific, testable questions that the sprint must answer. Sprint questions should be phrased as "Can we...?" or "Will users...?" to enable clear pass/fail assessment on Day 4. Example: "Will users understand the new progress indicator without instruction?"

4. User Journey Map -- Map the end-to-end user journey for the target behavior, from first awareness through the desired action. Identify: entry points, key decision moments, friction points, and the critical moment (the single most important interaction to get right).

5. Target Selection -- Choose the target user segment and the key moment in the journey that the sprint will focus on. The key moment is the narrowest scope that still addresses the sprint challenge. Per Knapp et al. (2016): "Pick the most important customer and the most important moment."

6. Expert Interviews -- Conduct structured "How Might We" interviews with 3-5 domain experts (product owner, support representative, technical lead, existing users if available). Each interview is 15-20 minutes. Capture HMW notes on individual cards/items for later clustering.

7. HMW Clustering -- Group HMW notes by theme. Vote to identify the most promising opportunity areas. Place winning HMW clusters on the journey map at the relevant moments.

Output: Challenge map document containing: HMW challenge statement, long-term goal, sprint questions (2-5), annotated user journey map, target user + key moment selection, expert interview summaries, clustered HMW notes.

Day 2: Sketch

Purpose: Generate individual solution ideas through structured sketching exercises, then surface and compare solutions through Art Museum voting.

Activities:

1. Lightning Demos -- Each participant (or the facilitator for the team) reviews 3-5 inspiring examples from other products, industries, or domains that solve analogous problems. Capture "big ideas" from each demo. External research via WebSearch/WebFetch supports this activity.

2. Four-Step Sketch -- Individual sketching process (Knapp et al., 2016):

   • Step 1: Notes (20 min) -- Review Day 1 outputs. Take personal notes on key insights, constraints, and opportunities.
   • Step 2: Ideas (20 min) -- Rough idea generation. Sketchy, informal, quantity over quality. No judgment.
   • Step 3: Crazy 8s (8 min) -- Fold paper into 8 panels. One variation per panel, one minute each. Forces rapid iteration on the strongest idea from Step 2.
   • Step 4: Solution Sketch (30-90 min) -- Detailed, self-explanatory 3-panel storyboard of the best solution. Must be understandable without verbal explanation. Anonymous (no names on sketches).

3. Art Museum -- All solution sketches posted on a wall (or Miro board). Silent review period where participants place dot votes on compelling elements. Heat map emerges showing which solutions and elements attract the most attention.

4. Speed Critiques -- Brief 3-minute presentations of each sketch by the facilitator (not the author). Author clarifies only at the end. Team discusses strengths and concerns.

Output: Collection of solution sketches with vote data, lightning demo research notes, Art Museum heat map results.

Day 3: Decide

Purpose: Select the winning solution, identify critical assumptions, and create a detailed storyboard for prototype construction.

Activities:

1. Straw Poll -- Each team member places one "super dot" on the solution (or solution element) they believe best addresses the sprint challenge. Non-binding poll to surface initial preferences.

2. Supervote -- The Decider (product owner or designated decision-maker) places 3 supervote dots. The Decider's votes determine the direction. Per Knapp et al. (2016): "The Decider has final say." If no human Decider is designated, the facilitator presents a ranked recommendation based on straw poll consensus, Day 1 sprint question alignment, and feasibility assessment, then asks the user to confirm.

3. Rumble or All-in-One -- If two strong but incompatible solutions survive the supervote: Rumble (test both in the prototype as A/B variants) or All-in-One (combine compatible elements). The Decider chooses the approach.

4. Assumption Identification -- Extract the critical assumptions embedded in the winning solution. Each assumption is phrased as a testable statement: "Users will [expected behavior] when [condition]." Classify as: must-be-true (sprint fails if wrong), nice-to-have (enhances but not critical), or unknown (requires investigation).

5. Storyboard -- Create a detailed 10-16 panel storyboard that narrates the user's interaction with the prototype from opening scene through completion. Each panel specifies: screen state, user action, system response, and emotional state. The storyboard serves as the prototype construction blueprint.

6. Prototype Specification -- Define the prototype scope: which screens to build, interaction fidelity level (clickable prototype vs. static mockups vs. wizard-of-oz), data requirements (realistic content vs. placeholder), and tools (Figma, paper, presentation software).

Output: Decision record (winning sketch, selection rationale, Decider identity), assumption inventory, detailed storyboard (10-16 panels), prototype specification.

Day 4: Test

Purpose: Build a realistic prototype, test it with 5 representative users, and identify validated patterns.

Activities:

1. Prototype Construction -- Build the prototype per the Day 3 storyboard and specification. Fidelity should be "just enough" to feel real without over-investing. Per Knapp et al. (2016): "A Goldilocks quality prototype -- just real enough." The facilitator provides guidance on prototype scope and structure; actual construction may use Figma MCP (if available) or manual methods.

2. Interview Script Preparation -- Structure a 60-minute interview protocol (Knapp et al., 2016, Chapter 14 "Friday: Test"):

   • Context Questions (5 min): Background about the user's relationship to the problem domain
   • Task Introduction (5 min): Set up the scenario without leading the user
   • Prototype Walkthrough (30 min): User completes tasks while thinking aloud; facilitator observes without guiding
   • Debrief Questions (15 min): Open-ended reflection on the experience
   • Wrap-up (5 min): Final impressions, anything the user wants to add

3. User Interviews -- Conduct structured interviews with 5 representative users (Nielsen, 2000). Five users are sufficient to identify approximately 85% of usability problems. Each interview follows the prepared script. Record observations against the sprint questions.

4. Observation Grid -- During each interview, the sprint team (or facilitator) records observations in a grid: rows = sprint questions + key screens, columns = users (U1-U5). Each cell captures: positive reaction (+), negative reaction (-), or neutral observation (~). Color-code for quick pattern identification.

5. Pattern Analysis -- After all 5 interviews, analyze the observation grid:

   • Strong theme (>= 3 of 5 users): Validated finding with HIGH synthesis confidence
   • Moderate theme (2 of 5 users): Noteworthy finding requiring additional validation (MEDIUM confidence)
   • Weak theme (1 of 5 users): Individual observation, not a pattern (noted but not actionable)

6. Sprint Question Verdict -- For each sprint question, assign a verdict:

   • Pass: Strong positive theme (>= 3 users completed the expected behavior without significant difficulty)
   • Fail: Strong negative theme (>= 3 users could not complete or expressed clear confusion/frustration)
   • Partial: Mixed results or moderate themes; requires follow-up investigation

7. Findings Synthesis -- Compile validated findings, categorize by severity and frequency, map findings to assumptions (validated vs. invalidated), and produce the sprint outcome summary.

Output: Prototype reference (file path or description), interview observation grid, thematic analysis with pattern strength, sprint question verdicts, assumption validation results, findings synthesis with confidence classifications.

Execution Phases (Agent Internal)

Note: This execution procedure describes target behavior for the fully-implemented ux-sprint-facilitator agent. The current agent definition is a Wave 5 stub; full implementation will follow this specification.

The facilitator follows a 5-phase sequential workflow corresponding to the sprint structure plus a synthesis phase. Each phase produces intermediate artifacts that feed the next.

Phase 1: Sprint Setup and Day 1 (Map)

Purpose: Establish sprint context, confirm wave entry criteria, and execute Day 1 activities.

Activities:

1. Confirm Wave 5 entry criteria are met: Wave 4 completed (30+ users for Kano survey OR 1 B=MAP bottleneck diagnosed), OR bypass condition satisfied (team at product inception with existing user research). (Verification: check for WAVE-4-SIGNOFF.md in projects/${JERRY_PROJECT}/engagements/; if absent, ask user per H-31.)
2. Catalog upstream inputs: check for /ux-jtbd job statements (job statement + switch forces feed the challenge statement); check for /ux-heuristic-eval findings (severity-rated findings provide problem context)
3. Execute Day 1 activities: challenge definition, long-term goal, sprint questions, user journey map, target selection, expert interviews, HMW clustering
4. Produce Day 1 output artifact: challenge map document

Output: Sprint setup brief (wave entry verification, upstream input inventory) and Day 1 challenge map.

Phase 2: Day 2 (Sketch)

Purpose: Generate and surface solution ideas.

Activities:

1. Conduct lightning demos using WebSearch/WebFetch for external research on analogous solutions
2. Facilitate 4-step sketch process (Notes, Ideas, Crazy 8s, Solution Sketch)
3. Structure Art Museum voting and speed critiques
4. Produce Day 2 output: solution sketches with vote data

Output: Lightning demo research notes, solution sketch descriptions, Art Museum results.

Phase 3: Day 3 (Decide)

Purpose: Select winning solution and create prototype blueprint.

Activities:

1. Facilitate straw poll and supervote (present recommendation if no human Decider designated)
2. Identify and classify critical assumptions
3. Create detailed storyboard (10-16 panels)
4. Specify prototype scope and fidelity

Output: Decision record, assumption inventory, storyboard, prototype specification.

Phase 4: Day 4 (Test)

Purpose: Construct prototype, test with users, and analyze results.

Activities:

1. Guide prototype construction (Figma MCP if available, manual methods otherwise)
2. Prepare structured interview script
3. Facilitate 5-user interview process and observation grid
4. Conduct pattern analysis using the >= 3 of 5 threshold for strong themes
5. Assign sprint question verdicts (pass/fail/partial)

Output: Prototype reference, interview observation grid, pattern analysis, sprint question verdicts.

Phase 5: Synthesis and Handoff Preparation

Purpose: Synthesize all sprint findings, produce L0/L1/L2 output artifact, and construct downstream handoffs.

Activities:

1. Produce L0 executive summary: sprint challenge, winning solution, Day 4 verdicts, top findings, next steps
2. Produce L1 technical detail: full four-day artifact set with evidence citations
3. Produce L2 strategic implications: validated/invalidated assumptions, product strategy implications, follow-up recommendations, sprint maturity assessment
4. Compile Synthesis Judgments Summary: every AI judgment call with confidence classification and rationale
5. Prepare downstream handoffs: /ux-lean-ux (validated prototype + Day 4 findings for hypothesis iteration), /ux-heuristic-eval (prototype for post-sprint evaluation), /ux-jtbd (validated job stories from user interviews)
6. Map findings to sprint questions; produce final sprint verdict

Output: Complete output artifact per Required Output Sections. Handoff payloads for downstream sub-skills.

---

Output Specification

Output Location

projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-sprint-facilitator-{topic-slug}.md

Where:

• {engagement-id} follows the pattern UX-{NNNN} (e.g., UX-0012)
• {topic-slug} is a kebab-case descriptor of the sprint challenge (e.g., mobile-navigation, checkout-redesign, onboarding-flow)

Required Output Sections

Section	Level	Content
Executive Summary	L0	Sprint challenge statement; winning solution summary; Day 4 test results (pass/fail/partial per sprint question); top validated findings; recommended next steps
Sprint Context	L1	Product description, target users, sprint participants, upstream inputs (JTBD job statements, heuristic findings), wave entry verification, MCP availability
Day 1: Map	L1	HMW challenge statement, long-term goal, sprint questions (2-5), annotated user journey map, target user + key moment, expert interview summaries, HMW clusters
Day 2: Sketch	L1	Lightning demo research notes, solution sketch descriptions, Crazy 8s variations summary, Art Museum vote results, speed critique highlights
Day 3: Decide	L1	Straw poll results, supervote outcome, Decider identity and rationale, Rumble/All-in-One decision, assumption inventory (must-be-true/nice-to-have/unknown), storyboard (10-16 panels), prototype specification
Day 4: Test	L1	Prototype reference (fidelity level, tool used), interview script summary, observation grid (5 users x sprint questions), pattern analysis with theme strength, sprint question verdicts (pass/fail/partial), assumption validation results
Strategic Implications	L2	Sprint learning synthesis; validated vs. invalidated assumptions mapped to product strategy; recommended follow-up (Lean UX cycles, heuristic evaluation, development planning); organizational sprint maturity assessment; competitive positioning insights from lightning demos
Synthesis Judgments Summary	L1	Each AI judgment call listed for synthesis confidence gate compliance
Handoff Data	L1	Structured data for downstream sub-skills: validated prototype + findings for /ux-lean-ux; prototype reference for /ux-heuristic-eval; validated job stories for /ux-jtbd

Synthesis Judgments Summary requirements: MUST list every AI judgment (sprint question framing, sketch selection recommendations, assumption classification, pattern strength assessment, sprint question verdicts) with confidence classification (HIGH/MEDIUM/LOW) and rationale. Each judgment row includes: finding ID, framework source (e.g., Day 1 challenge framing, Day 3 assumption classification, Day 4 pattern analysis), confidence level (HIGH/MEDIUM/LOW), and rationale explaining the classification basis and evidence chain. Follows the pattern in skills/user-experience/rules/synthesis-validation.md.

Templates

Template	Path	Purpose
Design Sprint Template	skills/ux-design-sprint/templates/design-sprint-template.md	Four-day sprint artifact structure with observation grid, storyboard panels, and sprint question verdict format

---

Routing

Trigger Keywords

Keyword	Routing Context
design sprint	Direct match -- primary trigger
GV sprint	Direct match (Google Ventures sprint)
rapid prototyping	In combination with sprint/validation context
sprint week	Direct match
map sketch decide test	Direct match (sprint day names)
4-day sprint	Direct match
design sprint 2.0	Direct match (AJ&Smart format)
AJ Smart sprint	Direct match
validate prototype	In combination with sprint/user testing context
test with users	In combination with prototype/sprint context (not general usability testing)
sprint facilitation	Direct match
design sprint challenge	Direct match
sprint storyboard	In combination with sprint/prototype context

Lifecycle-Stage Routing Integration

This sub-skill is routed to by the ux-orchestrator in the following lifecycle-stage scenarios:

Stage	User Intent	Route Condition
Before design	"Need validated prototype"	Direct route to /ux-design-sprint; source: skills/user-experience/rules/ux-routing-rules.md Stage Routing Table (pending EPIC-001 completion)
Product inception	"Don't know what to build"	Wave bypass route to /ux-design-sprint; team has no existing product but needs structured exploration
Before design	Follow-up from JTBD discovery	When /ux-jtbd has produced job statements + switch forces; job statement feeds the sprint challenge definition
Any stage	"Validate a design concept quickly"	Qualification question: "Do you need a full 4-day sprint process or a quick evaluation?" -> Full sprint: /ux-design-sprint; Quick evaluation: /ux-heuristic-eval; source: skills/user-experience/rules/ux-routing-rules.md Common Intent Resolution (pending EPIC-001 completion)

Wave Gating

This sub-skill is in Wave 5 (Process Intensives). See Wave Architecture for entry criteria, bypass condition, and terminal wave status.

---

Cross-Framework Integration

Upstream Inputs

This sub-skill receives context from other sub-skills when invoked as part of a multi-sub-skill workflow:

From Sub-Skill	Handoff Artifact	Key Fields	Usage
/ux-jtbd	Job statement + switch forces	Job statement, push/pull forces, hiring criteria, anxieties, habits	JTBD job statement feeds the Day 1 challenge definition; switch forces inform sprint question formulation; hiring criteria shape the target user selection
/ux-heuristic-eval	Severity-rated findings	Finding ID, heuristic violated, severity (0-4), affected screen/flow	Heuristic findings identify specific usability problems that the sprint can address; high-severity findings (>= 3) may define the sprint challenge directly

Downstream Handoffs

This sub-skill produces artifacts that feed into other sub-skills via the Jerry handoff protocol (docs/schemas/handoff-v2.schema.json).

To Sub-Skill	Handoff Artifact	Key Fields	Trigger
/ux-lean-ux	Validated prototype + Day 4 findings	Prototype reference, validated/invalidated assumptions, sprint question verdicts, usability findings, theme strength	After Day 4 completion; Lean UX uses sprint findings to generate hypothesis backlog for iterative experimentation
/ux-heuristic-eval	Prototype for post-sprint evaluation	Prototype reference (Figma link or file path), prototype fidelity level, key interaction flows	After sprint completion; heuristic evaluation provides systematic usability audit of the sprint prototype
/ux-jtbd	Validated job stories from user interviews	Interview observation grid, user quotes, validated behaviors, job story candidates	After Day 4 interviews; user testing reveals actual jobs and switching triggers that refine JTBD job statements

Handoff data format (handoff-v2 + ux-ext):

handoff:
  from_agent: ux-sprint-facilitator
  to_agent: ux-lean-ux-experimenter
  task: "Generate Lean UX hypothesis backlog from Design Sprint findings"
  success_criteria:
    - "Hypotheses generated for each validated and invalidated sprint assumption"
    - "Experiment designs prioritize assumptions that were partially validated"
  artifacts:
    - "projects/${JERRY_PROJECT}/engagements/{engagement-id}/ux-sprint-facilitator-{topic-slug}.md"
  key_findings:
    - "Sprint verdict: {pass/fail/partial} on {N} sprint questions"
    - "Strong themes (>= 3/5 users): {theme_count} findings"
    - "Invalidated assumptions: {list}"
  blockers: []
  confidence: 0.75
  criticality: C2
  ux_ext:
    sprint_day_completed: 4
    prototype_fidelity: "{high|medium|low}"
    interview_count: 5
    theme_strength: "{strong|moderate|weak}"
    usability_findings_count: "{N}"

Canonical Multi-Skill Workflow Sequences

This sub-skill participates in the following canonical sequences:

Sequence	Skills Involved	This Sub-Skill's Role
Discovery to Sprint	/ux-jtbd then /ux-design-sprint	Receives JTBD job statement and switch forces; uses them to frame the sprint challenge and target user selection
Sprint to Iterate to Measure	/ux-design-sprint then /ux-lean-ux then /ux-heart-metrics	Produces validated prototype and Day 4 findings; Lean UX iterates on hypotheses; HEART measures validated concept
Sprint to Evaluate	/ux-design-sprint then /ux-heuristic-eval	Produces prototype for systematic usability evaluation against Nielsen's 10 heuristics

---

Synthesis Hypothesis Confidence

Design Sprint outputs include synthesis hypotheses that carry confidence classifications per the synthesis validation protocol.

Synthesis Step	Typical Confidence	Rationale
Day 4 interview thematic analysis	HIGH	Based on direct user interviews (5 users per Sprint methodology; Knapp, Zeratsky & Kowitz, 2016). Themes identified by >= 3 of 5 users meet the strong theme threshold. Direct user observation provides the highest-quality evidence available in the UX skill framework.
Day 2 sketch selection rationale	MEDIUM	Selection rationale involves subjective judgment among sprint participants. Art Museum voting provides structured input but the Decider's supervote introduces individual judgment. Rationale is documented but not empirically validated until Day 4.

Gate enforcement:

• HIGH outputs (Day 4 thematic analysis): Include "Synthesis Judgments Summary" section. User reviews output + acknowledges specific AI judgment calls before design recommendations are generated. Strong themes (>= 3 of 5 users) advance directly; moderate themes (2 of 5) require acknowledgment of lower evidence strength.
• MEDIUM outputs (sketch selection rationale): Include "Validation Required" section noting that selection rationale is validated by Day 4 testing. If Day 4 confirms the selected solution addresses user needs, confidence may be elevated to HIGH in the synthesis findings.

Note on confidence dynamics: Day 4 thematic analysis represents one of the highest-confidence synthesis sources in the entire /user-experience skill because it is based on direct user observation. When Design Sprint findings converge with findings from a second framework (e.g., /ux-heuristic-eval confirms usability issues identified in Day 4), synthesis confidence is reinforced. Day 2 sketch selection starts at MEDIUM but is validated or invalidated by Day 4 testing, creating an internal confidence progression within a single sprint.

Signal Extraction

• Signals extracted from Day 4 interview findings
• Threshold: Interview themes identified by >= 3 of 5 users
• Evidence base: Direct user observation during structured testing

---

Quality Gate Integration

Design Sprint outputs are subject to the Jerry quality gate per H-13 and H-14:

Quality Check	Threshold	Application
S-014 LLM-as-Judge scoring	>= 0.92 composite (C2+)	Applied at Phase 5 completion
Creator-critic-revision	Minimum 3 iterations (H-14)	Orchestrator manages revision cycles
Self-review (S-010)	Required before presenting	Self-review before returning to orchestrator
Wave transition gate	S-014 composite >= 0.85	Applied at Wave 4 -> 5 transition

Scoring dimensions (Design Sprint interpretation):

Dimension	Weight	Interpretation
Completeness	0.20	All four sprint days documented; all sprint questions addressed; observation grid complete for 5 users
Internal Consistency	0.20	Day 4 findings consistent with Day 3 assumptions; sprint verdicts consistent with observation grid data; handoff data consistent with findings
Methodological Rigor	0.20	AJ&Smart Design Sprint 2.0 methodology correctly applied; 4-step sketch process followed; 5-user interview target met; observation grid structured per sprint questions
Evidence Quality	0.15	Day 4 findings cite specific user observations; pattern strength based on user count threshold (>= 3 of 5); quotes and behaviors recorded per user
Actionability	0.15	Sprint verdicts clearly pass/fail/partial; next steps specific and actionable; handoff data sufficient for downstream sub-skills
Traceability	0.10	Sprint questions trace to challenge statement; findings trace to observation grid; assumptions trace to storyboard; synthesis judgments documented

CI Gate Summary

The following CI gate criteria apply to this sub-skill (full gate definitions in skills/user-experience/rules/ci-checks.md):

Gate	Check	Enforcement
No Agent tool access	disallowedTools: [Agent] present in agent frontmatter; agent MUST NOT have Agent in tools list	L5 (CI): grep agent frontmatter for Agent tool presence
P-003 forbidden action	capabilities.forbidden_actions in .governance.yaml MUST include P-003 recursive subagent prohibition	L5 (CI): schema validation of governance YAML against docs/schemas/agent-governance-v1.schema.json
Output schema validation	Agent output MUST contain all Required Output Sections (Executive Summary, Sprint Context, Day 1-4, Strategic Implications, Synthesis Judgments Summary, Handoff Data)	L4 (post-tool): section heading presence check on output artifact

---

Degraded Mode Behavior

The ux-sprint-facilitator operates at T4 (External) and has access to WebSearch, WebFetch, and Context7 MCP. Additionally, it depends on Figma (REQ) for prototype creation and Miro (REQ) for collaborative sprint activities. Both MCP dependencies are required, so degraded mode behavior is significant.

Figma MCP Unavailable

When Figma MCP is not available, prototype creation falls back to manual methods:

Limitation	Impact	Mitigation
No interactive prototype creation	Cannot build clickable Figma prototype for Day 4 testing	Guide user to create prototype manually using presentation software (Keynote, PowerPoint), paper prototyping, or an alternative prototyping tool. Adjust prototype_fidelity to medium or low.
No component inspection	Cannot reference existing design system components in prototype	Ask user to provide screenshots of existing components or describe their design system manually
Reduced prototype realism	Day 4 test results may be influenced by lower prototype fidelity	Note prototype fidelity in output; flag that findings may differ with higher-fidelity prototype per P-022

Fallback mode: Miro-only mode -- sprint exercises (journey mapping, HMW clustering, Art Museum) conducted in Miro; prototype constructed manually outside the MCP ecosystem. Per parent SKILL.md: "Miro-only mode: sprint exercises in Miro; manual prototype reference."

Miro MCP Unavailable

When Miro MCP is not available, collaborative sprint activities fall back to local-file methods:

Limitation	Impact	Mitigation
No collaborative whiteboarding	Cannot use shared Miro board for journey mapping, HMW clustering, Art Museum voting	Use markdown-based sprint boards: journey map as a structured table, HMW notes as a bulleted list, Art Museum as a ranked list with vote counts
No real-time visual collaboration	Sprint team cannot see each other's contributions simultaneously	Facilitator compiles contributions into a single markdown document; sequential rather than simultaneous input
Reduced Art Museum effectiveness	Dot voting less intuitive without visual spatial layout	Use numbered ranking instead of spatial dot voting; facilitator tabulates votes

Fallback mode: Local-file sprint boards -- all sprint artifacts produced as structured markdown documents. The methodology remains identical; only the collaboration medium changes from visual board to text-based format.

Both Figma and Miro Unavailable

When both required MCPs are unavailable, the sprint operates in fully degraded text-only mode:

Aspect	Degraded Approach
Day 1 journey map	Structured markdown table: steps, user actions, pain points, opportunities
Day 2 sketches	Text descriptions of solution concepts; user asked to sketch manually and describe
Day 3 storyboard	Numbered panel descriptions in markdown; user asked to sketch panels manually
Day 4 prototype	Paper prototype or presentation-based prototype; user constructs offline

Degraded mode disclosure (P-022):

[DEGRADED MODE] This sprint was facilitated without Figma and/or Miro MCP access.
Limitations:
- Prototype fidelity: {low|medium} (no Figma interactive prototype)
- Sprint board format: {markdown-based|text-only} (no Miro collaborative board)
- Day 4 findings may be influenced by prototype fidelity limitations
- Art Museum voting conducted via {ranked list|numbered voting} (no spatial dot voting)
Impact: Sprint methodology is fully preserved; collaboration and prototype fidelity are reduced.

No Upstream Research

When invoked without prior /ux-jtbd output or /ux-heuristic-eval findings (e.g., direct invocation for product inception), the facilitator runs Day 1 challenge definition from scratch using user-provided context and sprint team knowledge. This is a valid and common sprint entry point -- many sprints begin without prior formal research.

---

Wave Architecture

Wave 5: Process Intensives

This sub-skill is part of Wave 5 (Process Intensives), alongside /ux-ai-first-design (CONDITIONAL).

Entry criteria: Wave 4 completed -- 30+ users for Kano survey OR 1 B=MAP bottleneck diagnosed.

Bypass condition: Design Sprint can proceed without Kano prerequisite if team has existing user research. This is the most significant bypass in the wave architecture because teams at product inception have the strongest need for Design Sprint and the least ability to satisfy Wave 4 advanced analytics prerequisites. Bypass requires 3-field documentation: unmet criterion, impact assessment ("sprint proceeds without Kano feature prioritization context; team has user research from other sources"), and remediation plan with target date.

Wave transition (terminal wave): Wave 5 is the final wave. When WAVE-5-SIGNOFF.md is valid, the orchestrator enters full operational mode with all 10 sub-skills deployed.

---

Constitutional Compliance

All agents in this sub-skill adhere to the Jerry Constitution v1.0:

Principle	Requirement	Consequence of Violation
P-003	NEVER spawn recursive subagents -- worker agent, no Agent tool access	Agent hierarchy violation; uncontrolled token consumption
P-020	NEVER override the Decider's sprint decisions or user priorities on solution selection	Unauthorized action; trust erosion; sprint methodology violation (Decider authority is core to GV Sprint)
P-022	NEVER present sprint findings as certain without disclosing evidence limitations; NEVER inflate theme strength without meeting the >= 3/5 user threshold; NEVER omit degraded mode disclosure when operating without Figma or Miro	Governance undermined; quality assessment invalidated
P-001	NEVER present Day 4 findings without citing specific user observations from the interview grid	Unreliable outputs; unfounded claims propagate downstream
P-002	NEVER leave sprint artifacts in transient context only -- persist all four days of output to files	Context rot vulnerability; sprint artifacts lost on session compaction
P-004	NEVER make sprint verdict decisions without documenting the observation evidence and reasoning chain	Untraceable decisions; audit trail broken
P-011	NEVER recommend next steps without supporting evidence from Day 4 testing	Unsupported recommendations; confidence inflated without basis

Per-agent enforcement: The ux-sprint-facilitator agent declares:

• constitution.principles_applied: P-003, P-020, P-022, P-001, P-002, P-004, P-011 in skills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml
• capabilities.forbidden_actions: 3 entries in NPT-009 format referencing the constitutional triplet
• disallowedTools: [Agent] in skills/ux-design-sprint/agents/ux-sprint-facilitator.md frontmatter

AI-Facilitated Sprint Limitations

The Design Sprint facilitator agent operates as an AI-augmented facilitation tool. The following limitations apply to all outputs and MUST be disclosed per P-022 (no deception):

• Facilitation is not replacement. The agent structures and guides the sprint process but cannot replace in-person team dynamics, whiteboard collaboration, or real-time ideation energy. Teams should use the agent's structure while conducting actual sprint activities.
• Sketch descriptions are not sketches. The agent describes solution concepts in text; it cannot draw. Actual visual sketching must be performed by team members. The agent provides structured prompts and frameworks for the sketching exercises.
• User interviews require real users. The agent structures the interview protocol and observation grid but cannot conduct interviews or observe user behavior. The team must recruit and interview 5 representative users.
• Prototype construction requires human execution. The agent specifies the prototype and provides construction guidance but the actual building must be done by the team (with or without Figma). The agent can assist with content and flow decisions.
• The Decider's authority is paramount. Per Knapp et al. (2016), the Decider has final say on solution direction. The agent facilitates the decision process but never overrides the Decider's choice, even when data suggests a different direction.
• Day 4 findings depend on interview quality. The observation grid analysis is only as good as the observations recorded during interviews. Incomplete or biased observation recording degrades finding quality.

---

Registration

This sub-skill follows a parent-routed registration model per H-26. Sub-skills are routed through the parent /user-experience orchestrator; independent registration would create duplicate triggers (AP-02).

Registration Point	Status	Detail
CLAUDE.md skill table	Registered via parent	/user-experience registered; sub-skills not independently listed
mandatory-skill-usage.md trigger map	Routed via parent	"design sprint" keyword routes to parent, which dispatches here
AGENTS.md agent registry	Registered	ux-sprint-facilitator listed under User-Experience Skill Agents
Parent SKILL.md agent table	Registered	Listed in skills/user-experience/SKILL.md [Available Agents]

---

Deployment Status

Wave 5 Sub-Skill -- Phase 1 Complete, Phase 2 Pending.

This sub-skill follows a two-phase implementation sequence:

• Wave 5 Phase 1 (this deliverable): SKILL.md specification -- methodology, output format, routing integration, template stub, cross-framework integration, and quality gate criteria. This document is the Phase 1 artifact.
• Wave 5 Phase 2 (pending): Agent implementation -- skills/ux-design-sprint/agents/ux-sprint-facilitator.md (agent definition with <input>, <capabilities>, <methodology>, <output> sections) and skills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml (governance metadata). Tracked under PROJ-022 EPIC-005.

---

Quick Reference

Common Workflows

Need	Command Example
New product exploration	"We don't know what to build -- help us figure it out"
Validate redesign concept	"Run a design sprint for the checkout redesign"
Test with real users	"We need to validate our mobile navigation with 5 users"
Full 4-day sprint	"Facilitate a Design Sprint 2.0 for the dashboard feature"
Post-JTBD solution exploration	"We have our JTBD job statements -- now run a sprint to explore solutions"
Competing ideas resolution	"Our team has 3 ideas for the settings page -- which one works?"

Agent Selection Hints

Keywords	Routes To
design sprint, GV sprint, rapid prototyping, sprint week, map sketch decide test, 4-day sprint, design sprint 2.0, validate prototype, sprint facilitation	ux-sprint-facilitator
heuristic, usability, Nielsen, severity, inspection, evaluation	/ux-heuristic-eval (not this sub-skill)
JTBD, jobs to be done, switch interview, user motivation, job statement	/ux-jtbd (not this sub-skill)
lean UX, hypothesis, assumption, experiment, build-measure-learn	/ux-lean-ux (not this sub-skill)
HEART, metrics, measurement, GSM, happiness, engagement	/ux-heart-metrics (not this sub-skill)
behavior design, B=MAP, Fogg model, behavior bottleneck	/ux-behavior-design (not this sub-skill)
Kano, feature prioritization, must-be, attractive, performance	/ux-kano-model (not this sub-skill)

---

References

Source	Content	Path
Parent SKILL.md	Sub-skill scope, wave architecture, routing, MCP dependencies, synthesis protocol	skills/user-experience/SKILL.md
Agent definition	Agent frontmatter, identity, expertise, guardrails	skills/ux-design-sprint/agents/ux-sprint-facilitator.md [PLANNED]
Agent governance	Tool tier, forbidden actions, output validation, constitutional compliance	skills/ux-design-sprint/agents/ux-sprint-facilitator.governance.yaml [PLANNED]
UX routing rules	Lifecycle-stage routing, handoff data contracts, common intent resolution	skills/user-experience/rules/ux-routing-rules.md
Synthesis validation	Confidence gate protocol, per-sub-skill confidence map, signal extraction criteria	skills/user-experience/rules/synthesis-validation.md
Wave progression	Wave 5 entry criteria, signoff requirements	skills/user-experience/rules/wave-progression.md
CI checks	P-003 enforcement, sub-skill validation gates	skills/user-experience/rules/ci-checks.md
Design sprint template	Four-day sprint artifact structure, observation grid, storyboard format	skills/ux-design-sprint/templates/design-sprint-template.md
Skill standards	H-25/H-26 skill structure requirements	.context/rules/skill-standards.md
Agent development standards	H-34 dual-file architecture, tool tiers, handoff protocol	.context/rules/agent-development-standards.md
Quality enforcement	Quality gate thresholds, criticality levels, strategy catalog	.context/rules/quality-enforcement.md
Handoff schema	Canonical handoff schema v2	docs/schemas/handoff-v2.schema.json
Agent governance schema	Governance YAML validation schema	docs/schemas/agent-governance-v1.schema.json

Requirements Traceability

Source	Content	Path
PROJ-022 PLAN.md	Project plan: sub-skill scope, wave assignment, acceptance criteria, implementation phases	projects/PROJ-022-user-experience-skill/PLAN.md
EPIC-005 (Wave 5 Deployment)	Parent work item for Wave 5 sub-skill implementation including this sub-skill	PROJ-022 EPIC-005 in projects/PROJ-022-user-experience-skill/WORKTRACKER.md
ORCHESTRATION.yaml	Orchestration plan governing the build sequence for this sub-skill	projects/PROJ-022-user-experience-skill/orchestration/ux-skill-build-20260303-001/ORCHESTRATION.yaml

External References

Source	Citation
Knapp, J., Zeratsky, J., & Kowitz, B. (2016)	"Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days." Simon & Schuster. Chapter 1: sprint overview and Decider role; Chapters 2-6: Day 1 Map methodology (long-term goal, sprint questions, user journey map, HMW interviews, target selection); Chapter 7: Day 2 lightning demos; Chapter 8: four-step sketch (Notes, Ideas, Crazy 8s, Solution Sketch); Chapter 9: Art Museum voting; Chapters 10-11: Day 3 straw poll, supervote, storyboard; Chapters 12-13: Day 4 prototype construction ("Goldilocks quality"); Chapter 14: 5-user interview protocol and pattern analysis.
Courtney, J. (2019)	"The Design Sprint 2.0." AJ&Smart. Compressed four-day format: Day 1 combines GV Days 1-2 (Map + Sketch begin), Day 2 completes sketching, Day 3 combines GV Days 3-4 (Decide + Storyboard), Day 4 is GV Day 5 (Test). Adopted here as the primary sprint format for time efficiency.
Nielsen, J. (2000)	"Why You Only Need to Test with 5 Users." Nielsen Norman Group. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/ (accessed 2026-03-04). Validates 5-user interview sample size for Day 4 testing: 5 users uncover approximately 85% of usability problems.
Brown, T. (2009)	"Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation." Harper Business. Origin of the "How Might We" (HMW) technique adopted by IDEO and subsequently incorporated into the Google Ventures Sprint methodology (Knapp et al., 2016, Chapter 4).

---

Sub-Skill Version: 1.1.0 Parent Skill: /user-experience v1.0.0 Constitutional Compliance: Jerry Constitution v1.0 Wave: 5 (Process Intensives) SSOT: skills/user-experience/SKILL.md Project: PROJ-022 User Experience Skill Created: 2026-03-04