With the rise in popularity of component-based architecture, and as design tools become increasingly complex, the need for Design Systems continues to grow. With a clearly defined system, designers and developers can focus their efforts on solving user needs rather than re-creating elements and chasing down assets. No matter how big or small a project is, a Design System is always beneficial.
Ok, so what is a Design System?
A Design System is a documented approach to systematic design. A common misconception is that style guides, component libraries, and design systems are all the same. This confusion is understandable, as often they contain many of the same parts.
A design system is not a single deliverable, but a set of deliverables. Style guides and component libraries are just some of the deliverables that go into creating a living, evolving Design System.
A Style Guide focuses on the stylistic application of a brand to UI elements. It contains high level details like color, typography, iconography, and more.
A Component Library consists of core functional elements and their usage.
Most contemporary Design Systems contain both. Google’s Material Design, for example, has a tab “design” for the style guide and “components” for the component library.
The fundamental goal of a Design System is to create a single source of truth containing all the elements needed for teams to design and implement a product.
Get everyone speaking the same language.
Think of a Design System as a shared language. Language allows us to share knowledge, learn complex ideas, and develop relationships. When everyone is speaking the same language it establishes a better, more consistent means of communication.
Terminology is not important. Consistency is.
There are lots of terms out there. For example, the terms components and patterns are often used interchangeably. A component library is often also called a pattern library. In our experience, terminology is important. But there is no need to get too caught up on exact phrasing. Define terms based on what works for your organization and keep it consistent with how you use them.
How to Create a Design System
Let’s take a look under the hood at some of the underlying design principles, guidelines, and components that make up a Design System.
There are 7 key facets that make up a Design System:
1. Design Principles
Design principles are the guiding rules that help the team make meaningful design decisions. An example of a design principle is Ant Design’s Make it Direct.
As Alan Cooper states, “Where there is output, let there be input.” Make it Direct is a principle of direct manipulation whenever possible (eg. instead of editing content on a separate page, do it directly in context). Design principles must guide design decisions.
Within identity the project’s core brand elements are defined. Typefaces, typography, primary and secondary colors are all specified. In the metaphor of a language, these make up the alphabet.
The third group defines the project’s smallest reusable parts: elements. These are the building blocks of your design system, the words of the language.
Their functional behavior must be specified, along with all their states; such as hover, focus, and disabled buttons. A few well-known examples of elements are things like: buttons, links, inputs, drop-downs, etc.
The next facet is a component. Components act like sentences. They can be anything that uses at least a few Elements. Things like cards, heroes and navigation menus are traditional examples of Components. However, they do not necessarily have to look modular.
A Composition is a part that has multiple Components inside it. They define how the Components inside it should behave. These larger pieces make up the paragraphs of your design language.
Layout is a more abstract collection of design guidelines. Herein the amounts of white-space, grids, and wrappers are defined. Layouts are the building blocks of a Page.
Each Page consists of an arrangement of Compositions and Components. All the one-off exceptions are defined at Page-level.
Documenting Your Guidelines
Everything in your Design System should have guidelines associated with it. By writing down guidelines you are reinforcing desired behaviors and promoting consistency.
When documenting new guidelines it helps to think about it from several different perspectives. Who are the people who will be using this system? What are their needs? If you keep these people in mind as you create the system, your language will be easy to understand and usable by everyone.
Types of Guidelines
There are several different types of guidelines that should be included within any Design System.
- Definitions: Include a brief overview of what you are documenting. What is a button? What is a hover state? It may seem obvious to you, but being explicit in your definitions strengthens your language and increases ease of understanding.
- Usage: Explain the usage and behavioral rules for each component. Users of the system should be able to answer what, when, where, and why for every component.
- Technical guidelines: Work closely with your development team to include technical guidelines. This could include class names and code snippets to aid in the creation and usage of a component.
Keep in mind that as elements combine into components and components combine into compositions, these larger groupings will require different guidelines that do not exist on the individual element level.
Don’t Forget to Maintain the System
Design Systems are like the tamagotchi you had as a kid, if you don’t feed and nurture them, they will wither away and die.
Lack of maintenance is one of the most common reasons Design Systems fail. As your organization grows or client needs shift, there will be revisions and iterations on components and guidelines you have already created. There will be times when you need to create a whole new component or guideline to meet changing needs.
Examples of Great Design Systems
Here are some of our favorite Design Systems:
Atlassian for its thoroughness.
Marvel App for its crisp simplicity.
Material Design for its flexibility and ease of navigation.
Ant Design for its designer/developer tools and focus on Design Language.
Final Thoughts on Design Systems
Design Systems provide a necessary overview of a product. They tell us about its goals, driving vision, and the guidelines that govern its implementation. It is a language through which we can speak intelligently and with ease about a product.
At ABT, we found that using clearly defined design systems reduces back and forth, enabling our teams to build and design faster and with more confidence.
Interested in learning more? Further Reading: