Nobody sets out to break a design system. It comes apart the way most things come apart, gradually and for good reasons, one reasonable exception at a time.
Drift is a governance problem
The usual explanation is that the components were not flexible enough. Occasionally that is true. Far more often the components were fine and the process around them was not. A designer needed a slightly different card for a campaign on Thursday, the system team had a two-week queue, and so a slightly different card was built in the campaign file. It shipped. It worked. It is still there.
Repeat that forty times and you no longer have a system. You have a library with a good reputation.
Three habits that hold a system together
Make the fast path the correct path. If pulling a component from the system is slower than drawing a new one, people will draw a new one. Every time. Measure the friction of the correct path before you write another guideline about following it.
Give exceptions an expiry date. Exceptions are not the enemy; permanent exceptions are. Log them somewhere visible with a date attached and a name next to them. Most will either be folded into the system or quietly deleted within a quarter.
Audit in public. Once a month, put every variant of a single component on one screen and show the team. Nothing motivates consolidation like seeing eleven button styles side by side.
A design system is not a set of files. It is an agreement that has to be renewed.
The uncomfortable trade
Consolidation costs velocity in the short term and buys it back later. That trade is easy to describe and hard to sell, particularly to anyone measured quarterly. The only argument that has ever worked for me is a demonstration: rebuild one real screen using only system parts and time it. The number does the persuading.
