The first year of a design system usually goes well. There is a launch, a component library, a documentation site, and genuine enthusiasm. The second year is where systems are decided.
By then the people who built it have moved to other work. New engineers were not there for the arguments. Deadlines produce one-off components that never make it back. Slowly, the system becomes a description of how the product used to be built.
Name an owner, or the system has none
The most reliable predictor of survival is whether a specific person has the system in their objectives. Not a committee, not a guild that meets when it can. A named owner with allocated time.
Shared ownership sounds collaborative and behaves like neglect. When everyone owns the system, nobody is answerable when a component drifts, and drift is exactly what needs answering for.
When everyone owns the design system, nobody is accountable for the day it stops being true.
Make contributing cheaper than working around
Engineers do not bypass the system out of disrespect. They bypass it because they have a Thursday deadline and contributing takes three days of review.
Every hour of contribution friction converts directly into off-system components. So the process has to be genuinely light: a clear proposal route, a fast decision, a published response time, and a documented way to ship something provisional under a flag while the proper version is agreed.
- A visible queue so contributors know where their request stands.
- A stated turnaround, even if it is two weeks, so people can plan.
- An accepted path for temporary local components, with a review date.
- A standing answer to why a request was declined, written down.
Treat it like an API, because it is one
A design system is a dependency that other teams build on. Changing a component silently is a breaking change to somebody's release.
That means semantic versioning, a changelog people actually receive, deprecation windows rather than removals, and migration notes written for someone who has never read the internal discussion. Teams that skip this get a reputation for breaking things, and the safest response to an unreliable dependency is to stop using it.
Measure adoption, not satisfaction
Survey scores about the system tell you how people feel. Adoption tells you what is happening.
Instrument what percentage of rendered components come from the library, which surfaces are furthest off-system, and how many one-off variants of a given pattern exist in the codebase. That last count is the clearest early warning available: seven bespoke modals means the system's modal does not fit real needs, and no amount of documentation will fix a fit problem.
Budget for the second year
Systems are usually funded as a project with a launch date and no operating budget. Maintenance then competes with feature work every sprint and loses.
The healthier framing is a product with users, a roadmap, and a running cost. It is a smaller ask than most people expect, and it is the difference between a system that compounds and one that becomes a migration project in three years.
This is the thinking behind our enterprise UX and design systems work. Written by the UXperts team. If this is a problem you are living with, tell us about it.