Handing design over to developers without it falling apart

There's a moment in almost every project where the design is signed off, everyone's happy, and then two weeks later you open the staging link and something is just... off. The spacing is a little tight. The blue is slightly the wrong blue. A button that was meant to be full width on mobile is floating in the middle. Nothing is broken exactly, but it doesn't feel like the thing you designed. That gap - between the Figma file and the built version - is where a lot of time and goodwill quietly leaks out.

For a long time I thought the fix was more detailed specs. Annotate every margin, every hover state, every breakpoint. It helps a bit, but it also means you're now maintaining two sources of truth, and the moment something changes in one, the other is wrong. What actually moved the needle for us was designing with the build in mind from the start. Real type scales, not one-off font sizes. A fixed set of spacing values instead of nudging things by 3px until they look right. Components that map to how the developer is actually going to build them, not just visual groupings on a canvas.

When we built the clinic system for PAL Physiotherapy, the thing that made the handoff smooth wasn't the documentation - it was that the design was already built out of a small kit of parts. A card looked the same whether it was showing a patient, an invoice, or an appointment. So the developer wasn't interpreting a hundred screens, he was assembling maybe fifteen pieces in different arrangements. Same story with the Zesti Fusion and PrintX sites - once the parts are consistent, the build stops being a translation exercise.

The other half of it is just talking earlier. We try to get the developer into the file while it's still rough, not after it's polished. That's when it's cheap to hear "that layout is going to be painful on a real screen" or "if we change this one thing, I can reuse a component we already have." By the time the design is pixel-perfect, everyone's emotionally attached to it and those conversations get harder.

None of this is exciting. It's type scales and spacing tokens and a slightly awkward call halfway through. But it's the difference between a build that matches the design and a build that's a decent impression of it. This is most of what our product design and UI/UX work actually is day to day - less about beautiful screens, more about screens that survive the trip into code.