- Workflow
- Design Handoff
From Figma to Code: Bridging the Gap
Handoff isn't a moment, it's a conversation. Here's the checklist I run through before I write a single line of code from a design.
• 5 min read •
You’ve probably lived this one. The designer shares a beautiful Figma link, everyone nods in the meeting, and two weeks later you’re both staring at the staging build going, “Hmm, that’s… not quite it.”
Nobody did anything wrong. The design was good and the code was decent. The problem is that a Figma file captures maybe 70% of what a UI actually has to do, and the other 30% gets decided by whoever happens to be holding the keyboard at 6pm on a Thursday.
I’ve spent a lot of my career standing in that gap. Here’s what actually helps.
Handoff is a conversation, not a file
The single biggest change I’d push any team to make: stop treating handoff as an event. “Designer finishes, throws it over the wall, developer catches it” is how you get drift.
What works better is pulling developers in while the design is still messy. A 20-minute call at the wireframe stage where a dev says “that table is going to have 400 rows, should it paginate?” saves days later. The designer still owns the design; the developer just gets to flag the landmines early.
The questions I ask before I build anything
When a design lands on my desk, I go through it with a short list. Most of these aren’t in the file, and that’s normal. Designers are usually designing the happy path because that’s what they’re asked to show.
1. What are all the states?
For every interactive thing on the screen I want to know:
- Default, hover, focus, active, disabled
- Loading (and what if it’s slow?)
- Empty (no data yet)
- Error (and what does the error say?)
- Success
The focus state is the one that’s missing most often, and it’s the one keyboard users depend on.
2. What happens with real content?
Designs are usually built with perfect content. “Jane Doe.” “Product name.” Three items in the list. Real life is messier:
- What if a user’s name is “Nana Akua Oforiwaa Boateng-Asante”?
- What if the list has 0 items? 1 item? 2,000 items?
- What if the image fails to load?
- What if the translated version of the button is twice as long?
I’ll often paste a stupidly long string into the Figma text layer myself and show the designer what happens. It’s a fun conversation, not a confrontational one.
3. How does it behave between breakpoints?
Most files show a mobile frame and a desktop frame. But your users are on everything in between: a 768px tablet, a laptop with the browser half-width. I ask: “What should this do at 900px?” Usually the answer is obvious once someone asks.
Make Figma and code speak the same language
The more your Figma file looks like your codebase, the less translating anyone has to do.
Name things the same. If Figma has a color style called Brand/Teal 500 and your CSS has --color-primary, someone has to keep a mental lookup table. Agree on names together. Design tokens are perfect for this:
:root {
--color-text-default: #111827;
--color-text-muted: #6b7280;
--color-action-primary: #00a0a8;
--space-2: 0.5rem;
--space-4: 1rem;
--radius-md: 8px;
}When the Figma variable is literally called color/action/primary, nobody has to guess.
Use auto layout like it’s flexbox, because it is. Auto layout maps almost one-to-one to CSS flexbox: direction, gap, padding, alignment. A design built with auto layout is basically a CSS spec. A design built with absolutely positioned layers is a puzzle.
| Figma auto layout | CSS |
|---|---|
| Direction: horizontal | flex-direction: row |
| Gap between items | gap |
| Padding | padding |
| Hug contents | width: fit-content |
| Fill container | flex: 1 |
Use Dev Mode, but don’t trust it blindly
Figma’s Dev Mode is great for grabbing exact values, measuring spacing and exporting assets. But the CSS it generates is a starting point, not production code. It’ll happily give you position: absolute; left: 247px; for something that should just be a flex child.
My rule: use Dev Mode for values, write the layout yourself.
A couple of asset tips while we’re here:
- Icons should be SVG. Ask for them to be exported on a consistent frame (24×24) so they line up.
- Photos should be exported large and compressed in your build pipeline. Don’t hand-optimize JPEGs at 2am.
- If a layer is called
Rectangle 47, gently ask for a better name. Future you will thank present you.
Close the loop with a design review on the real thing
Once something’s built, I ask the designer to review it in the browser, not in a screenshot. Ideally on their own phone. They’ll catch things a screenshot never shows: animation timing, scroll behavior, how the keyboard pushes the layout up on mobile.
Keep this low-pressure. I like to frame it as “help me make this feel right” rather than “please approve my work.” Designers notice tiny things, which is exactly why you want their eyes on it.
A quick checklist you can steal
Before you start building:
After you build:
The real takeaway
Tools help, but the gap between Figma and code is mostly a people gap. The teams I’ve seen ship the most polished work aren’t the ones with the fanciest plugins. They’re the ones where the designer and developer talk every day, ask each other dumb questions, and genuinely care how it feels in the end.
So next time a design lands in your lap, don’t just open Dev Mode. Open a chat with the designer and ask, “What happens when this breaks?” You’ll both build something better.