Dreabuild
000 %
Loading
← All notes
Process 8 min

The seam between design and engineering

Most projects do not fail in the design phase or the build phase. They fail in the handoff between them. Here is how we removed the handoff instead of trying to improve it.

Written by , CEO & Software Developer

Notes from the studio: the seam between design and engineering

Where projects actually go wrong

Ask anyone who has shipped a few products where the pain was, and almost nobody says “the design was wrong” or “the engineering was wrong.” They say some version of: the thing that got built was not the thing that got designed, and nobody could point at exactly when that happened.

That gap has a name in most studios. It is called handoff, and it is treated as a process problem to be solved with better documentation. We think that is the wrong diagnosis.

Documentation is a symptom

A handoff needs documentation because two groups of people who do not share context have to transfer intent through an artefact. The redlines, the spec docs, the annotated Figma frames — all of that exists to compensate for the fact that the person who decided and the person who implements are different people, working at different times, answering to different definitions of done.

You can get very good at that transfer. You will still lose something in it, because the interesting decisions are the ones nobody knew to document. What is the hover state of a disabled row inside an empty table? Nobody drew that frame. Somebody still has to decide it, and they will decide it in code, alone, at speed.

What we do instead

We keep the distance small enough that the transfer never happens.

Designers write CSS. Not all of it, and not the architecture. But when a designer can adjust a spacing scale or an easing curve directly in the running build, the twentieth refinement costs the same as the first — so the twentieth refinement actually happens.

Engineers are in the design reviews from week one. Not to approve, and not to estimate. To say “that pattern will be expensive and this near-identical one is free,” while the choice is still cheap to change.

We review in the browser, never in a static frame. A design that has only ever been seen at one width, on one machine, with placeholder text, is a hypothesis. Reviewing the real thing early means the awkward breakpoint gets found in week two rather than week nine.

The cost

This is a genuinely more expensive way to staff a project. It needs senior people on both sides who are comfortable being wrong in front of each other, and it does not scale by adding juniors. It is a large part of why we have stayed small on purpose.

What we get back is that the thing we shipped is the thing we designed, and when it is not, we know exactly which conversation changed it.

Next note How to brief a design studio

Got a project that needs this kind of attention?

Start a project