The handover problem: why beautiful designs ship ugly

19 August 2026

Designers hand over a file. Developers build an interpretation of that file. Nobody is wrong, and the result is still worse than what was designed. This gap is structural, and it closes only when the handover stops being a picture.

What a flat file does not say

• What happens at 380px, 768px and 1600px between the three designed widths.
• What the empty, loading and error states look like.
• How a button behaves on focus, on press, while disabled, while submitting.
• Whether that 18px gap is a one-off or an instance of a spacing token.

A developer has to answer all of these to write the code. If the file does not answer them, the developer does, under deadline, and every developer answers slightly differently.

Tokens before screens

Define colour, type, spacing and radius as a named set first. Then the handover conversation changes from 'this grey' to 'surface-2', and a change propagates instead of needing a hunt through forty screens.

A design system is not a style guide. It is a shared vocabulary that makes the hundredth screen cheaper than the tenth.

Ship coded components

The strongest handover we do is a small coded component library alongside the Figma file. Buttons, inputs, cards and the layout primitives, in real markup with real states. Engineering composes screens from them instead of rebuilding the basics on each page.

Design QA is part of the build

Book the designer for review passes during engineering, not after. An hour in week three is worth a week of rework in week nine.