There is a line item in most design-to-dev workflows that does not appear on any sprint board and does not surface in any retrospective: the time spent re-deriving token context from a flat mockup. It is absorbed as a normal overhead of doing implementation work. It is also, in teams with established design systems, almost entirely avoidable.
When we started building Flowstep, we spent time talking with designers and developers at early-stage product teams about their handoff workflows. Not enterprise orgs with dedicated DS infrastructure, but teams of three to eight people who had invested in building a real design system and were using it inconsistently because the handoff medium kept losing the context.
The cost pattern was consistent across these conversations. It does not show up in one place. It shows up distributed across the sprint in small increments that each feel like normal implementation work rather than overhead that could be eliminated.
The re-derivation tax
When a developer receives a flat image of a screen, they perform a set of interpretation tasks before writing a single line of implementation code. Those tasks have a name: token re-derivation. The developer looks at a button color and asks: is this --color-interactive-default or is this --color-brand-primary? Those might be visually the same in the current design system. The distinction matters for which component they use and whether a token update will propagate correctly.
They look at a card border and ask: is this --border-surface-default or is this a 1px solid using --color-border-neutral? They look at the spacing between a label and its input and ask: is this --spacing-sm (8px) or --spacing-component-form-gap (also 8px in the current scale but with different semantics)? Each of these questions is small. A developer familiar with the system can often answer them quickly. But "often" and "always" differ in ways that show up as implementation inconsistencies during QA.
Consider a typical sprint where a designer delivers three screens containing a combined 18 novel components or component states. If each component requires an average of 12 minutes of token re-derivation work (finding the right token names in the design system docs, confirming the mapping against the design system's component library, asking in Slack when uncertain), that is 3.6 hours of non-implementation work per sprint, recurring. Over a quarter, that is more than a week of developer time spent on a problem that exists because the handoff medium dropped the token context.
These are illustrative numbers, not a measured study. The exact figure varies by team size, design system maturity, and how well-documented the token layer is. The structural point holds regardless of the exact hours: re-derivation is a cost, it recurs every sprint, and it scales with the number of new components per sprint rather than decreasing as the system matures.
Why the cost is invisible
The re-derivation tax is invisible for a simple reason: it looks like implementation work. A developer checking which token to apply to a component border looks like a developer working. It does not look like a gap in the handoff process. There is no "token re-derivation" line in Jira. The cost is embedded in implementation estimates and attributed to implementation time.
This makes it structurally difficult to surface. When we ask developers about their workflow, they describe the re-derivation work as "checking the design system docs" or "clarifying with the designer," both of which sound like normal development activities. They are normal. They are also unnecessary when the design system's token context is carried in the handoff file rather than re-derived from a flat image.
The other reason the cost stays invisible is that it is not dramatic. No sprint fails because of re-derivation overhead. Tickets close, features ship, the product moves forward. The cost is a sustained drag rather than a visible blocker, which means it never triggers a retrospective action item.
Where the cost compresses
The re-derivation tax is not uniformly distributed. It is highest in two situations: when a new component type appears for the first time, and when a component is used in a context that differs from its documentation example.
A new component type means there is no prior implementation to reference. The developer has to establish the correct token mapping from scratch. Even in a well-documented system, this requires reading the component spec, cross-referencing the token layer, and sometimes making a judgment call when the spec is ambiguous. If the handoff file carried the token references directly, this work would largely be done.
A component in an unfamiliar context is harder because the developer cannot rely on their memory of how they have implemented it before. A card component used as a settings panel rather than a content card might use a different surface token. A button used as an in-table action might have a size variant that was not used in the standard flow. These contextual variations are where experienced developers diverge in their implementations, producing inconsistencies that QA catches and designers have to address.
What changes when token context is carried in the file
A handoff file that carries the design system's token references changes the implementation task. Instead of "what token should this be?", the question becomes "does this token application look correct?" That is a different kind of check. It is faster and more reliable, because the developer is verifying rather than deriving.
This is not a claim that token-referenced files eliminate all implementation ambiguity. A designer can apply the wrong token just as a developer can guess the wrong one. The difference is that a wrong token application in a structured file is visible and correctable before implementation begins. A wrong guess based on a flat image is invisible until QA.
We are not saying the flat mockup format is worthless. For early-stage concept communication, stakeholder presentations, and design review at a direction level, a flat image is fast and clear. The constraint is narrow: using flat images as the primary handoff artifact in a system with a developed token layer and a developer who needs to implement from that token layer precisely. That specific use case is where the re-derivation cost enters the workflow and compounds over time.
The compounding effect over system maturity
Here is the counterintuitive part: the re-derivation cost does not decrease as a design system matures. In some ways it increases, because a more mature system has more tokens, more component variants, and more documented states, which means more decisions to get right during implementation.
A team with 15 semantic tokens and 6 components has a relatively low re-derivation surface. The tokens are memorable; the components are few. A team with 120 tokens and 40 components, a mature system with real coverage, has a much larger surface. The cost of re-deriving context from a flat image scales with system complexity. The argument for token-referenced handoffs becomes stronger, not weaker, as the design system grows.
