Brian Feeney
1

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.

August 19, 2020

blog


Path of Atomic Design

Josh Clark clarifies a misconception about Atomic Design, which helps explain exactly why its so useful. He explains:

Right from the start, when Brad was first developing his tools and methodologies in our designs of TechCrunch and Entertainment Weekly, our process constantly zoomed back and forth between page level and atomic level. It’s never a linear path from small to large; it’s a constant roundtrip between the two scales.

Atomic Design prescribes a small-first process, but, like Josh says, it's a cycle. Sometimes, it's pretty chaotic, with design play often driving the car. But the structure of Atomic Design means you're always going back to defining and redefining the smallest elements (atoms), which are then used to construct larger ones (molecules, organisms, etc.). By the time you have your sights on the finish line, you'll have a highly structured design and front-end code architecture for building out nearly anything else in the future.

I've seen this play out a half-dozen times or more now on large projects. If you pay close attention to the detail (the atoms), and maintain control over the depth and breadth of your style guide, what you build will be highly efficient and easy to work with going forward.

April 10, 2017

blog


1936