1. A Figma file is not a site
A Figma file is a visual representation. It does not describe how the layout behaves at 768px, which ACF field feeds that headline, or whether that three-column grid is a custom post type loop or three repeatable fields.
All of those questions stay open until the developer resolves them — usually quietly, often without flagging that a decision was needed. That is not a designer problem. Design communicates visual intent. Turning it into technical structure is what development is for.
2. What happens before opening the editor
Before writing a single line of code there is a reading phase that many developers skip or rush through. The goal is to understand how many distinct templates actually exist, which components repeat, what the client will need to edit and what stays static.
- How many page templates are there? Home, landing, blog, inner page: each needs a separate PHP template file.
- What content is editable and what is not? This changes the ACF field architecture and theme structure.
- Do images have defined aspect ratios or are they flexible? If flexible, a crop strategy is needed.
- Are there custom fonts? They may come from Google Fonts, Adobe Fonts or local files.
3. WordPress project structure
Structure depends on how many moving parts the design has. A five-template site with near-static content does not need the same architecture as one with dynamic loops, filters, multiple custom post types and advanced forms.
For most agency projects the base setup works like this: a child theme or custom theme, ACF fields for editable content, PHP templates per page type, component CSS separate from global CSS. It is not the only option, but it tends to stay more readable six months after launch.
4. Responsive work is not optional
Figma files almost always show desktop. Sometimes mobile. Rarely anything in between.
Responsive work is not tracing the design: it is interpreting it so it holds across every width the designer and client never looked at together. That requires decisions the developer makes independently.
- Do padding and margins scale with a fluid logic, or are there hard jumps between breakpoints?
- Does typography use clamp() or fixed steps at each breakpoint?
- Do grid components collapse vertically or shrink proportionally?
5. What gets checked before handoff
Before passing the project there is a three-level check.
The first is visual: does the site match the design? Fonts, colors, spacing. A direct side-by-side comparison between Figma and browser.
The second is functional: does everything editable actually work? Open the backend, update ACF fields, verify the changes appear correctly on the frontend. Publish a post, upload an image, submit a form.
The third is technical: does the site hold up on real devices? Not just Chrome on a laptop. iOS Safari, Firefox, Edge. The menu opens on mobile, images do not overflow, forms work on small screens.
Frequently asked questions
How many revision rounds are typical on a design-to-build project?
It depends on file quality and the clarity of the initial brief. With a well-prepared file and careful upfront analysis, one or two feedback rounds are usually enough. The most common issues appear where the design does not specify responsive behavior or edge cases with real content.
Does the designer need to be available during development?
Not constantly. It makes sense to involve the designer on decisions that could not be resolved earlier: unspecified responsive behavior, content variants the design did not account for, components that behave differently with real data versus placeholder content.
Next step
You have an approved Figma file and need someone to turn it into WordPress?
The Design-to-WordPress service page explains how I work on builds from approved design files for agency teams.
Open the Design-to-WordPress service