Flexible But Focused, Designing Systems for Adaptability.

Now more than ever, design systems need to be built to bend.

An Expanding Problem Set

Nowadays, we’re demanding more from design systems than ever before. As design systems become more commonplace and standard, their problem set expands. The ol’ PDF style guide won’t cut it anymore. Design systems need to be flexible, accessible, customizable, available in different languages, successful across different platforms, and able to fold our socks.

The definition of a design system is changing. The idea of one brand = one design system, this-is-all-you-need set of components and rules, is being pushed aside for something far more flexible and far more integrated. There are several reasons why this is happening.

The scenarios we’re designing for are growing. There are more users on more platforms consuming content in more ways than ever before. There are even design systems for cars now.

Accessibility considerations also have design systems adding to their list of requirements. Whether it is large text, low-light, mobile-friendly, or dark mode, companies are pushing to make their products usable to the broadest possible audience.

We also see use cases expand internally. Companies might house multiple brands but use one core design system. Read how Harry’s is making this work.

A Growing List of Grievances

With all the evolution and leaps in advancement design systems have made in the past five years, it seems like the same problems remain. All those “Why Our Design System Failed” articles still sing the same tune: hard to integrate, harder to maintain, hard to follow, over-standardized, and creatively stifling. Google “why design systems fail” when you have a moment; it’s a pretty morbid page of search results.

The common thread that connects all these grievances is a long-held belief that design systems work best when the rules are followed and when consistency is king. There’s a natural inkling to lean into compliance when design systems scale as a way to make sure you don’t end up back where you started, with 15 shades of Lyft pink and a potpourri of submit buttons.

When we started creating a new design system at New York Public Radio, a non-profit organization with seven unique brands, our key value was flexibility. Our brands span a wide range of media, from talk radio and news to podcasts and music. And as you can imagine, a wide range of user personas and a wider range of use cases.

Designing for Variables

In our case, complete consistency would almost be the anti-goal. Each brand needs to have its unique expression and content experience but tie back to a larger organization. Each component we build is designed to flex to the properties and use cases of multiple brands. This gives a designer options when designing and a developer consistency when developing. I love Ken Skistimas’s example here about a car manufacturer’s family of cars.

“A family of cars addresses multiple use cases but carry common traits across to make them identifiable as belonging together.”

We can customize the car however we’d like, but what’s under the hood should stay predictable.

Flexibility was also a requirement for us to be able to pull off an effort like this. Like most real-life design systems, we didn’t start on a blank page. We began our new design system with tech debt, pre-existing components, and, sadly, a previously failed design system. Taking a piecemeal approach to developing a design system requires a little wiggle room as you straddle both the current and future state of your components. In this case, both an audit and component status log helped us maintain a clear standing of where we currently were, and where we wanted to be.

As design systems grow more complex and their uses more diverse, it’s important to build in a little flexibility, so when things do eventually change, you’ll have designed for them.

Hopefully, I’ve made a pretty good case on how and why you should be thinking about your design system’s flexibility. How can you build in flexibility but stay within predictable bounds? In the following article, I’ll run through methods and tools we use at NYPR to create genuinely adaptable components.