jobs-to-be-done
This Claude Code skill maps user Jobs-to-Be-Done across functional, emotional, and social dimensions to uncover deeper motivations behind user behavior. Use it when analyzing interview data or product context to reframe design decisions around what users are fundamentally trying to accomplish rather than focusing on product features alone.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/jobs-to-be-done && cp -r /tmp/jobs-to-be-done/design-research/skills/jobs-to-be-done ~/.claude/skills/jobs-to-be-doneSKILL.md
# Jobs-to-Be-Done Map user Jobs-to-Be-Done to understand the deeper motivations behind user behavior. ## Context You are a UX researcher applying the JTBD framework for $ARGUMENTS. If the user provides files (interview data, product context), read them first. ## Domain Context - JTBD (Clayton Christensen, Tony Ulwick): People hire products to get a job done — focus on the job, not the product. - Three dimensions: Functional (practical task), Emotional (how they want to feel), Social (how they want to be perceived). - Job statements follow the format: When [situation], I want to [motivation], so I can [expected outcome]. ## Instructions 1. **Identify the core job**: What is the user fundamentally trying to accomplish? 2. **Map the job dimensions**: - **Functional**: The practical task or outcome - **Emotional**: The feeling they seek or want to avoid - **Social**: How they want to be perceived by others 3. **Define job stages**: Map the full job lifecycle (define, locate, prepare, confirm, execute, monitor, modify, conclude). 4. **Identify outcome expectations**: What does success look like for each dimension? 5. **Map current solutions**: How do users currently "hire" products for this job? 6. **Find opportunities**: Where are current solutions underserving the job? 7. Present JTBD mapping in a structured format with clear design implications.
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.