Eight Things You Need To Know About Design Systems
I attended a whole lot of talks so you don’t have to.
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.
Diana Mounter, Design Systems Manager @ GitHub, summed it up rather well:
- Design systems bring order to chaos. Everyone is kept on the same page, so the entire product remains consistent and polished throughout.
- Design systems improve the user experience through the repeated use of familiar and proven patterns. Designing anything from scratch leaves room for error, so try to use what already works.
- Design systems improve workflow efficiency. Product teams know exactly how components of new features should look and how to implement them.
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.
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.
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 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.
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:
- What’s the need for this system?
- How is design being implemented now?
- How should it be implemented?
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:
- Nobody will be speaking the same language. “Style guide” means two different things for engineers and designers. How will you know if your terminology and documentation will be understood by everyone?
- Getting everybody onboard with your design system will be a lot harder. Your people won’t understand the value of something they didn’t help create.
- Nobody will know what the source of truth is. Kiss your consistency goodbye.
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.
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:
- Many don’t even want to read principles; if they do read, they might scan. If they scan, they may not understand. If they don’t understand, they certainly won’t apply. So, understand your audience when creating your copy and content!
- Be guiding, not prescriptive. Leave room for creativity by giving a spectrum of what’s acceptable. Principles should be a guide for decision-making.
- Limit the number of principles. Shopify started with 13, but they now have it boiled-down to 4. They removed “top down” and “middle management” principles that didn’t do much for those designing and implementing the design first-hand in day-to-day work. Grassroot principles are gold.
- Reflect your principles in what you create. For the type of user that refers to the design system in-context and learns through example, this will do a lot to ingrain your principles and remain consistent.
- They can’t limit your brand or product principles. Design systems should be subsystems of your organization, so make sure they fit within the whole.
- Keep evolving your principles. Apply user-centered design to the creation of your principles so that they reflect your system and reality accurately. Otherwise, consistency will break down as other users apply your principles.
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:
- Break paragraphs into bullets and lists.
- Use visual examples wherever possible.
- Keep sentences short and actionable.
- Use dos/don’ts.
- Make your don’ts less obvious. Model them after realistic mistakes that could result from misinterpretation
6. Design systems need to integrate accessibility.
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.
- Apply accessibility-minded design constraints. Ensure that your components account for scenarios in need of accessibility, like resized type for far-sightedness and alt-text for screen readers. Don’t forget about temporary disability; what if your product is used by drivers in bright daylight?
- Learn about the accessibility technology available to your users. OS technology like iOS Magnifier and Windows Narrator are most available, but add-on products like the Xbox Adaptive Controller exist, too. And some technology isn’t limited to use by disabled users, especially voice assistants.
- Test your components with those accessibility technologies turned on. Pretty simple. Turn on technologies like iOS VoiceOver and ensure they work with your system components in a useful manner.
- Test your product with users of varying disability. Of course, you need to bring your product in front of users who are on a spectrum of different mental, physical, and situational disabilities.
7. Color and illustration can and should be systematic.
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:
- Ensure your illustrations are grounded. Illustrations should allow most, if not everyone, to relate to your product and without thinking about minutae.
- Don’t let your illustrations take the spotlight. They should increase delight without distracting the user from their goal.
- Use accessible colors. Check your color ratios!
- Be diverse, but realistic. Airbnb’s illustrations are based on real people, so they “feature” Donald Glover and Jennifer’s random Facebook friends. Airbnb also spoke with organizations and authorities on disabilities that gave them the idea to use a subtle cue like headphones.
- Test your illustrations. Oh man, can you believe it? This piece of design needs to be tested as well. Showing the China-specific illustrations to the Beijing office allowed Jennifer to figure out that big-chested Chinese males wouldn’t be the most relatable.
8. How to scale a design system.
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:
- Use defined primitives. Define the color schemas, text styles, grids, etc. that will be the building blocks for every addition to your design system. All of Airbnb’s core components and team-specific libraries are built with the same set of primitives.
- Build your components using those primitives, and build your patterns with those components. This will ensure consistency while allowing for a degree of flexibility and malleability.
- Remain flexible. You need flexibility to allow for spacing, text truncating, different text sizes for accessibility and internationalization, different color choices, custom components, and good ol’ creativity.
- Make your design specs platform-agnostic. DLS defines their components in JSON, a ubiquitous data standard that allows for automated translation to platform-specific styles like CSS.
- Add team-specific libraries, but keep them under control. Airbnb limits their team libraries to experimental and specific components. So, team libraries are monitored and components are sent up the chain if they are suitable core components. 70 components make up 60% of Airbnb’s front-end across all platforms!
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”.
