How Do You Stop a Design System From Drifting?

How do you stop a design system from drifting?

Make the correct choice the easiest one to reach and delete the alternatives. Drift is not a discipline problem, it is a friction problem. When picking the right token takes longer than typing a value, people type the value, and six months later you have four greys.

Every design system I have inherited was in good shape on day one and degraded from there. The decay is never dramatic. It is one slightly different shade added under deadline, then a spacing value that was almost but not quite on the scale, then a font size nobody can find in the documentation.

Across more than seventy projects, the systems that held up were not the most rigorous ones. They were the ones where doing it properly was faster than doing it badly.

What does drift actually look like?

Three near identical greys where there should be one. A spacing value of eighteen pixels sitting between two scale steps. A heading style that exists only on one page. A class named after where it was first used rather than what it does. None of these look serious alone.

The cost shows up later and somewhere else. A redesign that should take a week takes three because nothing can be changed globally. A developer asks which of four buttons is the real one and nobody knows. A brand refresh reveals that the colour lives in sixty places.

The symptom to watch for is hesitation. When someone building a page has to stop and think about which token to use, or asks in a message which one is current, the system has already started to fail. A working system produces no questions.

Why do good systems degrade anyway?

Because deadlines are real and the system is optional. Under pressure, a person will always choose the path that ships tonight, and if the system's path is slower, the system loses. This happens regardless of how committed everyone was at the kickoff.

The second cause is absent authorship. A system created by one person and then used by four will drift unless somebody still owns it, because every user will make locally reasonable decisions that are globally incoherent. Ownership is not about permission, it is about someone noticing.

The third is that the system stops matching the work. Designs evolve, new page types appear, and if the system does not grow to cover them, people build outside it. That is not indiscipline, it is a gap, and the right response is to extend the system rather than to complain about the workaround.

What should a token actually be named after?

What it does, not what it looks like or where it first appeared. A token called surface-raised survives a redesign. One called light-grey-2 becomes a lie the moment the palette changes, and one called pricing-card-bg cannot be used anywhere else without feeling wrong.

The test I use is whether the name would still be correct if the value changed completely. If you switched to a dark palette tomorrow, surface-raised is still accurate and light-grey-2 is actively misleading. Names that describe role rather than appearance are the ones that last.

Keep the vocabulary small enough to memorise. A system with twelve well named colour tokens gets used correctly. One with forty precise ones gets used approximately, because nobody can hold forty names in their head and the search box is slower than guessing.

How many values should the system actually contain?

Fewer than you want. Every additional option is a decision you are asking someone to make correctly under time pressure, and most systems are too generous. A tight scale with obvious steps produces more consistent work than a comprehensive one with subtle ones.

Spacing is where this matters most, because spacing decisions happen constantly and the differences are small enough to argue about. A scale where each step is visibly different from the last removes the argument. A scale with steps four pixels apart invites everybody to have an opinion.

When somebody needs a value the system does not have, treat it as a question about the system rather than as an exception. Either the system should have that value, in which case add it deliberately, or the design should use an existing one. What it should not be is a one off that nobody records.

What should you delete?

Anything used once, anything unused, and any duplicate of something that already exists under a different name. Deletion is the maintenance activity that actually works, and it is the one teams avoid because removing things feels riskier than adding them.

Run this quarterly and make it boring. Find every style or token used on fewer than two pages, look at each one, and either promote it into the system properly or remove it. Half an hour, four times a year, prevents most of the accumulation that makes a system unusable by year three.

The thing that makes deletion safe is knowing where something is used, which is why naming matters so much. A system where you cannot answer that question is one where nothing ever gets deleted, and a system where nothing gets deleted is one that only grows.

Who should own it on a small team?

One named person, with the authority to say no and the obligation to say yes quickly. Shared ownership of a design system means nobody notices the drift, because noticing is a job and jobs that belong to everyone belong to no one.

The owner's most important quality is availability rather than taste. A system whose gatekeeper takes three days to answer a question will be bypassed, and rightly so, because the person building the page has a deadline. Fast decisions, even imperfect ones, keep a system alive.

On a team of one, which is most of my clients, the owner is the same person doing the building. The discipline there is writing decisions down at the moment you make them, because you will not remember in March why you chose what you chose in September.

What should the documentation contain?

The name of each token, what it is for, and one example of correct use. Not a rationale, not a history, not a philosophy of the brand. Someone reaching for the documentation is mid task and wants to know which thing to use, and anything longer will not be read.

Put it where the work happens rather than in a separate document. Documentation in a wiki that requires a context switch is documentation that gets consulted twice. Names and descriptions inside the design tool itself are read constantly because they cost nothing to read.

Write the note about what something is not for, where it matters. The most useful line in my own systems is usually a short warning that a particular token is only for one specific context, because that is the exact misuse that would otherwise happen, which is the same reasoning I applied to spacing in building a type scale you can actually maintain.

What should you do next?

Open your styles and count your greys. If there are more than three, you have drift, and the greys are the easiest place to prove the point to yourself and to anyone who needs convincing that this matters.

Then pick the single value used most often in your site and check whether a token exists for it, is easy to find, and is named for its role. Fixing that one is worth more than a full audit, because it is the value most likely to be typed by hand under pressure next week. The same is true of navigation decisions that accumulate quietly, which I looked at in designing mobile navigation for a site with too many pages.

If you have a system that was tidy a year ago and is not any more, I am happy to look at it and tell you where the leaks are. Reach out and show me what you have.