Design Systems Rot. Here Is the Maintenance Plan.

A design system is not a project. It is a garden, and the launch announcement is the day you finish planting, not the day you finish.

We shipped ours two years ago to genuine applause. Eighteen months later a designer told me, without malice, that she had stopped opening the library because it was faster to redraw a button than to find the right one. That sentence cost us a quarter to recover from. Here is what we changed.

Rot has a specific shape

Systems do not fail all at once. They accumulate small, individually reasonable decisions until the whole thing is untrustworthy. Ours rotted in four predictable ways.

• Forked components. A team needed a variant, could not get it prioritised, and copied the file. Six months later there were four buttons.
• Undocumented exceptions. The rule said sixteen pixels. The checkout page used twelve, for a good reason, written down nowhere.
• Token drift. New brand colours entered through the design files and never reached code, so the two sources disagreed about what primary meant.
• Orphaned owners. The two people who knew why the modal worked that way both changed teams.

None of these is a crisis. Together they are the reason nobody trusts the library.

Budget the maintenance, out loud

The single most useful change we made was arithmetic. We now allocate twenty percent of design and front-end capacity to system work, permanently, and we defend it the way we would defend a customer commitment.

That is not generosity. A forked component costs more than the fix, every time, and the cost lands on whoever inherits the page in a year.

If maintenance is not on the roadmap, it is not funded. If it is not funded, it is not happening, whatever anyone says in the kickoff.

Make contribution cheaper than forking

Most forks are not defiance. They are a rational response to a slow process. We measured ours: the median time from "I need a variant" to "it is in the library" was nineteen days. Of course people copied the file.

We cut it to four by doing three unglamorous things.

1. 01A standing ninety-minute review slot every Tuesday, with a published agenda. No waiting for a meeting to be scheduled.
2. 02A contribution template that asks for the use case and two real screens, not a written proposal.
3. 03Explicit permission to merge a variant as provisional and document it later.

Provisional variants felt dangerous. In practice they became our best signal: anything still provisional after two quarters is either a real pattern nobody promoted or a mistake nobody removed. Both are worth an afternoon.

Audit on a schedule, not on a feeling

Twice a year we run a two-day audit. It is not a redesign. We open every production screen, list the components in use, and compare that list to the library.

The output is always the same three piles: things in the library that nothing uses, things in production that the library does not cover, and things that exist twice. The third pile is where the damage lives.

Give every component an owner and an expiry

Each component now carries two pieces of metadata that have nothing to do with code: a named owner, and a review date. When the review date passes, the component appears in the Tuesday agenda automatically. The owner either renews it, deprecates it, or hands it over.

It sounds bureaucratic. It takes about four minutes per component, twice a year, and it is the reason we no longer have a modal that nobody understands.

What actually changed

Adoption is a lagging indicator, so we watched something faster: how often a designer opened the library in a working week. That number went from one and a half to nine.

The library did not get better looking. It got trustworthy, which is a different property and the only one that matters.