Name: Welcome to design systems - Lesson 1 : Introduction to design systems
Uploaded: 2024-07-28T04:40:38.000Z
Duration: 15 min 43 s
Description: Thousands of YouTube videos with English-Chinese subtitles! Now you can learn to understand native speakers, expand your vocabulary, and improve your pronunciation...

Adverbs of manner

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

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.

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.

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.

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?

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.

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.

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?

Subtitles ListPlay Video

Welcome to design systems - Lesson 1 : Introduction to design systems

entire

potential

process

dedicated