My Figma to Code Workflow

The Gap Between Design and Code

The handoff between design and development is where good intentions go to die. A pixel-perfect Figma mockup lands in the developer's lap, and somehow the shipped product looks... off. Spacing is wrong, colors are approximated, and interactions are left to interpretation.

Over the years, I have refined a workflow that minimizes this gap. It is not about fancy tools or automation — it is about setting up Figma the right way and communicating with precision.

Setting Up Figma for Developers

The foundation of a clean handoff starts long before anyone inspects a frame.

Auto-Layout Everywhere

I use auto-layout on virtually every frame. This is non-negotiable. Auto-layout communicates the same mental model that CSS flexbox and grid use — direction, gap, padding, alignment. When a developer inspects an auto-layout frame, they see values that translate directly to code.

A frame with manually positioned elements tells the developer nothing about how the layout should respond to content changes. Auto-layout tells them everything.

Components and Variants

Every repeated element is a component. Every state is a variant. I structure component properties to mirror what will become React props:

• Variant property for visual style (primary, secondary, ghost)
• Size property for dimensional variants (sm, md, lg)
• State property for interaction states (default, hover, focus, disabled)
• Boolean properties for toggleable features (showIcon, showBadge)

Naming these properties to match the eventual code props eliminates a whole class of handoff confusion.

Figma Variables for Tokens

I define all design tokens as Figma variables — colors, spacing, border radius, font sizes. Components reference variables, not raw values. This means when a developer inspects a component and sees color-primary instead of #3B82F6, they know exactly which token to use in code.

I organize variables into collections that mirror the token structure in code: primitives, semantic, and component.

Using Dev Mode Effectively

Figma's Dev Mode is powerful when the file is set up correctly. Here is how I make the most of it:

• Annotate interactions using Figma's built-in annotation tools. I mark hover states, transitions, and conditional logic directly on the frame.
• Section components clearly. I use section frames labeled "Ready for Dev" so engineers know which designs are finalized versus still in progress.
• Link to documentation. Each major component includes a link to its design system documentation page.

I also run a quick walkthrough with the developer before they start building. Ten minutes of context saves hours of back-and-forth.

Mapping Figma Components to React

Here is where the design-to-code translation happens. I think in React component structures while designing. A card in Figma becomes a mental model like this:

• Card (outer container) — padding, border-radius, background from tokens
• Card.Header — contains title and optional badge
• Card.Body — flexible content area
• Card.Footer — action buttons with consistent spacing

When I name Figma layers, I use the same hierarchy: Card / Header / Title. This makes the mapping obvious.

For spacing, I rely on the gap and padding values from auto-layout rather than margin-based positioning. This translates cleanly to gap in CSS, which is more predictable and maintainable than individual margins.

Handoff Tips That Actually Work

Redline sparingly, annotate generously. Developers do not need every pixel dimension called out — Dev Mode handles that. What they need are behavioral notes: "This list truncates at 5 items with a 'Show more' button," or "This input validates on blur, not on change."

Provide real content examples. Design with realistic data, not "Lorem ipsum." Show what the card looks like with a 3-word title and a 15-word title. Show the empty state, the loading state, and the error state. Developers will encounter all of these — make sure they know what to build.

Create a component checklist. For each feature handoff, I include a simple list:

• States covered (default, hover, active, disabled, error, loading)
• Responsive breakpoints (mobile, tablet, desktop)
• Edge cases (empty, overflow, single item, maximum items)
• Accessibility notes (ARIA labels, keyboard navigation, focus order)

Stay available. The best handoff process in the world does not eliminate questions. I block time during the development sprint to answer questions quickly. A 2-minute Slack response prevents a 2-hour guess-and-check cycle.

The Result

This workflow has cut our design QA feedback cycles by roughly 60%. Developers ship closer to the intended design on the first pass, and the conversations shift from "this doesn't match" to "should we improve this interaction?" That is a much better use of everyone's time.

The secret is not any single tool or technique — it is the discipline of designing with implementation in mind from the very first frame.