The system nobody follows

Walk into IKEA and pick up any flat-pack furniture box. Inside, you will find an instruction sheet with no words. Just diagrams. Numbered steps. A small cartoon person holding the right tool at the right moment.

The instructions look complete. They are not. What they assume is vast: that you know how to read a hex bolt diagram, that you understand which direction "clockwise" goes when you are upside down under a shelf, that you have a partner to hold the third panel while you align the fourth. The document is perfect on paper. It fails in the specific conditions of your Sunday afternoon.

I think about IKEA instructions every time I hear a team say they have a design system.

The promise of design systems was genuine. A shared visual language across a product reduces inconsistency, speeds up the design process, and gives engineering a stable contract to build from. The teams that articulated this vision were not wrong. Consistency is real. Efficiency is real. The Figma libraries, the component documentation, the token definitions, the contribution guidelines: all of it exists for good reasons.

But a system is only as good as the conditions it was built for.

But somewhere between the promise and the implementation, something reliably breaks down. Not in the components. In the conditions.

I have now been in this conversation at three different companies, and the shape of it is always the same. A design system gets built. It gets celebrated. It gets presented to leadership with a slide that says "single source of truth." And then, about six months later, someone notices that half the product team isn't using it.

Not because they are rebellious. But because the system was built for the product as it was, not the product as it needed to become.

The specific failure I remember most clearly happened at a mid-sized SaaS company. We had spent the better part of a year building out a component library that any designer on the team would have been proud of. Documented, versioned, accessible-compliant, with a Figma file that was genuinely beautiful to look at.

Three months after we shipped it, I sat down with one of the product designers who had been a vocal advocate for the system during its development. She was working on a new feature flow. I noticed she was building everything from scratch.

"Why aren't you using the library?" I asked.

She paused, which told me everything. "The components don't account for our new data structure," she said. "I tried to adapt them but they break in edge cases. It's faster to start fresh."

She was not wrong about the faster part. But the faster part was destroying the thing the system was supposed to protect. And nobody had noticed because the metrics we tracked were component adoption, not product consistency.

Here is what most teams miss when they build a design system: a system is not documentation. It is a set of decisions that have already been made so that future designers don't have to make them again. But those decisions have an expiry date.

The product at the time the system was built is not the product six months later. New features arrive. New user research surfaces edge cases nobody anticipated. The data model changes. The system that solved last year's consistency problem is now a ceiling on next year's design thinking.

This is not a failure of the system. It is the nature of systems. They encode what was true. They cannot anticipate what will be needed.

But most teams treat the system as permanent. The component library becomes the constraint, not the starting point. And the designers who most need the system's consistency end up working around it, which is precisely the outcome everyone was trying to prevent.

The teams I have seen get this right do one thing differently: they treat the system as a living product, with its own roadmap, its own feedback loops, and its own definition of done.

Not a document. Not a library. A product.

That means someone owns it the way a PM owns a product: with accountability for outcomes, not just outputs. The question isn't "is the system complete?" The question is "is the team using it, and when they aren't, do we understand why?"

The gap between those two questions is where most design system efforts go quiet. The first question is answerable with a Notion page. But the second requires conversations nobody wants to have, because the answer is usually that the system solved the problem the team used to have, not the one they have now.

And the team has moved on. But the system hasn't.

The IKEA instructions are not broken. They are specific to a set of conditions. When the conditions change, the instructions fail silently. Nobody updates the diagram. You just end up with a shelf that wobbles.

A design system that nobody follows is not a failed system. It is a system that succeeded at the wrong moment. But it is also a leadership failure, because someone decided that shipping the system was the finish line.

The only question worth asking is whether you know the difference.