This is the "how", not the "why". It assumes you've read the derivation document and accepted its conclusions.
Overview
Five phases. Each with a different goal, prompt structure, and exit criteria.
The workflow runs Phase 0 through Phase 4 in sequence. Each phase has a different goal, a different prompt structure, and a different definition of "done". Skipping phases produces worse results than doing them sequentially — not because of ritual, but because each phase loads context that the next phase needs to operate well.
The single most common failure mode is skipping Phase 0 to jump directly into prototyping. It produces output that is technically correct but strategically wrong — and wastes every review cycle that follows.
Pre-flight
Select the right CLAUDE.md. Once per project, not per session.
Before any design work starts, load the correct constraint file for the project type. This is a one-time decision made at the project kickoff, not something you revisit each session. The constraint file tells Claude which design system to use, which component vocabulary to stay within, which patterns are established, and which rules are non-negotiable.
Different project types need different constraint files. An app home redesign for Shopify merchants requires a different constraint set than a checkout flow or an admin tool. Loading the wrong constraint file doesn't just produce stylistic mismatches — it produces structurally incompatible output that has to be rebuilt, not adjusted. Getting this right before Phase 0 saves more time than any other single decision in the workflow.
A weak Phase 0 produces "correct but useless" output in every phase that follows.
Phase 0 · Intent Framing
Give Claude enough business context to become a thinking partner, not a pixel machine.
This is the most important phase. The goal is not to describe what you want to build — it's to give Claude enough context about why it matters that it can push back on weak decisions, flag missing considerations, and generate structurally sound options rather than just executing instructions.
A complete Phase 0 prompt includes: the business context and user problem, the constraints that aren't negotiable, what success looks like in measurable terms, and what you already know shouldn't work. Don't start with "build me a UI for X." Start with what job the user is trying to do, what's failing today, what the business needs to be true after this ships, and what edge cases you already know exist. The more business context Claude receives upfront, the less correction you'll need across all subsequent phases.
Phase 1 · Discovery and Research
Claude shifts from receiving context to generating insight.
Phase 1 is where the prompt structure changes from long context dumps to targeted questions. Claude now has enough information to generate useful hypotheses, identify gaps, and surface patterns from comparable products or design precedents.
Use this phase to pressure-test your problem framing, not to validate conclusions you've already reached. Ask Claude to steelman the opposite approach, identify the assumptions in your brief that are most likely to be wrong, and surface what similar products have tried and where they've struggled. The output of Phase 1 is a sharpened problem statement and a set of design hypotheses — not wireframes or layouts.
Phase 2 · Prototype and Explore
Constraint lists replace questions. Code generation starts here.
This is where code generation starts. The prompt structure shifts from questions to constraint lists. Instead of describing what you want in natural language, provide Claude with a structured list of requirements: component constraints, interaction behaviors, state coverage, edge cases to handle, and what not to do.
Start with Claude Artifacts for direction validation — they render instantly and let you evaluate structural decisions before committing to production-intent code. Once the direction is clear, switch to Claude Code for production-intent prototyping. The Artifact's code can serve as the blueprint; approximately 90% of the design intent transfers. Use the five natural language techniques from the derivation document to handle refinement: CSS property names for pixel work, screenshot annotations instead of verbal descriptions, batched modifications rather than one-at-a-time iteration.
Phase 3 · Review and Decide
Claude generates the review materials. You don't need a separate deck.
The prototype exists. Now it needs stakeholder approval. Claude generates the review materials directly — a flow walkthrough artifact showing the complete path at a glance, with each step displaying a simplified screen preview alongside its design rationale, success metric, and risk flags. Reviewers see global flow visibility and per-step decision context in a single artifact, always in sync with the actual prototype.
This replaces the separately-maintained Figma review deck that inevitably diverges from the prototype as it evolves. The review artifact is generated from the same source as the prototype, so it can't drift. Use Phase 3 to collect structured decisions — approval with specific conditions, rejection with specific reasons — not general feedback. Exit criteria: a written decision that unambiguously determines whether Phase 4 can begin.
Phase 4 · Blueprint and Ship
The approved prototype becomes production code. Demo quality becomes ship quality.
This is the second quality gate — where the approved prototype is converted to production-intent code. The Artifact or Claude Code prototype serves as the blueprint. Claude Code rebuilds it with proper routing, state management, component splitting, and accessibility coverage. The 10% that doesn't transfer automatically is the engineering adaptation layer — this is expected and scoped.
Use Phase 4 to resolve edge cases that weren't visible in the prototype, document component behavior for handoff, and confirm that the design system constraints from the CLAUDE.md file have been honored throughout. The measure of Phase 4 quality is not whether the code is clean — it's whether the shipped experience matches the reviewed prototype's intent.
Continuous Improvement
The CLAUDE.md file is the compound interest mechanism.
The constraint file is a living document. Every time Claude makes a mistake you correct, that correction belongs in the constraint file — not just the fix in the code. Every time a component pattern emerges across two or more projects, it belongs in the constraint file. Every time a review surfaces a class of decisions that shouldn't require human review, the decision rule belongs in the constraint file.
After three to four projects, Claude's first-attempt output quality should be high enough that Phase 2 takes hours, not days. The CLAUDE.md file compounds: each project makes the next one faster, and the productivity gap between the Claude-only workflow and the traditional multi-tool pipeline widens over time — not from the tools getting better, but from the constraint file accumulating institutional knowledge that would otherwise live only in the designer's head.
Metrics
Four signals that tell you whether the workflow is actually working.
Cycle time from intent to reviewed prototype: should compress consistently after the first two projects as the CLAUDE.md file matures. Review cycle count: if you're averaging more than two review cycles per phase, Phase 0 intent framing is the problem — the brief wasn't specific enough. First-attempt structural accuracy: how often does Claude's first prototype response require structural rework versus surface refinement? If structural rework is frequent, the constraint file is missing pattern rules. Artifact-to-production transfer rate: tracking how much of each Artifact is rebuilt from scratch in Phase 4 tells you whether Artifacts are being used for direction validation (correct) or as production-intent deliverables (incorrect).
Companion
The derivation document explains why this workflow is justified.
This document is the how. The reasoning chain that justifies each decision — why the Claude-only stack covers 95% of design-to-prototype work, why Figma has zero truly irreplaceable capabilities in the pre-production workflow, and why the natural language efficiency problem is structural rather than a prompting skill issue — lives in the companion derivation record. Read the full derivation →
Sequencing is the discipline. Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4. The workflow doesn't shortcut — it front-loads.
