The problem
The design-to-code handoff has always been structurally difficult. Design and engineering occupy two separate systems trying to stay synchronized. Better tooling manages the symptom. Tokens, Storybook, and component documentation make communication clearer, but they don't address the cause: the output of design and the output of engineering are still two separate artifacts. Keeping them aligned takes constant effort that chips away at fidelity over time.
I'd spent years watching teams fight this with stricter documentation, more detailed specs, automated snapshots. None of it stopped the drift. The problem wasn't clarity or communication. It was that design and engineering were working from different sources of truth, and that difference was baked into the system.
The insight
What shifted my thinking was a simple question: what if design started from the same foundation engineers already use, rather than asking engineers to adopt a design-centric platform? Production teams build with open-source component libraries. They have codebases, dependencies, version control. They're not leaving that for a visual builder.
Shadcn/ui is already in thousands of production codebases, designed as a starting point rather than a destination. Grounding the design system there meant design and engineering could begin from the same structural foundation. Not the same tool: the same underlying component architecture. That distinction mattered more than I expected.
Key decisions
Ground the design system in shadcn/ui, not a separate design tool
The traditional model: build the system in Figma, then ask engineers to implement it. Instead, I let the design system emerge from the component architecture engineers already ship. Parity is no longer aspirational: it's built in. When I design a button, it's not a Figma interpretation of a button; it's the actual button engineers will build from.
The tradeoffSome component behavior is set by shadcn's base structure and can't be redesigned from scratch. What I gain is a design system that stays in sync with the codebase by default: brand, sizing, type, spacing, and states all remain fully mine.
Use Claude as a collaborator on demand, not a replacement for design
I love design and problem-solving; I take pride in pixel-perfect, tight work. This workflow doesn't replace the design process. It supercharges it. The exploratory divergence you normally get from a workshop (days of coordination, the right people in a room) Claude delivers on demand: competitive research, inspiration pulls, and 6+ exploratory hi-fidelity directions with the intent behind each one. In minutes.
What I do next is where the collaboration lives: I review, direct, and adjust, and I change the designs myself. Because outputs arrive design-system-compliant, I start at 50% or more instead of lo-fi sketches. Claude handles the mechanical side of exploration. I keep judgment, strategy, and craft.
"Kick out 3 options for me to review. But before you do any design, scrape the internet and analyze what competitors and competitor-adjacent companies are doing. Review some of the most beautiful dashboard designs. Then when you're ready to create those layouts, give me the intent behind each design option."
My actual prompt: research first, intent required, judgment reserved
Plan for bidirectional Figma while the landscape was still shifting
I built the workflow on the official Figma MCP, which was originally read-only: Claude reads my styles, tokens, and components, and generates code with structural fidelity. I was preparing to add write-back through a third-party tool when Figma shipped official write access to the canvas (the use_figma tool, March 2026), a week before I would have wired it myself.
Why it mattersIt validated the direction I was anticipating. The loop is no longer read-only by default: design intent and code output can now feed each other directly.
The solution
The workflow starts with intent, not pixels. I describe what a dashboard needs to accomplish: the jobs the user is completing, the mental model they bring. Claude researches what's working elsewhere, then returns 3–6 fully realized layout directions: Figma components, token-driven styling, and the design logic explained. I pick what's right directionally, direct adjustments, and iterate.
The design system itself lives in two places that are structurally aligned: Figma as the visual reference, shadcn/ui as the code foundation. Changes to either ripple across both, not because I maintain the sync, but because they're expressions of the same underlying structure. A brand color change in the system appears in code automatically. There's no translation layer left to decay.
The outcomes
The deeper outcome is that design and code are no longer ships passing in the night. I start design from the assumption of alignment instead of managing it as ongoing effort. That changes what I can ask design to do, and it opens space to focus on the problems that require human judgment instead of the friction of synchronization.
What I took from this
Tools shape what's possible to think. When design and code live in the same system, you optimize for alignment early instead of patching misalignment late.
The collaboration works best when AI handles what's genuinely mechanical and I handle what requires judgment, and the foundation you choose often determines more about the outcome than the skill applied on top of it.