DesignOps promised to make design a first-class function. Design systems promised to eliminate translation drift. Figma-to-code tools promised to close the last mile. Dedicated UI developers promised faithful reproduction. Yet for many teams that have all four in place, the frustration persists. Why?

In the prevailing team dynamic, a designer produces a finished mockup, the dev team implements it. Then the designer reviews, points out what's wrong, the team iterates, and after several sprints the UI arrives at a close enough approximation for the designer to approve. This pattern feels familiar, maybe even comfortable (for the devs at least) because it's the same approach we use with product owners, domain experts, and subject matter experts: business stakeholders whose requirements genuinely emerge through iteration, and it's the most appropriate process for those roles. But it is not appropriate for designers. Designers are peers on the delivery team, contributing finished deliverables the way a backend developer contributes an API. The cycle that follows a design handover isn't refinement of shared understanding; it's correction of failures of reproduction, framed as normal iterative work. That's a fundamental miscategorisation.

This talk names it and grounds it in primary research with designers on how the current arrangement actually feels. And from that, one unavoidable question emerges: if iteration is the wrong process, do we get better at reproducing designs in code with tighter discipline and drift-detection tooling, or do we stop reproducing altogether?