"Just convert the Figma to WordPress" sounds simple until you're the one doing it. A design file and a working, editable, responsive WordPress site are two very different things — and the gap between them is where most conversions go wrong. Here's the workflow I use to keep that gap small.
1. Audit the design system before touching code
Before building a single section, I go through the Figma file and pull out the actual design system hiding inside it: the real color palette (not just what's visually used, but named tokens), the type scale, spacing units, and button/component states. Skipping this step is how you end up with seventeen slightly different shades of blue scattered across a site.
2. Choose the right build approach for the project
Not every design needs a fully custom theme. For a marketing site the client's own team will edit constantly, a well-structured Elementor or ACF-block build often serves them better long-term. For something with unusual interactions or that needs to be fast and lean, a custom-coded theme is the right call. I make this decision based on who maintains the site after launch, not just what's technically more impressive.
3. Build responsive behavior from the actual breakpoints in the file
Good Figma files include desktop, tablet, and mobile frames — bad conversions ignore the tablet frame entirely and just let CSS "figure it out" between breakpoints. I build from all three explicitly, then check the in-between sizes by hand, because that's where most pixel-perfect conversions quietly fall apart.
4. Build components, not pages
I break the design into reusable pieces — a card, a CTA band, a testimonial block — and build each once, properly, rather than rebuilding slightly different versions of the same section on every page. This is what makes the site maintainable six months later when the client wants to add a new page themselves.
5. QA against the design file directly, not against a screenshot
I overlay the live build against the actual Figma frames at each breakpoint and check spacing, font sizes, and alignment pixel by pixel. Small inconsistencies — 2px off here, a slightly wrong line-height there — are what separate a build that "looks close" from one that actually matches.
6. Make sure it's genuinely editable afterward
A pixel-perfect build that the client can't touch without breaking it isn't actually finished. Every dynamic section — hero text, testimonials, service cards — gets wired to ACF fields or block editor content, so the client can update copy and images without calling me every time.
The result
A conversion done this way holds up under real use: it looks like the design, works across devices exactly as designed, and doesn't fall apart the first time someone on the client's team edits a page. That's the actual bar — not just "does it look right in the first screenshot."
