From Figma to production: how our design-to-dev handoff works

I’ve been designing interfaces since before 5e existed. The worst part of the job was never the design itself. It was the handoff.

You spend two weeks crafting a pixel-perfect mockup in Figma. You export a PDF. You write a spec document. You hand it to the development team. They build it. You open the staging link. The spacing is wrong. The hover states are missing. The font weight is off. The responsive breakpoints are guessed, not designed.

You file bugs. They fix some. They argue about others. Two weeks of back-and-forth later, you have something that’s close enough to ship but not close enough to feel proud of.

That cycle is broken by design (pun intended) at 5e. Here’s how.

The problem isn’t the handoff document. It’s the handoff.

Most agencies treat design and development as sequential phases. Design finishes, development begins. The handoff is a moment in time: a meeting, a PDF, a Figma link thrown over the wall.

We eliminated the wall. Our designers and developers work in the same sprint cycle, in the same Slack channel, looking at the same Figma file. When I set up a component, the developer who’ll build it is already watching. When they have a question about interaction states, they comment in Figma and I respond in minutes, not days.

This isn’t revolutionary. It’s just how we’ve always done it because we’re one team, not two.

What the Figma file looks like

Our design files aren’t just pretty screens. They’re build-ready artifacts.

Component variants for every state. Default, hover, active, disabled, error, loading. If a button can be in that state, it’s in the file. Developers don’t guess.

Auto-layout on everything. Spacing isn’t eyeballed. It’s defined in the layout. A developer inspects the Figma file and sees the exact padding, gap, and alignment values. No spec document needed.

Design tokens. Colors, font sizes, border radii, shadows, all defined as Figma styles and variables. These map directly to CSS variables or Tailwind config. The developer doesn’t pick a hex color from the mockup. They reference a token.

Responsive variants. We design at least three breakpoints: desktop, tablet, mobile. Each page has all three. Developers see exactly how the layout shifts, not just the desktop version with a note that says “make it responsive.”

What the developer sees

Our frontend developers use Figma’s dev mode. They click on any element and see:

• Exact dimensions, padding, margin
• The design token (color name, not hex)
• The font family, weight, size, line height
• Auto-layout direction and gaps
• Component name and variant

They don’t need a separate spec. The Figma file is the spec. They inspect it directly, the same way they’d inspect an element in browser dev tools.

How this changes timelines

In a traditional agency flow:

• Design phase: 2 weeks
• Handoff meeting: 1 day
• Development: 2 weeks
• Design review and bug fixes: 1 week
• Total: about 5 weeks

In our flow:

• Design and development overlap in the same sprint
• Designer sets up components in week 1, developer starts building in week 1
• Questions answered same-day in Slack/Figma comments
• Design review is continuous, not a phase
• Total: about 3 weeks for the same feature

Two weeks saved on a single feature. Over a full project, that compounds.

It works because we’re the same team

I want to be clear: this isn’t a process you can bolt onto any agency. It works because our designers and developers have worked together for years. They know each other’s patterns. The developer knows I always put spacing tokens in auto-layout. I know the developer will check Figma before asking me a question.

That shared context is something you build over time. It’s also something our clients benefit from immediately, because they don’t need to build it themselves.

If you’re tired of the handoff cycle costing you weeks, or if you’ve ever opened a staging link and winced, this is what the alternative looks like.