Distinct Design Systems

What makes a design system better than any other?

By Dan Mall — 14 June 2018 at 03:04:36 am

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:

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 SystemLightning Design SystemU.S. Web Design SystemAtlassian DesignQuickbooks Design SystemFutureLearnPolaris 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:

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. Originally published at danmall.me.