Figma to Webflow: What Actually Gets Lost in Translation

The first time a client sent me a Figma file and said "just build this, it's all there," I said sure, no problem. Two days in, I had a list of nine questions and a hover state I'd basically had to invent myself. That happens on almost every handoff, and it's not really anyone's fault — Figma and a browser are just different mediums pretending to be the same thing.

Auto layout isn't flexbox, even though it looks like it

Figma's auto layout and Webflow's flexbox map onto each other maybe 80% of the time. The other 20% is where things get annoying: nested auto-layout frames that resize independently, gap values that round differently once they hit real pixels, and padding that behaves fine on a fixed frame but falls apart the moment content wraps onto a second line. None of this is visible in the design file. It only shows up once real (longer, shorter, translated) content goes in.

Hover, focus, and empty states usually don't exist yet

A Figma file shows the happy path — logged in, form filled out correctly, exactly three testimonials, nav closed. A real site has to handle all the states in between, and most of those never get designed. I end up making a judgment call, which is fine, except sometimes it's not the call the client would have made.

• Hover and focus-visible states on buttons and links
• Disabled and loading states on form fields and submit buttons
• Empty states — what a CMS list looks like with zero items
• Error states — a failed form submit, a broken image
• The mobile nav open state, which somehow gets skipped constantly

Type scale drifts between two tools that round differently

Figma lets you set line-height as a fixed pixel value or a percentage, and font sizes at whatever precision you want. Browsers round rem values, apply their own default line-height math, and handle letter-spacing slightly differently depending on the font's own metrics. The result is a page that's pixel-close to the design but never pixel-identical — and "it doesn't look exactly like Figma" is one of the most common notes I get, even when the build is technically correct.

What I actually ask before I start building

I've started sending a short list of questions before I touch a single component, because it's cheaper to ask upfront than to guess and redo it later:

• What happens on hover, and on mobile where there's no hover at all?
• What's the loading state, and the empty state, for anything dynamic?
• Which breakpoints did you actually design — and what's the assumption in between them?
• Is this 13px gap intentional, or an artifact of dragging things around?
• Do these two "identical" buttons use the same component, or did they drift apart?

Where this actually saves you money

None of this means design files need to be exhaustive. It means the handoff goes faster — and the build needs fewer rounds of "can you tweak this" — when a file at least acknowledges that hover states, mobile, and edge cases exist, even roughly. The projects that go smoothest aren't the ones with the most polished Figma file. They're the ones where the designer and I agreed on the boring stuff — states, breakpoints, real content — before a single div got built.

See how I handle Figma to Webflow builds