← Back to Writing
The case against pixel-perfect handoffs
Pixel-perfect handoff sounds like rigor. In practice it's often a way of outsourcing decisions that should be made in code, by people who understand the constraints of the medium better than a static file ever will.
I'd rather hand off intent — spacing logic, state behavior, priority — than a frozen picture of one possible outcome.
Designs can also shift responsibility in an unhelpful way. Instead of creating shared understanding, they can turn the handoff into a transfer of ownership: design produces the “correct” picture, and engineering is expected to reproduce it. Questions that should be discussed together are postponed until implementation, where they become more expensive to resolve.
This does not mean details are unimportant. Spacing, typography, hierarchy, and visual consistency matter. Precision is valuable when it communicates a decision. It becomes less useful when it is used to hide uncertainty or to avoid discussing the system behind the screen.
The more useful thing to hand off is not a frozen outcome, but the reasoning that produced it.
What is the layout trying to prioritise? Which elements should remain visible when space becomes limited? Is the spacing fixed, fluid, or based on a consistent scale? What happens when content is longer than expected? Which states are essential, and which are optional? What should happen when the ideal condition is not available?
These questions give implementation teams something more durable than a collection of coordinates. They communicate intent.
A strong handoff might include representative screens, design tokens, component states, responsive rules, content assumptions, and notes about behaviour. It should explain what must remain consistent and where adaptation is expected, while making room for technical knowledge.
This is not an argument for handing over vague ideas and asking developers to “make it work”. Clear documentation still matters. The difference is between documenting a system and documenting a picture.
A system can be tested, reused, and extended. A picture can only be matched.
Collaboration also changes the quality of the result. Engineers understand constraints that are often invisible in the design file: rendering behaviour, performance, browser differences, component architecture, and accessibility. Bringing that knowledge in early can improve the solution rather than merely limit it.
The best implementation may not look identical to the mock-up. It may handle real content better, behave more naturally across breakpoints, or be more accessible. That is not necessarily a failure of fidelity. It can be evidence that the team understood the problem.
The goal of a handoff is not to protect a design from change. It is to help the team make good decisions when change is unavoidable.
Instead of asking, “How do we make the product look exactly like this file?”, we should ask, “What should remain true when this design meets reality?”
That is the difference between handing off pixels and handing off intent.