"That's not what I designed." Five words that kill team morale. The designer sees the implementation and it's wrong. Not dramatically wrong. Subtly wrong. The spacing is off. The hover state is different. The responsive behaviour wasn't what they intended. The developer followed the spec as they understood it. The designer's intent was somewhere else entirely. Both people did their job. The system between them failed.
Why Handoff Breaks
The traditional design-to-development handoff goes like this: designer creates screens in Figma, adds annotations, maybe writes some specs, and passes it to a developer. The developer interprets the screens, builds the feature, and sends it for review. The designer finds fifteen things that aren't right.
This isn't a people problem. It's an information-transfer problem.
Rai: A Figma screen is a snapshot of a single state. It doesn't communicate hover states, loading states, error states, empty states, transition behaviour, responsive breakpoints, or edge cases. A developer looking at a static screen has to infer all of those things. And inference means interpretation, and interpretation means divergence.
John: From the engineering side, a Figma screen also doesn't communicate implementation constraints. That animation the designer imagined might require a library that adds 50KB to the bundle. The layout might break at a screen width that wasn't in the mockups. The data might not arrive in the shape the design assumes. These constraints are invisible until implementation.
3.5h
average weekly time spent by design-dev teams on rework caused by handoff miscommunication
Source: Zeplin Design-Development Workflow Report, 2022
The System That Works
After years of getting this wrong and gradually getting it better, here's what we do now.
1. Design and Development Start Together
Not "design finishes, then development starts." They start at the same time. The designer works on the visual direction while the developer reviews the data model and API shape. They sync daily, not at handoff.
This means the developer understands the design intent from the beginning, not from a spec document. And the designer understands the technical constraints before committing to a direction that's expensive to build.
Rai: The best implementations I've ever reviewed were on projects where the developer was in the design conversations. Not contributing design opinions - contributing feasibility. "This would be straightforward." "This would be complex but achievable." "This would require a fundamental architecture change." That information early saves weeks later.
2. Design Tokens, Not Pixel Specs
We stopped specifying exact pixel values in handoff documents. Instead, we reference design tokens. "This uses spacing-4." "This is the primary colour at 10% opacity." "This is the body-large text style."
This works because both designer and developer reference the same token system. The designer knows what spacing-4 means in Figma. The developer knows what spacing-4 means in code. The mapping is one-to-one. No interpretation required.
When I spec a design using tokens instead of pixels, the implementation matches the design almost perfectly on the first pass. It's the entire point of a design system.
Rainui Teihotua
Chief Creative Officer
3. State Documentation
For every screen, we document the states explicitly:
- Default state. What the user sees initially.
- Loading state. What shows while data is being fetched.
- Empty state. What shows when there's no data.
- Error state. What shows when something goes wrong.
- Hover/focus state. Interactive element behaviour.
- Edge cases. Long text, missing images, partial data.
This sounds like a lot of work. It is. But it's less work than three rounds of review finding missing states.
John: The state documentation changed everything for me. Before, I'd build the happy path and then improvise the edge cases. Now I know what every state looks like before I write a line of code. The build is faster because there are fewer decisions to make during implementation.
4. Responsive Behaviour Is Explicit
"Make it responsive" is not a specification. We document how each layout adapts at specific breakpoints. Not every breakpoint - the ones that matter. Usually three: mobile, tablet-ish, and desktop.
For each, we show what changes:
- Does the layout stack vertically?
- Do columns reduce?
- Does the sidebar collapse?
- What gets hidden on mobile?
- What reorders?
This eliminates the most common responsive implementation problem: the developer and designer had different mental models of how the layout should adapt.
5. The Review Happens Early
We don't wait for the feature to be "done" before the designer reviews it. The developer shows the basic layout first, before polishing. The designer catches structural problems when they're cheap to fix.
The review checklist is short:
- Layout matches the design structurally
- Spacing uses the correct tokens
- Typography uses the correct styles
- Interactive states match the documentation
- Responsive behaviour matches at each breakpoint
- Edge cases are handled as documented
If all six pass, the feature is approved. If any fail, the fix is small because the review happened early.
What We Still Get Wrong
We're not perfect at this. Honest areas where we still struggle:
Animation and transitions. Communicating motion in a static design tool is inherently difficult. We've experimented with prototype links and video references, but there's still a gap between "what the designer imagined" and "what the developer interpreted." We haven't solved this completely.
Complex form interactions. Forms with conditional visibility, dynamic validation, and dependent fields are hard to specify fully. We end up pairing on these rather than specifying them in advance.
Cross-platform consistency. When a feature exists on web and mobile, ensuring consistent behaviour across both requires extra coordination that our system doesn't fully automate.
The Investment
This system takes more time upfront than the traditional handoff. A designer spending half a day documenting states and responsive behaviour is time that wasn't in the old process.
But the total project time is less. We measured it. On projects using this system, design review cycles dropped from an average of three rounds to 1.2 rounds. Developer rework time dropped by roughly 60%. The designer and developer relationship improved because the frustration of "that's not what I designed" largely disappeared.
The upfront investment pays for itself within the first two sprints. After that, it's pure time savings.