What is a Design System, and why should I care?

A design system is a collection of reusable styles and components that are guided by a set of clear standards and rules. It is most comparable to a set of legos that can be assembled together to build an infinite number of applications–but it also serves as the representation of a brand, company, or organization’s visual language.

Design systems are primarily used to create efficiency within an organization, but they have various levels of maturity in terms of how much value they will actually add. A strong design system that is effectively championed across design and development teams will eliminate design inconsistencies across your organization, reduce design and tech debt, and streamline the process of onboarding new designers and developers.

Benefits of a Design System

Reduce Design & Tech Debt

Pulling from a common, governed set of components will reduce both design and technical debt for product teams. Utilization of a well-built and maintained design system will lead to less bugs in production.

Faster Production Times

Teams spend less time designing and coding common UI components and more time building real features. This means a lot more time to focus on solving complex problems rather than trying to rebuild the wheel time and time again.

Higher-Quality Production

By creating baked-in styles and functionality through a design system, UX designers can better enforce best-practices and more easily ensure visual and functional consistency across multiple applications.

Reduce QA Efforts

Designers can centralize and streamline some QA tasks within the design system–mostly related to UI component unit testing and visual regression testing.

Adopt New Tech Faster

A well-structured design system can alleviate complexity when implementing new features and help make adding additional or more experimental frameworks more manageable.

Useful Reference

The design system also serves as an essential resource hub for design and development best practices. It can be a powerful teaching tool for team members who are less familiar with front-end development.

Future-Friendly Foundation

Designers can easily and continuously modify, extend, and improve the design system over time. Once you have one with a proper process established, it is a cinch to add to it and have new teams adopt it.

Foundational Concepts

Atomic Design Methodology

The Atomic Design Methodology is an organizational framework developed by designer/developer Brad Frost. In this methodology, Brad provides a helpful way to think about design system components by classifying components based on their complexity. The overarching idea is to divide components up into 3 different types: atoms, molecules, and organisms.

Visual of Design System is atoms, molecules and organisms, which make foundations, components, and patterns.

Concepts outlined in Atomic Design by Brad Frost

Atoms are the most foundational styles that inform every other component, and are essential for the creation of larger molecule components; which are defined as the basic components that are most typically used within any user interface. Things like buttons, form inputs, and menus are considered molecules. Organisms on the other hand, are the larger-level building blocks that are made up of both molecules and atoms. A navigation bar, for example, might include a logo icon (atom) and a dropdown menu (molecule). Together, these components make up a larger organism component.

Brad Frost also takes the explanation further by describing how organism components can be arranged to create template screens and eventually lead to high-fidelity screen designs. These templates and screen designs are not always meant to be included in the design system, but teams who need to utilize specific templates and screens over and over again should always consider componentizing them relative to their specific project.

The Structure of a Design System

A design system typically consists of two main categories: a style guide and a component library.

Visual of a Design System defines rules and connections, style guides defines abstract styles and component library defines usable blocks.

A style guide is intended to define the visual style of the project, brand, or product as a whole. This would typically include “atoms” like: logos, colors, typography, photography, and icons. You could even go one layer deeper by including things like a layout grid and spacing scale to ensure every designer is spacing their components in a consistent way. Designers and developers should always reference the style guide to ensure that all pages, features, and components align with the overall visual direction of the product(s).

On the other hand, the component library, sometimes referred to as a pattern library–is a centralized collection of adaptable assets that make up a brand’s digital applications. These components are typically more tangible than a style guide–it is composed of concrete elements that are driven by patterns. In a typical component library, you would find both “molecule” components like buttons, links, and form fields as well as “organism” components like navigation bars, card components, and footers. The component library is meant to provide reusable components that designers and developers can utilize to build high-fidelity screen designs. Ideally, each component should be robustly-built and flexible enough to work across multiple screen sizes and applications.

The 5 Levels of Design System Maturity

When it comes to design system maturity, there are generally 5 different levels that companies, organizations, or design system teams could place themselves into.

Visual of design system maturity, 1 no system, 2 style guide, 3 pattern library, 4 design system, and 5 advanced design system.

No System

The first level is no system. Typically in this level, designers and developers are not utilizing a style guide or component library in any form. This means team members will often rely on tribal knowledge of a brand’s styles and standards to build their mockups and screens, with designers and developers manually copying common patterns into their designs and code. This can lead to a lot of spaghetti code and design inconsistencies down the line, and implementation upkeep can quickly become a nightmare if left unchecked.

Style Guide

The second level is having a style guide established. This means the brand has a centralized reference document that defines the reusable colors, typography, and overall visual identity. Level 2 indicates that the team does not have a component library, although they may have a few styled HTML samples. They still suffer from many of the same problems as level 1.

Pattern Library

The third level is having a pattern library that is supported by an external UI codebase. Level 3 teams are able to use this shared codebase to maintain consistency across design implementation. The documentation for these resources is minimal but utilizing a shared vocabulary can ease communication gaps. These teams may require a more extensive onboarding process when a new designer or developer joins the project.

Design System

The fourth is a dedicated design system. With a well-documented and well-maintained component library and style guide established in both design programs and code, level 4 teams are able to produce designs efficiently. Typically, the design system also integrates with the development codebase so that the developers benefit as well. Ideally, the design system is managed equally between design and development, although at this stage there might not be a dedicated team.

Advanced Design System

The 5th level is an advanced design system. This means there is a dedicated, cross-functional team whose sole job is to build, maintain, and document a design system both from a design and front-end perspective. Level 5 teams require strong governance, dedicated team members, and a detailed roadmap in order to continually manage the design system and the documentation.

Design System Tools

The tools used to implement and maintain design systems are constantly evolving. Change happens fast and designers/developers have to stay up to date on the latest and best tools on the market. With that said, a few tools have been taking the lead in recent years.

Visual of Design System Tools, design tools are Figma and Sketch, component versioning tool is bit.dev and Lerna, and documentation tool is Storybook and Docz.

Design Tools - Figma/Sketch

Design tools are an essential for the creation of a design system because they typically house the component library–and often the style guide too. Figma and Sketch are the probably the most commonly used tools among designers. These tools are used to define and create the styles as well as plan out the necessary components. Designers should work with developers to map out the architecture of the design system in a way that is compatible with development.

Component Versioning - Bit.dev/Lerna

Versioning tools, such as Bit.dev or Lerna, allow developers to package up components individually so that developers working within applications only use the components they need, reducing file size. This also allows developers to upgrade components without breaking things, or upgrading components until they are ready.

Documentation - Storybook/Docz

Documentation tools allow the team to clearly define and showcase the intended functionality of every component in isolation. Tools like Storybook and Docz enable designers and developers to understand the capabilities and functionality of the available components.

Building a Design System

In order to be successful, a design system should not fall on any one person to create and maintain. The responsibility and governance should be championed equally between design and development in the form of a cross-functional design system team.

Before getting started building your design system, there are a few key considerations the team will need to make. These decisions will affect the overall architecture of the system, so it is important for the design and development leads to work closely together to make sure they are both aligned on these decisions–fully understanding the way things need to be built and why.

Be prepared with a list of components you will need.

Creating a comprehensive list of the basic components you will need is a great place to start. Don’t be worried about accounting for everything right away–there will be plenty of opportunities to keep adding as you go along.

If You’re Starting From Scratch:

Start with the basics and build from there. It can be helpful to start with some screen designs first and extract components after. The more design work gets completed the clearer your path will become. Take a look at the example lists provided below. These core pieces are fundamental to any design system and building these first is always a great strategy.


  • Colors
  • Typography
  • Shadows/Elevation
  • Layout Grid
  • Spacing Scale
  • Icons


  • Buttons
  • Avatars
  • Inputs
  • Textarea
  • Checkbox
  • Radio
  • Dropdowns
  • Breadcrumbs
  • Alerts
  • Modals
  • Pagination
  • Tabs

If You’re Creating a Design System Based on Existing Elements and Designs:

1. Conduct a Visual Audit

You will need to conduct a visual audit on the existing applications. Make sure to compare what is mocked up in designs (if there are any) to what is actually developed and in production–most of the times there will be differences. It is good practice to take a lot of screenshots of all the existing elements within a presentation, with each slide representing a component.

2. Highlight any Inconsistencies:

Once you have everything documented slide by slide, you can begin to converge on any inconsistencies and understand each component’s functional needs.

3. Using your Audit as a List, Rebuild the Components:

This is your opportunity to start making improvements and squash any inconsistencies found. It is always helpful to do this in accordance with any existing brand guidelines.

Be sure to ask the right questions.

What Platforms will the Design System need to Support?

Platform determination is usually a decision made at the product strategy level. Understand whether your team is building responsive web applications, native mobile applications, or a combination of both. This determination will likely decide the types of components the design system will need to support. Knowing your target platform(s) will help you come to a decision on how you need to organize components within your design files & documentation.

What front-end technologies will the team be using?

Technology choice can sometimes depend on which platforms your product needs to support. Knowing your target platform(s) and technology will help you come to a decision on which third-party component library(s) to leverage.

Which third party component library should the team utilize?

Choice of a third party library will depend on both the platform and front-end technology needs. After choosing a third-party component library, always read through their documentation and make sure you’re familiar with what components are available to you and what their limitations are. Not all teams will choose to leverage a third-party component library, but it is always an option to consider if you’re crunched for dev time.

Other Design System Tips

Don’t be afraid to build components from scratch.

Third-party component libraries are really powerful tools that are great for getting a design system off the ground quickly, but don’t be fooled into thinking they will be able to provide everything you need.

Make sure to weigh the pros and cons of utilizing a third-party component–especially if it requires additional work to get it functioning the way you need it. Also consider the visual implications–if you need to make drastic updates to the way a third-party component is styled it might not always be worth it.

Communicate between design & development as much as possible.

Never make assumptions on how a component should look or function. If you’re ever unsure, always ask! Set up a process where you present components and their intended functionalities before development work begins to discuss any questions or doubts between the team.

Also check in regularly during development to make sure the component looks and functions as desired. Set up a QA process once development is in a good spot to catch any mistakes before pushing to production.

Document as you design & build.

Don’t release any design system components without some form of documentation. Although it is a bit more of a time investment up front, it will save the team a lot of heartache in the future.

If working within agile, build documentation requirements into your acceptance criteria. Always include documentation in your estimates when time-boxing component development.

Don’t worry about making your documentation perfect for the first pass. Like other parts of a design system, get something in place and strive to improve it with future iterations as time allows. Even just getting the team used to writing documentation is a win.

Think through governance and communication strategies up front.

How you communicate updates to other designers and developers that are utilizing your design system matters. Set up a slack channel specific to the design system for users to ask questions, report bugs, or request new features.

Make sure to publish a changelog with each component as you update it. It is valuable for other teams to know exactly what has changed between versions and if those changes will require them to commit to any extra work upon updating.

Designate a team member to blast out slack notifications to the channel when a new component has been created or changes have been made to a component. Make sure to include the changelog, the new version number, and a link to any relevant documentation.

Send out regular surveys to gauge perception.

Anonymous surveys are a great way to gauge how your design system is received by its users and what the team can do to improve the experience. You can ask questions around ease of use, quality of documentation, and how working with the design has affected their typical process. Don’t just send this survey out to developers- it is equally as valuable to get feedback from everyone who interacts with the design system.

On that note–make sure you’re soliciting feedback from everyone who comes in contact with the system; developers, designers, BAs, and QA testers alike. Don’t forget to ask open-ended questions around specific things they would like to see improved, and what their biggest pain points of using the system are. Results from these surveys should shape the team’s roadmap and act as a guide for what to focus on next.

Understand that it is something that will need to constantly be maintained.

Strive for your design system to be big and beautiful, but understand that it will take time. As long as UI work on a project or application continues, so should support on the design system.

The benefits outweigh the initial efforts

Although most teams agree with the benefits of a design system, the daunting task of actually establishing one can deter organizations. The process often requires deprioritizing short-term deadlines and allocating time towards the creation and adoption of the new system. It is important to remember that the upfront costs of establishing a robust design system will greatly payoff shortly after set up. As the team begins to utilize the new system, you will notice more visual consistency, less design and development debt, and simplified processes that enable the team to get more done. To help you and your team get started, take a look at the Getting Started Checklist below.

Getting Started Checklist

  1. Know what platforms the design system will be supporting.
  2. Know and understand the front-end technologies the team will be using.
  3. Determine if/which third-party component library(s) the team will leverage.
  4. Make a list of the basic components your design system will need.
  5. Start building!