Design System Drift Checker
See whether your design system still governs what ships, and where it stopped.
How to use it
Use this checker when teams keep forking components, when the same fix keeps being made twice, or before commissioning any design system work.
It is for design system leads, product designers and frontend engineers who suspect the library and the product have quietly separated.
You need one component family, access to Figma, access to the code, and one running product screen that uses it.
Pick one component family that causes trouble. Buttons and form fields are useful candidates, because most teams already have an opinion about them. Do not try to audit the whole library. Drift is a pattern, and one family traced properly will show you the pattern.
Work through the four traces in order. Write down every difference you find, even the ones that seem trivial. The point is not to catch mistakes but to see where the system loses authority.
Trace 1: Does design agree with itself?
- Is there exactly one definition of this component, or several near-duplicates?
- Are the variants named for what they mean, or for what they look like?
- Does the design file include the disabled, loading, error, empty and overflow states?
- Can a designer tell, from the file alone, which variant to use when?
- Does the file record what the component must not be used for?
Trace 2: Does code match design?
- Does every design variant exist in code, and every code variant in design?
- Do the names match, or do designers and developers use different words for the same thing?
- Are spacing, colour and type coming from shared tokens, or hardcoded locally? If a token pipeline exists, whether through Figma Variables, Tokens Studio, Style Dictionary or something you built, it should be producing both sides from one source.
- Do the states from trace 1 exist in the implementation?
- Does the coded component enforce the rules, or merely allow them?
Trace 3: Does the running product match code?
- Open a real screen. Is this the shared component, or a copy?
- If it is a copy, find out why. The reason is the finding.
- Are there style overrides applied at the point of use?
- Does keyboard focus, screen-reader labelling and touch target size survive in the real context?
- Does the component behave the same with real content as with placeholder content?
Trace 4: Can the system absorb what you just found?
This is the trace most audits skip, and it is usually where the real answer is.
- If a team needed a variant that does not exist, what would they do today?
- How long would that take, and who decides?
- Has anyone actually done it recently, or did they fork instead?
- Who is allowed to say no, and does the organisation respect it?
- When the shared component changes, who migrates the consuming products?
Reading your results
| What you found | What it usually means | Reasonable next move |
|---|---|---|
Differences only in trace 1 | The system is under-specified, not broken | Define states and usage rules before building anything new |
Differences appearing in trace 2 | Design and code have separate sources of truth | Establish correspondence and a check that keeps it |
Differences appearing in trace 3 | The system is advisory rather than governing | Find out what product need caused the first fork |
Trace 4 has no answers | This is a governance problem wearing a component costume | Settle decision rights and response time before more library work |
Forking is rarely laziness. More often it is a product need arriving faster than the system could answer it, which makes each fork useful evidence about the contribution path.
What this does not tell you
It will not tell you whether your design system is worth the investment, how mature it is compared with anyone else's, or whether the architecture is right. It looks at one family and shows you the shape of a problem.
What to do next
If trace 4 came back empty, the reading is probably Design System Governance and Adoption rather than more components. If the differences cluster in trace 2, look at Figma and Storybook Alignment. The design system drift definition explains why some differences are legitimate and some are not.
To have a practitioner trace a family with you, the Design System Audit starts with a free audit on one component family.
Trace a family with a practitioner
The Design System Audit starts with a free audit on one component family.