What is design system drift, and how do you catch it early?
Design system drift is the slow gap between your system and what ships. The five places it starts, how to spot each one, and how a small team keeps it away.
Nobody decides to break a design system. It drifts.
A hex value goes into the code because the right token wasn’t obvious. A Figma variable gets renamed and the code never hears about it. Someone forks a button “just for this page”. None of these is a big mistake. Together, they’re why people stop trusting the system, and a system people don’t trust stops being used.
This post covers where drift starts, how to spot it, and how a small team keeps it away without adding process.
What design system drift looks like
Drift is any place where the product and the system disagree. On most teams it shows up in five ways.
| Kind of drift | What it looks like | Where you find it |
|---|---|---|
| Raw values | #2563eb in a stylesheet instead of bg-accent-solid | Code |
| Renamed or moved tokens | A Figma variable called primary that code still calls brand | Figma vs code |
| Forked components | ButtonNew, ButtonV2, a “special” card for one page | Code and Figma |
| Stale docs | A usage page that describes last year’s component | Docs |
| Missing modes | Dark mode added later, with half the tokens missing a Dark value | Tokens |
Each one is small. The cost comes from how they stack: every raw value is a place a future token change won’t reach, and every fork is one more thing to update by hand.
Why drift happens on small teams
Drift isn’t a discipline problem. It’s a time problem.
Most design systems are kept by very few people. zeroheight’s Design Systems Report 2026 found that 61% of the design system teams it surveyed have five people or fewer, and 61% say they’re understaffed. When one or two people hold the system together, checking every change isn’t realistic.
Three things make it worse:
- The system lives in several places. Tokens in one tool, components in another, docs somewhere else. Every copy can disagree with the others.
- Changes skip review. A quick fix in code or a rename in Figma doesn’t go through anyone, so nobody sees the gap it opens.
- Nobody owns the check. Everyone assumes someone else is watching for drift.
How to spot drift in an afternoon
You don’t need a tool to start. These checks take a few hours and tell you how far things have drifted.
- Search for raw color values. A quick search finds them:
grep -rnE "#[0-9a-fA-F]{6}\b" src/in your codebase. Every result outside your token files is drift. - Compare token names across Figma and code. Export your Figma variables and put the names next to your code tokens. Renames and orphans show up fast.
- Count your component variants. Search for names like
New,V2,CustomorOld. Each one is a fork that probably should be a variant or a token change. - Check the dates on your docs. Any page older than the last change to its component is suspect.
- Look for missing modes. List every color token and check it has a value for each mode (Light, Dark, and every brand). Gaps are where Dark mode bugs come from.
Write down what you find. The list itself is useful: it tells you which kind of drift costs your team the most.
How to keep drift from coming back
Fixing drift once is easy. Keeping it away is the real work. What works on small teams is less process, not more.
Keep one source of truth
Pick one place where the real values live, and make the other places follow it. If Figma, code and docs each hold their own copy, they will disagree. If one place holds the truth and the others are generated or synced from it, drift has fewer places to start.
Make every change small and reviewed
A token rename that someone looks at before it ships is cheap. One that nobody sees until a release is not. Small changes with a quick review, the way code teams use pull requests, catch most drift before it lands.
Block raw values where you can
The cheapest drift to fix is the drift that never gets in. A lint rule that flags hex values, or a publishing step that refuses components with raw values, stops the most common kind at the door.
Check the system on a schedule
A light check every release (raw values, missing modes) and a deeper one each quarter (Figma vs code vs docs). Put it in the calendar, because “when we have time” never comes.
Where Fenly fits
This is the problem I’m building Fenly for. Fenly is a design system manager for small teams: tokens, components and docs live in one place, and that place is the source of truth.
Every change, whether a person or Pluto (Fenly’s AI agent) makes it, arrives as a change request with its checks, and someone with review rights approves it. Components are built only from tokens, and raw values block publishing. A health score combines token usage, accessibility, docs and Figma parity, with a “Fix with Pluto” option on each issue that drafts the fix for you to review.
Fenly is in early access, opening to small groups from the waitlist. Whatever tool you use, the habits above will keep most drift away on their own.
Questions, answered
They overlap, but drift is more specific. Design debt is any shortcut you plan to fix later. Drift is the gap between the system and the product, and it often grows from shortcuts nobody remembers taking.
A light check every release, and a deeper one once a quarter. The light check is a search for raw values and missing Dark values. The deeper one compares Figma, code and docs side by side.
AI is good at the tedious part, finding every hard-coded value and drafting the fix. It should not apply the fix on its own. In Fenly, Pluto drafts the change and shows its checks, and a person approves it.
Raw color values in your code. They’re the most common kind of drift, the easiest to find with a search, and every one you replace with a token makes the next change cheaper.