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:

  Carbon Design System Lightning Design System U.S. Web Design System Atlassian Design Quickbooks Design System FutureLearn Polaris by Shopify
Accordion      
Action List            
Activity Timeline            
Alert/Flag Messages        
App Launcher            
Arrow Toggle            
Avatar        
Badges      
Banners          
Billboard            
Boombox            
Brand Band            
Breadcrumb        
Builder Header            
Button Groups        
Button Icons            
Buttons
Callout Cards            
Caption            
Cards        
Carousel            
Chat            
Checkbox  
Checkbox Buttons Group            
Checkbox Toggle            
Checkbox            
Code Snippet            
Color Picker        
Combobox            
Context Switcher            
Data table        
Data vis            
Date Picker    
Datetime Picker          
Description List            
Dividers            
Docked Composer            
Docked Form Footer            
Docked Utility Bar            
Drawers            
Dropdown          
Drop Zone            
Dueling Picklist            
Dynamic Icons            
Dynamic Menu            
Empty State            
End of Flow Confirmation            
Expandable Section            
Exception List              
Explanation            
Featurebox            
Feeds            
File Selector/Uploader          
Files            
Flag            
Flyout            
Footers          
Form  
Global Header        
Global Navigation            
Grids            
Headings          
Icons          
Illustration            
Info Link            
Labels            
Link        
List        
List Builder            
Loading/Spinners    
Logos in Product            
Lookups            
Lozenges            
Map            
Menus          
Modal    
Multi-select            
Notification        
Overflow Menu            
Page Headers            
Pagination        
Panels            
Path            
Picklist            
Pills            
Popovers        
Progress Bar      
Progress Indicator          
Progress Ring          
Progress Toggle          
Promo Banner            
Prompt            
Publishers            
Quiz Progress Nav            
Range Slider            
Radio button/Choice List    
Resource List              
Ribbons            
Rich Text Editor            
Scoped Notifications            
Scoped Tabs            
Search          
Select      
Setup Assistant            
Signpost            
Slider          
Split View            
Spotlight            
Step Number            
Structured List            
Summary Detail            
Tabs    
Tables      
Tag        
Testimonial            
Textarea        
Text Input    
Thumbnail            
Tile          
Timestamp            
Timepicker            
Toast            
Toggle/Switch      
Tooltip    
Trees            
Trial Bar            
Trowser            
Typeahead          
Vertical Navigation/Side Navigation          
Vertical Tabs            
Video            
Visual Picker            
Welcome Mat            

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!

Up Next

The Only-ness Statement