Why Design Handoff Goes Wrong
Design handoff fails in predictable ways. The designer builds in Figma with fonts, shadows, and spacing that don't map to the code framework. The engineer implements the design "approximately" because the Figma file doesn't specify every state and every breakpoint. The PM reviews the implementation against the design and finds 30 discrepancies. This cycle repeats.
The solution is not more design review meetings. It is a better handoff process with clear ownership at each step.
The Modern Handoff Stack
Figma as the source of truth. Figma has become the industry-standard design tool for good reason. It's collaborative, versioned, and has developer-mode features specifically for handoff.
Figma Dev Mode. In inspect mode, engineers can view exact values (hex colors, pixel values, spacing, font specs) directly in the Figma file. This eliminates "eyeballing" implementations.
Design tokens in code. When Figma variables map to Tailwind config values (or CSS custom properties), engineers don't need to inspect every value. They use the same token names the designer used. A color named brand in Figma is text-brand in Tailwind. The mapping is documented once and followed everywhere.
Component parity. The Figma component library and the React/HTML component library should correspond 1:1. A "Button (Primary)" in Figma should map exactly to <Button variant="primary" /> in code. This means component names, variants, and states are agreed upon before building begins.
The Handoff Checklist
Before a design is handed to an engineer:
- [ ] All screens are at final-fidelity (not wireframe quality)
- [ ] Responsive breakpoints are designed (mobile, tablet, desktop)
- [ ] Interactive states are defined (default, hover, active, disabled, loading, error)
- [ ] Empty states are designed (what does the screen look like with no data?)
- [ ] Error states are designed
- [ ] All colours reference Figma variables (no raw hex values)
- [ ] Typography uses a defined text style (no custom sizes)
- [ ] Spacing uses the defined scale (no arbitrary pixel values)
- [ ] Component names in Figma match component names in code
This list reduces implementation ambiguity to near-zero.
Communication During Build
Good handoff is not a one-time document transfer. It is an ongoing conversation. Establish:
- A shared channel (Slack, Linear) where design questions get answered within 2 hours
- A "design debt" log where engineering notes deviations that need addressing
- A review cadence, a brief design review (30 minutes) midway through the build, not only at the end
The most common failure: engineering finishes a build and the first design review is at the end of the sprint. By then, corrections require significant rework. Mid-sprint review prevents this.
What Kastling's Handoff Looks Like
We design, build, and launch AI products, so brand and engineering sit under one roof. Design and engineering handoff runs continuously, not sequentially. The designer uses Figma with a token library that maps to the codebase. Engineers have Figma Dev Mode access from day one, with the code living in your repo. We run a design review at the end of each feature, not at the end of the build. The result: builds that match designs at > 95% fidelity without extensive revision cycles.
FAQ
Q: Should developers have access to Figma during the build?
Yes, always. Developers should be able to see the design they're implementing without asking the designer every time they need a value.
Q: What happens when the design and the implementation don't match?
There should be a defined process: document the deviation, decide whether to fix the code or update the design, and close the loop. Don't let deviations accumulate silently.
Q: Do I need Figma Dev Mode or can I use the free version?
Figma's free tier has view-only access for developers, which includes basic inspect capabilities. Dev Mode (part of paid plans) adds code snippets and more detailed specifications.
Q: What's the best tool for annotating designs for handoff?
Figma's built-in annotation tools are sufficient for most teams. If you need more structured specs, Zeplin or Storybook (for component documentation) can supplement.