How I Talk to Developers About Design Fidelity

After years of interface work, the sentence I dread most is: “This doesn’t quite match the design.”

I used to assume developers weren’t being careful enough. Later I realised that most of the time, I simply hadn’t said what “matching” means.

Agree on what has to match

Not every pixel matters equally. In the kickoff I sort the page into three groups: things that must be identical (brand colours, type sizes, key spacing), things with some give (illustration placement, shadows), and things left to the developer’s judgement (how text wraps on unusual screens).

Once that’s settled, review stops being an argument about “two pixels off” and becomes a discussion about which group an item belongs to.

Turn motion into a table

Animation is where fidelity slips most, because a static mockup can’t show it. I now export the motion and write a simple table: duration, easing curve, trigger. Developers build from the table, and the back-and-forth drops by more than half.

Use design tokens instead of redlines

Annotating every colour and spacing value by hand is tiring and error-prone. Make them tokens instead, so a name in the design file is the same name in code, and changing one value updates both. It takes a couple of days up front, and after that every page is paying back instead of paying down debt.

Leave time for review

The last one is the plainest: put “design review” in the schedule as its own line. Without it, review turns into a scramble the night before launch, and nobody is happy.