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, and highlight a few things to consider as you start your design system's journey.

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 a collection 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 are 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.

Let's explore some of the resources a design system might include.

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 the product, how things should look and feel.

You'll see aspects of these in most design systems.

Examples include color and typography.

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 red lines or annotations, or are embedded alongside code components with detailed documentation.

As you go through your design system's journey, keep in mind that there is no one design system that fits all.

Different companies have different needs, which require different solutions.

Now that we have an idea of what a design system is, do we actually need one?

You might be wondering how this could play out in real life.

Let's look at this scenario.

Kai is a product designer in Habits, 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 look like.

They referenced 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 straightforward 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.

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.

And 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 processes of building a product.

They also contribute to your customers' experience of the product.

Consistency, usability, and accessibility build trust in your product and can lead to a more engaged and loyal customer base in the long run.

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?

The first thing to look out for is 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?

Does your product use more than one theme, such as dark and light modes?

What about different devices?

Or you might need to remove redundancy.

Are people building the same things over and over?

Are teammates debating over the same issues again and again?

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?

If your team is growing, how long does it take to onboard new teammates with the product information they need?

Lastly, 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?

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 on 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.

Roam 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 get to see the results of your efforts.

This can make it challenging to get buy-in from leadership, especially if it takes away from the 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.

After discovering some design inconsistencies, a need for knowledge share 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?

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 or not you decide to implement a design system, audits are a crucial step in understanding the current state of the product.

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, and the support team might know about sneaky modals and error messages that you wouldn't regularly catch.

To perform an audit, first gather everything that exists.

Identify user flows in 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.

Next, sort and categorize everything.

If there are large numbers 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 notice 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.

Lastly, analyze what's been gathered to identify patterns and areas of opportunity.

Where do we see redundancy in user flows that can be 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?

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 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.

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.

Approval 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.

Throughout our design systems journey, we'll likely find ourselves revisiting phases on a regular basis.

Some phases may even overlap with each other.

Remember, this is not a linear process with a single endpoint.

Treat a design system like you would building software, an ever-evolving product that is regularly iterated on.

Thoughtfully planning and doing discovery work for your design system will make an impact on its quality, as well as support a more efficient journey.

Here's 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 can help champion and socialize it.

Take some time to consider.

Who in your organization would be valuable contributors?

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 systems team.

Keep in mind you'll need to balance it against the organization's needs and available resources.

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?

Audience 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.

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?

What might the process of soliciting feedback look like, now and ongoing?

The last aspect is to consider how we might implement a design system.

If we build the 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 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's Polaris, and update it within our own guidelines.

We can also pull inspiration from other design 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 own 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 within company goals?

How much time and bandwidth do contributors have?

How many resources is leadership willing to provide?

This is a good place to refer to your audit findings as well.

Let's pay the Habits 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 the 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 sufficient bandwidth to tackle this project now, they've got the thumbs up to build the design system.

Hooray!

Throughout this course, we'll watch how the Habits team builds their design system, and how they make decisions along the way.

If you're at the beginning of your design system adventure, remember that the starting point can look different for everyone.