How Design Systems Can Fail

Marissa Christy had some smart thoughts on how design systems can fail (way back in 2018).

A project can go awry for a number of reasons — budget, resources, time, mismanagement — even turnover. But even successful design systems with organizational buy-in can fail. The pitfalls I am about to highlight feel inherent to the very idea of a design system, even in the most ideal of scenarios.

The entire article is worth your time. I felt a particularly strong resonance with these paragraphs:

When the timeline for implementation gets spread out over multiple months (and more likely, quarters or years), a lot can change. And from an implementation standpoint, front-end development is changing more quickly than ever before. The past few years have seen paradigms shift from utility-like reusable classes (think .margin-sm) to BEM syntax, from monolithic sass outputs to scoped styles within React components. And as the CSS spec adds more and more functionality, from grids to variables, the future is far from fixed.

I’ve seen several implementations of style guides fail because they simply couldn’t keep up with the front end. Bloated bootstrap-like files when everyone is worried about performance. A ruby gem at the moment that node was taking off. And even though React seems almost designed for componentized design systems, the changing nature of tech makes the whole notion of creating a permanent, forever system unlikely.”

It's important to remember that a Design System is a tool. It helps you build your product faster and more coherently. But, like everything else having to do with the internet, it's a tool with eventually diminishing usefulness. The more you keep that top of mind, the better off you'll be when it comes time to start over. At some point, _you will need to start over_. That's the straight truth of building software.

I've been thinking a lot about which kind of design system is better: A design system tightly entwining design and code documentation? Or a DS which is just design, agnostic to the code framework used? I lean towards the former: it provides the most immediate beneficial returns; but it requires constant maintenance and dedication to one framework. The later is great because it can outlast any one framework, but it doesn't save engineers much time.

There are clear cut trade-offs for either path you choose. But you have to choose one. You can't have both. And, eventually, either will fail. So it goes.