Figma →
Webflow.

Why this handoff is hard

Figma is built for design systems. Webflow is built for sites. The two share vocabulary — components, variables, breakpoints — but they implement those concepts on different rails. A Figma component is a design pattern; a Webflow component (a Symbol) is a DOM template. A Figma variable is a token bound to a value; a Webflow variable is a CSS custom property bound to a class.

Most of the rework on a Figma-to-Webflow handoff is the gap between those two models. The designer thinks they handed off a "system"; the engineer receives 47 frames that look related but don't carry the inheritance the system implied. Three weeks later the project ships, but every change request requires a designer to point and an engineer to retrace.

The checklist below is what we use on every Figma→Webflow engagement to close that gap before the build starts. It's boring, opinionated, and assumes you already know your tools.

The Figma side — before you hand off

The job of the Figma file at handoff is to be strict enough that an engineer can rebuild it without making any micro-decisions. Strict means: no ambiguous spacing, no component-without-component, no copy-as-placeholder. Three specific traps:

1. Free-floating frames pretending to be components

If a "card" is reused on six pages but isn't an actual Figma component, the engineer will rebuild it six times in Webflow and the project will have six different button paddings by week three. Every reused pattern in the file should be a real Figma component before handoff, with auto-layout, variants, and properties. Webflow's Symbols mirror this 1:1.

2. Variables that aren't variables

"Brand pink" used as a hex code in 40 places looks the same as "Brand pink" used as a variable. The engineer can't tell the difference until they try to swap the colour and discover 40 places where it's hard-coded. Run the file through Figma's "Find and replace colour with variable" before handoff. Same for spacing tokens and type styles.

3. Edge cases that aren't drawn

If the empty state isn't drawn, it will ship as the default-styled empty state Webflow gives you (which is nothing). If the loading state isn't drawn, the build will contain whatever the engineer's first instinct was. Drawing the edges is cheaper than designing them by reaction.

If you want a Webflow team to take it from here, see our Figma → Webflow engagement or Webflow design agency overview.

The Webflow side — project setup

Build the Style Guide page first. Always. Typography scale, colour swatches, button states, form elements — drop them on one Webflow page before you build any production page. Every subsequent page inherits from there, and design drift becomes impossible because changing the production page would visibly diverge from the Style Guide.

Class naming is the second irreversible decision. Pick BEM-ish (section_hero_title) OR utility-driven (u-pad-md) at the start of the project. Mixing them produces the worst of both worlds — utility classes that aren't reusable AND component classes that fight the cascade.

Webflow Variables (introduced 2023) consume Figma Variables cleanly when the names match. Don't rename on import. If Figma calls it --color-brand-magenta, Webflow calls it the same. The two stay in sync forever; rename either side and they drift.

QA + launch

Three categories of pre-launch issue, in order of impact:

• Performance regressions. Webflow's WebP-by-default helps; Lighthouse below 85 on mobile means the asset pipeline isn't pulling its weight. Crop hero images to the actual served size, not the source size.
• Form wiring not tested. "We'll wire the form last week" is the most-broken promise on every Webflow project. Wire it on day one with a fake-handler endpoint, replace the endpoint at launch.
• Old-URL traffic dropped. If the site is replacing an existing one, every URL that received any traffic in the last 90 days needs a redirect. Webflow's 301 manager is one CSV upload — there is no excuse for missing this.