A designer updates the spacing on a card component in Figma. Tweaks the border radius. Adjusts a label from 14px to 13px. Publishes the change to the team library. Moves on.
Three weeks later, the developer ships the feature. The spacing is wrong. The border radius is off. The label is 14px. Nobody notices until QA flags it, or worse, until a user does.
This is not a handoff problem. The handoff happened. The designer handed off the original design. The developer received it. The breakdown occurred after: the designer iterated, and the update never propagated to the person building it.
It is one of the most common, least discussed failure modes in product teams.
The Post-Handoff Blind Spot
Most product teams have invested heavily in the handoff moment. Figma annotations, Zeplin specs, design tokens, dev-ready documentation. The initial transfer of intent from designer to developer is better than it has ever been.
But design does not stop at handoff. Designers continue to refine. They respond to feedback from stakeholders. They catch inconsistencies during design reviews. They align with updated brand guidelines. Each of these changes is legitimate, necessary, and invisible to the developer who is already building from the previous version.
Industry data supports the scale of this problem. Research from ScopeMaster suggests that 30 to 50 percent of all software development activity is rework, with a significant portion traced back to evolving requirements and design changes that were not communicated to engineering [1]. When rework does occur, developer productivity drops: typical output falls from 1 COSMIC Function Point per day to roughly 0.75, meaning a task that should take one day balloons to 2.5 days once the original build and subsequent rework are combined [2].
Why This Keeps Happening
The root cause is structural, not personal. Three dynamics converge to make post-handoff drift almost inevitable.
First, design tools and development tools operate on separate version timelines. A designer publishes a component update to the Figma library. That update has no automatic downstream connection to the Jira ticket, the pull request, or the branch the developer is working on. The two systems do not talk to each other. Nathan Curtis at EightShapes has written extensively on this gap, noting that design tools still lack the robust versioning capabilities that code libraries have had for decades [3].
Second, notification fatigue kills signal. Even when designers post updates in Slack or leave comments in Figma, developers are buried in their own workflow. A message that says "updated the card component, check the latest" competes with 40 other notifications that hour. It gets read, acknowledged, and forgotten. The cognitive cost of context-switching from code to a design tool, locating the change, understanding its scope, and mapping it back to in-progress work is high enough that developers rationally deprioritise it.
Third, there is no shared contract for post-handoff changes. Teams define what a handoff looks like. They rarely define what happens when the design changes after handoff. There is no protocol for: who is responsible for flagging the change, how the developer should be notified, what the threshold is for a change significant enough to warrant re-review, or how to version-tag a design update against an in-progress sprint.
The Compounding Cost
The direct cost is rework. A developer builds against a stale design, the discrepancy surfaces in QA, and someone has to go back and fix it. Each rework cycle adds 2 to 4 hours of combined designer and engineer time [4]. Multiply that across a team shipping 10 features per month, and the overhead becomes material.
But the indirect costs are worse. Trust erodes between design and engineering. Developers start to treat design specs as approximate rather than authoritative, because they have learned from experience that the spec they received may already be outdated. This leads to a culture where developers interpret rather than implement, which introduces further drift. Designers, in turn, become frustrated that their refinements are not reflected in the shipped product, and start over-specifying or micro-managing implementation.
The result is a feedback loop: design changes are not propagated, so developers stop trusting specs, so they build loosely, so designers over-specify, so the volume of post-handoff changes increases, so even fewer of them get propagated.
What Actually Fixes This
The solution is not more documentation. It is not better handoff ceremonies. Those address the wrong moment in the workflow. The fix requires three structural changes.
The first is a change ledger tied to implementation. Every post-handoff design change needs to be logged against the ticket or task the developer is actively working on. Not in a general Slack channel. Not as a Figma comment the developer may never revisit. It needs to appear in the same tool the developer uses to track their work. Some teams achieve this with automation: a Figma webhook that posts to the relevant Jira ticket when a linked component is updated. Others do it manually with a simple discipline of tagging the developer on the ticket itself.
The second is a change threshold agreement. Not every design tweak warrants developer attention during active development. Teams need a shared understanding of what constitutes a blocking change (layout restructuring, new states, removed elements) versus a non-blocking refinement (colour adjustments, minor spacing tweaks) that can be batched and addressed after the initial implementation. One SaaS company that formalised this distinction, combined with weekly designer-developer syncs, reduced development rework by 35 percent [5].
The third is a single, timestamped source of truth that both disciplines reference. Design tokens and component libraries help, but only if the developer's implementation is actively synced to them. The real requirement is that when a developer asks "what is the current spec for this component," there is exactly one place to look, and that place reflects the latest version with a clear changelog.
The Deeper Pattern
This problem is a specific instance of a broader pattern in product work: the assumption that information, once shared, stays current. It does not. Knowledge decays the moment it is transferred, because the source continues to evolve while the copy remains static.
Teams that recognise this build systems for continuous synchronisation, not one-time transfer. They treat the design-to-development relationship not as a handoff but as a live connection. The designer does not throw the design over the wall and move on. The developer does not receive the design and close the loop. Both remain connected to a shared, evolving artefact until the feature ships.
The designer made changes. The developer never saw them. It will keep happening until teams stop optimising for the handoff and start optimising for what comes after.
References
[1] ScopeMaster. "Software Rework — How to Reduce It." scopemaster.com.
[2] ScopeMaster. "Software Rework — How to Reduce It." Productivity analysis: 1 CFP/day standard vs 0.75 CFP/day rework.
[3] Nathan Curtis. "Versioning Design Systems." EightShapes, Medium.
[4] UXPin. "10 Ways to Improve Design-to-Development Handoff." uxpin.com.
[5] UXPin. "Design Handoff vs. Manual Handoff: Key Differences." uxpin.com.