Design to code: Figma to production without rework

The best design to code workflow is one where the handover hardly feels like one. Give developers code-ready components with variants and tokens, involve engineering from the first research and sizing sessions, and let them review a working prototype instead of static screens. That keeps design and code in sync and saves the rework that comes from guessing.

This is how I do it as a senior product designer, with three examples from real projects.

Why do design handovers go wrong?

Most problems start long before the handover. Developers see the design for the first time when it is finished. Edge cases are missing, states are unclear and nobody has checked what the screens cost to build. Then a file with dozens of frames arrives and the guessing begins.

Three habits fix most of it:

• Engineering joins from research and sizing onwards, not at the end.
• Components are handed over, not screens.
• The format of the handover is a design decision, because development speed is a constraint like any other.

What does a good design to code workflow look like?

Storybook as the shared language

At NURI, a mobile banking and investing app, the handover ran through Storybook. I brought the whole Figma library up to date, with variants and design tokens, and the developers built from those components. The redesign added more than 20 new components to the system, so a shared source was not a nice to have. Without it, every new screen would have drifted. The NURI case study has the details.

React components for a fast build

At Bosch Security, I designed a platform to plan surveillance installations. Development speed was a hard constraint, so I handed over component sets from Figma as React components via Anima. The base components came from a React-ready system, which meant the time went into what was new: the map, the camera cones and the capacity matrix. Read the Bosch Security Planning case study.

Coded prototypes on the real design system

Today I go one step further. I build prototypes with Claude Code on the real design system, with tokens synced from Figma through Figma MCP. The prototype already uses the components and tokens the product will use, so the handover becomes a review. Developers see how it behaves, not only how it looks.

Tools are moving in the same direction. Claude Design, released in April 2026, can package a finished design as a handoff bundle for Claude Code.

How do you start?

1. Agree on the format early. Ask engineering what they want to receive. Figma dev mode, Storybook links and a coded prototype all work if the team chose it together.
2. Build components with variants and tokens. Name them the way developers name them.
3. Show behaviour. Hover, focus, error, loading and empty states belong in the handover.
4. Review the build together. A short review of the first implemented screen catches more than any spec.

Key takeaways

• Hand over components with variants and tokens, not screens.
• Involve engineering from research and sizing onwards.
• Treat the handover format as part of the design.
• A prototype on the real design system turns the handover into a review.

The foundation underneath is one set of design tokens. The full flow is on How I work.

Sources: Claude Design launch, VentureBeat