Handoffs are where good designs go to die. Every designer who's shipped a real product knows this, even if they don't say it out loud.
It's not a process problem. Better specs don't fix it. Figma's dev mode doesn't fix it. Zeplin didn't fix it either. The problem is that intention doesn't survive translation.
What actually gets lost
When you hand off a design, you hand off a snapshot. The developer gets a frame, not a thought process. They don't know that the hover state should feel a little slower because the element is big and fast feels aggressive. They don't know that the empty state copy matters as much as the loaded state. They don't know which edge cases you already considered and which ones you didn't.
Specs document decisions. They don't document the reasoning behind them. And the reasoning is everything.
So the developer makes calls. Small ones, constantly. Most of them are fine. A few of them are the wrong call — not because the developer is bad, but because they didn't have the information, and asking about every micro-decision isn't how anyone ships anything.
What changed when I started building
I spent five years as a software engineer before I ever opened Figma. I left that career to design. Now I'm back at the intersection — designing and building in the same sitting, for the same product.
The shift isn't dramatic. It's just: the design decisions that used to happen in Figma now also happen in the browser. Sometimes the browser wins. A layout that looked clean in the design file looked claustrophobic at 375px. I know because I'm the one who set padding: 16px and then opened Safari and immediately changed it to 24px. No ticket. No comment thread. No async Loom.
Real-time decisions by the person who actually cares about the outcome.
AI closed the skill gap
When I stepped away from engineering in 2019, I wasn't equipped to build production-quality frontends solo. The gap felt too big to close while also doing design work.
Claude and Cursor changed that. Not by writing perfect code — but by making iteration fast enough that I can stay in design-thinking mode while still producing real output. I describe what I want, I review what comes back, I adjust. The loop is fast enough that the creative thread doesn't break.
This is what I mean when I say AI made design engineering tractable for someone like me. Not that it writes the product. It handles the friction points that used to force me to context-switch into pure engineering mode and lose the design thread entirely.
The honest counterpoint
This approach doesn't work everywhere. If you're on a team where design and engineering are genuinely separate disciplines with dedicated specialists — and the product is complex enough that it needs that separation — then a design engineer solo-building everything creates different problems than it solves.
The model works when you have end-to-end ownership of something. It works for solo projects, startup-stage products, design systems, internal tools, and portfolios. It works less well when you're the designer on a ten-person engineering team and "building it yourself" means owning a codebase that six other people also live in.
Know which situation you're in before you evangelize this to your team.
The reframe
The handoff problem feels like a process problem. But it's actually a proximity problem. The further you are from implementation, the more gets lost in translation. Moving closer to implementation — even partially — compresses the loss.
Building what you design isn't the only way to do this. But for me, it's the most direct.
Further reading
- Maggie Appleton on design engineering as a discipline — maggieappleton.com
- Josh Comeau's writing on CSS in the browser, specifically why feel can't be fully speced — joshwcomeau.com