The designer-developer workflow with Claude Code that actually ships

Most teams bolt Claude Code onto an existing process and wonder why it underperforms. The designer-developer workflow with Claude Code breaks down not because Claude can't code. It's because the handoff is a mess. Vague specs, missing design context, sessions that spiral into stale state. The AI isn't the bottleneck. The protocol around it is.

Here's my exact process.

The context problem nobody talks about

Claude starts degrading your session quality at 20-40% of its context window. Not at the end, at the beginning third. The attention mechanism down-weights older instructions as new content accumulates. By the time you're three implementation cycles deep, Claude is operating on a blurred version of your original spec.

Auto-compaction kicks in around 83.5% of the context window and retains roughly 20-30% of session details. Which means if you've been pumping your Figma specs, edge cases, and design decisions into a single long session, most of that context is gone before you realize it.

This matters because most people treat a coding session as one long thread. They start with the design brief, iterate, correct, expand. By hour two, they're not debugging a Claude problem. They're debugging a context problem. The AI is doing its best with half the information it started with.

The fix isn't a bigger CLAUDE.md. I've tried that. Everyone who recommends a 500-line CLAUDE.md has either never hit the limit or hasn't noticed when it stops working. Summary docs have the same issue: tedious to maintain and they don't actually survive context compaction the way you expect. I burned a full afternoon learning this on a recent project before I stopped fighting the tool and changed the process.

The fix is treating context as perishable. Each task gets a fresh conversation.

Structuring the designer-developer workflow with Claude Code

My pipeline has three distinct gates before any code gets written.

The Figma-to-code protocol that actually works

When a new screen lands in my inbox, I don't open my editor. I run a skill.

I wrote this Claude Code skill once. It walks me through every phase of turning a Figma design into production code - and the first thing it does isn't write code. It builds context.

Phase 1: Discovery

The skill walks through the Figma designs and produces a design registry - a markdown file with one row per component to implement. Frame name, Figma URL, description, state (new / refines existing / replaces), status. Claude builds this. Not me.

Then decomposition: each design gets broken into atoms, molecules, and templates. The skill maps the structure, identifies which pieces already exist in the codebase, and notes what they replace. By the end of this phase, Claude knows what needs to be built, what already exists, and how they relate - without touching a single file in the app.

This matters more than it sounds. If you hand Claude a Figma link and say "implement this screen," it will try to hold the entire design in context while also reading your codebase, mapping the data, and writing code. It will drift. It will make assumptions. It will break. The discovery phase exists to prevent that - all the expensive Figma calls happen once, upfront, and the output is a set of structured files Claude can reference cleanly for the rest of the work.

Phase 2: Storybook first

Each component gets implemented in Storybook before it touches the app. This is deliberate. The goal at this stage is purely visual: pixel-perfect match with the Figma design, no business logic, no data connections.

Claude implements the component, then opens Playwright and compares the Storybook render against the Figma frame. If it matches, we move on. If it doesn't, we fix it before going further. Catching visual issues here costs almost nothing. Catching them after you've wired up state management and API calls costs a lot.

Phase 3: Integration

Once the component passes in Storybook, it goes into the app. The scope is narrow on purpose: how does this component talk to the rest of the application? Which props does it receive? Which callbacks does it expose? Which actions do its buttons trigger?

Nothing else. No new logic. No new data fetching. The component is done - this phase is just the connection layer.

Splitting "build the component" and "integrate the component" into two separate tasks is what makes this scalable. Do them at the same time and you're debugging visual inconsistencies and state bugs simultaneously. Keep them separate and each step has one failure mode.

Everything runs in a loop

The whole thing runs in a Ralph Loop - Claude works through the registry autonomously, component by component. When it's done, it gives me a recap: what was implemented, what was validated, what still needs human review. Then I test.

It's not faster because Claude is smarter. It's faster because the protocol removes the conditions under which Claude breaks.

Gate 2: Plan mode as a checkpoint, not a green light.

I run Claude in plan mode for anything non-trivial. But plan mode gives you a starting point, not complete instructions. Edge cases emerge during implementation. Ambiguous specs become visible when Claude tries to interpret them. I treat plan mode output as a structured draft I'll correct in review, not a ticket to walk away.

The rule I follow: if Claude fails the same thing twice, I don't correct a third time. I do /clear, rewrite the initial prompt with what I've learned, and start fresh. This is the official Anthropic recommendation and it's correct. Correcting in a polluted context is almost always slower than starting over with a cleaner brief. The sunk-cost instinct will tell you to push through. Ignore it.

If you're trying to set up this kind of workflow on your own codebase, that's exactly what I help teams with, reach out.

What stays human

People keep asking which parts of this can be "fully delegated." The answer is: fewer than the pitch material suggests.

What I delegate to Claude Code: implementation of clearly-specced components, repetitive UI patterns, state wiring when the data model is stable, test generation for defined behavior, refactoring when the target state is explicit.

What I keep: every UX decision where the spec is ambiguous. Architecture choices when multiple valid approaches exist. Judgment on whether Claude's output coheres with the rest of the product, not just the component in isolation, but the whole visual system at page level. The decision to push vs. iterate.

The principle I keep coming back to: humans design the diagnostic templates, AI handles execution. It's not about what Claude can do. It's about what requires the reasoning that comes from shipping this specific product for months. That reasoning doesn't live in a prompt. It lives in whoever owns the product.

There's also a category of judgment that's invisible until it surfaces in QA. A component that passes review in isolation but breaks the visual hierarchy at page scale. A pattern that works in the happy path but creates a confusing mental model for the user. Claude will not catch this unless you give it enough context to evaluate it, and I almost never want to pay that context cost. It's faster to review the output myself and call it.

The teams I see struggle most are the ones trying to remove themselves entirely from the loop. That's not agentic coding. That's wishful delegation. The goal is precision, not absence.

The discipline, not the tool

The mistake I see most often: treating Claude Code as a faster version of the existing process. It isn't. It's a different process with different failure modes.

The existing process fails at implementation speed. Claude Code fails at context integrity and scope creep. If you don't actively manage what goes into each session, you end up with a confident AI producing subtly wrong output. The errors compound faster than with manual coding because iteration speed is higher. Velocity without discipline creates debt at a different scale.

What works is treating every implementation session as a small, bounded contract: here's the spec, here's the target file, here's the behavior. Ship this. Done. Next contract.

That discipline, scoped context, fresh starts, human checkpoints at the right moments, is what makes the designer-developer workflow with Claude Code actually replicable across a team. Not the tool configuration. The protocol around it.

---

If your team is losing hours in design-to-code handoffs, this workflow is transferable. I consult on exactly this. Let's talk.