The Figma-to-WordPress Handoff Problem (And How to Fix It Upstream)

The Figma-to-WordPress handoff is the point where two crafts that rarely speak the same language are expected to pass work across cleanly. The designer produces a set of static pictures, perfect at a single size. The developer has to turn those pictures into something that works at every size, on every device, under conditions the pictures never showed. When the result differs from the design, the conversation becomes about fault, and fault is the least useful thing to discuss, because neither side owns the actual problem. The designer owns the design. The developer owns the build. Nobody owns the translation between them, and the translation is where everything goes wrong. A handoff problem is an ownership gap, not a competence gap.

The friction is structural, not personal, and it helps to see why. Figma is built for infinite freedom: any element can be any size, any colour, placed anywhere, with no cost to inconsistency. WordPress, built with a page builder, is the opposite: it works best as a system of reusable parts, a defined set of styles, spacing, and components applied consistently across the site. The two pull in opposite directions. A design that uses Figma’s freedom fully, slightly different spacing on every section, a dozen near-identical greys, headings at nine sizes that should be four, is natural to draw and painful to build, because every inconsistency the designer did not notice becomes a decision the developer has to make. Reproduce the inconsistency faithfully and the build becomes an unmaintainable tangle. Quietly correct it and the design team says the build is wrong. The disagreement is baked into the tools.

The specific failures recur on almost every project, and they are worth naming, because each one is preventable:

• Responsive behaviour is undefined. The design shows one width. What happens between that width and a phone is left for the developer to invent, then judged against a picture that never specified it.
• States and edge cases are missing. The design shows the happy path: the full button, the short heading, the three perfect items. The hover, the error, the empty list, or the heading that runs to three lines is anyone’s guess.
• The system is implied, not defined. There is no stated type scale, spacing scale, or set of components, so the developer reverse-engineers one from the pixels, and reverse-engineering is guessing.
• Components are not really components. The same card is drawn six times with small differences, and the developer cannot tell which differences are intentional and which are drift.
• The file has no structure. Layers named generically, nothing that maps to how a site is organised, so nothing in the file tells the developer what anything is meant to be.

None of these is a building problem. Every one of them is a decision that was never made, handed to the person least able to make it.

These failures persist because of how the work is arranged: design and development as two separate phases, with a wall between them and a handoff over the top. Design finishes, throws the file over the wall, and moves on. Development catches it, discovers everything that was not decided, makes the decisions alone, and builds. Design reviews the result, finds the decisions it would have made differently, and sends it back. The cycle burns time and budget on both sides and leaves each convinced the other is the problem. But the wall is the problem. Two competent teams, separated by a handoff and a set of undecided questions, will produce this every time, no matter how good either of them is. Fixing the people does nothing. The arrangement has to change.

Here is the part that matters: a handoff problem cannot be fixed at the handoff. By the time the file is passed across, the decisions that cause the trouble have already been made, or rather not made, and the only options left are expensive ones, build the inconsistency or argue about it. The fix is upstream, in how the design is created, before it is ever handed over. That does not mean designers should think like developers or compromise the work. It means the design should be made with the system it will be built on in mind, the behaviour it needs specified, and the developer present early enough to catch the impossible before it is drawn. Three changes upstream remove most of the pain downstream.

A WordPress site built well is a system: a defined type scale, a spacing scale, a colour set, and a library of reusable components. A design made to that same system hands across almost cleanly, because every element already maps to something the build understands. A design made without it has to be forced into a system afterward, which is where inconsistency and bloat come from. The practical version is simple: agree the type scale, the spacing values, the colour tokens, and the core components before the screens are designed, and design the screens from that shared kit. The design stays as good and becomes buildable, because it was drawn in the same language the site will be built in. This is also what keeps the resulting site fast and maintainable rather than a pile of bespoke styling, the kind of accumulation covered in a separate Targetiv article on technical debt.

A static frame describes how the site looks at one moment, at one size, in one state. A website has to work across all of them, and the parts that are not drawn are exactly the parts that come back wrong. Fixing this upstream means deciding the behaviour while designing, not leaving it to be discovered. How does each section reflow on a phone. What are the hover, focus, and error states. What happens when the content is longer, shorter, or absent than the design assumed. None of this requires drawing every case, but it requires deciding the rules and stating them, so the developer is building to a specification rather than guessing and being corrected. A design that specifies behaviour is a design that can be built once instead of three times.

The single most effective change costs the least: involve the developer while the design is still being made, not after it is done. A short review at the right moment catches the things that are easy to draw and impossible or expensive to build, before they are committed to, when changing them is free. It is the difference between a developer saying “this cannot work as drawn” during design, when it is a quick adjustment, and saying it after handoff, when it is a renegotiation. This is why a clean handoff is not really a handoff at all. It is a conversation that started early enough that there was nothing left to argue about by the time the file changed hands. When we work with agencies as a build partner, this is the first thing we ask for: a little time at the design stage, which saves a great deal at the build stage.

A handoff done right is quiet. The design arrives built on an agreed system, so every element maps to a component the build already has. The responsive behaviour and the key states are specified, so there is nothing to guess. The file is structured and named so its intent is legible. And none of it is a surprise, because the developer saw it taking shape and flagged the problems while they were still cheap to fix. What comes back matches what was designed, not because anyone was heroic, but because the hard decisions were made together, upstream, when they were easy. The build becomes the straightforward part, which is exactly how it should be. The work that decides whether a project goes smoothly happens before the first section is built.

• Most Figma-to-WordPress problems are not build failures or design failures. They are decisions that were never made in the gap between the two.
• Figma rewards infinite freedom; WordPress rewards a consistent system. Designs that use Figma’s freedom fully are natural to draw and painful to build.
• The recurring failures are undefined responsive behaviour, missing states and edge cases, an implied rather than defined system, fake components, and unstructured files.
• The blame cycle is caused by the wall between design and development, not by either team. Fixing the people changes nothing.
• A handoff problem cannot be fixed at the handoff. By then the costly decisions are already made.
• Fix it upstream: design to the system the site will be built on, specify behaviour and not just appearance, and bring the developer in before the design is finished.
• A clean handoff is quiet, because the hard decisions were made together, early, when they were cheap.