10 Tips for Creating a Design System That Works

How We Do at Kazoo 7 min read

In this guest post, “10 Tips for Creating a Design System That Works,” Kazoo’s Senior Product Designer Kelley Shanahan gets real about the challenge of creating a design system from scratch after a major M&A. The scene opens in 2019, when companies YouEarnedIt and HighGround merge to become Kazoo…

Mid-2019 our new company, Kazoo, set off to design a new user experience: combining our award-winning Recognition & Rewards and Performance Management platforms into a single Employee Experience Platform.

As a new brand, Kazoo was still learning our visual direction. So the Product team took the opportunity to evaluate the design systems in our two platforms, align with our budding marketing strategy, and generate a visual design to reflect where we came from and where we are going.

With so many screens to re-skin and replace, we knew a comprehensive design library would be our best chance of aligning our design and engineering teams — and save a lot of time in the future. Here are 10 tips we learned along the way!

10 tips for creating a design system that works

— no. 1 rule: include other departments

1. Choose the right tool to build your design system 🔨

Our design team had used Sketch for years. Every artboard and design decision was documented in Sketch. It was an important and valuable part of our design workflow.


With our design team growing, we needed to revisit some of the issues that kept coming up with Sketch. The main problems? Version control and file sharing. Sketch files are stored locally, and when you have team members working in similar files, or in the same design library but in different locations, it’s almost impossible to keep everyone’s versions synchronized. We decided this was the perfect moment to switch over to Figma, a cloud-based interface design system. That way, we could have a centralized design library and a shared file structure which facilitated real-time collaboration between designers.

We found that when participants had access to a design system they completed their objective 34% faster than without a design system.


2. Involve the engineering team 👩‍💻

Whenever a project is design-led, there’s a tendency to wait until the last minute to share your direction with code-owners. There are times when it’s important to block yourself off from other influences to creatively solve a problem. Building a design system is not one of those times.

System thinking is actually what engineers are really good at! So we made sure Engineering leaders had input and shared implementation advice from the beginning, because they have a component library as well. By aligning our design library to the engineering library, we saved a lot of time we might have wasted chasing down components that didn’t need to exist.

Overall, Engineering input throughout the process helped us focus on effective visual changes and comprehensive documentation. So when it came to implementing the library in code, we were all on the same page.

3. Start with accessibility 👁

Setting accessibility standards helps determine rules for using fonts, colors, and other important UI indicators. This goes beyond making things look pretty and identifies areas where we should make the app usable for all people. We didn’t start by setting accessibility rules, and that ended up biting us. Our designers began creating some really beautiful experiences  but that didn’t matter if we were alienating parts of the population we were designing for.

10 tips for creating a design system -- accessibility guidelines

Then we put that design to the test and found out we weren’t meeting the basic WCAG AA requirements for accessibility. This is how we learned we needed a higher contrast for our buttons. We also switched from using color as the only visual representation of errors. We even found a helpful plugin for our code repository which calls out compliance errors and warnings before it has a chance to go out to customers!

4. Create an inventory 📝

In order to migrate from Sketch to Figma, we sifted through years of components and various transformations to get a sense of how big our library actually was. This helped us understand how big an undertaking this project would be.

First, we gathered all the patterns we had in our design files and created a central library from commonly used components. Then, we piled examples into broad categories like inputs, colors, avatars, and buttons. Once we had a sense of our design components, we pulled Engineering in again to see how their component library compared to our Product Design library. We documented places where the code did not match designs. These would be our starting points for refining the library once we established baseline rules.

Generally, it’s a good idea to do a code audit every few years – minor inconsistencies can build up over time. One surprising inconsistency we resolved was that we were naming similar components differently. For example, what the design team called “tags,” Engineering called “pills.” Creating a common vocabulary helped us collaborate more effectively without needing to code-switch.

5. Define core elements 🎨

Starting with fonts and colors, we outlined the rules for how we’d use core elements in our designs. Within our Product Design team, this set clear expectations on styles, rules, and formatting.

Figma’s library tool helped us enforce this consistency. We first identified colors and text styles in our Kazoo Library file. Then we published the file as our default team library so that any time a new file is created, our designers start with a consistent palette of tools and text styles to choose from. Other core elements include our grid, shadows, and accessibility standards which set general requirements for all designs.

10 tips for creating a design system -- system colors
Defined colors that are never overridden by company branding, their hex codes, SASS variables, and rules for how we do and do not use the colors.

6. Design to reflect your brand 🎉

…and figure out what customers can override.

When building a product that is used by other businesses, it’s impossible to avoid branding dilemmas. Design teams must define rules for how to balance customer needs for customization and branding while still reflecting their company’s visual identity.

Since Kazoo is an employee experience platform, we’re constantly considering this balance. When logos, colors, and platform backgrounds may change, how might our design system and visual elements subtly reflect our brand? To answer this question, we teamed up with our senior graphic designer in marketing to identify patterns and components that would subtly reflect our brand. And as our brand evolved through the second half of 2019, so did our style guide.

10 tips for creating a design system -- app layout versions
Left: our first version of the app layout, with dark green and confetti all over felt heavy and busy. Right: Our second version of the layout after our company design strategy changed from ‘confetti everywhere’ to strategically using color.

We decided to create patterns where images and icons adopted our client branding colors in monochromatic or bichromatic compositions. By layering black or white tints and shades over a base shape, we identified how to create consistency with Kazoo branding while appealing to our customers’ desires to reflect their company identity.

7. Don’t forget breakpoints 📱

Whether mobile or desktop first, breakpoints guide designers toward more flexible layouts. While we don’t design mobile-first, our design library includes page layouts for common breakpoints. This sets standards for padding and page width when screens and windows are reduced in size, and we can easily copy those artboards when designing a new screen.

Another reason we chose Figma’s design library is because grids are defined as core styles. When we defined our breakpoints, we designed our grid to align with these breakpoints so that in any design file we create, we align to the same grid. Developers rely on these grids to programmatically change the layout depending on window size, so sticking to these grids is as important to our engineering efficiency as it is to our design efficiency and consistency in the user experience.

10 tips for creating a design system -- responsive layout detail
One of our breakpoints documented to show how padding, page layout, and header navigation changes at different screen sizes.

8. Rebuild components based on core element & apply those to existing designs ♻️

Once we had the foundation of our library, we began an arduous process of applying the design principles to hundreds of existing designs. Remember the inventory compiled in step 2? We began with those components, applying color, text, spacing, and accessibility patterns to each one. The categories then became unique sections in our design documentation, where we could describe details within each design so it was extremely apparent how the core elements were applied to each component.

10 tips for creating a design system -- button groups
An example of how basic components like buttons build on top of each other to create rules and patterns for our layouts

Whenever we came across an instance where a component couldn’t be applied, we asked ourselves:

  1. Was another component we could use instead of the current design pattern?
  2. Could we use the current design pattern as a new component?

If neither of these questions led to positive answers, we would have to justify why the overrides would be made. 

9. Share. A lot. 🗣

Share until people are sick of hearing from you!

When we had a complete set of design principles and components, we brought these back to Engineering to make sure our designs were clear and could be made into components in our Storybook code library. One thing our design system conveyed to developers (that individual designs couldn’t) were all the aspects of a single component. This allowed them to code flexibly and provide ways to configure that component on the front end. Or, they could define new components to prevent code-overload when a single component became too heavy. With all sorts of clarifying information, our developer colleagues became excited to continue implementing the design library and reduce the amount of custom code written in our app.

Beyond the open communication we had with the development team, we aligned with our product leadership and the company as a whole. This allowed us to evolve our ideas even further to accommodate things that were coming on the roadmap. Our company has a culture of ‘Lunch & Learns’, where departments share an aspect of their work with the company as a whole. So we were able to keep accountable and connect with the company as a whole by sharing our design system through some Lunch & Learns.

10. Iterate and improve 📈

We’re always finding things that we missed in the documentation, or instances where we could have used an existing component instead of designing a new one. By keeping our design library living and constantly improving, we are future-proofing our app and reducing overall code complexity – which allows us to make visual updates easier in the future (we see you, iOS 14!).

Another example we’ve encountered is that our brand design is constantly evolving. Mid-design system update our marketing team released new brand guidelines. Because we had an inventory and guidelines of our own, we easily adapted to the new styles and were able to work with our brand team to make these changes.

In order to accommodate these changing and evolving styles, we keep a design system backlog. Developers grab these small Jira tickets at least once a sprint, as we identify improvements, things not working as expected, and incrementally make changes to our components.

The power of a “just start” mentality

As with any major undertaking, the process of creating, documenting, and implementing our design system was full of highs, lows, and constant innovation. We encountered some challenges along the way. But we also learned so much about our teams and ways to collaborate with a ‘just start’ mentality.

Our design system is now full of 29 pages of documentation. We have a mutual understanding for when to use one button instead of another. And we have processes for improving and maintaining that system. Our component library makes it easier to design new pages. And because the engineering system is aligned with the design system, our time spent developing and reviewing code has significantly decreased. Creating Kazoo’s product design system and library has improved both efficiency and harmony within our app, but it also played a major role in establishing camaraderie and a culture of communication between our product, design, marketing, and engineering teams at Kazoo.

10 tips for creating a design system -- guest post by Kelley Shanahan Kelley Shanahan (she/they), Sr. Product Designer at Kazoo has 8 years of experience creating digital experiences. Before designing B2B products, Kelley worked with Indigenous communities designing archives and cultural heritage management software. She has presented at over 30 international workshops and collaborated with people of all backgrounds, from Aboriginal Elders to Silicon Valley tech giants. Kelley now lives in Austin, TX with her fiancé and two fur-babies and has enjoyed most of 2020 gardening and baking at home.