A colour that no longer matches its token, a spacing value typed by hand, a component rebuilt locally instead of reused. Each is small; together they pull production away from the system. A single difference like these is called a divergence. FISYCO calls each one a difference and lists it on the Differences tab: a component that differs from its design, a token bypass, an inline asset copy or a home-made twin.
Where drift comes from
Drift doesn't need one big mistake. It comes from ordinary work:
- a value copied from Figma instead of read from a design token;
- a token renamed in design but not in code;
- a component patched locally under deadline and never merged back;
- a primitive used where a semantic token belongs, so a theme or mode change misses it.
What one divergence records
A useful record of a divergence answers three questions:
- Which side moved. The design changed and code hasn't followed, or code wandered off the design. This is different from who moves next.
- How serious it is. Its change class: breaking, additive or cosmetic.
- How much it touches. Its reach across the product.
Together, they say who takes the next step and what to fix first.
Why it stays invisible
Nobody owns the gap. Designers see Figma, developers see code, and reviews compare each against itself, not against the other. A drifted button still works, so nothing fails until a rebrand or an audit finds dozens of places to fix at once. In Sparkbox's 2022 design systems survey, 37% of maintainers named parity between design and code as a top challenge (Sparkbox).
How teams keep it in check
Three habits keep it in check:
- Deliver design changes to code as reviewed pull requests.
- Compare design and code by stable token IDs, not by eye.
- Measure drift regularly instead of discovering it during a redesign.
Related
- Why production quietly drifts from your design system: causes and costs in detail.
- How to measure design system health
- Differences in FISYCO: who moves next on each difference, and how to fix or dismiss it.