Understanding the goal of a design system is the first step toward implementing a solution that helps teams successfully scale product. With a clearly defined system, designers and engineers can focus their efforts on solving user needs, rather than re-creating elements and reinventing solutions.
Layout: Defined measures that make up your spacing and grid system.
Styles: Core aspects of your visual language. These include colors, iconography, and typography.
Components: Core elements of an interface. These include buttons and form fields.
Regions: Overarching design paradigms, such as navigation or search.
Content: Information regarding the voice and tone, as well as punctuation guidelines. Content can also include terminology if your product has a specific vocabulary.
Usability: Rules that define accessibility and internationalization.
Spacing (layout), combined with color and typography (styles), create components
Components can be combined to form component groups. In this example, combined buttons create a segmented control. Another example includes combining an input field with a button to create a form.
Multiple components can create larger paradigms used throughout your product, such as navigation. It is helpful to document guidelines related to these specific regions.
Elements: The lowest-level object. Elements cannot be broken down further. This can include labels and icons.
Components : A combination of one or more elements that function as a whole, such as a form.
Component groups: A group of components that form a larger component, as seen in Figure 2-2.
Style Guides, Component Libraries, and Design Systems
As design tools become more sophisticated, style guides and component libraries continue to grow in popularity. This popularity is for a good reason, as they allow designers to create core elements that can be shared and synced across multiple design files. By making a change in one file, you can easily update the design across all files that use that same element. This allows designers to easily make global changes and achieve consistency within their design tool.
Style guide: Static documentation that defines how the brand is stylistically applied to interface elements. It contains high-level details about color, typography, iconography, and more.
Component library: A set of styles and components that can be used and shared among a team. A component library consists of common core elements that are used throughout an application. If supported by a design tool, they can automatically sync across design files when a change is made. Component libraries may or may not include living code.
Design system: A series of documented elements, components, and regions that include both design and front-end guidelines. The documentation contains live code examples, allowing cross-functional teams to easily reuse styles and components in several instances across an application. A design system also includes underlying design principles, rules, and guidelines that help a team build one or multiple products.
Our experience
The terms components and patterns are often used interchangeably. For example, a component library is often also called a pattern library.
Terminology is important, but don’t get too caught up on exact phrases. Define terms based on what works for your organization and be consistent in how you use them within your team.
The Right Time to Implement a Design System
Age of the organization.
Team size.
Volume and type of work.
Age of the Organization
In the beginning, many organizations invest more time and effort into growing products and features than they do in developing good user interfaces. It is easy to point fingers, but the climate for technology and the speed at which companies must move to become profitable can make even the smartest organization choose features over experience.
Putting a design system in place takes a great deal of time and effort. According to a 2018 design systems survey conducted by Figma, design systems typically come after the product is built.1 Creating patterns and strict guidelines are often unnecessary during the early stages of a startup or in a young organization. Attempting to lock the team into a set of strict guidelines while everything is still in flux will result in wasted time, as the organization pivots to meet market demands.
That isn’t to say you can’t begin to lay the foundations for a design system. This is the time to loosely organize patterns and guidelines. Establish a single source of truth for the basics, such as typography, colors, and spacing, but avoid creating too much overhead and process. Until things are more stable, it will be important to remain flexible.
Team Size
If there are only a few designers and engineers on your team, it may be too early to start thinking about a design system. Keep in mind the resources that you have. A small team might mean you are strapped for time. Being unable to spend sufficient time to start your system could result in failure. If you anticipate that the team will be growing soon, now is the time to think about how you will handle that growth. Keeping things organized and preparing only the essential documentation should suffice. Once the team grows to five or more members, it is likely time to think about a more sophisticated system.
It is equally important to think about other teams you interact with. Will a design system improve communication and collaboration with product, development, and even marketing? If the answer is yes, then it is time!
Volume and Type of Work
At first glance, agency work may seem too varied and fast-paced to benefit from a design system. The work is continually changing and can vary significantly from day to day. Designers must often context switch between different sets of branding guidelines and user bases. Compared to that of a product team, the work does not have a regular cadence of iteration, and designers don’t typically have the opportunity to grow the user experience steadily over time. However, a design system can be used as a starting point for creating brand-consistent user experiences at agency speed. Many agencies can use a generic set of layout rules, components, and regions that can be easily adapted to each brand’s unique look and feel. In some cases, agencies will even build unique design systems for their clients.
Approaching the Start of Your Design System
In the beginning, implementing a design system can feel overwhelming. Understanding the current state of your product is always a good first step toward incrementally building your design system.
Whether your organization is young or mature, starting with an interface inventory will provide insight into where you are in the process of creating your system. The goal of your inventory is to assess the layout, styles, and components used throughout your product. It can also serve as a road map when defining the scope of your design system.
A component library can be used as a first step toward incrementally implementing your design system. You and your design team can work from the interface inventory to create a series of components that are then used to communicate with your front-end engineering team during implementation.
What details prevent our team from quickly and efficiently creating designs?
How does our visual language complement brand guidelines?
Which components are most frequently used?
Which interactions are critical to core business needs?
Does our organization support internationalization?
Who is our user base and how can we enable them to use the product effectively?
What tone do we use to communicate with users?
Questions such as these map long-term goals to the six interlocking areas that make up a design system. Asking the right questions also helps break down the needs of your organization into small, digestible pieces, making it easier to get started and stay motivated.
Note
To learn more about implementation techniques, see Chapter 5.
Understanding Why Design Systems Fail
Design systems are not foolproof. They can fail for many reasons. Understanding how and why things can go wrong will help you stay on track.
Lack of Initial Buy-In
Attempting to build anything without the support of your organization will be a struggle. Building a design system requires resources and time. You can’t do it all on your own. Before making any decisions or taking any steps, take the time to talk to others in your organization. Start by getting a feel for what they already may know about design systems. Approach conversations from the perspective of problem-solving: What pain points do they encounter that a design system would help relieve? What goals and initiatives are important to them, and how can a design system further those goals?
Make sure to reach out to colleagues at every level of the organization: product management, engineering, sales, marketing, and executive leadership. It is essential that everyone understands the specific benefits a design system will provide them. You must evangelize and then socialize your design system; otherwise, you run the risk of others seeing it as a design-only initiative and losing support for the time and resources needed.
Note
To learn more about getting support for your design system, see Chapter 3.
Trying to Do Too Much, Too Soon
Getting started on your design system is exciting, but don’t let that excitement get the better of you and your team. It can be tempting to jump right into working on your system. It is vital to understand your company’s unique needs and challenges before devoting all your time and resources to building something.
Pace yourself and your team, or you run the risk of burning out. Understand what you really need before committing, and accept the fact that progress may not always be as fast as you would like. Doing a lot and then nothing can make both stakeholders and your team lose faith in your system.
Note
To learn more about framing your design system, see Chapter 3.
Perfectionism
Don’t try to make your system perfect by worrying over every little detail. Iteration will be vital to getting your design system up and running. As you work, you will discover patterns you forgot or details that seem vital. Keep a running list of improvements and additions. Avoid the impulse to switch gears to get them in your system immediately. Approach building your design system as you would any other project. Plan, execute, and iterate as new information or needs arise. Most of all, get comfortable with the idea that it will never be “done.”
Note
To learn how to implement your system iteratively, see Chapter 5.
Maintenance
It is common to feel the pressure to deliver quickly, both for your team and external stakeholders. Don’t give in to this pressure. Think strategically when developing your design system. Avoid getting stuck with a system that requires constant upkeep. Such things as static images and repeated text will not scale as your system grows and becomes more complicated. Self-documentation is essential if you want to ensure the system remains relevant.
Design System Envy
Getting inspiration from other design systems can be extremely helpful. You can see how other companies have grouped their content, which components are vital to include, as well as how much and what information is necessary to document. However, it is hard not to compare your progress to more prominent organizations, and that can be demotivating. You may have only a few people in your organization available to work on your system part-time. Remember that many of the well-established design systems you see have been developed over a period of years by full-time, devoted teams. Be happy with your progress and concentrate on the needs of your organization.
Note
To learn how to use other design systems to your advantage, see Chapter 8.
Tying It All Together
Six interlocking areas make up a design system: layout, styles, components, regions, content, and usability. A robust design system should contain guiding design principles, guidelines for use and implementation, as well as a component library that includes front-end code.
Before you build anything, determine whether it is the right time to implement a design system. Avoid investing a lot of time creating a design system before your team and organization are ready for it. You may have to start gradually, beginning with a style guide and basic UI kit. As your team and organization grow, so will the need for a design system.
When you are ready, start with an interface inventory of your product. Document the layouts, styles, and components that make up your unique interface. Then, ask some fundamental questions to understand the needs and goals of your organization and its user base. Answers to these questions will allow you to map out the long-term goals of your system.
Finally, knowing why design systems fail is as essential as knowing what makes them successful. Avoid the common traps, such as perfectionism, taking on too much, and starting a system without proper buy-in from stakeholders.