Lesson 1: Welcome to design systems
This is a written version of our Introduction to design systems: Lesson 1 video tutorial. Watch the video and follow along with the written course below.
There are millions of websites and applications that are endlessly evolving, many of which are operating on different systems and devices.
As their audiences grow and change, so does the demand for progress, evolution, and possibilities. Many of them are turning to design systems as a potential solution.
In this lesson, we’ll:
- Learn what a design system is and what’s included in one
- Explore the problems a design system can help solve
- Help you identify when you need one
- Highlight a few things to consider as you start your design systems journey
Chapter 1: What is a design system?
So what exactly is a design system? If your first thought is a style guide and a component or pattern library, you’re not alone.
Yes, you’ll see aspects of these in a design system, but you’ll also see a focus on the bigger picture: the entire product ecosystem.
After all, products aren’t just collections of UI elements splattered on a screen. They’re organized in strategic ways to communicate messages, encourage certain behaviors, and guide you through processes. They’re a reflection of the vision, concepts, and values of an organization.
It’s important that a design system communicates not just the “what,” but the “how” and the “why.” A design system provides the tools and resources you need to build consistent and cohesive products.
Let’s explore some of the resources a design system might include.
Style guides
Style guides are a set of standards that define the appearance of elements, and the overall voice and tone. They focus on the visual language of a product: how things should look and feel.
You’ll see aspects of these in most design systems. Examples include color and typography.
Component libraries
Component libraries contain the building blocks of a product. This might include individual components, layouts and templates, and interaction patterns. They focus on how assets should behave in the product.
They also often include on-canvas redlines or annotations, or are embedded alongside code components with detailed documentation.
One size does not fill all
As you go through your design systems journey, keep in mind that there is no one design system that fits all. Different companies have different needs, which require different solutions.
Chapter 2: Do you need a design system?
Now that we have an idea of what a design system is, do we actually need one? You might be wondering how this might play out in real life. Let's look at this scenario.
Habitz
Kai is a product designer at Habitz, a habit-forming app available on multiple device types, and is supported by smart reminders and integrations. This app has been in development for a while, and the design team just received additional headcount.
Recently, they were working on new screens and couldn’t remember what a few elements looked like. They reference older screens, but noticed that some details look different across different device themes. Which of these are reliable? What if it’s none of them?
In weekly critiques, Kai also noticed components looking different between different designers. They’re beginning to wonder if it’s time to consider a design system.
There is no straight-forward answer on when to implement a design system. However, we can make informed decisions by understanding the benefits a design system can bring, the challenges that can come along with it, and what problems we need to solve within our organization.
Benefits
First, let’s cover how a design system can help.
Even when starting small, design systems allow teams to do more with less. Not just when it comes to designing and prototyping features, but also when building real-world experiences.
- Designers spend less time remaking components and sweating the small stuff. This increases their design output and allows them to focus more time on solving design problems.
- When we’re ready to scale teams, a design system becomes an onboarding resource that allows new teammates to contribute sooner.
- Design systems aren’t just for designers. When we align design components with code, tokens, and animation presets, developers can translate designs into functional, accessible code, in a fraction of the time.
- As a design system matures, it becomes the single source of truth within an organization. It provides teams with a shared vision and language that leads to better understanding and more consistent products.
These benefits don’t just impact the internal process of building a product. They also contribute to your customer’s experience with the product. Consistency, usability, and accessibility build trust in your product, and lead to a more engaged and loyal customer base in the long run.
Signs a design system might be for you
Conversations about design systems are ever-present, and with so many impressive examples to take inspiration from, the fear of missing out feels very real. It’s tempting to jump right into the deep end. So when might a design system actually be the right decision?
- Consistency: Do you spot inconsistencies between styles, components, and behaviors in the product? Are you building for multiple brands or products and need unification across their experiences?
- Theming: Does your product use more than one theme, such as dark and light modes? What about different devices?
- Remove redundancy: Are people building the same things over and over? Are teammates debating over the same issues again and again?
- Knowledge sharing and cross-functional alignment: Does the team use a shared language to talk about the product and solve problems? How efficient is it to find answers to product questions?
- Onboarding: If your team is growing, how long does it take to onboard new teammates with the product information they need?
- Efficiency: Where in the product lifecycle can you benefit from improved speed and efficiency? How much time is spent creating, iterating, or prototyping? How about finding out whether a design is up to date?
Reflect on how your team works
Take time to observe or reflect on how your product teams work together, the product’s overall experience, and the problem areas we just outlined. If you work in a team, consider discussing as a group.
Remember, not everyone needs a design system. You may already have effective solutions for these different issues. Or, “Not right now,” may be your answer, and you revisit this later down the line.
Challenges
Rome wasn’t built in a day, and neither is a design system. Like products, a design system requires consistent time and effort, not only to implement, but also to maintain.
And while they require investment, it might be a while before you see the results of your efforts. This can make it challenging to get buy-in from leadership. Especially if it takes away from day-to-day work, or requires hiring more people.
Socializing a design system with the rest of the organization can also feel like an uphill battle. You’ll need a group of design system champions to accomplish this successfully.
Habitz
After discovering some design inconsistencies, a need for knowledge sharing with a growing team, and a need for device theming, Kai believes it’s a good time to consider a design system.
They’re not fully convinced that they need one quite yet, and will need to gather more information before they can convince leadership that this is worth the investment.
What should they do next?
Chapter 3: Audit your product
If you’re still uncertain whether a design system is for you, performing an audit could provide additional insight.
Audits give you the opportunity to take stock of the entire product, everything it consists of, and areas of improvement. Findings from an audit can help open up conversations about various problems, and even contribute to buy-in from leadership.
It can be initiated by any team, but will eventually bring on other disciplines, making this a company-wide effort. Whether you decide to implement a design system, audits are a crucial step in understanding the current state of a product.
Find collaborators and recruit allies
Before you begin auditing, think about who can help you with this task. What cross-functional partners can provide a fuller picture of what the product consists of and what it needs?
For example: Developers can help identify gaps between design and code. The support team might know about sneaky modals and error messages that you wouldn’t regularly catch.
Perform an audit
-
1
Gather everything that exists
Identify user flows and all elements used in product, like colors and text, illustrations and icons, buttons and dropdowns, patterns and interactions, and so on. Collect them all in one place to refer to them later.
Remember to interact with the product so we don’t miss elements like loading states, hover states, or warning modals. If the product spans different devices or operating systems, we’ll want to audit those as well.
-
2
Sort and categorize
If there are a large number of elements in a group, we can categorize them even further.
For example: we’ve collected a group of text elements being used in our product. We noticed that we can further categorize these by paragraph, quote, heading 1, and so on. Each of these subcategories have more than one instance per style, which will help us in our evaluation later.
-
3
Identify opportunities
Analyze what’s been gathered to identify patterns and areas of opportunity:
- Where do we see redundancies in user flows that can be reduced or consolidated?
- Which areas have poor accessibility? Think beyond contrast and readability. How is alt text handled for images and icons? Are input forms built for the device they’re being viewed on?
- Are assets and styles consistent with the developer’s library?
- What inconsistencies are among styles, patterns, and objects?
Habitz
Kai explained to their manager the issues and opportunities they’ve been observing. The manager gave approval to recruit the entire design team to conduct an audit.
The team gathers everything they see across the multiple device themes, notes patterns, and synthesizes everything into a spreadsheet to look for use cases and inconsistencies.
They brainstorm various solutions to prevent the issues from happening in the future. A design system is on this list of potential solutions, and it’s looking more and more like a winner.
Chapter 4: Overview of the design system process
So, you’ve done some discovery work. Maybe you’ve concluded that a design system is the path for you. What’s next? Let’s see what the future might hold.
As the company grows and matures, so does its design system. Design systems are ever-evolving, just like the products they support. To anchor us on this journey, it’s important to understand that design systems have a non-linear path. This process may vary from one company to the next. Let's take a look at what phases we may encounter throughout our process:
- Approval: This is where we work to get leadership on board with design systems, so we have access to bandwidth and resources needed for the project.
- Discovery: Where we conduct research and audits, identify audiences and problems, and brainstorm solutions.
- Definition: Where we make decisions on solutions, contributors, and approaches.
- Building: Where we assemble the actual design system.
- Documentation: Where we detail how to use the design system in an approachable way.
- Maintenance: Where we make sure the system is up-to-date with supporting the product, and that design and code are aligned.
- Advocacy: Where we socialize the design system into the organization, often with the help of champions.
Its circular, not linear
Throughout our design systems journey, we’ll likely find ourselves revisiting phases regularly. Some phases may even overlap with one another.
Remember, this is not a linear process with a single end-point. Treat a design system like you would treat building software: an ever-evolving product that is regularly iterated upon.
Considerations
Thoughtfully planning and doing discovery work for your design system will have an impact on its quality, as well as support a more efficient journey. Here are a few things you may want to consider.
Contributors
Contributors are the people who help build and maintain the design system. They can be individuals from different teams across the organization, or a team whose full-time job is dedicated to this ongoing project.
Contributors can also be individuals who approve changes to a design system, or who help champion and socialize it.
Activity
Take some time to consider:
- Who in your organization would be a valuable contributor?
- How many people will it take to support the success of this project?
Remember, there is more to this process than building. There are other phases like getting buy-in or documentation. You may find that some tasks are better supported by different people.
Discuss with your team to determine whether you need a separate, dedicated design system team. Keep in mind, you’ll need to balance it against the organization’s needs and available resources.
Audience
Your audience are the ones who will be using your design system. Think beyond designers as the audience. What about developers, UX Writers, Brand, Marketing, and Product Education teams 😉?
Audiences can inform what and how things go into a design system. They can be recruited to pressure-test the system and provide meaningful feedback on how to improve it.
Activity
Set up time with yourself or with contributors to explore these questions and understand your audience better:
- Who will be using the design system, and how often?
- Who might we not be considering?
- What is their experience with design systems and the design system tools they’ll be using?
- Will the design system be kept internal, or will it be shared with external partners and users?
- What might the process of soliciting feedback look like, now and ongoing?
Implementation
The last aspect to consider is how we might implement a design system.
If we build a design system from the ground up, the result will be a unique, customized solution, made to solve our specific set of problems. This method requires the most time, effort, and resources, making it challenging to get buy-in.
If we need something more quick and budget-friendly, we could use or borrow parts of existing design systems as our own.
We may base our style guide on an existing one from another company, and only document things we want to do differently. Or, we could build a wireframe library using an existing design kit. We may borrow a token structure from another system, like Shopify Polaris, and update it with our own guidelines.
We can also pull inspiration from other systems to better support our design system goals. We might see another company’s accessibility guidelines and find that we want to include our own. We might love how a system communicates information to developers, and decide we need to improve this aspect of our system.
While it’s possible to stick with one of these approaches, it’s more likely that we’ll use a combination of them. Here are other questions to help you evaluate further:
- Where does this project fit in with company goals?
- How much time and bandwidth do contributors have?
- How much resources is leadership willing to provide?
This is a good place to refer to your audit findings as well.
Habitz
Let’s pay the Habitz team another visit to see how their decision is coming along.
They’ve had multiple conversations with leadership, who have ambitions to expand the company and product more rapidly. Leadership understands that even though the number of inconsistencies in the product is nothing to be alarmed of, it’s a problem that may soon grow.
Since the team has enough bandwidth to tackle this project now, they got the thumbs up to build a design system (hooray!).
Throughout this course, we’ll watch how the Habitz team builds their design system, and how they make decisions along the way.
Outro
If you’re at the beginning of your design system adventure, remember that the starting point can look different for everyone. It’s tempting to want to dive head-first and build something big right away.
However, if the timing isn’t right yet, making small incremental changes can still provide immense value and improvements to your team. Here are some resources to further explore:
- Sparkbox: Design Systems Survey 2022
- Knapsak's Design System ROI Calculator
- Design Systems Repo
- Sparkbox: Anatomy of a Design System
- Spectrum of maturity for design systems
When you’re ready, the next lesson will dive into different parts of a design system and how to build each of them out. I'll see you in the next one.