On Design Systems: And Why Good Design Erodes as Teams Grow.

As digital products grow, design quality rarely collapses. It quietly decomposes. A designer ships a feature that works. Another team ships something adjacent and makes slightly different decisions about spacing, colour, typography, terminology. Nobody does anything wrong. But small, reasonable decisions compound. Six months later you have ten button styles and navigation that feels different depending on where you are.

Design systems exist to stop that drift. The mistake is thinking they are just a component library. Components help reuse, but they do not scale decision-making. What scales is a shared set of rules for how we design and build, plus ownership that keeps those rules current.

AI is starting to matter here too. AI is good at applying rules consistently, but only if the rules are explicit. If your standards are vague or trapped in people’s heads, AI will copy the mess faster.

The quiet erosion of coherence

Early-stage products get consistency almost for free. A small team has shared context. People notice inconsistencies quickly and fix them in the moment.

Then the product grows. Delivery pressure increases. Work splits across squads. A tiny “just for this flow” tweak becomes a new variant. Someone introduces a new term because they didn’t know the product already had a word for it. An engineer rebuilds a component because the existing one almost fits.

Nothing is obviously wrong. Everything works. But the interface starts to feel off. In high-stakes products, especially in insurance, health, or cyber, that “off” becomes cost. More cognitive load. More mistakes. More support tickets. More time spent debating basics instead of solving user problems.

This is the moment most teams decide they need a design system.

When the system meets a new context

In her book on ‘Design Systems’, Alla Kholmatova defines a design system as “a set of connected patterns and shared practices, coherently organised to serve the purposes of a digital product.” I like that definition because it includes the part that usually gets skipped: shared practices. A system is not only what the UI looks like, it’s how a team makes consistent decisions when the product changes shape.

A lot of teams start with the visible artefacts. A Figma library. A component repo. That’s understandable, and it does create immediate efficiency. Dan Mall’s line that “design systems are a tool for scale” is true in the simplest sense: you solve a design problem once and reuse it.

But scale also means new contexts.

The breaking point usually looks like this: the system was built for one kind of experience, then the business expands into another. The most common example of this is when a core application needs some kind of ‘admin’ dashboard.

From the outside, it can look like a discipline problem. In practice, it’s often the system hitting the edge of its utility. You can’t solve that by collecting more buttons.

The missing layer is principles that work under pressure.

Not poster slogans like “be delightful.” Principles matter only if they resolve real trade-offs.

The principles that scale are research-backed decision rules. Research shows users get overwhelmed by options. That becomes a rule: don’t show everything at once. Research shows users struggle when the same thing has multiple names. That becomes a rule: use the same word for the same thing. Research shows users abandon complex forms. That becomes a rule: keep critical paths focused.

Those rules aren’t lofty. They’re practical. They help teams make consistent decisions in situations the system hasn’t explicitly solved yet.

My Experiences

I saw the value of this layered approach while working with adidas — specifically working with Adidas Design Language (ADL) on Locker Room, a platform that enables clubs to design and order custom teamwear. ADL was created to support adidas’s e-commerce website, which is highly photography-driven to showcase products and marketing campaigns. The UI here is very minimal to help create a canvas where the product is king.

But Locker Room is a different animal – facilitating kit design and complex orders from internal users, agents, buyers and third-party retailers. Similar journeys to eComm, but with a different intent. The system needed to adapt.

We used ADL foundations (tokens, principles, and primitive components) and made product-specific adjustments where the workflow required them. Our users valued speed and convenience vs a more minimal approach, so it was important that we respected that.

What prevented drift wasn’t a perfect library. It was a shared understanding of what had to stay consistent versus what could flex.

What actually scales

The most common failure mode is rot.

Not because people don’t care, but because it requires a lot of work, and it isn’t a top priority until everything slowly starts to fall apart. Because to grow, we need to build new features and new context. But it’s flimsy if we don’t have a system to build on.

What works is ownership paired with trust. Ownership doesn’t mean gatekeeping. It means staying close to the teams that consume the system, noticing where it doesn’t fit, and making contributions the norm. Trust matters because design intent always gets translated into code, and there are endless details you could argue about. Teams that scale learn which details matter because they change comprehension, accessibility, and outcomes.

It also helps to make room for sanctioned flexibility. Some basic patterns should be standardised and consistent, such as buttons, inputs, error messages, and navigation primitives. Other areas can adapt, like onboarding moments, empty states, or certain layouts, as long as the foundations are clear.

I used to think the main job of a design system was consistency. I now think it's making good decisions repeatable.

Consistency is the byproduct

The work is in the foundations.

Principles grounded in evidence, a shared language across design and engineering, and ownership that keeps the system alive as the product changes. This need for explicit, structured rules is becoming an operational necessity.

AI makes this more obvious. Great at enforcing rules, but it can’t enforce a philosophy you haven’t written down.

If your standards live in people’s heads, AI will not save you. It will just accelerate whatever behaviour already exists.

If you’re feeling the early signs of decay, treat it as a signal. Something has shifted. Your product has moved.

And your system needs to move with it.