Stats
Actions
Tags
From ux-designer-skills
Design process philosophy and frameworks. When to use JTBD, Design Sprints, Double Diamond, IDEO. How to run outcome-driven design, effective critique, and recognize when process is theater. Use when planning design work, structuring discovery, or choosing the right level of rigor for the problem.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ux-designer-skills:design-processThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design process exists for one reason: to produce artifacts that change conversations. Not to follow steps. Not to fill Confluence pages. Not to make stakeholders feel like "the process was followed."
Design process exists for one reason: to produce artifacts that change conversations. Not to follow steps. Not to fill Confluence pages. Not to make stakeholders feel like "the process was followed."
The artifact ends the debate. A prototype beats a slide deck. A research doc with a recommendation beats a readout with no opinion. A brief that frames three jobs to be done beats a kickoff meeting where everyone nods along and leaves confused.
If your process isn't producing things that move decisions forward, it's not a process. It's a performance.
This comes first because it's the foundation. Every other framework is downstream of understanding what job the user is hiring your product to do.
People don't buy products. They hire them. And every job has three dimensions:
Job statement format:
"When [situation], I want to [motivation], so I can [expected outcome]."
When it matters: Always. JTBD should be in every brief, every PRD, every design review. If you can't articulate the job, you're not ready to design. When I wrote the Collections Redesign brief, the entire thing organized around three jobs to be done. That's how you keep a team aligned on what matters and prevent scope creep disguised as "good ideas."
When it's overhead: Never. If someone tells you JTBD is too heavy for the project, the project probably isn't worth doing.
Strategyn reports teams using JTBD achieve an 86% innovation success rate. That's not because the framework is magic. It's because it forces you to validate the problem before falling in love with a solution.
Impact > Outcome > Output
This hierarchy matters because most teams skip straight to output. "We need a new search page." Why? "Because the old one is bad." That's not a reason. That's a feeling.
Every design surface maps to a business outcome. If it doesn't, question whether it should exist. Every review should start with: "What outcome are we driving?" not "What are we building?"
An output is what you ship. An outcome is the behavior you change. An impact is the number that moves. Design for the impact. Measure the outcome. Ship the output.
The best framework for when you need to answer a big question fast and you don't have months to figure it out.
| Day | Focus | Key Activity |
|---|---|---|
| Monday | Understand | Set long-term goal, map the challenge, pick a target |
| Tuesday | Diverge | Individual sketching. No group brainstorming. |
| Wednesday | Decide | Silent critique, dot voting, storyboard the winner |
| Thursday | Prototype | Build a realistic facade in one day |
| Friday | Validate | Interview 5 customers using the prototype |
When it matters: High-stakes decisions with real ambiguity. New product directions. Major redesigns. Moments where the team is going in circles and needs a forcing function. The no-group-brainstorming rule is the best part. Individual sketching kills groupthink. Silent critique (Wednesday) is how you get honest signal instead of whoever-talks-loudest-wins.
When it's overhead: Small iterations on existing features. Bug fixes. Anything where the problem is already well-defined and you just need to execute. Running a 5-day sprint to redesign a settings page is cosplaying as a startup.
Two phases: figure out the right problem, then figure out the right solution.
Diamond 1, Problem Space:
Diamond 2, Solution Space:
When it matters: Projects where you genuinely don't know what the problem is yet. Discovery work. New market entry. When leadership says "our users are unhappy" but can't tell you why.
When it's overhead: When the problem is already validated. If you have data showing organic users convert at 4% and paid users at 1.7%, you don't need to "discover" the problem. You need to fix the onboarding for paid users. Skipping straight to Diamond 2 is fine. The framework is a tool, not a religion.
When it matters: Teaching junior designers how to think. Workshops with non-design stakeholders who need a shared vocabulary. It's a good mental model for someone who's never done design work before.
When it's overhead: For experienced teams, this is training wheels. You don't need to label each phase. You already do this intuitively. If your team is spending time arguing about whether they're in "Ideate" or "Prototype," you've confused the map for the territory. Just make things and test them.
Critique is not a meeting format. It's a culture of producing better work through structured, honest feedback. The goal of critique is artifacts, not discussion. If a critique session ends with "great discussion" and no clear next steps, it failed.
Here's the thing nobody wants to say: most design process is theater. It's performative rigor that substitutes for actually making things.
Signs your process has become theater:
The fix is simple: ask "what decision does this activity produce?" If you can't answer that, skip it. Make the thing. Test the thing. Ship the thing.
Process serves the work. The moment it's the other way around, you've lost the plot.
design-critique - Structured critique framework for reviewing specific designsusability-testing - Testing methodologyux-metrics - Measuring outcomesCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub trevorgrogers/ux-designer-skills