Free handbook · No email gate

Figma → Webflow handoff.

A complete handoff handbook + a printable 24-item checklist. What to prepare in Figma, what NOT to prepare, the Webflow gotchas that catch engineers on every project, and a single artefact you can print, share, or staple to a project brief.

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.

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.

The 24-item checklist

The full artefact — tick the boxes here, or copy it into your project brief. It's the same list we run on every engagement, split into the three phases of a handoff.

Figma side — before you hand off

  • Auto-layout applied to every component the engineer will rebuild — no free-floating frames.
  • Variables set up for colour, spacing, type, radius — at minimum these four. Webflow consumes them as variables, not hex codes.
  • Components named in semantic terms ("Button / Primary / Sm"), not visual ones ("Pink Button"). The engineer will use those names in Webflow class slugs.
  • Breakpoints defined explicitly: mobile (≤479), tablet portrait (≤767), tablet landscape (≤991), desktop (≥992). Same set Webflow uses.
  • Edge cases drawn — empty state, error state, loading state, max-content state — so the engineer doesn’t have to guess them in the build.
  • Hover / focus / active states present for interactive components (or annotated if no design exists for them).
  • All copy locked, including button labels, error messages, microcopy. Copy churn is the #1 source of rework after handoff.
  • Image assets exported and dropped into a /assets folder in the file or in a shared Drive. Filenames lowercase, kebab-case, descriptive.
  • Icons consolidated into a single icon set (one library, one stroke weight, one corner style).
  • Shadow + radius tokens limited to ≤6 values across the system. Webflow will struggle if every component invents its own.

Webflow side — project setup

  • Style Guide page built first — typography scale, colour swatches, button states, form elements. Future pages inherit from here.
  • Class naming convention agreed: BEM-ish ("section_hero_title", "card_pricing_label") OR utility-driven ("u-pad-md", "u-text-h2"). One or the other, never both.
  • Components ("symbols") set up for: nav, footer, button, card, hero, section header. Components added later are fine; reusing a class without a component is the trap.
  • Variables imported (Webflow → Variables) for the same colour / spacing / radius tokens defined in Figma. Names match exactly.
  • Breakpoints in Webflow set to the four agreed in Figma. Custom breakpoints in Webflow > 479 are pro-only — agree the cap before building.
  • Asset library uploaded — images in WebP where supported, fallback PNG/JPG, max 1920px wide for hero imagery, lazy-loading enabled.
  • CMS Collections sketched if the project needs them — even on a static-pages-first build, sketching now saves a re-architect later.

QA + launch

  • Cross-browser test: Chrome, Safari, Firefox, mobile Safari (iOS 16+), mobile Chrome.
  • Lighthouse run: Performance ≥85, Accessibility ≥95, Best Practices ≥95, SEO ≥95 on every page.
  • Form submissions wired (Webflow native or Make/Zapier handler) AND tested with a real submission.
  • 301 redirects from the old URL structure mapped — never deploy without a redirect map for any URL that received traffic in the last 90 days.
  • Open Graph + Twitter card meta on every page, with custom OG image per page.
  • Sitemap submitted to Google Search Console post-launch (you’d be surprised how often this gets missed).
  • Cookie consent banner wired if the project has analytics / tracking. EEA / UK / CH visitors should see default-deny.

FAQ

01 Should I design in Figma if I know the build is in Webflow?

Yes. Designing in Webflow directly works for one-off marketing sites with a single page; it doesn’t work for systems. Figma stays the source of truth for typography, colour, spacing, components — Webflow consumes the result. The handoff checklist exists because that two-step model is where most of the friction sits.

02 How long does a Figma-to-Webflow handoff take?

For a 5–10 page marketing site with a clean Figma file: 1–2 weeks of build, 3–5 days of QA. For a CMS-heavy site or a system port from another platform: 3–5 weeks. The variance is almost entirely driven by how strict the Figma file is — a tidy file collapses the build by ~40%.

03 Do you take handoff-only engagements?

Yes. We build in Webflow from a Figma file you already own — no design fee. Useful for teams who have an in-house designer but don’t have a Webflow specialist. Standalone handoff projects start at $4–6k for a 5–10 page site.

04 What about Webflow → Framer / Webflow → custom stack?

Same checklist applies — almost all of the Figma-side prep is platform-agnostic. The Webflow-side section is the part that swaps. We have the engineer side covered for Webflow and Framer; for custom stacks (Next.js / Astro / etc.) we hand the file to your engineering team and run a 30-min walkthrough so they can use the system without re-pitching the rationale.

05 Can I use this checklist on a project I’m running internally?

Yes — that’s the point. Print it, share it, link to it from your design wiki. Attribution back to funky-rabbit.com is appreciated but not required.

Want a Webflow team to take it from here?

If you have a Figma file ready and you'd rather hand it to a team that has done the build a hundred times — we do that. Standalone handoff projects start at $4–6k for a 5–10 page marketing site.

Start your project