The Design Handoff Is a Lie: Why Your Engineers and Designers Are Playing Telephone

Namfon hadn’t said a word in five minutes. She sat three seats from the projector, scrolling slowly through the Figma file on her laptop while the designer walked the room through pixel-perfect mockups of a new form. The PO was nodding. The designer was clicking. Namfon’s colleague Somchai leaned over and whispered something in Thai — something about a WCF backend, from what I could piece together. Their keyboards had gone quiet. That’s always the tell.

Then came planning poker. The cards flipped: 15, 18, 25, 18. The engineer who’d put down 15 immediately backtracked — “I think I’m too low, I’m fine to go higher.” The PO looked stunned. So did the designer. And then came the question that made me intervene: “How can we get this done faster, guys?”

That’s the wrong question. And I’ve written about why it’s the wrong question before. But today I want to talk about what caused it — because the real problem happened long before anyone flipped a card.

The Telephone Game You’re Playing Without Realising

Here’s what actually happened in that meeting. A designer, working in good faith, had spent weeks producing a high-fidelity design. Beautiful work. Thorough. Every state accounted for, every pixel considered. And when something looks that polished, that finished, it doesn’t look like something you’re allowed to challenge. It looks like a decision that’s already been made.

So when those engineers were whispering in Thai — and I can speak a bit of Thai, enough to get taxis, order food, and know when my staff are talking about me — they weren’t being rude. They were trying to figure out how to build something that connected to three separate backends, one of which was a legacy WCF service that’s notoriously difficult to integrate with from our newer systems. They were solving an engineering problem that nobody had discussed with them before committing it to high-fidelity pixels.

I stopped the meeting. “What’s the hardest part about building this form?” I asked. They looked at each other. Namfon spoke up: “It’s connecting to the legacy WCF service.” “Right,” I said. “How many fields use that?” “One,” she replied. “OK, then let’s re-estimate it without that one field.”

Planning poker again: 8, 10, 12, 8.

One field. That’s the difference between a two-week effort and a one-week effort. One field that nobody questioned because the design looked done.

John Cleese, in his famous 1991 lecture on creativity, observed that “creativity is not a talent. It is a way of operating.” He wasn’t talking about software, but he perfectly described what was missing from that room. Creativity in product development isn’t about having brilliant ideas in isolation — it’s about operating in a way that allows the right conversations to happen before you’ve committed to a direction. When design becomes a document instead of a conversation, you’ve already lost that operating mode.

Why High-Fidelity Handoffs Kill the Wrong Darlings

The handoff model — designer designs, then throws specs over the wall to engineering — makes an implicit assumption: that the design problem and the engineering problem can be solved sequentially. First you figure out what to build. Then you figure out how to build it.

This assumption is wrong more often than most teams are willing to admit.

When you present engineers with a polished, high-fidelity design, you’re doing two things simultaneously. First, you’re signalling that the thinking phase is over and the building phase has begun. Second, you’re making it psychologically difficult for anyone — particularly younger engineers or those with less confidence — to push back. Challenging a wireframe sketch feels like collaboration. Challenging a polished Figma file with interactive prototypes, design tokens, and pixel-perfect spacing feels like obstruction.

The PO asked the wrong question — “how can we get this done faster?” — because from their perspective, the what was settled. The only variable left was the how. But the engineers knew something the PO didn’t: that one legacy integration was going to dominate the entire effort. If that conversation had happened at the wireframe stage, someone would have asked whether that single field was worth doubling the estimate for the entire form. At the high-fidelity stage, nobody felt comfortable asking.

What Pixar Figured Out Decades Ago

There’s a model for doing this better, and it comes from a place you wouldn’t expect: animation.

In Ed Catmull’s Creativity, Inc., he describes a practice at Pixar called the Brain Trust. It has a specific structure that I think every product team should study, because it solves exactly the dysfunction we’re talking about.

The Brain Trust works on three principles that translate directly to how engineering teams should operate.

First, no authority, only candor. The Brain Trust gives notes, but the director isn’t obligated to act on any of them. As Catmull writes, “we don’t want the Braintrust to solve a director’s problem because we believe that, in all likelihood, our solution won’t be as good as the one the director and his or her creative team comes up with.” This removes the politics entirely. Applied to product teams, it means design reviews where engineers give real feedback on feasibility and UX concerns without it becoming a power struggle over who “owns” the experience. The feedback is in service of the work, not in competition with it.

Second, show work early and ugly. Pixar screens rough cuts that are, by Catmull’s own admission, embarrassing. The product team equivalent: prototyping in code early, not waiting for polished designs. Rough interactive prototypes beat beautiful static mocks because they expose the things Figma can’t show — latency, state transitions, edge cases, how it feels to actually use something. If that form had been a rough prototype first, the engineers would have hit the WCF wall immediately, and the conversation about whether to include that field would have happened naturally.

Third, the room composition matters. Brain Trust sessions include directors, writers, and producers — people with different lenses on the same problem. The engineering equivalent: getting design, engineering, and product into the same room at problem definition time, not at solution review time. By the time you’re reviewing solutions, it’s too late. The decisions have already calcified into pixels.

The PO Who Does This Right

I have one PO who does this brilliantly. A full quarter out from delivery, he has low-fidelity designs — sketches, really — and he reviews them with the engineers. Not for detailed estimates. Not for sprint planning. Just for a conversation: “Here’s roughly what we’re thinking. What’s hard? What’s easy? Where are the landmines?”

The engineers give high-level estimates for end-of-quarter planning. The designs evolve based on what they learn. By the time high-fidelity work begins, the engineering constraints are already baked in. Nobody’s surprised by a WCF integration because it was surfaced and discussed months ago.

We’re trying to roll this practice out to other teams. It doesn’t always work — not all teams can plan that far in advance, and some problem spaces genuinely require discovery closer to implementation. But where it does work, the results are dramatic: fewer surprises in planning, more accurate estimates, and engineers who feel like collaborators rather than order-takers.

The CSS Explosion: What Happens at Scale Without Alignment

Let me tell you what happens when design and engineering operate in separate universes for long enough. At Agoda, almost a decade ago, we used pixel-perfect designs from designers. The designers would review designs together and achieve general consistency, but not at the pixel level. Each variation, each slight difference in spacing or colour, generated a chunk of custom CSS for that specific piece of UI. Almost no reusability. Multiply that by hundreds of engineers over a couple of years, and the volume of CSS we had exploded into something unmanageable.

The engineers were screaming for reusability. At first, they wanted code-level solutions — a shared component library. We built one. It helped, but it didn’t solve the root problem because the designers weren’t involved. The components were engineering abstractions that didn’t map to how designers thought about the interface.

So the next evolution was a proper design system — a holistic replacement for the old component library that included designers as first-class participants. It enforced design conformity, dramatically reduced the custom CSS generated per task, and made things generally consistent. When your design system components map one-to-one with your frontend components, designers can compose screens knowing exactly what’s buildable, and engineers can implement knowing exactly what’s intended. The telephone gap shrinks to near-zero for standard patterns, freeing up collaboration time for the genuinely novel interactions that actually need creative problem-solving.

But I wouldn’t start down this road unless you have the resources to properly staff it. If you’re a smaller team, you might be better off adopting an open-source design system and customising it to your needs. We actually do this for our internal tooling — we use open-source design systems there because the requirements are lighter. Our public-facing design system needs to handle things like accessibility compliance and internationalisation (including right-to-left languages), which aren’t necessary for internal tools. Know your requirements before you build.

The Ownership Lesson We Learned the Hard Way

That first component library taught us something painful about ownership, and it connects directly to what I’ve written about in The Taste Gap — shared taste doesn’t emerge from shared ownership unless the culture already supports it.

We tried collective ownership of the component library. It failed.

Not immediately. It worked while we had a few motivated individuals championing it. They cared deeply, they reviewed contributions, they maintained quality. But after a couple of years, those champions left. And then the spiral began. First, test automation started to degrade — changes were pushed without adequate coverage. Then it tipped, and within a few quarters we had breaking changes everywhere. It never recovered.

Too many owners means no one owns it. We’ve learned this lesson many times. The new design system and its associated component library? We have a dedicated team for that now. It includes designers as full members, not just consumers. And it has excellent test automation using Playwright component tests, so validation is done visually and across multiple browsers.

A word of caution on that last point: if you’re going down the Playwright visual testing route, read what I’ve written about the regenerate button problem. Screenshot-based testing is powerful but comes with its own set of traps — environment differences between Linux and Mac, rendering engine variations, and the ever-present temptation to regenerate baselines without actually reviewing what changed. It works brilliantly when you have a dedicated team maintaining it. It falls apart when it’s everyone’s responsibility and nobody’s priority.

Creativity as an Operating Mode, Not a Phase in a Pipeline

The fundamental mistake in the handoff model is treating creativity as something that happens in a specific phase — the design phase — and then stops. As if building software were a relay race where the baton passes cleanly from one discipline to the next.

It’s not. It’s more like jazz. Everyone plays at the same time. The drummer responds to the pianist. The saxophone adjusts to the rhythm section. The music emerges from the interaction, not from one person composing a score and handing it to the others to execute.

As the management theorist Peter Drucker once observed, “The most important thing in communication is hearing what isn’t said.” In that planning meeting, what wasn’t said — because the high-fidelity design discouraged it — was that the engineering constraints should have shaped the design from the beginning. The engineers heard what was being presented. The PO heard the estimates. But nobody heard the silence between them — the conversation about trade-offs that never happened because the format didn’t allow for it.

Involve engineering at the problem stage, not the solution stage. Show work early, when it’s ugly and cheap to change. Build a design system that gives you a shared language so the standard stuff doesn’t need creative collaboration at all, freeing your best minds for the genuinely hard problems. Own that system with a dedicated team. And when someone asks how to get something done faster, ask instead how to make it simpler — because simpler is almost always faster, and it doesn’t come with the same hangover.

The Bottom Line

The design handoff isn’t just inefficient — it’s actively hostile to the kind of creative collaboration that produces great products. It turns engineers into order-takers and designers into people who’ve never had the conversation that would have changed their design. It makes POs ask the wrong questions because they don’t know the right questions exist.

Pixar figured this out decades ago: show ugly work early, give feedback without authority, and make sure the room has everyone who needs to be there. Your product team isn’t making animated films, but the dynamics are identical. Creative work requires creative operating modes, and those modes require the right people in the room at the right time.

The next time you see a perfectly polished Figma file land in a planning meeting and watch the estimates double, ask yourself: was this a design problem, an engineering problem, or a conversation that never happened?

Now, if you’ll excuse me, I need to go sit in on a planning meeting. They’re estimating a new feature, and I have a feeling there’s a WCF field in there somewhere that nobody’s questioned yet.

References & Further Reading:

Ed Catmull, Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration (Random House, 2014)John Cleese, Lecture on Creativity, Video Arts Conference, 1991Martin Fowler, Code OwnershipPlaywright Component Testing