Design and engineering should not be separate stages

Most digital work is still organised as a relay. Design produces screens. Engineering receives them and builds. There is a handoff in the middle, usually with a document attached.

It is a tidy arrangement and it produces a specific, recognisable kind of bad product: one that looked excellent before it existed.

What the handoff actually hides

A design file is a best case. Every name is the right length. Every list has exactly enough items to fill the space. Every image is the correct aspect ratio, every price is two digits, nobody has a long surname, and the network is fast.

Production is not a best case. It is where a product title runs to ninety characters, a category has one item in it instead of six, and someone loads the page on a train.

When design and engineering are separate stages, nobody owns the gap between those two worlds. The designer never sees the ninety-character title. The engineer sees it, has no mandate to redesign, and makes a judgement call under deadline. That call becomes the product.

Multiply it across a few hundred small decisions and you get software that feels subtly wrong in a way no one can point at. Every individual compromise was reasonable. Nobody was ever asked whether the accumulation was.

The empty state problem

Here is the tell. Ask to see the empty states.

Almost every design presents a system that is already full: populated dashboards, active orders, healthy lists. But the first thing a new user meets is the empty version, and the moment a product is under stress is when something has failed or returned nothing.

Those screens are the ones that get designed last or not at all, because they are not what anyone wants to look at in a review. They are also the screens that decide whether someone stays.

Teams that design and build together tend to catch this early, for an unglamorous reason: whoever is writing the code has to render something when the array is empty, and they ask the question while there is still time to answer it well.

Constraints are design material

The strongest argument for keeping the two together is not about catching errors. It is that technical constraints are useful design input, and they arrive too late to use when they arrive as objections.

If a piece of data takes two seconds to fetch, that is not an engineering problem to be solved quietly. It is a fact about the interface. It might mean showing partial results, or restructuring the screen so the slow part is not blocking, or deciding the data is not worth showing. Those are design decisions, and they are better ones when the constraint is known at the start rather than discovered during build.

The same is true in reverse. Engineers who understand what a screen is trying to achieve make better calls when reality diverges from the file, and it always does.

What this looks like in practice

It does not require one person who does both jobs. Those people exist and they are rare, and building a team around finding them is not a plan.

What it requires is that the two disciplines are in the same conversation from the start, and that neither one signs off and walks away.

Concretely: prototype in the real medium early, so decisions are made against something that behaves rather than something that is drawn. Design the failure and empty states in the same pass as the happy path, not as cleanup. Let engineering raise constraints while they are still cheap to design around. And keep whoever designed it involved through build, so the hundred small judgement calls are made by someone who knows what the thing is for.

None of this is exotic. It is mostly a refusal to treat the handoff as the natural shape of the work.

Why we work this way

We are a small studio, so we get this partly by default. But we would organise it this way regardless, because the alternative produces work that reviews well and holds up badly.

A design that cannot survive real data was never finished. It was just a picture of a product.