Starting your own design system can be overwhelming. While we’ve provided you with everything you need to start working, it can be helpful to look at existing systems for inspiration. Public-facing and open source design systems provide a window into how different organizations categorize and structure their systems. In this chapter, we will cover the common similarities and differences you can expect to encounter among popular design systems when researching for your own.
The Role of Open Source
The term open source refers to publicly available technology that is often free to use and modify. The goal of open source software is to encourage and maintain free-flowing ideas, unhindered by proprietary business interests. Open source projects are developed and curated by those with a deep interest in the software, as well as the problem that software seeks to solve. This interest helps contribute to higher quality, as the goals revolve around the software itself, rather than potential monetary gain.
Open source software (OSS) also helped contribute to the open design movement. While open design often refers to physical products, the principles remain the same as OSS. Primarily, this involves publicly sharing design information related to the development of your product and allowing anyone to use and alter it freely.1
These trends have encouraged companies to be more open with their design language. Many organizations have even created and open-sourced their design systems as a way of disseminating information more efficiently. It has allowed organizations to get direct feedback and contributions from users, as well as designers and engineers working with their system. Access to these systems has provided an easy way to learn the reasoning behind decisions made, enabling designers to improve the user experience while collaborating more effectively with engineers.
Google’s Material Design debuted in 2014 and was backed by open source code. It provided stronger dialogue and improved collaboration among designers and developers, as each group had insight into the function as well as the form of the product.
Throughout this chapter, we will use publicly available design systems as a way of researching common similarities and differences. Use these as an additional way to understand what is essential to include in your system, but remember that every organization is unique and will have different needs and goals.
Researching Other Systems
Looking at how other organizations tackle their design systems is helpful when starting your own. It is also often overwhelming. We found that there are many design systems out there, all with their own way of categorizing, organizing, and conveying their design language. It is challenging to know which method makes the most sense for your system.
Rather than look at other systems as a prescription for how a design system should be, look to them for insight and inspiration. You will notice many similarities and just as many differences. At first, it can be difficult to grasp the reasons behind why they differ. Why does one system use voice and tone while others use writing style? Why do some systems break things down into elements and components while others don’t? Much of the differences come down to what we have focused on throughout this book: the size of the organization, the type of product it builds, organizational needs, and user goals. Study these systems as an additional way of understanding what makes the most sense for your organization.
It is important to remember that these systems, like all, are in constant evolution. By the time you are reading this, they have likely undergone additional tweaks and changes.
Commonalities
Nearly every system contains the essentials: typography, grid, color, components, etc. Some include general guidelines for components with more specific usage guidelines for each component group. This is necessary because specific rules come out of combined groups that do not exist for the individual components. Many also include working code examples, along with technical guidelines.
It is common for design systems to include particular guidelines to describe and prescribe personality, voice, and tone. These typically consist of a word or short phrase, such as “Playful” or “Optimistic,” followed by a few guiding sentences that set the tone for the brand.
Most systems do not include a section specific to marketing. Atlassian and GitLab are the only organizations that have a separate section dedicated to marketing guidelines within their systems. Including marketing in your design system can strengthen the alignment between the user experience of the product and how that product is branded and marketed to users.
Some systems supply users and possible contributors with access to resources such as code repositories, design files, and icon sets. They often include user-friendly public-facing sites focused on both design and development. These sites help foster design thinking within your organization.
Differences
We saw a distinct difference between design systems in how they choose to build and mix elements. Some systems, such as Google’s Material Design, use design standards similar to those of Atomic design.2 Atomic design is defined by breaking interfaces down into basic building blocks and working up from there. Every piece of the interface must be defined.
Instead of relying on individual atoms (or atomic design), we started considering our components as elements of a living organism. They have a function and personality, are defined by a set of properties, can co-exist with others and can evolve (or die) independently. This is one of the key points about the system compared to more atomic ones—we don’t have complicated networks of interconnected parts and components.
—Karri Saarinen4
Further differences arise in how organizations choose to categorize and structure their systems. A few begin with guiding principles, working progressively toward elements and components.
Atlassian and GitLab split their systems into marketing and product sections before listing guiding principles, elements, and components. Mailchimp does not include any guiding principles.
There is a variety of terminology used by different systems. Some use the terms patterns and components. However, in Shopify’s system, the pattern section includes guidelines for layout, error messages, and mobile patterns, while their components section is dedicated to reusable interface elements. Mailchimp’s system combines patterns and components under the general term patterns, providing guidelines and code snippets together. GitLab makes a distinction between components and regions, with regions representing overarching design paradigms such as the navigation. Other organizations refer to these paradigms as patterns. Most systems include guidelines for overarching paradigms, but the naming often varies. While the terminology differs, the contents remain similar and often overlap.
Overview of the Contents Within Some of the More Popular Design Systems
|
Tying It All Together
The systems we’ve outlined all contain key aspects that help drive their individual design languages. What works for them won’t necessarily be a good fit for your organization. Use these design systems, along with this book, as a reference and inspiration for when you feel lost or unsure of which direction to go in.