From Figma to Production: Why Design Systems Break at the Engineering Handoff
Design systems usually look perfect in Figma and fall apart in code. Here's where the breakdown happens and how to design for the handoff from day one.
Table of contents +
Design systems have a peculiar failure mode. They look immaculate in Figma. The components are named, the tokens are organized, the variants are exhaustive. Then the production codebase drifts. Six months in, the buttons in the app look slightly different from the buttons in the design file, and nobody can explain why.
This is not a discipline problem. It’s a structural problem. The seam between design and engineering is where the system fails, and the fix is to design for that seam from the start.
Where the system actually breaks
There are five recurring places where design systems break in production:
- Tokens get translated, not transmitted. A designer changes a color in Figma. An engineer eventually catches it and updates a Sass variable. By the time it reaches production, the original intent is mediated through two translations and at least one ticket.
- Components have invisible variants. The button in Figma has five states. The button in code has seven, because someone needed an icon-only variant and added it without going back to the design system.
- Layout primitives are missing. The system has a Button component but no Stack or Grid. Every page reinvents spacing. The system is detailed at the component level and absent at the layout level.
- Accessibility is a docs section, not a default. ARIA roles, focus states, and keyboard navigation are documented somewhere. The code defaults don’t enforce them.
- There’s no source of truth for “shipped.” The Figma file shows the design system. The Storybook shows the component library. The production app shows what’s actually there. The three don’t always agree.
Design tokens, transmitted not translated
The single biggest leverage point is design tokens that are pipeline-fed, not hand-translated. The pattern that has held up:
- Tokens live in a single source (a JSON file, a Figma Variables export, a tokens package)
- A build step converts them to whatever each platform consumes: CSS custom properties for web, Swift constants for iOS, etc.
- Figma reads from the same source via the Variables feature
When the designer updates a color, every consumer updates. No ticket. No translation. The drift problem mostly dissolves at this layer.
Component contracts, not component appearances
A button in a design system is not a visual artifact. It is a contract: it does this thing, it accepts these props, it behaves this way under these states. Designing the component starts with the contract.
The contract is what engineering implements. The visual is one expression of the contract. The Figma file documents the visual; the code implements the contract; the Storybook (or equivalent) demonstrates the implementation against the contract.
What changes in practice:
- Component specs name props, not appearances (“variant: primary, destructive” not “the red button”)
- Edge states are designed (loading, empty, error, disabled), not just the happy state
- A11y is part of the spec, not a follow-up
The handoff that doesn’t happen
The phrase “design handoff” is itself the problem. It implies a moment, a meeting, a Figma share link, and a thrown-over-the-wall transaction. Systems that hold up replace the handoff with a shared workflow:
- Designers and engineers work on the same components in the same review cadence
- Component additions go through both a design review and a code review, in either order
- The system is updated together, not separately
This sounds soft. It is not. The teams that ship the most durable design systems treat them as a product the design and engineering team co-own, with explicit roles for maintenance, versioning, and breaking changes.
A practical starter set
If you’re starting or rebuilding a design system, the order of operations we’d recommend:
- Tokens first. Colors, type scale, spacing, radius, motion. Get them into a pipeline. Defer everything else until this is done.
- Layout primitives second. Stack, Grid, Box, Container. The components that make every other component possible.
- Atomic components third. Button, Input, Select, Checkbox. Each with its full set of states and a11y baked in.
- Composed components fourth. Card, Modal, Form, Table. Built from the atomic ones.
- Patterns last. Specific layouts for specific page types. Built from the composed ones.
Most systems get started in reverse order, beginning with the page that’s due Tuesday, and never get back to the foundation.
Where this connects to our work
A meaningful portion of the work we ship is exactly this: rebuilding the system layer underneath a product that’s drifting. Design and engineering on the same team, shipping the system as a single deliverable. Examples include the platform work across Akash, Arbitrum Hub, and others.
If you’re staring at a design system that looks great in Figma and feels broken in production, that gap has a known shape. Schedule a call and we’ll talk through it.
Key takeaways
- Design tokens should be pipeline-fed from a single source, not translated by hand into a Sass variable via a ticket.
- Specify components as contracts (props, states, behavior), not appearances ('variant: destructive', not 'the red button').
- Build the system bottom-up: tokens, layout primitives, atomic components, composed components, patterns, most teams build in reverse.
- The 'handoff' framing is the problem, replace it with shared review cadence where design and engineering co-own the system.
- Accessibility belongs in defaults and contracts, not in a documentation section the team can skip.
Frequently asked
Why do design systems break between Figma and production? +
Five recurring failures: tokens get hand-translated instead of pipeline-fed, components grow invisible variants that never go back to the design file, layout primitives like Stack and Grid are missing so every page reinvents spacing, accessibility lives in docs instead of defaults, and there is no single source of truth across Figma, Storybook, and the production app.
What are design tokens and how should they flow? +
Design tokens are the atomic values of a design system, colors, type scale, spacing, radius, motion. They should live in a single source (JSON file, Figma Variables export, tokens package), with a build step converting them to CSS custom properties for web, Swift constants for iOS, and so on. Figma reads from the same source via Variables. When a designer updates a color, every consumer updates automatically, no ticket, no drift.
What order should I build a design system in? +
Tokens first (colors, type, spacing, radius, motion), then layout primitives (Stack, Grid, Box, Container), then atomic components (Button, Input, Select), then composed components (Card, Modal, Form, Table), then patterns last. Most teams build in reverse, starting with the page that's due Tuesday, and never get back to the foundation.
How should design and engineering collaborate on a design system? +
Replace the 'handoff' framing with a shared workflow: designers and engineers work on the same components in the same review cadence, component additions go through both a design review and a code review in either order, and the system is updated together rather than separately. Treat the design system as a product the two teams co-own, with explicit roles for maintenance, versioning, and breaking changes.