[00:00] Imagine your team has just designed, engineered and shipped a new application for your client, it's embraced as a huge success. The screens are consistent, the core user flows are streamlined and it's proven by the operators who work well at various locations. Now imagine six months have gone by, and that same client brings you back on to make some changes to the application. What you see on arrival is nothing like how you left it at the launch. The ones consistent screens are diverging and using different layouts to solve the same problems in different places. Your core user flows may be secondary to new ones, which don't follow the same design patterns you established at the outset. What was once intuitive feels unfamiliar and complex. What happened? This is an incredibly common situation, that's because product and application development is never done. It's an intuitive and evolving process. Operators or users discover new problems, which need new solutions.

[01:01] So screens are added or changed over time. Add to the fact that software is often built by large groups of people. When you combine that with ever-changing product goals, personnel and deadlines, a unique set of challenges arise. Creating a coherent and consistent and user experience, which will stand the test of time, quickly becomes a big challenge. In order to rise to this challenge, you'll need to establish a design system. This problem of divergence and inconsistent user experiences is what design systems solve. At first glance, a lack of design consistency may not seem like a major issue. However, the real world problems which arise from it are many and serious. Let's talk about those briefly. Different patterns responsible for the same action, generally results in user confusion. Lack of reusable design assets slows down the designers because everything needs to be created from scratch. A low number of reusable components will also slow down the development process. Introducing new designers and developers to an undocumented system is impossibly difficult. Hopefully this helps to demonstrate the benefits of investing in a design system, avoiding these potentially devastating problems.

[02:09] Now let's talk about what exactly a design system is. A design system is a collection of artifacts and tools used to ensure design and code consistency and product development efficiency. Your design system may be a collection of documents, articles, examples, code snippets, screenshots, design guidelines, components, philosophies, and other digital assets. It's a way to catalog your team's design patterns and decisions. Once in place, your system of tools and documentation will help your software to stand the test of time and scale. Usually this comes together on a webpage maintained by a design systems team. Larger corporations frequently make use of design systems. However, smaller teams or internal business applications will also benefit leaps and bounds by implementing a design system. Here's an illustration showing the parts of an example design system. Presented this way, it seems a little overwhelming and complicated.

[03:03] So let's organize and break these deliverables out into logical groups. We start at the left with mall abstract deliverables and work our way over to the right with more complex and tangible ones. These parts build up and then begin to rely on each other. This way of thinking from the ground up differs from how most folks have worked on application design and development in the past. The quote unquote old way is to deconstruct existing screens and document how their parts are being used. Instead, we'll start out with those parts and document how they might be used to build out future interfaces. It's a subtle but important difference. Starting with the parts and building up to screens is incredibly flexible compared to starting with entire screens and trying to pull them apart. So to review, a design system is a collection of digital assets and tools that will ensure design and code consistency. And you want to approach this by designing parts and then documenting how they could be used. So we now understand what a design system might be, let's get into building one ourselves.

[04:06] While design systems are not prescriptive, they do often share a set of common elements. Each system will be catered to the needs of your product and the teams involved. That said, start with these essentials and build what else you might need from them. The essential elements of a design system include principles, best practices, core design elements, components, and templates. As previously mentioned, the elements of your design system will start small and abstract, building up in complexity. Each step builds upon the previous level, compounding the value provided. Your design principles will drive all other parts of the design system. These might be derived from your company's mission statement or business principles. Think of them as a reference point or a north star if you will, that may be sought out when your team is facing a tough decision. For example, the Salesforce design system principles include clarity, efficiency, consistency and beauty.

[05:03] They state that we consistently keep these core principles in mind when making design decisions at Salesforce, and we encourage you to adopt them as well. It's helpful to include a bit more information and context about each principal's purpose or goal, so your whole team is on the same page. You'll also wanna keep the principles abstract and few in number. You don't wanna list 10 or more things here. Just a few words which can serve as foundational reference for future decisions. To give an example of what a principal could be, let's focus on the clarity principle. It reads simply, eliminate ambiguity, enable people to see, understand and act with confidence. Moving on to best practices. These are generally delivered as some form of written documentation. We won't be documenting specific design elements just yet, but instead we're documenting the essential patterns and work guidelines that come along with a team driven product. The goal of your best practices documentation is to avoid divergence and save everyone time by making decisions upfront.

[06:04] When everyone is on the same page, things move quickly. Best practices can radically change the onboarding and comprehension for a new employee. They help in drastically reducing the need for training or tacit knowledge transfer as your team grows and changes over time. Here's some best practices which your design system documentation might include. Naming conventions for files, projects or other assets, scripting or coding syntax which the whole team will abide by. For example, are we using tabs or spaces? How should everyone's development environment be set up so that we're all working together well and can benefit from each other's learning. Along those same lines, are there design tools or plugins, which might enable us to have a better work flow? What are those modules called and how should they be procured by everyone on the team? And we can't forget copywriting, so a glossary of company and industry terms would be helpful. This list is far from exhaustive but should get some ideas flowing on what and how to document the best practices your team will rely on to work efficiently. Remember that the more concise and clear your documentation is, the less you have to be involved in later on.

[07:08] So spend some time really working these ideas out in detail. We're switching over to core design elements, which means we'll move into the visual interface design portion of this design system. Style guides have been used for years as a way to document a brand's color palette, logo variance and spell out the do's and don'ts for working with that brand's assets. Here we'll start with the most basic design elements. These are sort of the raw materials of a design language. Components, pages and screens are usually made up of a collection of elements, all building upon one another. Similar to best practices, these core elements should be mapped out and display it in some way that they can be referenced by the larger team. This usually means more documentation, but can even include code repositories and other library sources tied directly into the product development process. Finally, we arrive at components. This is what most people think of when they hear about a design system. These deliverables are very important and the most frequently referenced by the team.

[08:04] So it's imperative to get them right. The goal of a component reference is to identify and illustrate its proper usage. Think of a humble button component. On the surface, it seems really simple. What would you need a document about a button? Well, here are a couple of questions you might wanna ask yourself. How large should this button be to support touch interactions? What should change about the button when it's on a mobile device? Are there different types of buttons to use in different cases? What color buttons should I use in dark mode? How much space should be in between buttons so they aren't miss clicked? Which button should be used to confirm an action versus cancel one? Which side of the text should my buttons icon be aligned to? Should I just use an icon here or should I use icon in text? Hopefully this gives you an idea of how complex a seemingly simple component actually is. Your design systems component documentation should address all of these questions so that everyone on the team now and in the future are making the same decisions. So how do you know what components you need to document? Well, you can start by taking an interface inventory of your application or do one of the competitor if your product doesn't exist yet.

[09:06] And interface inventory is pretty much what sounds like a comprehensive collection of the bits and pieces that make up the interfaces. Come through what you have, collecting screenshots and information about what is in the use now. Not only is this a useful place to start, but it will reveal all of your existing inconsistencies and highlight why this is such important work. With the interface inventory in hand, you'll have a solid foundation on what your specific system needs. Per component, it's helpful to approach the documentation from a few different angles. Categories such as structure style and usage help to organize the information and make it easier to find what your developers may be looking for. Let's walk through these categories again, using our button component for reference. Starting with structure, you'll want to detail the sizing and makeup of the component. Does this component reference any of your core design elements, such as color, spacing or typography? Here's the place to make those connections as you detail how the component is built. For our button, we define things like the different sizes available and when each should be used.

[10:05] Additionally, we'll map out the spacing needs around them and each of the variants that might exist. These cases when defined in a systematic way, cut out the issues, which commonly arise in product development, and will allow your application to seamlessly scale over time. Next, we might include a style category for a component which details how it looks and behaves in different environments. What changes when our button is in a disabled state versus a hover state? Should I use all capital text or not? The style will mostly referenced back to your core design elements and cherry-pick how and where they might be applied within these larger components. Finally, you'll want to define the usage of the component. The goals of usage guidelines are to provide a clear vision for how to use that component within the context of other interface elements. This should include both what to do and what not to do. For a button, we'll define when to use a primary versus secondary style button. Other users guidelines may include using icons and loading states to indicate that a process is happening.

[11:06] Usage documents may even include code snippets or API details for development teams and design file resources from designers. So that covers our example categories. Just remember that they're not prescriptive. Other categories might include things like interactions, placement, or even implementation. Finally, you'll want to introduce a concept of templates or layouts. Think of pages or user flows, which might be commonly used in your applications. These are made up of smaller components to form a complex layout. You want these to be consistent and intuitive for your users so that they're grounded and confident in their understanding of the product. Let's look at a few examples of templates. Say my application has operators managing items in a list on a bunch of different screens. Managing items analyst should consistent everywhere in this application. We don't want users to have to relearn how to create, reconfigure or delete items from this list every time. Additionally, where lists are located on a screen in relation to other content should be consistent.

[12:08] That means you need to document this type of list management interface as a template in your design system. By documenting these higher level UX patterns as templates, you can ensure that all future patterns created are developed in the same way. Another template example might be related to each level of hierarchy in a high-performance HMI. By creating a hierarchical system of displays, the operators can have overall situational awareness and the ability to drill down to very specific data points when necessary. Each of these levels might follow a unique layout and be documented as a design system template. Each layout would be unique from the level one overuse all the way down to the level four diagnostics. Forms can also be described as a template. Forms are used to get information and guide people with minimal fuss. Designing forms well requires making decisions about structure, sequence, interface elements, field labels, help and feedback. And we can't forget error messages, which can be scary.

[13:05] By making them consistent, clear and visible to end users, they can become easy to understand and even helpful. In addition to visual style and content, error messaging can be documented as a template, such as where and when they should be used. So let's review the essentials of a design system. Design principles are abstract ideas that drive other decisions, best practices are general ideas that other design decisions are derived from. Core design elements offer specific recommendation for things like color palettes and typography. Components in your design system are used to illustrate proper usage, templates can be used to demonstrate commonly used screens and complex objects such as forms and error states. Okay, so we finished crafting this amazing collection of resources. Now what? This step is critical because if no one uses or maintains a design system, it's a failed effort. It's all about open communication and making it easy for people to access and understand the rules. Let's go over some best practices for sharing your new design system.

[14:05] You'll want to host the resources somewhere that is obvious and accessible to everyone that will need them. This should be the single source of truth. Design systems are usually hosted online as a website, either publicly or internally. Think of them as a big knowledge base that is part UI kit, part documentation with instructions, part language and coding guidelines all wrapped up together. The more accessible and available this information, the stronger your design system acceptance and adherence will be. As changes or updates are made, be sure to communicate and inform everyone involved. Instill in your team that your design system will evolve constantly alongside your product, tools and the technologies. A design system is never done just as software development is typically never done, but is constantly maintain and added to over time. To enable an open dialogue and communication within your team, you might try to communicate changes to the team with a regular bulletin or published change logs. You can also give the pieces of your design system a clear status.

[15:03] Are they new, are they stable, are they in review? Is this page deprecated. Have open office hours or channels where folks can ask questions and expect a timely response from the design system team. Accept input and take action from folks that use the design system. A collaborative approach can be more successful than a top-down one. In review, your design is your single source of truth. Make sure it's easy for your team to access and update. Make it easy for your team to know when changes are made to the design system, and remember to respond to feedback from users and update your design system accordingly. We hope through this lesson, you're now aware of the advantages that a well-constructed and executed design system can bring to your organization or application. Some of the most visible and impactful benefits include fast and effective development, improved user experience and documentation to improve onboarding. As with any good tool, the more integrated your system is with your teams, the more effective it will be in the long run. If we leave you with one final takeaway to lead you to success, it would be to involve others early and often.

[16:05] Building a design system takes a lot of time and effort. Involving others in this process without rushing into things can be the difference between success and failure.