DesignDesign system adoption stalls: 5 causes and how to fix each
83% of teams that called their design system unsuccessful named adoption a top challenge. The 5 causes of stalled adoption and the fix for each one.
Design system adoption stalls when the infrastructure is in place and the habits are not: the package sits in every repository, the Figma library is published, and new screens still ship with local buttons, detached instances and hex values typed by hand. The install count goes up while real usage stays flat. Below are the five causes we look for when a system stops spreading, and the fix for each one.
The pattern is easy to miss because every infrastructure metric looks healthy. The dependency is there. The tokens build. The documentation site is online. What has not moved is the decision a designer or an engineer makes late on a deadline day: reach for the system, or write the thing locally and move on.
What does stalled adoption look like in a real codebase?
Four signs show up together, and each one can be counted.
- Installed, not imported. Every app lists the package in its dependencies, and a scan shows three or four components carrying almost every import.
- Local look-alikes. A
PrimaryButton.tsxor aCardWrapperin the app folder that reproduces a system component with one prop changed. - Detached instances in design files. Figma logs a detach every time someone breaks the link between an instance and its main component, and library analytics show the count per component (Figma Help Center).
- Raw values in styles. Hex colours and pixel spacings written straight into CSS where a token exists.
None of these is a failure on its own. A detached instance can be a sketch. A local component can be a prototype. The signal is the trend: when the four counts rise release after release while the package version stays current, the system is installed and bypassed.
Why does adoption stall after launch?
Surveys have tracked the problem for years. In Sparkbox's 2021 Design Systems Survey, 44% of in-house respondents selected increasing adoption as a challenge, and adoption has been on that list since the 2018 edition. The same survey ties it to outcomes: among respondents who rated their system "not successful", 83% named adoption as a top challenge, against 9% of those who rated it "very successful" (Sparkbox).
The teams that run systems are stretched as well. zeroheight's Design Systems Report 2026, built on 147 responses, found that 3 in 5 design system teams did not have enough people to meet their goals, and that satisfaction with how the organization secures buy-in fell from 42% to 32% in a year (zeroheight). A small team with weak buy-in can ship the infrastructure. It has far fewer hours left to change how other teams work, and that second job is where adoption is decided.
The five causes we look for
1. The component is missing on the day it is needed
An engineer needs a date range picker on Tuesday. The system has a date picker, and no range. The ticket ships on Thursday. The local version gets written, reviewed and merged, and from then on it is the version that team reuses. Every gap in the catalogue is a fork waiting to happen, and forks outlive the gap: when the system adds the range picker two months later, nobody goes back to swap it in.
Fix: keep a public list of known gaps, each with a planned date, and publish an approved interim pattern for each one: a composition of existing parts, documented in a paragraph. A gap with a sanctioned workaround produces one shared fork instead of six private ones, and one fork is easy to migrate later.
2. Asking costs more than building
If proposing a change to the system means a form, a review meeting and a two-week wait, the rational choice on a deadline is to build locally. Adoption follows the cost of the path. When the contribution path is slower than the workaround, the workaround wins every time it is weighed against a sprint.
Fix: set a response time for contribution requests (two working days for a first answer is a workable target) and a light path for small changes: a prop, a variant, a token. Keep the full review for new components. How we decide what earns a new component at all is in the design system diet.
3. The documentation answers what, not when
A props table and a live example tell a reader what a component does. They do not say when to use it, when to use its neighbour instead, and what to do when neither fits. That is the question a person has at the moment of choice. zeroheight's 2026 research on AI in design systems found that only 17% of 123 respondents rate their documentation "very AI-ready" (zeroheight). Agents and people get stuck on the same missing piece: the rule for choosing.
Fix: add a "When to use" and a "When not to use" block to every component page, each one naming the alternative. Then read the support channel for a month and turn every repeated question into one line of those blocks.
4. Nobody measures usage, so nobody sees the drift
Without a count, a stalled system and a growing one look the same from the inside. The measurement is cheap. Brevo's engineering team runs react-scanner across its repositories in a GitHub Actions matrix, stores the reports, and charts component usage per project in Metabase (Brevo Engineering). On the design side, Figma's library analytics report insertions and detaches per component. The code-side scan is covered in more detail in component drift: how design systems decay.
Fix: track three numbers per product, every month: the share of UI imports that come from the system, the count of local components that duplicate a system one, and the detach rate per library component. Publish them where product teams can see them.
5. Adoption is nobody's goal on the product team
The system team owns the system. The product team owns a roadmap with dates. If no product goal mentions the system, every migration task competes with a feature and loses. The people who would do the adopting are measured on something else.
Fix: write adoption into the product team's own objectives, as a number tied to their screens ("the checkout flow uses only system components by the end of the quarter"), and budget the hours for it in the same plan. With many products on one system, the governance side is in how to govern a design system across 10 consumer projects.
What does stalled adoption cost?
The cost shows up the day the system changes. An accessibility fix to the system button reaches every screen that imports it, and none of the screens that copied it. A rebrand updates the tokens, and the hex values typed by hand keep the old colour. Each fork turns one change into a search through the codebase. To put a figure on that, see design system ROI as a P&L line item.
How do you fix adoption that has already stalled?
- Take a baseline. Run a usage scan on every repository and export the detach report. That gives the three numbers above in an afternoon.
- Rank the forks. List the local look-alikes by how many screens use them, and start from the top.
- Close the gap behind each fork. If a fork exists because a variant is missing, add the variant to the system first, then migrate.
- Migrate with one product team at a time. Pair a system maintainer with that team for a sprint, ship the migration inside their roadmap, and publish the counts before and after.
- Treat detaches as bug reports. A detach on a library component says the component did not fit. Review the ten most detached each month and decide: new variant, better documentation, or accepted exception.
How do you keep it from stalling again?
Put the rules where the work happens. Stylelint's color-no-hex rule flags hex colours in stylesheets (Stylelint), and ESLint's no-restricted-imports can block imports from a deprecated local component folder or from a second UI library (ESLint). A lint rule turns a guideline into a comment on the pull request, at the moment the choice is made.
Then keep the three counts on a monthly calendar, keep the contribution response time, and keep the gap list public. Adoption holds as long as using the system stays the cheapest path for the person with the deadline.
Sources
Frequently asked questions
No published benchmark has a sample large enough to set one number for every team, so a fixed target is a guess. Measure the share of UI imports that come from the system in each product, and judge the trend over three or four months. New screens are the better test: if the screens built this quarter use the system almost entirely, adoption is working, and migrating the old ones becomes a planning question.
Only for what the system already covers. A rule that blocks hex colours while the token set is incomplete pushes people to disable the rule, and a disabled rule teaches the team that the system is optional. Start with warnings in the areas where the system is complete, and switch a rule to an error once the gap list for that area is empty. Pair every new error with the documented alternative, so the message in the pull request says what to use instead.
Rarely. Look at where the detaches and the local copies concentrate first. If they cluster on a few components, those components need new variants or better documentation, and the rest of the system is doing its job. A rebuild resets adoption to zero and asks every product team to migrate again, so it is worth it only when the foundations (tokens, naming, the component API) are what people are working around.
Both, with different jobs. The system team owns the cost of the path: complete components, fast answers to contribution requests, documentation that says when to use what, and the monthly counts. The product teams own the number on their own screens, written into their objectives with hours budgeted for it. When only the system team is measured on adoption, it has the goal and none of the screens.
Related services
Related articles
Design
DesignHow to govern a design system across 10+ consumer projects
A practical playbook for governing a design system across many consumer projects: contribution model, versioning, codemods, and adoption tracking.
Design