From Design to Code: The Handoff Process

Design handoff is the moment when a designer's vision meets a developer's implementation. A good handoff is clear, complete, and enables developers to build accurately. A bad handoff requires developers to guess, leading to inconsistencies and rework.

The gap between "how it was designed" and "how it was built" is common. Developers make assumptions about spacing, colours, or behaviour that weren't specified. Designers discover edge cases during implementation that weren't considered in the design. Communication prevents this.

Figma: The Standard Design Tool

Figma has become the standard because it's browser-based, collaborative, and built for design systems. Its Inspect panel shows spacing, sizing, colours, and typography. Developers can measure and copy exact values.

A well-organized Figma file is developer-friendly. Clear naming conventions (not "Frame 1", "Heading 1", but "Button Primary", "Input Email"), logical nesting, components that represent code components, design tokens instead of hard-coded values.

Figma's Dev Mode streamlines handoff. Developers can inspect layers, see applied styles, export assets. This reduces the need to ask the designer "what's this spacing?"

What a Good Figma File Includes

Organized Frames and Pages

Structure your file logically. Pages for different sections (marketing site, dashboard, settings). Within each page, frames for different screens and components. Navigation aids developers find what they need.

Named Components

Code components should have corresponding design components. A Button Primary in code is Button/Primary in Figma. A Card component in code is a Card component in Figma. When developers see a button in the design, they know to use the Button component in code.

Design Tokens

Define variables for colours, spacing, and typography. Use "primary-blue" instead of hard-coding #0066FF. In code, use CSS custom properties with the same names. Design and code stay in sync automatically.

Annotated Interactions and States

Every button, link, form input has states: default, hover, focus, active, disabled, loading. Design all these states or document them. A button without a hover state is incomplete—developers need to know what it looks like on hover.

Use Figma prototyping to show interactions. When a button is clicked, what happens? Does a modal open? Does the page scroll? These flow diagrams prevent misunderstandings.

Exported Assets

Export icons, logos, and images at multiple resolutions (2x for retina). Use modern formats (SVG for icons, WebP for images). Include both light and dark mode versions if applicable.

What a Bad Figma File Requires Developers to Do

When a Figma file is poorly organized, developers waste time:

Guessing spacing and sizing (is that 8px or 10px?)
Asking for every colour value instead of finding a design system
Implementing multiple button states without knowing the design
Reconstructing a navigation structure from screenshots
Inferring responsive breakpoints (does this stack on mobile?)
Discovering during development that a key screen wasn't designed

This rework is expensive and demoralizing. A 10-minute Figma improvement saves hours of developer time.

Note

Invest in design system documentation. A living document (Figma file + wiki/docs) that describes the design system saves time and prevents inconsistency.

Design Tokens: The Bridge

Design tokens are named variables for design decisions. Instead of "the blue colour is #0066FF", it's "primary blue is a token, which is #0066FF". When primary blue changes to #0052CC, one change updates everywhere.

Common tokens: colors (primary, secondary, success, error, warning), spacing (spacing-1 through spacing-8), typography (heading-1 through heading-6, body-regular, caption), shadows, borders, border-radius.

Tokens in design (Figma variables) and tokens in code (CSS custom properties) with the same names keep design and implementation in sync.

Responsive Design Documentation

Not everything is obvious from a single desktop design. Which elements stack on mobile? Which disappear? Which resize? How much padding on mobile vs desktop?

Show mobile, tablet, and desktop designs. Or document the breakpoint decisions. "The hero section is full width on mobile, max-width 1200px on desktop. The sidebar collapses into a hamburger menu below 768px."

States: The Often-Forgotten Part

Every interactive element has multiple states. A button has: default, hover, focus (keyboard), active (pressed), disabled, loading. A form input has: default, focused, invalid, valid, disabled. A menu has: closed, open, hover, focus.

Designing all states is tedious but essential. Without them, developers guess ("what should a disabled button look like?"). Inconsistent implementations follow.

Use Figma's variants feature to show multiple states of a component. When developers inspect the button component, they see all states.

The Iterative Reality

Even with perfect designs, implementation reveals edge cases. A design that looks great in a 1920px frame might have awkward spacing at 1024px. An input field that looks fine in isolation might crowd when in a form. A colour choice that works on desktop might fail contrast on mobile.

Design and development must remain in communication during implementation. "This doesn't quite work at this breakpoint, can we adjust?" or "The text is getting cut off here" lead to solutions that satisfy both aesthetics and practicality.

This is not a failure of the design or development—it's the normal process. Design specifications are complete enough to build from, but implementation details emerge during build.

Design System Maintenance

A design system is living—it changes as the product evolves. When a new feature adds a new component type, the design system needs a new component. When a colour palette is updated, all components must reflect it.

Without discipline, design and code diverge. Someone updates the button in code but forgets to update the Figma component. Someone adds a new shade of blue to the design but doesn't add it to the code. Inconsistency accumulates.

For larger teams, a dedicated design systems person or team prevents drift. But even for smaller teams, a shared understanding that the design system is the source of truth prevents confusion.

Tools and Workflow

Modern workflows use:

Figma: Design and prototyping
Storybook: Component library for code (see next section)
Design system documentation: Figma + Storybook + wiki explaining design patterns and usage
Version control: Design changes versioned in Git when design tokens are in code

Some teams use tools like Abstract or Figma branches to version design changes alongside code changes.

Tip

Designers should understand code constraints. Knowing that CSS Grid has 12 columns helps a designer make layouts that developers can implement easily. Developers understanding design tools helps them ask better questions.

The Bottom Line

A great design handoff is clear, complete, and maintainable. It eliminates guessing. It enables developers to build accurately. It prevents rework. Invest in the handoff process.