From handoffs to hands on

I've been designing and building products for over 25 years. I've shipped enterprise platforms, AI-powered products, boutique client projects, e-commerce flows — the full range. I split my time between full-time product design for Triple Eye Partners (iii.partners) and running a solo design practice. And for most of that career, regardless of the scale, I followed the same workflow every other product designer follows. The one we all pretend works fine.

It doesn't work fine.

Here's what it actually looks like:

You start with the idea. Use cases, user flows, screen design. This is the best part — pure creative problem-solving with no friction. You're mapping real human needs to interface decisions, and the work feels alive. You refine it against the current product, make sure it fits, account for technical constraints. This is where the design is sharpest.

Then you build a static frontend view. A high-fidelity representation of what the thing should be. Every spacing decision, every interaction hint, every state accounted for. You've spent real time here. The design is right.

Now comes the handoff.

You write up the use case. You document expected behaviors, edge cases, responsive breakpoints. You annotate the hell out of your designs because you know what's about to happen — interpretation. You hand this carefully constructed package to a frontend developer, and the telephone game begins.

The first build comes back. It's close. Maybe 80%. The padding's off. The loading state doesn't quite match. The empty state you designed got skipped entirely. A hover interaction is missing. There's a div nested inside another div nested inside a third div, all with display: flex and justify-content: center, and you quietly wonder if there is meaning behind this suffering.

These aren't failures on the developer's part — they're the natural cost of translating one person's vision through another person's hands.

So you iterate. You hop on a call. You leave comments in the PR. You redline screenshots. Sometimes you jump into the code yourself — not to build, but to adjust. You're tweaking margins in a codebase someone else structured. You're polishing within constraints you didn't set.

Eventually you validate. The use case works. Edge cases get caught and fixed. Bugs get filed, triaged, resolved. And then you push to production.

The thing ships. It's good. It works. Users are fine with it.

But you know.

You know it's 75% of what you designed. Maybe 80 on a good day. Not because anyone failed. Because the process itself is lossy. Every handoff leaks fidelity. Every translation loses nuance. The gap between what you envisioned and what shipped isn't a bug — it's a feature of the workflow. (Though if you filed it as a bug, it would end up in the backlog, and eventually deleted.)

The Real Cost of the Gap

I want to talk about this gap honestly, because I think most designers have made peace with it in a way that isn't healthy. We've internalized it. "That's just how product development works." And sure, maybe it was. For a long time, there wasn't an alternative. You either designed things or you built things. If you did both — and in my solo practice, I did both — you were still splitting the work into two phases. Design exploration in one tool, code translation in another. Two hats, worn sequentially, never at the same time.

The real cost isn't the visual discrepancies, though. It's something more fundamental.

When you design a product, you hold the full picture in your head. You understand why that button is 12px from the edge and not 16. You know why the error state uses a different layout than the success state. You designed the micro-interaction because it reinforces the mental model you're building for the user. These decisions aren't aesthetic preferences — they're functional choices tied to how someone will actually use the thing.

The moment you hand that off, you lose authorship. Not credit — authorship. The ability to make real-time decisions as the thing takes shape. A developer implementing your spec is solving a different problem than you were. They're asking "how do I build this?" You were asking "how should this feel?" Both are valid. But only one of those questions produces the product you designed.

I've been on both sides. I've been the designer waiting on a build that doesn't match. I've been the developer-designer hybrid trying to fix it in someone else's code. And in my solo practice, I've been both roles at once — designing in Sketch, then switching hats to translate my own designs into code. No handoff to another person, but still a handoff between two modes of thinking. Still the same friction of moving from vision to implementation, even when both lived in the same brain. Neither approach gives you the thing you actually want: direct translation from intent to implementation with zero loss.

Where This Is Going

That's where this story is going.

I'm not writing this to complain about developers or handoff culture or Agile ceremonies. (Okay, maybe a little about the ceremonies. Nobody needs a 45-minute refinement session for a button color change.) I've worked with brilliant engineers who made my designs better. That will always be true.

What I am saying is that for the first time in my career, the workflow has fundamentally changed. Not incrementally. Not "a better Figma plugin" or "improved design tokens." A structural shift in how a designer can take an idea from concept to production.

My next post will get into the specifics — what the new workflow actually looks like, how it changes the way I think about design, and why it's the biggest unlock I've experienced in 25 years of building products.

But the starting point matters. Before you can understand what changed, you need to feel what it was like before. And if you've been designing products for any length of time, I'm guessing you already do.

This is Part 1 of a series on moving from a traditional design-to-development workflow to a code-first approach powered by AI. Next up: the moment everything shifted.