The design system purity trap
Life isn’t tidy - why design systems fail by chasing neatness instead of reality.
Too many design systems start with purity rather than reality. It’s a recipe for struggle, if not failure. It’s like knocking down an old city’s messy, but functional, street layout and trying to impose a perfect grid instead. Might look more efficient. But actually you’re destroying the desire paths - the organic routes that people have been using to actually move through the space.
That’s the purity trap. Mistaking an elegant model for a system that actually works.
Organic beginnings are powerful
There are design systems that have been instrumental in shaping the field. Salesforce Lightning, Google Material, IBM Carbon, and others. None of them were immaculate new frameworks. All of them emerged from sprawling, chaotic organizations.
Lightning distilled Salesforce’s complex engineering and UX practice into something more scalable
Material captured Google’s design DNA, giving coherence to patterns that had already emerged
Carbon grew out of IBM’s complex ecosystem, curating repeatable components that engineers were already using
These are design systems that feel natural. They didn’t ask teams to abandon everything. Instead they codified what were already familiar solutions, indexed and refined them, and made them more useful. It was a grounding, building something not to disrupt, but to support and make repeatable.
Then it got all “theoretical”
At a certain point, “have a design system” became accepted as inherently a good thing. Which meant companies started treating them as something to make from scratch. They leaned away from curation, designed idealized libraries of guidance and code, and pushed these onto their organization.
That’s the purity trap in practice. Building for theoretical neatness and not lived practice. And it causes predictable problems.
Low adoption because the new stuff doesn’t fit teams needs, so they just keep doing what already works for them
Cultural resistance to the design system because it feels like a burden, not something that helps
Irrelevance to what’s shipping in code, so it doesn’t matter how flawless things look in Figma or Storybook
There are a lot of lovely looking design systems out there that are pretty hollow behind that facade. You need the accumulated knowledge embedded in an organization to really help you thrive.
Ingest and index
Mature systems aren’t sets of tokens and components. They codify the ecosystem of an organization’s design and engineering practice.
Code and components reflect what’s actually used in product
The brand standards already established by marketing
Accessibiliity and compliance requirements that no team can realistically ignore
Guidelines and documentation that explain why, as well as what
Indexing all of this creates a map of a lived landscape. That index is then the perfect foundation for future refinement. We see what’s inconsistent, and we can standardize it. We see what’s missing, and we can add it. But the system is relevant from the very start, because it’s starting from reality.
Escape that trap
Don’t start with a clean grid. Start with the messy streets that are already there.
Discover what already exists, codify that into a shared source of truth, then refine it iteratively. Trying to force a system probably fails. Building a system that learns from what’s already there more likely succeeds.
Elegance is achieved through evolution.
In closing
Design systems aren’t about control or theoretical neatness. They need relevancy, continuity, and adoption. The best systems honor desire paths, curating the organic practices that exist and making them stronger.
Relevance is what lasts.
Further reading:
Coutts, Christopher, et al. Exploratory Analysis of Revealed Pedestrian Paths as Cues for Designing Pedestrian Infrastructure (PDF). Florida State University Libraries, n.d.