Jelena Racković · · 4 min read · Design systems
Keeping a design system alive: ownership, debt and small regular fixes
Most design systems don’t die in a crisis. They erode, quietly and gradually: a local override here, a detached component there, a colour typed in by hand because the token felt too far away. By the time anyone notices, the remedy looks like a rewrite. I would much rather look after a system with small, regular care than try to rescue it once a year.
Why systems fade
A design system is easy to admire at launch. Everything is new, documented and coherent, and every team is glad to adopt it. Then the real work begins. A deadline looms, a component is almost right, and copying it seems quicker than requesting a change. Nobody does anything wrong, and yet the system drifts a little further from the products it was meant to serve.
The shortcut itself is not the problem; shortcuts are, if anything, evidence that people are shipping. The problem is that nobody sees them accumulate, and nobody is accountable for reconciling them.
Someone has to own it
A system needs a single, clearly identified owner, rather than a committee or, worse, “everyone”. The owner decides what enters the library, what changes and what stays out, and has the standing to say no. That does not mean doing all the work alone. It means that every question has an address and every decision carries a name.
When ownership is shared by everyone, in practice it belongs to no one, and the library gradually becomes a repository of good intentions.
Debt is normal, silence is not
Every living system accrues debt: overrides, detached instances, hard-coded values, components designed for last year’s problem. I do not regard that as failure. I regard it as information, a record of where the system no longer fits the work. What matters is that the debt is visible, recorded in one place everyone can consult, rather than living in somebody’s memory.
Small fixes, every sprint
The habits that keep a system alive are unglamorous, and that’s deliberate. A modest share of every sprint belongs to the system rather than to new features, and it remains there even when the deadline grows insistent. Every change is entered in a changelog with a sentence explaining why, so that the products can follow it with confidence rather than fear.
The library also has a place of its own to learn from, with examples and rules, so that someone new doesn’t have to wait for a meeting to begin. And before anything new is admitted, I look for something old that can be retired. A leaner system is simply easier to keep alive.
What changes
Teams stop working around the system, because requesting a change becomes quicker than copying a component. Updates cease to be daunting, because each one is small and explained. And the system retains its value long after launch, which is, after all, the only reason to build one.
On my most recent large project, the library ran as a separate learning space alongside the products, and every change was entered in the changelog with a brief rationale. Newcomers could find answers on their own, and the products could follow the library without a disruptive migration.
When a rewrite is the right call
Occasionally, small fixes are not enough. When the foundation itself is flawed, for instance tokens that conflate meaning with value, or components built for a product that no longer exists, patching only spreads the problem further. In that case I rewrite once, carefully, and establish the habits that make a second rewrite unnecessary.
A design system is never finished. That may sound exhausting, but it is in fact rather good news: it means people are still using it.
Is your design system starting to fade?
I’d like to hear about it →