Systematically Not Following the Design System Is a System

Every organization swears by its design system. Few truly follow it.

The irony is that breaking the system isn’t neutral. It doesn’t vanish the moment you sidestep it. What actually happens is far more dangerous... you create a new system in its place.

This is how shadow systems are born. They don’t start with grand decisions or bold rebellions. They creep in quietly through small acts of "just this once." A color is hardcoded because a token feels inconvenient. A margin is adjusted by eye. A component is forked and slightly re-styled. None of these moments feel catastrophic. But together, they form a new pattern. And patterns, repeated at scale, become systems.

The shadow system is not written down. It has no owners. It doesn’t show up in the roadmap or the design tokens. But it rules all the same. It guides decisions, creates expectations, and shapes the product experience in ways that are inconsistent, confusing, and costly.

Here’s the truth most teams don’t want to admit: systematically not following the system is still a system. And it is always a worse one. It erodes consistency. It slows down development. It breaks scalability. It undermines trust. It doesn’t just coexist with the official system; it replaces it.

The fix is not heavier policing or louder preaching. The fix is cultural. A design system is not a Figma file or a code repository. It is a contract. It’s a shared understanding of how we build, scale, and engage with our users. When that agreement is honored, it accelerates everything. When it’s ignored, the cost compounds in ways teams only realize much later.

So the next time someone suggests "just this once," remember: you are not bending the system. You are creating another one. And the only question worth asking is this, "Do you want to build on the system you chose, or the system you let happen by accident?"

Because either way, you’re building a system. The difference is whether it works for you, or against you.