From Figma to WordPress: from design tokens to theme.json and blocks, without losing fidelity

Much of my work with agencies starts from a Figma file. The challenge is not making the site look like the design on the 1440-pixel screen: it is keeping it faithful at 375, at 1920, with a three-line heading, with a missing image, in a form's error state, and after the client has been editing the page for six months. This is the method I use to bring a design into WordPress without losing it along the way.

Before the code: reading the file

A technical read of the Figma file before estimating avoids half the problems. What I check:

• variables and styles: are colour, typography, spacing and radii defined as variables, or does each element have its own values?
• components and variants: are buttons, cards and fields components with variants and states, or disconnected copies?
• auto layout: are elements laid out with auto layout, which maps directly to flexbox, or placed by hand?
• reference widths: is there at least a mobile version, and what happens between one width and another?
• states and edge cases: hover, focus, error, empty, loading, long text.

Whatever is missing is flagged to the agency immediately, with precise questions. Guessing behaviour that was never designed is the number one source of revisions.

From tokens to theme.json

Figma variables become the theme's tokens. In WordPress the right place is theme.json:

• palette with the design colours, and custom colours disabled, so the editor does not allow off-system shades;
• typography: families, sizes with fluid values (clamp()) that interpolate between mobile and desktop instead of jumping at each breakpoint;
• spacing as a scale, used by blocks and templates;
• content widths and wide widths.

The benefit is twofold: the front end uses CSS variables generated from a single source, and the editor shows the writer only choices consistent with the design.

From Figma components to blocks

Every recurring component becomes a block or a pattern:

• simple components (buttons, quotes) as block styles on native blocks;
• recurring sections as patterns locked in structure and free in content;
• data-driven components (service cards, team members, events) as custom blocks with defined fields, fed by dedicated content types.

Figma variants become block attributes, not classes added by hand by the editor.

Layout: auto layout, grid and container queries

Auto layout maps to flexbox with gap; Figma grids to CSS Grid. For components that appear in contexts of different widths (a card in a narrow column or a wide section) I use container queries: the component adapts to the space it has, not the window width. That is the difference between a truly reusable component and one that only works where it was drawn.

Where fidelity gets lost

The mistakes I see most in rushed handovers:

• fixed pixel sizes copied from the file, which break at any other width;
• fonts loaded with extra weights or without the right metrics, causing layout shifts on load;
• images without defined aspect ratios and without the responsive sizes generated by the theme;
• focus and error states never designed and therefore never built;
• a page builder used "to save time", producing markup far from the design and leaving consistency to the editor.

Checking with previews

I work on a staging environment with shared previews: the agency compares the site with the file while it is being built, not at the end. The final check covers in-between widths, edge cases, Core Web Vitals and an accessibility pass on contrast, focus and forms.

Handing over to the editor

A theme that is faithful on launch day can lose fidelity within six months if the admin allows too much freedom. That is why the handover includes precise choices:

• patterns locked in structure and free in content, so a section does not fall apart when a block is dragged;
• a limited set of blocks per content type: a service page does not need the whole block catalogue;
• roles with consistent permissions: people writing articles do not edit templates;
• fields with guidance on recommended title and text lengths, which are the first things to break a layout;
• a short guide with the design rules applied to content: image formats, use of headings, alt text.

It is the least visible part of going from Figma to WordPress, and it makes the difference between a site that stays as designed and one that degrades page by page.

My take

Going from Figma to code is the part of the job I enjoy most, and I apply the same logic whatever the destination. When the client needs a panel to manage content, block-based WordPress with theme.json is an excellent choice: that is how I built the Dotcampus site, translating a deliberately unconventional design into blocks the team updates on its own, and the Olio Intini site, faithful to the design supplied by the client.

When no panel is needed, I bring the same tokens into a Tailwind theme for Nuxt, and it is even more direct: Figma variables become the theme variables, one by one. Either way, no page builder: the design deserves code written for it.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely, including white-label. I develop from Figma with tokens, custom blocks and shared previews, and I flag problems in the file before estimating, not after.

If you have a design to build, get in touch: in a call of about 20 minutes we read the file together. The service is in From Figma to WordPress.