Ask any senior frontend engineer how much time they spend rebuilding components that already exist in the design system. You'll get a pause before the answer, because the honest answer is uncomfortable.
Ask any design manager how many sprints include at least one round of implementation review where the result doesn't match the design. The honest answer is almost all of them.
These are symptoms of the same problem: a design-to-code handoff process that's generating work nobody is tracking as a cost. It shows up in individual tickets as "implementation feedback," in velocity data as unexplained slowdowns, and in retrospectives as a persistent frustration that never quite rises to the level of a formal initiative.
At small scale, it's manageable friction. At enterprise scale, it's a structural tax on engineering output — one that compounds with team size, product surface area, and the distance between design and engineering.
The parallel-work problem
The most expensive version of handoff failure isn't miscommunication. It's parallel work: two people solving the same problem independently because neither knew the other had already solved it.
A developer working on a new product area needs a data table with sortable columns. The design system team built one six months ago. But the designs handed off to the developer are custom Figma frames, not components from the shared library — because the designer who created them was newer to the team and didn't know the system well enough to find the existing component. The developer implements the table from scratch. A review catches the duplication three weeks later, after the implementation is complete and tested.
Now there are two data tables in the codebase. Both need to be maintained. The one that was just built probably diverges from the design system's accessibility and token standards, because it was built in isolation. Someone will need to migrate it. Nobody knows when.
This pattern is not rare. In large organizations with multiple product teams, partial design system adoption, and inconsistent onboarding, it plays out constantly. The individual instances are small enough that they don't generate escalations. The aggregate is significant.
The scorecard asks directly: do developers regularly rebuild components that already exist in the library? If the honest answer is "sometimes" or "more than we'd like," the parallel-work problem is active in your organization.
The translation tax
Even when developers aren't rebuilding from scratch, the handoff process often requires translation work that shouldn't be necessary.
Design files that use custom Figma frames instead of shared components force developers to interpret rather than implement. The developer looks at a design, identifies the pattern, finds the closest existing component, and makes judgment calls about how closely the design should be followed. Those judgment calls are never fully consistent. Two developers interpreting the same ambiguous design will produce implementations that differ in small ways — spacing, font weight, border radius — that accumulate into visual inconsistency across the product.
Token mismatches compound this. When designers specify colors using Figma style names that don't map to the token names in code, developers translate: they look at the color value in the Inspect panel, find the closest matching token, and hope it's the right one. When it isn't, the visual output is close but not correct. The mismatches are subtle enough that they survive initial review and accumulate in the codebase over time.
The translation tax is paid on every handoff, by every developer, across every sprint. It's not visible as a line item in any project plan. It's visible only in aggregate, as a sustained gap between estimated and actual implementation time, and as the persistent sense that the design-to-code workflow is slower than it should be.
The review cycle overhead
Handoff failures that do get caught generate review cycles. A developer implements a design. A designer reviews the implementation. The result doesn't match. Feedback gets written up, the developer context-switches back, the fix ships, and the process repeats until the implementation is close enough.
In a well-functioning handoff process, this cycle is short: the design was unambiguous, the implementation is close on the first try, and review is a quick confirmation. In a broken handoff process, the cycle is long: the design was ambiguous, the implementation reflects the developer's best interpretation, and review produces a list of corrections.
Multiply a two-day review cycle by the number of features that touch the UI surface across a sprint, and the overhead is real. It affects delivery timelines directly and morale indirectly — designers who spend their time reviewing implementations rather than designing new work, and developers who feel like they can never fully close a ticket, are both less effective over time.
The review cycle overhead also has a ceiling problem. Senior engineers and senior designers are disproportionately involved in resolving handoff ambiguity. They're the ones who know the system well enough to catch the subtle mismatches, and they're the ones who get pulled into reviews. Time spent reviewing implementation fidelity is time not spent on architecture, mentorship, or the complex technical work that only senior people can do. At scale, handoff friction has a real cost to the ceiling of what the most experienced people on the team can contribute.
The version history problem
A broken handoff process usually means nobody owns the version history between design and code.
When a component evolves — the button gets a new variant, the modal gets a size update, the form input gets a new error state — that change needs to propagate in both directions. The Figma library needs to reflect the new version. The component library needs to release an update. Consumer teams need to know a change happened and what it means for their implementations.
When the handoff process doesn't include a clear owner for this propagation, it breaks down predictably. The design gets updated in Figma. The code doesn't. Or the code gets updated in a library release. The Figma file doesn't. Developers implementing new work follow the design; the design is ahead of the code. Or the code is ahead of the design. Nobody is sure which is canonical.
The scorecard's handoff section asks two questions that directly surface this: is there a clear owner responsible for maintaining and evolving the design system, and is there a versioning and changelog process so consumers know what changed between releases? These questions identify whether the structural conditions for version alignment exist, or whether your team is relying on informal coordination to keep design and code in sync.
Informal coordination works until the team gets large enough that it doesn't. In enterprise organizations, it usually stopped working some time ago, and the accumulated divergence between Figma and code is the evidence.
Why this rarely surfaces as a single initiative
The reason handoff failure stays unfixed in large organizations is the same reason most structural design system problems stay unfixed: the cost is distributed across many teams and many tickets, none of which individually rises to the level of an initiative worth resourcing.
No single developer spent three weeks rebuilding a component from scratch. They each spent a few days. No single sprint lost two days to review cycles. Each sprint lost a few hours. From the outside, everything looks approximately fine. The system exists, designs are getting implemented, products are shipping.
From the inside, it feels like running through water. The handoff should be faster than it is. Reviews should be shorter than they are. Components should exist before developers need them. Everyone knows it. Nobody has the authority to fix it unilaterally, because the fix requires both design and engineering to change their workflow simultaneously.
This is why a structured baseline assessment is more useful than an internal conversation. When the handoff section of the Design System Scorecard produces a concrete score across six specific dimensions — whether design files use shared library components, whether token names are shared, whether a new component process exists, whether developers are rebuilding existing work, whether there's a clear system owner, and whether versioning is handled — it creates a shared document of what's actually broken. Not a feeling. Not a retrospective frustration. A specific list.
That list is the starting point for a cross-functional conversation with a defined scope. Which of these six things do we fix first? Who owns it? What does done look like?
Without that baseline, the conversation about handoff improvement stays abstract and stays stuck. With it, it becomes tractable — and the engineering time currently spent on translation, rework, and parallel implementation becomes recoverable.