From handoffs to hands on

I’ve been designing and building products for more than 25 years. Enterprise platforms, AI products, e-commerce, client work, the occasional weird little experiment. And for most of that time, I’ve used some version of the same workflow. Design it. Document it. Hand it off. Wait. Review what comes back. Fix the gaps.

We’ve gotten very good at making this process work. I’m not convinced it works particularly well.

The Cost of Translation

Here’s how it usually goes.

You start with the problem. You work through the use cases, user flows, and screen designs. You consider the constraints, figure out how the pieces fit together, and refine the experience until the decisions feel right. This is the part I enjoy most. You’re solving problems, thinking about how people will use the product, and making decisions while everything is still flexible.

Then you build the high-fidelity design. Every spacing decision, interaction, and state has been considered. The design is finally communicating exactly what you have in mind.

Now comes the handoff. You document the use case, describe expected behavior, annotate responsive breakpoints, and account for edge cases. You add enough detail that the person building it should have no trouble understanding what you intended. And then they build it.

The first version comes back. It’s close. Maybe 80%. The padding is off. The loading state isn’t quite right. The empty state disappeared. A hover interaction never made it into the build. And somewhere there’s a div inside a div inside a div, all of them using display: flex and justify-content: center, and you briefly wonder what you did to deserve this.

None of that necessarily means the developer did a bad job. It means translation has a cost.

You go back through the implementation, leave comments, mark up screenshots, and explain what needs to change. Sometimes you jump into the code yourself, adjusting margins and fixing details within a codebase someone else structured. Eventually, you get there. The interactions work, the edge cases are covered, and the bugs are fixed. The product ships.

It’s good. It works. Users are fine with it. But you know it’s not quite what you designed. Maybe it’s 75% of the original vision. Maybe 80% on a good day.

The gap isn’t necessarily the result of anyone making a mistake. It’s what happens when an idea passes through multiple stages of interpretation before it becomes a working product.

The Real Cost of the Gap

Visual fidelity is the obvious casualty. The more significant loss is context.

When I’m designing something, I know why the button sits 12px from the edge instead of 16px. I know why the error state uses a different layout from the success state. I know why a particular interaction moves the way it does. Those aren’t arbitrary aesthetic decisions. They’re connected to how the product works and how someone is expected to use it.

When the design crosses a handoff, that context has to travel with it. Some of it makes the trip. Some of it doesn’t.

A developer implementing a specification is solving a different problem from the designer who created it. They’re figuring out how to build the thing. The designer has been working through how it should behave, feel, and communicate. Both perspectives matter. The problem is that the second set of decisions often gets separated from the first.

I’ve worked on both sides of this exchange. I’ve been the designer waiting for a build that doesn’t quite match. I’ve been the person fixing the implementation. And in my own practice, I’ve been both people, designing in Sketch and then switching into developer mode to translate my own work into code.

Even when the designer and developer are the same person, the workflow still creates a handoff. Design first. Implementation second. You’re switching between tools, mental models, and ways of thinking. The design exists in one place, while the working product exists somewhere else. You still have to translate between them.

That’s the part I eventually stopped accepting.

What Actually Changed

This isn’t an argument against developers. I’ve worked with excellent engineers who made my designs better, and I expect that to continue. It’s an argument against the assumption that design and implementation have to be separate phases.

For most of my career, the tools reinforced that separation. I designed in one environment, then moved into another to build what I’d designed. Better prototyping tools made the first part more sophisticated, but they didn’t fundamentally change the relationship between design intent and implementation.

AI-assisted development has changed that relationship. I can describe an interface, generate a working implementation, inspect it in the browser, and adjust the design while looking at the actual result. I don’t have to finish a static representation before I can start evaluating the experience. The feedback loop is short enough that design and implementation can happen together.

That doesn’t eliminate engineering. It changes where the collaboration starts. Instead of handing over a design and asking someone to interpret it, I can arrive with a working implementation and ask them to make it better. That’s a much more interesting conversation.

In the next article, I’ll explain the moment this clicked for me. It wasn’t a big revelation or a particularly complicated project. It was a small change in how I approached a piece of product work, and the implications took a little while to sink in.

After 25 years of working this way, I realized the workflow itself was no longer a given.

Part 1 of the Hands-On series.