What is a Design System?
The common misconception about Design Systems, as they relate to software development projects, is that they’re simply style guides and/or component libraries put together by UX/UI designers so that developers know what a product is supposed to look like. While style guides and libraries are aspects of a good Design System, they are only a part of a much bigger picture.
The key word to focus on here is “System.” It’s actually a systematic approach to product development, not just design. Implemented well, Design Systems can have a significant, positive impact on the overall speed of your development process and the level of collaboration between your designers and developers. And they’re not static - a Design System evolves as your product and company evolve.
So let’s look at what a Design System really is, what goes into a good Design System, and how they can benefit your organization.
So what is a Design System?
A Design System can be defined as a collection of components that are governed by clear guidelines for use within a product or set of products.
A fully developed Design System contains both tangible and intangible elements. On the tangible side, you have the component libraries, both for UX/UI elements and code. These are the main building blocks that designers and developers can use, reuse, and reuse again and again throughout the entire lifecycle of your product. We’ll explore these in more detail in a moment.
On the intangible side, you not only have the how-to-implement guidelines, but you also have the reasons behind the system you’ve developed - the “why” of the system. This is key for adoption of the system and to ensure everyone on the team is on the same page.
On top of all of this is the overall governance of the Design System. These are the policies and procedures that guide how the system gets updated to ensure the Design System evolves with the needs of your organization and product.
Elements of a Design System
Any Design System you implement is really the sum of its parts. Generally, you can find the following elements in most Design Systems.
Purpose and Goals
This is the “why” part of the system - why do you even have a Design System? What’s the purpose and what do you aim to achieve? How will it benefit the product being developed, the company as a whole, and, even more importantly, how will it benefit those who use the system and make their lives easier?
With set purposes and goals for the system, you align everyone involved in the design and development process. This also promotes buy-in and helps ensure that people actually implement the Design System.
Visual Design Language
With any system, you need a common language. These are really the basic building blocks that your designers will work from and that your developers will implement in code.
Color: What are the primary colors that will be used throughout the product, and when and where will they be used? For example, a single button could have three different colors: initial, hover and clicked. Those need to be consistently implemented.
Imagery: Guidelines for the type and style of icons, illustrations, and other visual imagery that will be used throughout the product. Once created, these will sit in your UI component library (see below), but this will serve your design team when the need for new ones arises.
Typography: This is not just the name of the font that will be used, but also the different sizes, weights, colors, and styles. Different combinations will be used in different areas, and on different platforms, and you want to be sure this is consistent throughout your product.
Sizing and Spacing: It’s amazing how much sizing and spacing affect the design of your system. Here, the platform you are building for will have significant impacts - the real estate available on a smartphone is much different from a desktop app.
UI Component Library
This is often referred to as a pattern library as you’re implementing different patterns, or groupings of components, in different situations. What you want to avoid is prescribing a layout for each and every page in your application. This results in a nightmare when you add a new feature because your designers would then have to update each and every affected page. Instead, you have each element as a singular component, and then examples of how the elements are executed together. Check out Brad Frost’s work on Atomic Design for great examples of how this can be executed.
Code Component Library
What code elements can you componentize that can be reused, especially as they relate to the design of the product? On a simple level, if you’re always implementing a button or dropdown list the same way, they should be componentized so developers can quickly implement them without having to recode those same elements over and over. Like any code you develop, these will be version-controlled.
Documentation
These are the written guidelines of how and when the UI and Code components of your design system will be implemented. The documentation is a key element of your system that separates you from organizations that simply have style guides or libraries of components. This guides the implementation of the system to ensure consistency across a product or a related suite of products.
Governance Model
Organizations grow and evolve. Products grow and evolve. Your design system has to grow and evolve along with them. What worked for you as a startup with two developers and a designer won’t necessarily work when you’re a team of 10 or 20, or when you start adding third-party contractors or distributed teams.
Your governance model dictates how the Design System will grow, who’s in charge of what elements, how new versions of your component libraries get promoted and deprecated, and what happens when edge cases are discovered. Like anything, growth and change without control is chaos.
How Detailed or Strict does a Design System need to be?
The short answer to this question is: it depends. While a Design System can benefit an organization of any size, smaller teams with a high level of maturity may be able to function with a looser set of controls. While larger teams with many junior developers may need tighter controls.
As mentioned, developing your Design System is not a simple one-time process. You need to continuously evaluate the system and make adjustments as necessary. Along with analyzing your product to see how well it’s being implemented, gather feedback from the designers and developers that actually use the system to gauge its effectiveness.
Benefits of a Design System
When it comes to a consistent look and feel for your product, or for a suite of products, the benefits are fairly obvious. Consistency of design and function can increase a user’s experience and their overall satisfaction with a product.
Design Systems can also improve the speed of development. Reusable components reduce rework and well-documented systems take the guesswork out of how elements should be implemented. Plus you remove downtime as developers no longer need to wait for designers to update the design of each and every screen.
Finally, you’re removing silos with both your developers and designers working on the system and from the system, and promoting more collaboration between the two.
All of this leads to less waste, improved teams, faster implementations, and a better overall product that you deliver to your customers.