Everyone has a theory about why designers and engineers struggle to work together.
The designer says the engineer didn't respect the specs. The engineer says the specs didn't account for reality. Both are usually right. Neither is the actual problem.
The actual problem is that somewhere along the way, someone decided their job was done.
Handoff Is a Myth
The word "handoff" implies a relay race — you run your leg, pass the baton, and stop. That mental model is where most of the friction starts.
I've never seen a product built well that way.
Every project I've been part of that actually worked — where the shipped thing resembled the intended thing — had one thing in common: the conversation never really ended until the product shipped. Not a handoff. Not a review. Back-and-forth, all the way through.
That's not a process insight. It's a mindset shift.
The Gap Is Usually Ego or Assumption
When the back-and-forth doesn't happen, it's rarely because of tools. Rarely even because of time.
It's usually one of two things:
Assumption — each side assumes the other understands the intent. The designer assumes the engineer can feel why the spacing matters. The engineer assumes the designer knows what's technically expensive. Neither says anything. Both ship something slightly off.
Ownership without collaboration — the design is "mine," the code is "yours." Feedback feels like criticism. Iteration feels like failure. So people stop asking.
Both are soft problems. And soft problems don't get solved with better tooling.
What Actually Works
The part of this job I care most about isn't the craft — it's how people communicate, how teams move together, how you build enough trust that someone will tell you your design doesn't work before it gets built wrong.
A few things that have made a real difference:
Involve engineers early — not at the end. Not for sign-off, but for input. An engineer who understands why a design decision was made will implement it better than one just following a spec.
Make your thinking visible. A Figma file full of polished screens tells you what — not why. Notes, annotations, a quick Loom walking through a decision — those close more gaps than documentation ever will.
Ask before you assume. If something shipped differently than designed, the first question isn't "why didn't they follow the spec?" It's "did I communicate this clearly enough?"
Treat iteration as the process, not a failure of it. The back-and-forth isn't a sign something went wrong. It's how good work gets made.
Both Sides of the Table
Being a designer and an engineer hasn't made me better at both by default. What it's done is make me allergic to blame.
When I design something that's hard to build, I feel it. When I implement something that loses the design intent, I feel that too. There's no other side of the table to point at.
That accountability — that inability to disconnect intent from execution — is the closest thing I have to a working philosophy.
The gap between design and engineering isn't technical. It was never technical. It's the gap between people who stopped talking and people who never started.
Next up: how this plays out in practice — building the Codemod (opens in new tab) design system from the ground up.