Design Systems That Survive the Second Year

The first year of a design system is the easy one. There is a launch, a component library, a documentation site, and genuine enthusiasm. Adoption climbs. Screens look consistent for the first time in years.

The second year is where most systems quietly fail. Product teams begin forking components because the canonical one does not quite fit. The documentation drifts from the code. The original team is reassigned. Eventually the system becomes a historical artefact that new work routes around.

The decay is predictable

It follows a recognisable sequence, and each step is individually reasonable:

1. A team needs a variant the system does not offer, under deadline pressure.
2. The contribution process is slower than the deadline, so they copy the component locally and modify it.
3. The local fork works. Other teams find it and copy it too.
4. The canonical component and the forks diverge. Fixing a bug now means fixing it in several places, and nobody knows how many.
5. The system is now describing a past state of the product rather than the current one.

Contribution has to be genuinely fast

This is the whole game. If adding a variant to the shared component takes three weeks of review and copying it takes an afternoon, teams under deadline will copy it, and they will be making the right call for their situation.

Systems that survive tend to share a few properties:

• A tiered review model. A new colour token is not the same decision as a new interaction pattern. Reviewing them with the same ceremony guarantees the small changes will bypass the process.
• A published response time. Contributors need to know whether a review takes a day or a fortnight so they can plan. Unpredictability drives forking more reliably than slowness does.
• A visible path from fork to canonical. Assume forks will happen; make it easy to promote a good one back into the system rather than treating it as a violation.

Deprecation is a feature

Systems accumulate. Without a removal process, the library grows monotonically until choosing a component requires understanding the history of the organisation. New engineers cannot tell which of four button variants is current, so they guess, and the guess is often wrong.

Deprecation needs to be a normal, scheduled activity with a clear contract: a component is marked deprecated, the replacement is named, a migration codemod is provided where feasible, and a removal date is set far enough out to be reasonable. Then it is actually removed on that date.

Measure adoption honestly

Counting installs tells you nothing useful. What matters is what proportion of the interface a user actually sees is built from system components, and that requires measuring the product rather than the package registry.

Static analysis across product repositories gives a workable signal: how many components are imported from the system versus defined locally, and which local ones recur across teams. That second number is your roadmap: a pattern independently reinvented by three teams is a component the system should own.

Fund it as a product

The underlying failure in most decayed systems is organisational rather than technical. The system was funded as a project with a launch date, and when the launch happened the funding moved on.

A design system has users, a roadmap, support obligations and a maintenance burden that never reaches zero. Staffed as a product with a standing team, it compounds in value. Staffed as a project, it will decay on roughly the schedule described above, and the second attempt is always harder than the first, because the organisation has learned that these things do not last.