Design system debt is not a backlog item

Every design system we have inherited had a backlog item called something like tidy up the button variants. It is never done. It is never going to be done, because it is competing for capacity against work that has a date attached, and it will lose that competition every quarter forever.

This is usually described as debt, on the analogy with technical debt, and the analogy is doing damage. Technical debt has an interest rate you can feel: the build gets slower, the tests get flakier, deployments start failing on Fridays. Design system drift has almost no felt cost until it crosses a threshold, at which point the cost arrives all at once as a rebuild. Nothing hurts, and then everything does.

What we have found actually works is unglamorous and structural. Make the system the fastest path. If using the shared component is quicker than writing a bespoke one, drift stops being a discipline problem and becomes a non-issue. That means investing in the boring surface area: install, documentation, examples that can be copied, and a contribution route that does not require a meeting.

The second thing is to write down who decides. Most drift we have audited is not defiance, it is a team that needed a variant, could not find out whether they were allowed to add one, and shipped a local copy to hit a date. That is a governance gap wearing a design costume. A one-page document naming who approves a new component and what evidence they want will prevent more divergence than any amount of linting.

And accept that some drift is correct. A team that keeps building the same local variant is telling you something the system does not cover. The right response is to absorb it, not to file a ticket asking them to stop.