How do you get a design system adopted by product teams moving at different speeds, and what do you do about the team that forked your component?
A design system adoption strategy works when the system is cheaper to use than avoid, measured by component coverage and version lag, and backed by migration help. Forked components should be treated as evidence before they are treated as resistance.
5 min readUpdated 2026-08-15
0
Answer
Short answer
Drive design system adoption by making the system cheaper than local work: provide components that cover real cases, write migration PRs, publish clear examples and make upgrades predictable. Measure adoption by component usage, override rate and version lag, then read forks as feedback about missing capability, slow review or genuine product differences.
Use design systems as an adoption problem, not only a component problem: the question is whether teams trust the system enough to stop rebuilding around it. A strong design systems answer names the contribution path, the governance rule, and the evidence that adoption is improving rather than merely being announced.
Was this answer helpful?
Likely follow-ups
→What would you instrument to know your adoption number is real rather than self-reported?
→How do you handle a legacy product that will never migrate but still carries the company logo?
→Who breaks the tie when the design system team and a product designer disagree on a pattern?
→What is the first thing you would cut if the design system team lost half its headcount?
A mandate produces compliance theatre. A team told to adopt will import your package, use three components, keep their own for everything with a deadline attached, and report themselves as adopted. What actually moves adoption is that using the system is cheaper for the team this quarter than not using it, and the design system team is the party with the budget to make that true.
Cheaper means specific things. The component you want them to use covers the cases they have, including the ugly one. The migration is a codemod you wrote and a pull request you opened against their repository, not a ticket you filed on their backlog. The documentation answers the question they had at 4pm, with a copyable example. And upgrading does not cost them a day of visual regression triage, which is a promise you keep by testing pairings and publishing the visual delta rather than by asking them to trust you.
The speed difference between teams is not a discipline problem and treating it as one is the fastest way to lose the room. A team on a two-week release train with a greenfield surface can adopt in a sprint. A team maintaining a nine-year-old application with a bespoke grid and a compliance freeze cannot, and telling them they are blocking the initiative gets you an enemy who talks to your other consumers.
Measure by component, not by team
"Team X has adopted" is a claim nobody can falsify. Coverage is countable.
Signal
What it tells you
How it is gamed
Share of rendered buttons from the library
Real usage on real screens
Wrappers around the library component
Number of local overrides per consumer
Where the system falls short
Overrides moved into a private theme
Version lag per consumer
Whether upgrades are affordable
A pin nobody has looked at in a year
Open contributions awaiting review
Whether the door is actually open
Requests filed as chat messages
Duplicate implementations found in code search
Silent forks
Renamed local copies
The right-hand column is the point. Every one of these is gameable, so the number is a conversation opener rather than a verdict, and the conversation is what tells you whether a team is stuck or resisting. Version lag is the single most diagnostic figure, because a consumer who has not upgraded in eight months is telling you upgrades hurt, and that is a defect in your release process rather than in their attitude.
The forked component
Someone copied your DataTable into their repository four months ago and it has diverged. Before you decide what to do about it, find out what happened, because the answer determines everything else.
Loading diagram…
Note that only two of the four branches end in a migration. A fork caused by a slow review queue is not fixed by migrating this component, because the next team will fork the next one; and a fork that exists because the product is genuinely different should be supported openly rather than pretended away.
If the capability is the reason, the sequence that works is to read their diff carefully, take what generalises into the shared component behind a sanctioned variant, credit them for it, and then open the migration pull request yourself. That last step is what makes the story travel. Once one team has seen the platform team do the migration work, contribution stops looking like a tax.
If the reason is your own throughput, say so and fix the throughput. A contribution model with no reserved review capacity is a suggestion box. Publish a review service-level expectation you can actually meet, even a modest one, and hold it — a reliable two weeks beats an aspirational two days that slips to five weeks.
What governance is for, and what it is not
Governance is the answer to "who decides", written down before the disagreement. It needs a small number of things: a named owner for the component library, a stated review path with a time bound, a promotion threshold that turns a repeated local pattern into a system-level one, and a deprecation policy that says how long an old name keeps working. That is roughly the whole apparatus, and it fits on a page.
What governance is not is a gate that every design decision passes through. A council that meets fortnightly to approve additions becomes the bottleneck it was created to prevent, and the observable consequence is more forks, not fewer. The healthier posture is that the system is permissive about local exceptions and strict about what gets promoted, with the promotion bar being evidence from more than one product rather than the seniority of whoever asked.
The failure that actually kills these programmes is the one nobody proposes deliberately: the system is built, the adoption push happens, the funding moves elsewhere, and eighteen months later the library is behind the framework version everyone else is on. At that point every consumer is right to fork, and they will. A design system is a product with users who can leave, and it needs the staffing and roadmap of one.
Every fork in your organisation is a written complaint about the system. Read them before you file them.