Do we have too many design systems?

Clearly, I’m biased: most of SuperFriendly’s work nowadays involves either creating a design system or modifying one as part of a larger effort for a client. But why even go through any of that effort in the first place?

When I started researching design systems for Unity, the design system we made for ExxonMobil, my biggest observation was that the digital design systems out at the time were extremely generic. There’s a lot of benefit to that: part of the job of a design system is to take care of the boring stuff to free you up to tackle the more exciting and challenging bits, so some amount of convention is expected and encouraged. That genericness is what allows designers and developers to create quickly, not to overthink our interfaces and unnecessarily reinvent the wheel. It’s no surprise that Bootstrap is as popular as it is: you can build something significant with even a basic understanding of HTML, CSS, and JS without a lot of fuss. And a quick search on UpLabs shows how much can be done with Google’s Material Design.

Sometimes, though, we need better tools. In fact, a lot of our design system work has used “better than Bootstrap” or “more meaningful than Material” as a creative brief or rallying cry of sorts. But what does it mean to be better? Every client I work with has at least one problem or challenge that Bootstrap or Material Design didn’t anticipate. That’s not to disparage those tools; it was never their job to do in the first place. This is where a distinct design system can be helpful: to solve your organization’s unique problems in a way a generic tool isn’t designed to help with.

Relying on Principles

Web developer and author Jeremy Keith shares some great wisdom about design systems:

It’s not very useful to create a library of patterns without providing any framework for using those patterns.

Often times, that framework comes in the form of principles, which is likely why most design systems have them. Design Principles FTW describes two types of principles: universal and specific. The problem is that most design systems stop at universal principles. For example, SAP Fiori’s design principles are all universal. While “delightful” and “simple” apply to Fiori, they also apply to, well, every other design system too. I’m not implying malice or ignorance here; I think that’s a result of 1) the difficulty of writing great, specific principles and 2) the fact that having only universal principles are better than having nothing at all.

In contrast, TiVo has specific design principles like:

• It’s entertainment, stupid.
• It’s TV, stupid.
• It’s video, dammit.

Very brand! Such tone! Those wouldn’t work for a car manufacturer or a tech company. Specific design principles should fit your organization perfectly and look awkward on everyone else.

I’d love to see every design system strive for an only-ness, some unique angle or aspect that other design systems don’t cater to. Your product or organization probably has a specific perspective on the problem it’s trying to solve in the world; your design system should reflect, refract, and reverberate that position. (If your organization doesn’t have that differentiation, you’ve got some foundational identity work to do.)

That only-ness doesn’t have only to be principle-driven; it could come directly from the mission of your company. In Vox Media senior design director Yesenia Perez-Cruz’s talk, Building Flexible Design Systems, she nails what Vox’s design system is built for: telling better stories, faster. That clear purpose drives what components they need, what scenarios to design for, and what they can work toward together.

Reverse-engineering principles from components

One workflow tip I’ve tried to put to good use is that you don’t have to define principles before you create components; it’s not a one-way street. Many times, you can derive your principles from how the work gets done. Designer Mark Boulton shares his experience with this flexibility around design principles:

…a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work.

A team can do this because the general public can too. Here’s a quick inventory of a handful of design systems and the components they contain:

By looking across components in aggregate, we can very clearly see what the boring stuff is, because most of these design systems have them. That’s stuff like buttons and form elements, as just about all of these design systems seem to contain them.

More interesting, however, are the components that only appear in one of these design systems. (Ignore the ones that look isolated but are actually just a result of non-standard taxonomies for components.) They start to give you a clue as to the unique value proposition of each design system. For example, FutureLearn’s Quiz Progress Nav only seems appropriate in environments where one is being tested online, which already starts to give you a clue as to what FutureLearn does.

Emmet Connolly, director of product design for Intercom, calls this a full stack design system. He suggests building everything around the core objects of your brand or organization. Here are some examples of what that might be for some well-known companies:

• Facebook: Friend, Post, Message, Event, Page, Group.
• Airbnb: Listing, Host, Guest, Trip, Experience.
• Slack: Team, Member, Channel, Message, Reaction, Thread.
• Intercom: Customer, Teammate, Message, Conversation, Article.

By focusing on this kind of specificity, I think we’ll see a lot more innovative and interesting design systems pop up in the near future. I sure hope so!

Special thanks to Stephanie Rewis for her eagle-eye QA skills.