Same hands, design and code

There is a moment in almost every product project that nobody plans for. The designs are approved, everyone is happy, and the files go over to development. A few weeks later the product comes back, and it is close. The layout is right, the colours are right, the content is there. And yet it feels different. Heavier. Slightly off.

For years I thought that was a quality problem. It is not. It is a translation problem.

What gets lost in the hand-off

A design file describes how a product looks in a few frozen moments. It cannot fully describe how it behaves. What happens when a name is twice as long as the example. How a button feels when you press it. How fast a panel opens, and how it closes. What the screen looks like while it is loading, when it is empty, when something fails.

Those moments make up most of the real experience. In a hand-off, every one of them becomes a guess. A good developer makes good guesses, but they are guessing at decisions the designer already made in their head and never wrote down.

Multiply that by hundreds of small moments and you get the product that is close but not right.

Why I design and build

For a long time my work ended at the design file. Over the years I started building as well, first my own projects in the evenings, then products for real. Today the same hands draw the interface and write the code that runs it.

That changes more than speed. When I design something I already know how it will be built, so the design stays honest. I do not draw things that only work in a static frame. And when I build it, every small decision that was never in the file gets made by the same person who made the big ones. The spacing, the motion, the empty states and the error messages all come from one point of view.

The result is not a perfect copy of the design. It is often better than the design, because the building process teaches you things a static file never could.

Design and code are one decision

We usually talk about design and engineering as two disciplines that need to collaborate. In practice they are the same decision seen from two sides. Choosing a type scale is a design decision and a code decision. Choosing how a list behaves when it gets long is a usability decision and a performance decision.

When one person holds both sides, the decision only has to be made once. There is no meeting to align, no ticket to explain what was meant, no review cycle to catch what was lost. That is where most of the time goes in a typical project, and almost none of it improves the product.

What this does not mean

It does not mean one person should build everything alone. Larger products need more people, and I work with designers and engineers I trust. It also does not mean designers should all learn to code, or the other way round. Specialists matter.

What it means is that the core of a product, its structure, its components and the way it feels, should come from one coherent mind. The team can grow around that core. But if the core is split between a design team and a build team from day one, the product will feel split too.

The test I use

When a product is finished, I go through it the way a first-time user would. Not the happy path from the presentation, but the real one. The slow connection. The form with a mistake in it. The page with no data yet.

If those moments feel as considered as the hero section, the product was made by people who cared about the whole thing. If they feel like an afterthought, it was handed over somewhere along the way.

Users never see the design file. They only see what was built. That is the version that has to be right.