Figma to WordPress: Turning a Design into a Real Theme

• Defined type and spacing scales, used consistently. Fifteen arbitrary font sizes means fifteen decisions I have to make on your behalf.
• Named colour styles rather than raw hex values scattered through the file, so the palette is a system.
• Components for repeated elements, so a card is one thing with variants rather than nine similar frames.
• At least two breakpoints — desktop and mobile — for anything whose layout genuinely changes. Tablet can usually be inferred; the mobile navigation cannot.
• Interactive states: hover, focus, active, disabled, error. Focus states in particular are almost always missing, and they're an accessibility requirement.
• Realistic content, not lorem ipsum at a convenient length.

Designs show the ideal case. Real sites don't stay in it, and the gap is where most post-launch complaints come from.

• Empty states: a category with no posts, a search with no results, a testimonials section before there are any testimonials.
• Overflow: a product name three times longer than the one in the design, a navigation item that wraps, a price with more digits.
• Long content: what a 4,000-word article looks like in a layout designed around 600 words.
• Missing images: what a card does when there's no featured image.
• Loading and error states for anything asynchronous.
• Ask about these before building. Deciding them during development means I'm designing, which is not what anyone hired me for.

The first thing I extract from a design file isn't a layout, it's the system underneath it: the colour palette, the type scale, the spacing scale, the border radii, the shadows.

Those go into theme.json and CSS custom properties, which makes them available as editor controls and as variables throughout the stylesheet. A colour changed in one place then changes everywhere it's used.

This also constrains editors usefully. When the colour picker offers the five brand colours rather than an arbitrary spectrum, and the font size control offers the type scale rather than free text, the site still looks designed in two years.

Before writing templates, I go through the design and list the repeated pieces: the card, the hero, the feature grid, the call to action, the testimonial, the accordion.

Each becomes a template part, a block pattern, or a custom block depending on who needs to place it and how much it varies. A component editors place themselves becomes a block with constrained options; one that only appears in a fixed position becomes a template part.

This step is where the build either gets efficient or doesn't. Building twelve pages as twelve layouts is slow and produces a site where a change has to be made twelve times.

Clients ask for pixel-perfect and they mean 'it should look like the design', which is reasonable. Taken literally it's the wrong goal, because the design was drawn at one width with one content length and the web is neither.

What I aim for instead: identical at the design's breakpoints with the design's content, and sensible everywhere in between and beyond. Spacing from the scale rather than eyeballed per element. Type that scales smoothly rather than jumping at breakpoints.

The places I'll deviate deliberately: tap targets too small for a thumb, contrast that fails accessibility requirements, a hover-only interaction that has no touch equivalent, and text in images. I'll raise each of those rather than silently implementing them or silently changing them.

Some design choices have costs that aren't visible in the file, and it's much cheaper to discuss them before the build than after a Core Web Vitals report.

• Number of font weights. Each is a separate download; two is usually enough.
• Large hero images, particularly full-bleed background images which the browser discovers late.
• Carousels, which are heavy, rarely interacted with past the first slide, and awkward for accessibility.
• Scroll-triggered animation, which costs main-thread work on exactly the devices that can least afford it.
• Custom icon fonts, where inline SVG is smaller and sharper.
• None of these are forbidden. They're trade-offs worth making knowingly.

• Which parts of this will editors need to change themselves, and how often?
• Which sections repeat across pages, and should they be identical everywhere?
• What happens to this layout when the content is twice as long?
• Is this section's content coming from a custom post type, or is it hand-written per page?
• Are these images uploaded by editors, and if so at what aspect ratio?
• Is there a design system this should feed into, or is this a one-off?

A small habit that saves a surprising amount of back-and-forth: name the components in the design the way they will be named in the code and in the editor.

• If the design calls it a Feature Card and the block is called Feature Card, a review comment about the feature card is unambiguous.
• Name components for what they are, not where they currently sit. HomepageBox becomes wrong the moment it appears on a second page.
• Keep the colour style names semantic rather than literal. Brand Primary survives a rebrand; Purple does not.
• Name the spacing and type scale steps once, and use the same names in theme.json. Then a conversation about spacing is about a named step rather than a number someone measured off a screenshot.
• Where a component has variants, name the variants too, because those become the options an editor sees in the sidebar.

Review it with real content, not the design's content. A build that looks right with lorem ipsum and wrong with the actual copy isn't finished.

Review it on an actual phone, not a browser window resized to phone width. Touch targets, scrolling behaviour and font rendering all differ.

Check the states: an empty category, a long title, a missing image, a focused form field. These are where the difference between a careful build and a quick one shows.

And check it with the editor in mind: can the person maintaining this site produce a new page that looks right, without a developer?