A design system is easy to launch and hard to keep. The first release is a good week: the tokens are clean, the components are documented, the team is enthusiastic. Eighteen months later the same system has four button variants nobody can tell apart, a colour called “grey-450” and a documentation site that is one release behind the code.
The components are rarely the problem. The problem is that nobody decided who owns the decisions.
Name things after their job, not their looks
A token called “button-teal” expires the moment the brand shifts. “button-primary” survives it. The same rule applies to spacing, elevation and type: a token should describe the role it plays in the interface, so a visual change becomes a value change instead of a rename across two hundred files.
This sounds obvious and it is the single most common thing teams get wrong in the first month.
One owner per decision, written down
Every system needs an answer to a boring question: who decides whether a new component enters the library? If the answer is “the team”, the answer is nobody, and the library grows a fifth card variant every quarter.
Write down who approves additions, who approves deprecations, and how long a deprecated component stays available. Three sentences in a readme file is enough. The point is that the sentences exist.
Deprecation needs a path, not a warning
Marking a component deprecated does nothing on its own. Deprecation works when it comes with three things: what to use instead, a search-and-replace recipe, and a date after which the old component is deleted. Without the date, deprecated components live forever.
Measure adoption, not coverage
Coverage tells you how many components exist. Adoption tells you how many screens use them. The second number is the one that predicts whether the system is working. If adoption falls while coverage rises, the library is growing in a direction the product does not need.
A simple query against your codebase, run monthly, is enough. You are looking for a trend, not a dashboard.
What this looks like in practice
In the UI/UX Design path we rebuild a small system twice: once the way most teams do it, and once with ownership and deprecation defined from the start. The second build is slower for two weeks and considerably faster after that. Seeing both is the fastest way to understand why the second one holds.