Design and engineering: same team or handoff?
The handoff model is the default in most agencies. We have never done it that way. Here is what twenty-two years of integrated teams has taught us.
We founded Yonescat in 2003 with one conviction: designers and engineers working in the same room produce better software than designers and engineers working in sequence. That conviction has not changed. The evidence for it has only accumulated.
What the handoff model costs
In the typical agency or in-house model, a designer produces a specification — wireframes, prototypes, a Figma file — and hands it to an engineering team. The engineering team interprets it, builds it, and returns questions. The designer answers questions about intent. Revisions follow. Eventually something ships.
Every step in that process is a lossy translation. The designer encodes their intent into a static document. The engineer decodes it into code. Something is always lost in transmission — usually the reasoning behind a decision, which means the engineer cannot make good judgment calls when implementation constraints arise.
The result is software that looks like the spec but does not behave like the intent. Interactions that felt obvious in the prototype feel wrong in the browser. Edge cases that never appeared in the design file surface in engineering and get resolved arbitrarily. The designer reviews the built version and issues correction notes. Another round.
We have watched this process run on projects at other studios. The overhead is enormous. Weeks of a project timeline can disappear into handoff cycles that would not exist if the people making design decisions and the people making engineering decisions were the same people, or at minimum were in constant contact.
What one team actually means
When we say designers and engineers work as one team, we mean they are in the same conversations from the start. Not that designers code, or that engineers do visual design — though some of ours do both — but that the constraint surface is shared.
When we were building the Royal Astronomical Society's website, the content structure, navigation, and visual design decisions were made with an eye to how they would be implemented. There was no spec to interpret. There was a shared understanding of what we were building and why, and the work proceeded accordingly.
When we built iQiD — a national digital identity platform — the KYC flow required both deep UX thinking (the emotional state of a user trying to prove their identity under pressure) and deep engineering thinking (biometric thresholds, fallback paths, NFC behaviour across device types). Those two bodies of thinking had to be in the same room at the same time. A handoff model would have produced a flow that looked clean in Figma and broke on a budget Android in bad lighting.
The objection
The obvious objection is specialisation. Designers are better at design. Engineers are better at engineering. Why dilute either?
The answer is that the quality loss from poor communication between specialists exceeds the quality loss from moderate generalism. A slightly less specialised designer who fully understands the implementation context will make better decisions than a highly specialised designer working in isolation. The same applies in reverse.
The handoff model optimises for individual output. The integrated model optimises for the product. Those are different objectives, and the second one matters more.
What this means in practice
We hire for people who are curious about the other discipline. Designers who want to understand why something is hard to build. Engineers who want to understand why something needs to feel a certain way. That curiosity is what makes the model work.
It is not faster in the early stages. Shared context takes time to build. But it is dramatically faster over the life of a project — and it produces software that the people who commissioned it can actually use.