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?

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.

Adoption is a price, not a decision

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.

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.

flowchart TD
    A["Fork discovered"] --> B{"Why did they fork?"}
    B -- "missing capability" --> C["Absorb it as a variant"]
    B -- "review queue too slow" --> D["Fix contribution capacity"]
    B -- "genuinely different product" --> E["Bless it, document boundary"]
    B -- "did not know we had one" --> F["Discovery problem, not governance"]
    C --> G["Migrate them back, you do the work"]
    D --> G

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.

© 2026 Preptima. Originally published at preptima.com.