Back to all posts

The State of Design Handoff

March 8, 2026 · 7 min read

Claude Code-to-Figma announcement

Design handoff has always been one of the weakest links between designers and developers. When Figma announced a two-way integration with Claude Code, I was hopeful that the design handoff gap had finally been closed. After looking closer, it became clear the gap still isn't fully closed. Getting a design into Figma from Claude Code still breaks important context. Code structure, tokens, and component relationships do not map cleanly to Figma concepts such as colors, typography, and components.

A little over a month earlier, Mark Anthony Cianfrani had already shown a better approach as a proof of concept. It enables Claude Code to work in Figma through Chrome DevTools and Chrome. The downside is that it gives Claude Code access to the browser environment. That creates risks similar to what people discussed with Clawdbot/OpenClaw. This is because the access is not fully encapsulated.

A week ago, GPT-5.4 was also released with the ability to use the computer and the ability to understand design from images more accurately. So it is much closer to Clawdbot/OpenClaw now and might rival Claude Code flows.

The core problem is that design tools and production code still operate on different abstractions.

Why Design Handoff Still Fails

I'll take a small step back here and talk about where I think the problem lies. This is especially true now, where AI speeds up the product development process significantly. Design handoff still follows a waterfall structure: design finishes first, then development starts. This often creates a blocker for developers when design isn't fully realized but the PM already wants things to move forward. This creates unnecessary tension in the whole process and makes the whole system very iterative and often costly. Mistakes creep in and need to be polished — often much later. This designer-developer loop usually runs within an agile project structure and eventually — fingers crossed — reaches the end.

Design-to-Code

This is still much better than what we had. The design handoff was and still is all about documentation, communication, and iteration. I don't know if you are familiar with Anima or Builder.io, but they built some of the best Figma plugins that provided Design-to-Code functionality to Figma before AI. They had their use case at times but managed to fumble with code in so many ways it was almost comical. For a non-coder they had more utility as you were able to use that code to bring your designs to life. For a designer handoff to an actual developer they just didn't work.

In practice the output was rarely usable. You ended up with frames within frames and an endless mess of divs and hardcoded values. This is what you get when you overvalue coders and undervalue designers. Any designer worth his salt could have told you that this is not what is needed. Same goes for the developers I guess. Whoever made this had neither in their team? I think I might not be the client.

The Usual AI Builders

What is useful are the new tools that have emerged. I really like some that I will mention below.

You know the top tools: Lovable, v0, Replit, and Bolt.new.

They can generate working apps quickly and even allow some design interaction.

Tools Closer to the Design-Code Bridge

The more interesting tools are those trying to close the gap between design and code.

Honorable mentions:

  • Pencil.dev - I really like their plugin, I can just add to the IDE so I can also tell Claude to either work on the design or the code and then implement either one or the other. Not yet sure if this is the way forward as it is using a new filetype but it has some very good parts.
  • Paper.design (I know, it seems like it is branded by the same people) - Similar in many ways. They don't have plugins but enable editing the designs for the final polish (this is what designers crave… or was it Brawndo?).
  • Subframe - it requires design context and you can also sync your code so matching design to code or other way around is built in and accessible.
  • Magic Patterns - has similar core features to previous mentions and their team also actively shares experiments and ideas with the community.

A different approach altogether brought to you by Drew Minns and CoralUI as a translation layer. This is needed if we want to translate designs to code properly.

Figma also has Code Connect so it can match components and actual code, but it is only available for Enterprise accounts.

The Holy Grail

A good middle-ground option has been Storybook which shows the actual components but doesn't enable editing.

At current pace I don't think Figma is the answer. It wasn't built on web standards and needs a translation layer to be useful and accurate in code. They do have some features and a community behind them that competitors need to catch up on but it is not a moat anymore.

If design and development are going to Converge(™), the ideal tool would have a few properties:

  • Enable designers to edit production code components. This can be a layer away from production but shouldn't lose any detail or context when translated to production code.
  • Have their changes translated to PRs or something similar within git. Maybe a new git-like operation is needed?
  • Developer in the loop so nothing breaks when pushed to live. The developer is still responsible for the code.

What if we had a tool that enables designers and developers to work in the same environment at the same time without it being… weird? I am thinking about a system that can generate production code while still letting designers "vibe-code" safely. I hope I am allowed to say that, as designers, we don't really want to use git that much. We want to spend our time on spacing and work with design systems. What if the tool we use translates all that into simpler language for designers and adds guardrails to the environment so we can't really break anything. Our Save can work as a PR or maybe not exactly. Whatever it is, it shouldn't be as complicated technically and be as close to development code as possible. Some of the tools already prove this can be possible.

A good example

Coming back to the present.

Magic Patterns co-founder Teddy Ni gave a good real world example on how to use AI well in its current form:

(paraphrased)

  • Add context to your components on when and how to use them.
  • Add patterns from your code how you use those components together.
  • Create skills for AI to understand how to create components using your tokens and context and make AI write documentation and Storybook stories for them.
  • Connect everything in an MCP server so you can brainstorm, prototype or code with your preferred tools without losing context.

(removed Tailwind suggestion as it is too specific)

All this is currently necessary to get the most out of AI. There are also other ways to achieve this so let me know if any of this is useful and I will make a new post about all the ways I can find.

Conclusion

What AI companies and Figma have put out is not completely there yet. All the stacks people use to design and build have their caveats… for now. I am hopeful that this changes in the future and we can move on from this broken process between designer and developer that enables so much confusion and conflict. There are new solutions popping up for this every day — even every hour. The design-to-development gap is shrinking quickly. AI is forcing tools to converge around the same problem: translating design intent into production code without losing context.

The solution may not come from Figma alone. It will likely emerge from tools that allow designers and developers to work directly on the same system of components and code. Who will prevail is another question. There might also be open-source alternatives at that point. I am also conceptualizing and prototyping a way to address this and I will be publishing this in the near future. So stay tuned and stay hopeful.