In short
The design-to-development "handoff" treats design and build as separate phases with a wall between them. That wall is where intent gets lost, details get approximated, and rework piles up. Running design and development as one team removes the wall — and most of the waste with it.
The wall nobody defends
Ask anyone whether the handoff is a good idea and they’ll hedge. Nobody actually likes the moment where a finished design is thrown over a wall to a team that wasn’t in the room when it was decided. Yet most studios keep the wall because it’s how the org chart is drawn.
We took the wall down. Here is why.
What the handoff actually costs
A handoff assumes design is "done" before development starts. It never is. The gaps a static file can’t express — the empty state, the error, the loading moment, the awkward breakpoint — get discovered during build, by the people least equipped to make the design call. So they guess. Multiply that by a few hundred small decisions and the shipped product drifts from the intended one. We wrote about the mechanics of that drift in the design-to-development handoff.
The cost isn’t just quality. It’s time. Every guess that’s wrong becomes a review comment, a revision, a re-export, a re-implementation.
Design tokens made the wall unnecessary
Part of what kept design and development separate was translation: designers worked in one vocabulary, developers in another. Design tokens collapse that. When a colour, a spacing step, or a type size is a named token that lives in both the design file and the code, there is nothing to "hand off" — the decision is already shared.
One team, one set of decisions
Running as one team means the person designing the empty state and the person building it are the same conversation, if not the same person. Decisions get made once, by people who understand both the intent and the constraints. This is the core of how we think about product engineering: design and build are one discipline wearing two hats, not two departments passing files.
The difference between a UI and a UX decision stops being a boundary dispute and becomes what it should be — the same team caring about both.
What we do instead
- Design and development start together and stay together for the whole project.
- Tokens and components are the shared source of truth, not a spec document.
- The design "file" is a living reference, not a contract to be fulfilled and forgotten.
- The people who made a decision are the people who ship it.
It is less tidy on an org chart. It produces markedly better products. If that’s how you’d want your next build to run, tell us what you’re making.
Further reading: MDN Web Docs publishes primary guidance behind the practices covered here.
Common questions
Does removing the handoff mean no documentation?
No. It means the documentation is living — shared tokens, components, and references that both design and development use — rather than a static spec handed over once and left to rot.
Do designers and developers need to be the same person?
Not necessarily. What matters is that they work as one team on one set of decisions from the start, so intent and constraints are understood by everyone shipping the work.
Isn’t a handoff more efficient for large teams?
It can feel more organised, but the rework from misread intent usually costs more than the coordination it saves. Shared tokens and a single team scale better than a wall.