From Figma to WordPress: how a design becomes a website that works

A design in Figma looks perfect. Every space is measured, the text fits exactly and the images have just the right proportions. Then it reaches WordPress and the questions start. What happens if the client’s headline takes three lines instead of two? How does this look on a phone that is not in the file? Who is going to edit this section six months from now?

I have been moving Figma designs into WordPress for years, and almost every problem I see comes from the same place: the website is treated as a screenshot to copy, when it is really something alive that will keep changing. Here is what I have learned about doing it well.

A website is not a PDF

Figma shows one page, with specific content, at a specific width. WordPress will receive content that changes: longer or shorter text, images with other proportions, and people who are not designers touching everything.

So “faithful to the design” does not mean copying pixels. It means respecting the system: the typography, the spacing, the colors, the hierarchy, the character of the brand. And making sure that system holds up when reality does not look like the mockup.

What helps a lot in the Figma file

If you are a designer or an agency, these things save back-and-forth for both of us:

• A mobile version, at the very least. If there is only a desktop design, somebody has to invent the mobile one, and that somebody usually ends up being the developer. It is better if the person who designed it decides.
• Well-named styles and components. Colors, fonts and buttons defined once and reused. If every button is a hand-drawn variant, I have to guess which one is the right one.
• Element states. What a button looks like on hover, a field with an error, an open menu. Whatever is not in the file gets improvised.
• Real content, or as close as possible. A short “Lorem ipsum” is misleading. A real, long headline shows whether the design holds up.
• Exportable images and icons, with clear licenses if they are not yours.

It does not all have to be perfect. But the more complete the file, the fewer decisions get made blind.

What happens along the way

First the design is reviewed, before touching WordPress

Before building anything I go through the whole file: pages, components, responsive versions. I note what is missing, what is ambiguous and what will be hard to edit. It is much cheaper to sort this out now than with the site half built.

It is built with a page builder, but with judgment

I mostly work with Bricks Builder and Elementor. Both can reproduce a design quite precisely, and the difference is in how they are used: global classes and styles instead of one-off settings on every element, reusable sections, a clean structure. A site built that way can be edited without things breaking. One built from patches cannot.

What almost always gets adjusted

Some things change between Figma and the website, and that is fine:

• In-between screen sizes. Figma usually has one large desktop and one mobile. The web also lives on tablets, small laptops and huge monitors. Someone has to decide how the design behaves between those points.
• Long text. If a headline grows, the design has to take it without breaking.
• Animations. A Figma prototype can hint at movement that has to be translated carefully on the web, so speed does not suffer.
• What the client needs to edit. A text that is “part of the image” in the design probably needs to be real text: editable, and readable by Google.

It is compared with the design at several sizes

At the end I put the result next to Figma and check it at different screen widths, not just the two in the file. That is where the details no mockup covers show up.

Mistakes I see again and again

1. Building without reviewing the design. The problems show up anyway, only later and at a higher cost.
2. Adjusting everything by hand. A margin changed here, another there, and three months later nobody knows why the site behaves strangely.
3. Ignoring performance. A site that looks identical to the design but takes five seconds to load has not done its job. Properly sized images and little leftover code matter as much as visual fidelity. If that is on your mind, I wrote about why a WordPress site is slow.
4. Not thinking about who will edit it. If the client has to call the developer to change a phone number, something went wrong.
5. Adding design changes along the way without talking about it. It happens, and it is normal, but it is worth deciding whether they fall inside the scope or are handled separately.

How much does it cost?

It depends on how many pages there are, how complex they are and how much interaction, forms or dynamic content they involve. I work at a fixed price: after reviewing the file I send you a closed amount in writing, so you know from the start what you will pay. If you want a rough idea before writing to me, the ranges and a budget estimator are on the pricing page.

A real example

For Eatonville Rising I built an agency’s Figma designs in Elementor. You can see the published site along with screenshots of the original file.

If you already have the design

If you have a Figma file and want it in WordPress, tell me where it stands and, if you can, send me the link. I review it before replying and tell you frankly what I see, what is missing and what it would cost. You can see how I work on the Figma to WordPress page.