You designed it, you need it built
You own the client relationship and the design language. You need a build that matches the file, keeps to your naming and structure conventions, and lands on the date you promised your client.
Figma to Webflow
Figma to Webflow, built to survive the second year
A Figma file shows one width, with content someone chose, in one state. A website has to hold every width, every headline an editor will write, and states nobody drew. That gap is where handoffs go wrong, and closing it deliberately is most of this job.
- Components, not copies
- Real content states
- Fixed delivery date
Who this is for
Two kinds of file arrive, and they need different things.
A designer, no Webflow developer
Your designer works in Figma and there is nobody to implement it. You need the build plus a CMS your marketing team can operate afterwards without opening a ticket.
A file from a previous project
You have a design from a contractor who is gone. The build needs someone to make the decisions the file did not make, and to say which ones need your approval.
The gap
What a design file does not decide.
These get decided by somebody during the build. The only question is whether they are decided deliberately or improvised on the day of launch.
Intermediate widths
The file shows desktop, tablet and mobile. Browsers show everything in between, and that is where layouts break in ways nobody drew.
Content extremes
A three-line headline, an empty field, a product name twice as long as the placeholder. Real content is messier than the content chosen for the mockup.
Interaction states
Focus, error, loading, empty and disabled states are rarely in the file, and they are what people meet when something goes wrong.
What repeats
Which structures become components with properties, and which stay one-off compositions. Getting this wrong makes the site expensive to change later.
How it runs
The handoff, step by step.
- 01
Read the file properly
Type roles, spacing scale, colours, grids and component variants. I come back with the list of decisions the file does not make, before quoting a date.
- 02
Agree the component map
What becomes a component, what stays flexible, and which properties each component exposes. This is the decision that governs maintenance cost.
- 03
Model the CMS
Fields named after what content means, not where it currently sits, so a redesign later does not require re-entering everything.
- 04
Build and QA in the browser
Representative widths, keyboard paths, fonts, forms and metadata. The approved frame is an input; the working browser is the product.
- 05
Hand it over
A short walkthrough of what is safe to edit, what is a component that affects many pages, and who to ask before changing structure.
Frequently asked questions
Questions connected to this decision.
Can Figma designs be imported into Webflow automatically?
Tools can move parts of it, but structure, responsive behaviour, semantics and CMS decisions still need a person. An imported layout that nobody can maintain is not a saving.
Do you follow our class naming convention?
Yes. If you work in Client-First or your own system, I build to it. Tell me at the start, because retrofitting a convention costs more than following one.
What if the design is incomplete?
That is the normal case. I list what is missing, propose the decisions, and either you approve them or your designer supplies the frames. Nothing gets invented quietly.
Will you talk to our client?
Only if you want me to. Agencies usually prefer that I stay behind the scenes, and that is the default.
Can you hit a fixed launch date?
Once I have seen the file and we have agreed the component map, yes. Before that any date would be a guess.
Sources and basis
What supports this page.
Component and accessibility decisions reference published documentation and standards rather than preference. Everything else is judgement, presented as judgement.
- Build with components
Webflow University · Verified 2026-07-19
Current documentation for components and properties, which is what makes a build maintainable rather than a set of copied sections.
- Web Content Accessibility Guidelines overview
W3C Web Accessibility Initiative · Verified 2026-07-19
The standard used when checking semantics, keyboard paths, contrast and responsive behaviour.
Related decisions
