Eight Things You Need To Know About Design Systems

I attended a whole lot of talks so you don’t have to.

Mikhail Gündoğdu
Jul 3, 2018 · 12 min read

It’s on every job description. You see it all over the freshest design tool release. You might have even heard your family mention it at Thanksgiving. But what are the facts on these “design systems” that has the whole industry talking?

Bridging design and engineering has been an intense interest of mine since transitioning to design from software engineering, so I was eager to learn all about design systems as soon as I heard they were powerful tools for design teams and their engineering stakeholders. Fortunately, RETHINK and SF Design Week organized a whole lot of events on the subject over the last month and I tried going to every single one of ‘em.

That means I went to over fifteen different talks by designers throughout different organizations. Each designer brought unique, actionable insights on design systems. Here they are.

This is a longer read, so I’ve applied some liberal bolding if you want to scan the important bits.

1. Why design systems are important.

Image result for figma design systems
Source. Figma‘s designsystems.com is their resource for design system learning.

Diana Mounter, Design Systems Manager @ GitHub, summed it up rather well:

Noah Levin, Head of Design @ Figma, really drove the last point home. He preached the philosophy of repeatability in his talk, explaining that the best thing you can do after spending your time doing something like building a new icon, is to automate that practice for the next person. In doing so, you will not only have brought value to your own work, but to the work of the entire organization. For Noah, Behavior = Motivation * Ability * Trigger. When somebody on your team is triggered to complete a design, we can do little to change their motivation, but we can do so much through design systems to improve their ability. The end result is behavior that produces a more consistent, proven design so much faster.

2. What a design system is.

Karri Saarinen, Design Systems Lead @ Airbnb, gave this definition:

A set of shared, integrated patterns and principles that define the overall design of the product

If you have little experience with design systems, a definition so broad could be perceived as ambiguous or unhelpful. The lack of detail is key, though. Design systems don’t require a more specific definition. They need the room to be whatever an organization requires for design and its implementation to move fast without breaking things.

But here’s a little more info, straight from the man:

Flip through existing design systems to better understand what they are in practice. Here’s Material Design. This is Protocol by Mozilla. And here’s the iOS Human Interface Guidelines, which we don’t officially call a design system for some nuanced Apple-reason much like why we shouldn’t call the HomePod a smart speaker. All these systems are built differently, but understand how they all fit within the boundaries of Karri’s definition.

You might be wondering why the components you threw together in Sketch are merely considered “pattern libraries”, “style guides”, or “UI kits”. Mike Dick, Design Technologist @ SurveyMonkey, actually started with one of these UI kits when he went about componentizing their elements, but he went back to the drawing board as he started showing it to engineering. Rather than building a system of components for designers, Mike implemented a single source-of-truth for design to integrate with engineering. Designs built with this design system could easily be translated to CSS, the language used to define styling, and could therefore quickly cascade design changes to their front-end components. With enough resources, larger organizations like AirBnb can implement tooling that translates screens built with their design system directly to code (This is why Framer X is such a big deal).

Looking back at Karri’s definition, we see a mention of principles. This is to say that design systems incorporate rules and guidelines, which inform users on how to implement the patterns and styles organized within the system. Rich Fulcher, Head of Material Design @ Google, explained why principles were a defining piece of the system: because a design system only truly exists if it can be used without the creator.

3. Any design system is better than no design system at all.

Diana Mounter, GitHub

GitHub’s design system, Primer, was being revamped internally and privately. Doing so, Diana said, was in part because her team faced Imposter Syndrome comparing Primer to the systems of matured and larger organizations like AirBnb’s DLS, Shopify’s Polaris, and the US Web Design System. Primer felt unpolished in comparison. Many components were deprecated.

But you know what’s worse than knowing a component is deprecated? Not knowing, and pushing that atrocity to production.

Primer and other systems use flags to quickly indicate whether or not components are deprecated.

That’s why Diana says you shouldn’t worry about comparing your design system to any other organization’s system, because thats not what proves its success. Instead, Diana says, push your design system out and analyze utilization to measure its success. Chaos will be a natural part of something so new to the practice as design systems, so focus on what matters and take advantage of the chaos. Are people using the design system in their workflow, and contributing back to it to make it better?

There’s no doubt that systems like Polaris, iOS HIG, and Material Design are remarkably thorough and even cool to look at. But not only are these systems built by companies with massive resources, they’re especially targeted at third-party stakeholders who don’t work under them. It just comes with the territory.

Diana showed this funny blunder. Ideally, components would not hinder readability of the exemplified code.

Diana ended her talk with a tweet to share Primer with the world, flaws and all. In this way, GitHub’s system gives stakeholders: 1. Access to its resources, and 2. Opportunities to improve the system’s flaws.

4. How to get started on a design system.

The first thing you see at Shopify’s Polaris.

First off, you need a snazzy name. As soon as you read Polaris, you know you’ll be led to your well-designed salvation.

Just kidding. In fact, Material Design wasn’t officially titled until a month before being published. Rich Fulcher said it was known internally as ‘Quantum Paper’ most of the time.

And don’t start with a Sketch file either! Michael McCombie, Systems Designer @ Mozilla, made that mistake once. As soon as he brought on other stakeholders, he had to start again. A design system is a piece of design solving user problems. Understand the problem and the users first.

When Jordan Girman, Sr. Director of User Experience @ Glassdoor, set out to make Glassdoor’s first design system, he had the team start with these questions:

From there, they set goals and requirements for their design system that aligned with the rest of the organization. That alignment, as explained by Mike Dick, relies on a relationship. Without a relationship with your stakeholders, you’ll run into a few challenges:

What an engineer thinks when you say, “style guide”

Mike especially recommends finding a counterpart who complements your skills with a shared passion for bridging the design and engineering gap. If you’re not a great coder, make friends with someone who is a great coder with a deep understanding of the engineering stacks. That allowed Mike to understand that documenting CSS, rather than redlining system components, was key for engineering to make the best use of system.

I recommend you search Medium for resources on what tools to use and how to use them to build your design system. You don’t want to hear it from me, because I’m just going to say something about Figma.

5. Design systems document everything.

Microsoft’s Fluent documentation on Radio Buttons.

After you’ve established the goals and requirements of your system with stakeholders, nailing down your overarching, guiding design principles is a great place to start. Great design principles will allow you to build out your system with a consistency that aligns with your goals, and they can be a shortcut to your user’s fluency of the entire system. Again, I recommend you take a look at existing, robust design systems like Polaris to find the best examples of principles in practice. When you start creating your own, Rich Fulcher and Selene Hinkley, Content Strategist @ Shopify, had a few things to keep in mind:

From there, add the components of your design system while making sure to document their specific principles. Things will move so much faster, clueless teammates won’t bug you, and your name won’t be cursed when you’re not around. Here’s what Selene had to say about documenting your design system:

Source: material.io

6. Design systems need to integrate accessibility.

Check out this tool for checking accessible contrast ratios at WebAIM.

John Cassidy, Senior Designer @ Google, started his talk with a fat stat:

1 in 7 people are disabled. That’s over a billion people.

Still, John had more to say. A user is disabled as soon as their hands are full of groceries. If they find themselves traveling in a foreign country with no local language skills, they’re disabled. If you live long enough, you‘ll probably end up permanently disabled one day.

If you’re convinced yet, John has this advice for bringing accessibility to your design system.

Microsoft’s Xbox Adaptive Controller is one of the latest accesibility technologies for users.

7. Color and illustration can and should be systematic.

Shopify’s Polaris color palette

Your organization may already have brand colors that would be handy for filling in your UI, but not so fast. Do not choose your UI colors by copy-pasting your brand colors. Brand colors do not take into account usability, though deriving your base colors from your branding is probably the best place to start. Linda Dong, Design Manager @ Lyft, recommends you create spectrums of brand colors with overlaid text to settle on UI colors that satisfy accessible color ratios. Of course, test all of this in the situations your product will be used in. Lyft needs to work for drivers in the dead of night and on the brightest of days.

When you settle on your colors, don’t refer to those colors in your design system with their hex code or their “official” name. Linda pointed this out with a funny color-naming quiz. Turns out that dove is a medium-grey. Call me unsophisticated, but I think pidgeon is what you’re looking for.

Instead, define your color scheme through color tokens. Michael McCombie and the Protocol system use basic color names like $color-red, while Linda and Lyft use a $ColorName-Value format because of their color spectrums. Of course, bring in all of your stakeholders as you build your color system — and advertise it when its ready — to ensure adoption.

Jennifer Hom, Experience Design Manager of Illustration @ Airbnb, came onboard to revamp their illustration system. Before, Airbnb had illustrations shared across sizes or different illustrations between sizes. Jennifer changed illustrations to systematically increased vector weights and detail as export sizes went up (1x, 2x, 3x), allowing for a consistent but platform-appropriate design between devices.

Jennifer also had these principles to consider for your illustration system:

8. How to scale a design system.

Karri Saarinen: How a design system will evolve with scale.

What’s that? Your company just announced a Series C! Within 3 months, you’re expected to have a full suite of apps across every platform and a team of Not-Yous managing every one.

Fear not. Others have made it to the other side. Here’s how Karri thinks you can scale your design system:

Big thanks to the incredible speakers: Diana Mounter, Noah Levin, Karri Saarinen, Rich Fulcher, Michael McCombie, Linda Dong, John Cassidy, Jennifer Hom, Selene Hinkley, and Jordan Girman. And thanks to Julie Stanescu (along with her team at Rethink) and SF Design Week for organizing their awesome talks!

Lastly, thanks to Jasmine Rosen and Jodee Cherney for editing and the rest of Tradecraft for their continued support, and Tyler Heucke for being my “engineering counterpart”.


Stories about startups, technology, traction, and design…