Most "design to code" tutorials skip the part that actually matters — the messy middle where you're tweaking spacing, swapping out colors that looked fine in your head but feel wrong on screen, and figuring out how to hand off code that engineers won't immediately reject.
We've been shipping frontend code from design directly into client repos for over 50 B2B SaaS teams. And the single biggest shift in our workflow has been designing in Claude Code instead of treating it like a code generator you throw a finished mockup at. Here's the real process — not the polished demo, but the actual back-and-forth that gets a wireframe into a reviewable pull request.
In this post, I'll walk through the full workflow I use to take a wireframe from concept to committed PR using Claude Code. We'll cover how to set up your first prompt, iterate on design decisions in real time, scope your work into PRs that engineers can actually review, and push code that follows your repo's contribution guidelines. Table of contents:
- What designing in Claude Code actually looks like
- Why this changes the designer-engineer handoff
- How to go from wireframe to pull request
- Tools and resources
What designing in Claude Code actually looks like
Designing in Claude Code means using conversation to make UI decisions — the same decisions you'd make pushing pixels, except the output is production-ready frontend code that uses your actual component library.
You're not writing code yourself. You're directing Claude Code the way you'd direct a very fast, very literal junior developer who happens to have your entire codebase memorized. You say "the messages should stick to the bottom like a traditional chat app" and it updates the layout. You say "pull the primary button component and use that styling for all buttons" and it swaps them in.
In practice, this looks like:
- Starting from a wireframe and telling Claude Code to migrate it to your design system's tokens and components
- Iterating on layout, color, spacing, and typography through natural language instead of dragging handles
- Taking screenshots of designs you like and asking Claude Code to incorporate that direction while staying within your existing brand
The key distinction is that you're not asking Claude Code to generate a design from scratch. You're designing through it — making the same judgment calls you always make, just faster and with code as the medium.
Designing in code vs. designing in Figma
When you design in Figma, you create a representation of what the product should look like. Someone else then interprets that representation and builds it. When you design in code, you're working with the real components, real tokens, and real constraints. There's no interpretation gap.
That doesn't mean Figma is dead. Wireframing, early exploration, and stakeholder reviews still happen there. But the high-fidelity design phase — where you're dialing in spacing, choosing between component variants, and making sure everything feels cohesive — that's where Claude Code takes over.
Designing in code vs. using a code generator
Code generators (v0, Bolt, etc.) take a prompt and output a finished page. Designing in Claude Code is iterative. You're going back and forth — "I don't like this gray background, make the chat white and put the gray on the messages instead" — the same way you'd iterate in any design tool. The difference is each iteration produces real, committable code.
Why this changes the designer-engineer handoff
The traditional handoff is broken in a specific way: designers produce a pixel-perfect mockup, engineers rebuild it from scratch, and then everyone argues about whether the implementation matches the design. The mockup is a communication artifact, not a building material.
When you design in Claude Code, your output isn't a mockup — it's working frontend code that uses the same components engineers use. The goal isn't to write 100% production-ready code. It's to get 80% of the way there so the engineering review is about logic and edge cases, not about "you used the wrong shade of gray."
This matters right now because most product teams are shipping faster than their design-to-dev pipeline can support. If you can hand off a PR instead of a Figma link, you've just cut days (sometimes weeks) out of the cycle.
But it requires you to learn a few engineering concepts — branches, commits, PRs, scoping. Not because you need to become an engineer, but because shipping code means speaking enough of the language to collaborate effectively.
- Faster feedback loops. You see the real UI as you design it, running in the actual product. No surprises when it gets built.
- Smaller review surface. Engineers review your code diffs, not a 40-page Figma file. Specific, scoped changes are easier to approve.
- Design decisions stay in your hands. Instead of filing a ticket and hoping the spacing comes out right, you make the call and commit it.
How to go from wireframe to pull request
This is the actual process I used to redesign an onboarding flow for Cal.com, an open source scheduling platform. The wireframe was a chat-based signup experience that my team had already approved — so I was moving from approved concept to designed, coded, PR-ready implementation.
1. Set up your first prompt with intention
Your opening prompt matters more than you think. Claude Code defaults to thinking like an engineer — it wants to build features, handle edge cases, and wire up backends. As a designer, you need to redirect that energy.
Here's the prompt structure I use:
> You are a world class product designer. I have gotten approval to move forward with this [feature]. I want to bring in all of the styles, the tokens, the components from [component library]. Help me plan out how to design this so I can hand it off and create a PR for the engineering team to review.
Three things are happening here. First, "world class product designer" shifts how Claude Code approaches the work — it thinks about UX, visual hierarchy, and cohesiveness instead of just functionality. Second, "help me plan" triggers plan mode, where Claude Code analyzes what exists before touching anything. Third, "create a PR for the engineering team" tells it to think about code organization from the start.
That last part is critical. If you don't mention PRs upfront, you'll end up with a giant blob of changes that no engineer can review.
2. Review the plan before building
Claude Code will come back with a plan — what tokens to migrate, which components to swap in, what design decisions need your input. Read it carefully.
In my Cal.com project, it proposed migrating hardcoded colors to semantic design tokens, swapping custom elements for the Cal.com component library equivalents, and using lighter animations on frequently appearing chat messages. It even flagged that switching to semantic tokens would give us dark mode support for free.
This is where you catch misunderstandings early. If the plan mentions touching backend logic, stop it. You're a designer — you want it to look good and feel good. The backend is engineering's job.
3. Iterate on design the way you normally would
This is the core of the process, and it's the part that feels most like actual design work. You're making decisions, reacting to what you see, and refining.
Here's what a real iteration session looks like:
- "The messages get lighter as they get older — that doesn't make sense for a chat. Keep them all the same color and weight."
- "The gray background feels wrong. Make the chat area white and put the gray on the message bubbles instead."
- "These buttons aren't left-aligned with the text above them. Fix that."
- "This feels outdated. Here's a screenshot of something more modern — rethink the containers and buttons to feel more like this, but stay within Cal.com's branding."
Notice what's happening: these are design decisions, not code instructions. You're not saying "change the CSS padding to 16px." You're saying "this feels off" and letting Claude Code figure out the implementation.
One practical tip: screenshots are powerful but expensive (they use a lot of tokens). For small fixes, describe the issue in words — "the caret arrows in the time fields aren't aligned correctly" — instead of attaching an image. Save screenshots for when you're communicating a whole direction shift.
4. Commit early and often
Every time you reach a state that feels like progress, commit. Think of commits like the old-school save button — they're snapshots you can return to if the next round of changes goes sideways.
I committed after the initial token migration (before I even liked the design), then again after fixing the layout and modernizing the UI. This way, if a later iteration breaks something, I can roll back to a known-good state without losing everything.
The command is simple — just tell Claude Code "let's commit this change" and it handles the git mechanics. You don't need to memorize terminal commands.
5. Scope your PRs like an engineer would
This is where most designers go wrong when they first start pushing code. The instinct is to do all your design work, then create one massive pull request with everything. I've done it — 50,000 lines of changes in a single PR. Engineers can't review that. They won't review that.
Instead, ask Claude Code to break your work into properly scoped PRs. In my project, it split the work into separate PRs:
- PR 1: Design token migration (swap hardcoded colors for semantic tokens) — ~120 lines changed
- PR 2: Layout and UI modernization (chat positioning, button styling, message formatting) — ~200 lines changed
- PR 3: Availability modal redesign (new component patterns, time picker integration) — ~180 lines changed
Each PR is 80-200 lines, well under the 500-line limit that most teams consider reviewable. Claude Code even identified dependencies — PR 1 had to land first, PR 2 depended on it, and PRs 3 and 4 could be developed in parallel.
If you've already made a bunch of changes before thinking about scope, that's fine too. Ask Claude Code: "Based on the changes I've made, what makes sense to scope as a PR?" It'll analyze what you've done and suggest logical groupings.
6. Follow your repo's contribution guidelines
Before pushing, ask Claude Code: "Is there a standard for how to push a PR from this repo's guidelines?" Most established repos have contribution docs, PR templates, naming conventions, and sometimes even JIRA card requirements.
In the Cal.com repo, there was a documented PR process — specific branch naming, description format, and review steps. Claude Code found this in the repo's documentation and followed every step automatically.
This is the kind of detail that separates a PR that gets reviewed from one that gets ignored. Engineers notice when you follow their conventions. It builds trust, and trust is what gets your design PRs merged.
7. Send it for review
Once your PR is created, send the link to your engineering team. The PR description should clearly communicate what changed, why it changed, and how to verify it — Claude Code generates all of this if you've set it up correctly in your initial prompt.
Your engineers are now reviewing actual code diffs, not interpreting a Figma file. The conversation shifts from "does this match the design?" to "does this logic make sense?" — which is a much more productive review.
Tools and resources
To get started with this workflow, you need:
- Claude Code — the CLI tool that makes all of this possible. Available as a terminal app, desktop app, or IDE extension.
- A component library — this works best when your product already has a design system or component library in code. Claude Code pulls from what exists in the repo.
- Basic git understanding — you don't need to be an expert, but understanding branches, commits, and PRs will help you communicate with Claude Code and your engineering team. (We have a [guide to GitHub for designers] if you're starting from zero.)
If your team is spending more time waiting for design handoffs than actually building, this workflow eliminates the bottleneck. At TDP, this is exactly how we work with our clients — we take approved designs, build them in code using the client's actual component library, and deliver PRs that engineering teams can review and merge. If you want help implementing this on your team, [we run workshops for exactly this, apply with this link: https://tally.so/r/WOPNPP
Want to see this workflow in action on your own product? Book a workshop with our team →https://tally.so/r/WOPNPP
