Digital Design: Creating Design Systems for Easier, Better & Faster Design | Dan Mall | Skillshare

Digital Design: Creating Design Systems for Easier, Better & Faster Design skillshare originals badge

Dan Mall, Creative Director + Advisor

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
10 Lessons (54m)
    • 1. Let's Get Started!

    • 2. What are Design Systems?

    • 3. Examples of Design Systems

    • 4. Making Your Design System Wishlist

    • 5. Creating Your Own Design System

    • 6. Getting Buy-In

    • 7. Implementing Your Design System

    • 8. Evolving Your Design System

    • 9. Final Thoughts

    • 10. More Classes on Skillshare

211 students are watching this class

About This Class

Stop reinventing the wheel, and start having more fun. The secret to easier, faster, and better design is an effective design system!

Great design systems help you spend less time on rote, repetitive tasks and more time on the creative work you love. They're a comprehensive reference full of guiding principles and usable components—and that means less time creating buttons, forms, and menus, and more time for innovation.

In this one-hour class, you'll join creative director Dan Mall as he shares his step-by-step process for making effective design systems.

From creating your own system to evolving it over time, lessons cover everything you need to create a comprehensive, effective design system you can use every day.

Key lessons include:

  • Practical components & overarching guidelines
  • Examples from Apple, Google, Shopify & more
  • Methods for creating a great design system
  • Advice for getting buy-in from key stakeholders
  • Tips for implementing & evolving your system

Plus, Dan shares one of his favorite exercises: a wishlist prompt to help your team unlock how a system can benefit them every day.

Get ready to learn how a design system can make your design work easier, faster, and better!

Whether you're a creative freelancer, designer, or member of a product team, you'll leave this class with the tools you need to make better decisions, save time, and focus your efforts on the design work you love most.





Images: Dan Mall x Skillshare


1. Let's Get Started!: I'm Dan Mall, a designer and creative director and the founder and director of Super Friendly, a design collaborative in Philadelphia. Today's class is about design systems, how to create them, how to work with, um, and how to get all of your colleagues on board. A design system is a tool to help you become more efficient and more effective in your work . It should help you move faster. It should help you work better with other people. And honestly, you should have more fun. One thing that I see designers and developers doing over and over again is just reinventing the wheel. How many times you want to design that button or that form are just the things that are really dry about a project Lets get that stuff out of the way. A design system should take care of that stuff so that you could be freed up to do all the fun stuff that you normally don't get time to do. But you actually want to do otherwise. After taking this class, you'll have all the knowledge and the tools that you need to be able to work with a design system, create your own and work with other people. My goal for you is to get you thinking more and more about design systems, trying one out and then really using one on your project. No good class is complete without homework, so I'm gonna be giving you some stuff to do, too. What we'll do is we'll create a checklist of things that will help you figure out why you need to use a design system and actually make you excited about doing that. We'll be able to share it in the project gallery, comment on it and see what other people are doing as well. Thanks for taking this class. Let's get started. 2. What are Design Systems?: If you think about a design system, I don't know that we have a canonical definition for it. But it should be something that helps you easily make the things that you want to make. Most design systems have a lot of things in common. They have components or patterns, which are really the little pieces that you're going to use to put together in what you're making. And there's also the guidance in the reference for how you're going to use those things. And those things are usually put together in a reference site. And that reference site has all sorts of instructions for you, like things like how to get started. How do I download this and actually start using it When, When we're talking about a digital product, what do I do with it? Where do I get the files? Where do I get all of the all of the stuff that I need? And then once I have them, how do I use them? What are the best practices in terms of both industry best practices as well as the best practices of this system in particular? And so those things are usually the things that come with a design system. I think it's also important to talk about what a design system is not and this authentic. It's like super nuanced because what a design system is not, Let's say, a sketch file. Now a sketch file can be part of a design system, but in itself, it's not a design system. In the same way a pattern library or component library is not a design system in its on its own because it's missing the guidance part. It's just the pieces, so a pattern library and our ah component library are part of a design system. But it's not the whole thing, so really, I think what's important about the design system is that it's the combination of these things. It's not just one of those things on its own, and that combination again has to have a result as well. The design system has to help us collaborate better. So as designers, developers, product people content people, the design system should be a tool that all of us can kind of rally around and used to help us make better work. If we don't, if we're missing parts of that, our work can be better. There are lots of great things about design systems. The first great thing is that design system save you time and save you money. And that could be you as a freelancer or a single person working on something, or it could be your whole organization. So how does it save time? Well, think about how many times you've designed a button or how many times you've designed a form. Let's say it takes a whole day to design a form page, and you do that for every single project. Now imagine having a tool that makes that go from one day to 10 minutes. That's already a day that you say. That's a day that you could do something else. And if you are building for your time, that's a whole day that you don't have to build on that thing. You can actually build for something else, so it helps you. It helps your clients. It helps your organisation. It helps you save time in doing the things that you don't need to do any more, and it saves everybody money because they don't have to worry about those things. It also saves money in a little bit of an indirect way, too, in that it gives you consistency. So one of the things that breaks down organizations and breaks down projects at a nuanced level is really about how consistent something is. So when things are inconsistent, it makes users uncomfortable. It makes designers uncomfortable. It makes developers have to build slightly different things. So consistency actually helps you to build something once and know that it will propagate throughout the rest of your system. Another way that it designed to some helps is that it should help all the people on the team collaborate. So I know that when I'm working on my work with a team, sometimes I'm the designer and I'll be working with the developer. And what I love about having a design system is we can use it as a shared reference. We now the same language so we can sit around a white board and we could say, Oh, let's use the drop down component and everybody knows what I mean. And so what that has done is that saved me time, and it saved our collaboration time where I don't have to go away, make a photo shop or a sketch file handed off to a developer, and then they have to build that. We can actually just sketch it out together. And I sometimes don't even have to jump into Photoshopped to do those things right. Well, sketch it together. The developer can build it, and then I can come back after that and say, All right, let's tweak this. Let's tweak the spacing and things like that. So it actually helps collaboration by giving you a shared language that all of you are using the same words saying the same things about the things that you're trying to design and build. Maybe my favorite way that a design system will help you is that it actually should free you up to do the things that you really want to do that Normally, look, you can't even get to on a project. I know I have a list of all the things that I can't do on a project sometimes, and it's having a design system or something to help me and give me some efficiency. There helps me get to those things. So, as an example, if I didn't have to design that button over and over or that form or that header or these global elements Instead, I could take time to do that. Animation. I really want to get Teoh or maybe that illustration Or maybe try a new technique or learn a new technology, or maybe learned fig, MMA or a new app or something like that. So if you have those things already in the can, if you have the components, if you have the principles and you're using them, that just save you time and now you can get to that extra little bit of oomph that you want to put in your project that you normally don't get a chance to. 3. Examples of Design Systems: talking about definitions. It's pretty abstract, So let's look at a few examples to help make it more real for us. So this is the graphic standards manual for the New York City Transit Authority, and this has been around for a long time. This is really the Bible of graphic standards manuals. Part of the reason that I think that the New York City Transit Authority has lasted so long is because, and the standards of it is because this manual is written so well because this design system has written so well. Take a look at the the guts of this. You'll see here that one part of this manual is just the parts, so you'll see that they have everything from how each letter is supposed to be specified in here. So here's how you print a double A. Here's how you print a B. Here's how you print a double C, and it's in meticulous detail. It's every single letter of the alphabet to show you. If there was a subway line that had these letters, this is how you would print it so they don't We spare no expense in making sure that you have specifications for every single thing that you might want to use all the letters of the alphabet. It's not like they're showing you one, and then they're saying, Yeah, I just do all the rest of them like that They're going into painstaking detail to kind of show you that stuff. So this book is full of all of the different parts, but it's not just the parts. It's also full of examples of how to use things and guidance on how to use those things. So Michelle an example of that? This page here is a page about temporary signs, and this shows the people who are implementing this system how you can create a temporary sign. So there's guidance here that says that tells you what a temporary sign is. The nature of the temporary sign requires that it will be easy to produce, place and remove, and then has instructions for how to produce a temporary sign. And then it also shows examples of where to put that temporary sign, what it should look like, where it should go and how it should actually function. And this is a great guy. This is great guidance for a design system. So this this whole book, this whole manual is, uh, partially just the parts partially the components themselves. But then partially the guidance and had the thoroughness of both the parts and the guidance is, I think, what has made this standard this system hold up for so long. Both of these books are really great thes air books that were written in the late seventies about architecture and crystal Alex Christopher Alexander basically talks about in this in these books, how can you approach building architecture in a way that a systematic and like the cover of the book says a timeless way of building on This is kind of a part one and part two, and the pattern language side of it is How do you actually implement those things? And then this is kind of the theory of it. So it's almost like a design system in two parts where part of it is the parts, and then part of it is the actual guidance on those parts and on. There's a lot of great theory and kind of philosophy as to how to build architecture in this way, a lot of which applies to how we might build digital products today if you're looking for something more modern, This is a fantastic book by Allah. Call Mantova. It's called design systems, and it's about how to build a modern design systems, all the things that we're talking about in terms of theory and in terms of practice and in terms of parts. All the compiles in this book and talks about how to actually use design systems and make design systems and maintain them is a fantastic reference for anybody that wants to learn more about this topic. Now this is a bit of, Ah, nontraditional example here. Most the things that we've looked at our actually manuals on. This book is called Designed by Apple in California, and it's a little bit a little bit different than some of the other examples. If I look through this book, you'll see that there aren't a lot of words. There's really just photos, and these photos are beautiful photos, that kind of document what Apple products actually look like Now you could call this a photography book more than is a design system, but it doesn't. It does have a little bit of ah reference for design system. So what I mean by that is there are a few 100 pages in here. And as you just flip through this book, just page by page, looking at hardware, looking at all the different device devices that they make and just kind of getting and seeing them from different angles. What you'll find here is that you could leaf through the couple 100 pages of this book and at the end of the book, even though there hasn't been any words, you can understand how Apple builds the products. You could probably conclude something at the end that says here the principles that are important to Apple's work. I think that's the job of a good design system, too, is to be able to look through all the things and be able to conclude. Okay, this is what's important to this organization about how products are built. And so even though this is a little bit of a traditional a nontraditional example, I think it still makes a good point as to the job of what a design system should dio. So one of the things that I want to point out through this is that not all design systems have to look the same. The outcome is what's important, not the actual format of it. So this is one example of a design system that Apple might have. They also have another that's maybe modeling more popular than this book. It's called the Apple Hig Human Interface Guidelines, and that's for anybody who wants to build an iPhone app. So when we look at at that hig and we look at this, it's two examples of design systems from the same company. That's not to say that you can only have one design system. You can have two if they apply in different ways, or if you want to show your products in different ways. So there are also digital versions of design systems, not just in books. And so let's look at a couple of the most popular ones. Material design is one that is created by Google, and lots of people use material designed for non Google products, but also Google use them for Google products. So what you'll see here is that it's a unified interface for android APS for APS, that air by Google for things like Gmail and, uh, and Google Maps, but also some of their subsidiaries, like YouTube. And so this is a design system that has all the stuff that we've been talking about. It's got components and it's got guidance. So let's click around here. If we go to the developed tab for developers, it's got all the components that we actually need, and it's distributed by platform. So I've got Android, IOS, Web and flutter. So if I click into the Web portion here, what you'll see is I can get to the components and I can get to the documentation itself. So Components gives me this whole list of things and all its just clicking one. So if I wanted to use a button in as part of material design, it gives me an example for what this is, and I can scroll down and it gives me all of the guidance is toe. Had it installed this thing and how to use it? And even more than that, this whole system gives me guidance on how to use these things from a philosophical standpoint. So it's got all the technical work as well as the philosophical work, and all of this is in one place, and this is pretty common with design systems is being able to see sort of a list of all the components being able to see the component here in action, a live version of it, and then some guidance on how to use it and when to use it. The same thing is true. Kind of on the design end for material is that this is kind of a coating end but the design and introduces things like principles. So let's look at the color principles for material designed. For example, what this shows is all the color palettes to come with material and how you might use them . So lots of robust color palette here for all the way from shades 50 to 900 with show you the primary and the secondary colors as well as all the variants and the tents. And the Hughes on this also comes with principal, so they talk about ledge ability as a principle and expressiveness as a principle in a hierarchy as a principle. So again, you see these combinations s, it's not just the components, and it's not just the guidance, it's all of those things come together in context, we jump over to another example. This is Salesforce's design system, and it's called the Lightning Design system to see here some kind of a similar approach where they have guidelines and they also have components. But they also have specific details about things like accessibility and tokens and icons. So if we're going to look at the components themselves, I'll see you here again. Kind of the same thing. Here is a list of all of the components that come with this system. If I go into buttons here, you'll see that I get all the variants. So I've got all the button based, the neutral, the brand outlined brand, the destructive in the success and again, right below. It's just the code to be able to use that. So from a design standpoint, here's how the thing will look from a development standpoint. Here's the code that I need to implement this, and then again, right in context is the guidance. So I get. Here's an accessibility rule of thumb for for the button. I don't have to go somewhere else to actually see it. It's in context that the component itself, last example that will look at here is Polaris by Shopify, and this is a design system. And so it's got again the same things that material and and lightning have, but in a slightly different way. And I want to point out something specific about this. So we look into the components of Shopify. Shopify is an e commerce platform, and what's really great about their design system, Polaris, is that they actually show things that are specific to their users into their customers. So it's not just here's a button to use because it's a button and people need to use buttons, but they actually show things in relation to merchants and in relation to purchasers. So, as an example kind of go into actions here, and I go into an action list and this action list gives me some guidance. Same thing that we saw in material and in lightning, where we've got the the component in action, get to see how it works, and I get the code to be able to implement that. But what they talk about here that is specific to them. If I read this guidance, here's an actual list renders a list of actions are selectable options that's universal. That's generic. But then they get more specific. This component is usually placed inside a pop over container to create a drop down menu to let merchants select from a list of options. So again, this is really specific to how they want merchants to be able to use these components. And that's one of the things I love most about This Polaris system is that it's not just anybody who wants to use a list here. I use list. It's specifically designed for merchants and for purchasers. 4. Making Your Design System Wishlist: Let's get started on our first assignment. Let's say you don't have a design system that you're working with either by yourself or maybe with your team. Let's start to create one. The first thing that we want to do in creating one is really just understand why we need it . So let's do this. Grab a piece of paper and fold that piece of paper in half on the left side. What I'd like you to do is write down all of the tasks that you did on the last project. So think about the last project. You did everything you did, no matter how nuanced. Write that stuff down. That could be. I designed the icons. It could be. I designed this page. It could be I wrote a brief. It could be whatever it is, I sent this email about this particular thing. Try to write everything that you can remember about your last project. Okay, Next step. Now that you have a list of everything you did on your last project on the right side of the paper, I'd like you to write all of the things that you wish you would've gotten to that you didn't get a chance to. Right? And this is really like your dream stuff. So think about that animation you couldn't do that. Extra little bit of accessibility helped. You didn't build in. That could be the icon system that you want to design custom. But you had to use a stock library instead. What's all the stuff that you wish you could do on that project? Or maybe any project? Here's where it gets interesting. On the left side of the paper, you have all the things that you did on the last project. I like you to circle the things that you think could be done more efficiently. A good format for thinking about that is, if only I had X, this thing would have been easier Last step. Now they have all the stuff circled on the left of things that you could be or efficient. I'd like you to draw a line from that thing to something on the right side. And this is gonna be your trade sheet. So, for example, on the left, you might have something like a design all the buttons and on the right, you might have something that says design custom. I concept if you draw a line from the buttons to the icon set, you essentially have made a trade list to say, If I had a set of buttons already now I could spend time on this. I concept. Here's where the match comes in. You've just created your first wish list for what your design system should do. So now that you know what you want a design system for start crossing stuff off the left side, where on your design system. As you start on it first thing, you take care of buttons. Want to take care of those buttons? You get your icon set on the next project. Here's the cool part. Now that you've got your assignment done, you have a list of all the things that should be in your version one of your design system , and this is great when you're working by herself. What makes it even better is you can now start to do this with your team, right, and you could do this exercise with your team. You can lead this so you make your list. Maybe you could ask your co workers to make their list two so If you're a designer, maybe ask your developers that you work with to make their list. What's the stuff that they wish they could dio? What's the stuff that they would trade for? Something that bit that they could have in the can already And then ask your team members to trade him around is the thing that I do in workshops all the time. I have designers make a list of all the stuff that they want to do. Then I'll have developers make a list of all the stuff they want to do, and everybody else is working on the project. And then we trade lists. And what that does is it creates empathy for each other because sometimes designers don't even know that a developer would have liked to put a little bit of extra designed polish on that thing. Maybe that was a thing on their list, and designers get really fed up with developers like Oh, man, it didn't you know, they did put the time in, but it could have been that they just didn't have the time. So exposing this thes lists, making them public and being able to see everybody else's actually will help build some empathy for saying, Well, I didn't even know that you want to do that now I can help you with that on your next project. That's a really great team building exercise and something that really gets people shared on the vision of a design system. And so even the process of creating one could be something that gets people more on the same page. Now that you have this list, you know why you need a design system. Next, let's talk about how we actually make one. 5. Creating Your Own Design System: design systems generally have two parts patterns and processes. Which one you start with is really up to you. There's no right or wrong order. Where I would recommend that you start, though, is the one that you have the most ideas for. What's just itching to get out of your head? Do you just know what buttons you want to design, or what Drop down components you want? Design will then start there. Maybe, though if you don't have ideas for that, maybe you have more ideas for principles, things that you want to guide the system. If that's something that's interesting to you and you already know what you want to say, they're start on those. So eventually you have to get to both. But wherever you want to start is up to you. Let's dive into principles. There are two types of principles. There's universal principles and their specific principles. So, for example, a good universal principle could be something like access for everyone. Now that's something that, as you make APs and websites, you want everyone to be able to access. But that's also true of every website to that doesn't mean it shouldn't be in your design system. Put it in there. Let's talk about specific principles, though specific principles are ones that work just for your system. A great example of a specific principle is from TiVo. One of TiVo's designs of principles is its TV Stupid. What I love about that principle for TiVo is that it's so great for them. It's a great monster for them to follow its spirit of them. It's casual. It's a little bit of reverent. It fits the brand. And also it wouldn't work for another organization it wouldn't work for, say, it's QuickBooks or Salesforce or any of those. A specific principle should be something that's really great for you and your organization , but kind of an awkward fit for someone else. I imagine that I was working a TiVo, and I had a problem on something that I was trying to design that I could look to those principles to go. How can this help me? So principle should really help you in times in point of tension. So where you don't really know what to do, you should be able to reference your principles and go, Oh, right, that's what it's saying to Dio so a principle like it's TV stupid. If I'm trying to decide between two different interfaces, maybe I would choose the more simple one because it is more in line with the principle of the company. Both principles and patterns should have both universal application and specific application. So let's talk about the pattern side of that. When we talk about patterns being universal, There are some things that every site is gonna have. Text is a good example of that. Ah, form is probably a good example of that to maybe you don't need to reinvent the wheel with how you're gonna display text. That's fine. But you also are gonna want some specific patterns for you for this project you're working on or the organization that you work in. As an example, let's say you work for the I. R. S. Your design system for the IRS probably should really focus on forms and data entry, But let's say you work for entertainment company. It's probably less about data entry than it is about maybe billboards and heroes, so make sure that the patterns that you're working on the components that you're creating are really specific to your organization and your organization's needs or the needs of the project that you're actually working on. There's an interesting nuance to patterns and components and language between them. If you look at all the design systems that Republican out there right now, not all of them use those words in the same way. So components generally means the little pieces and parts that you'll need to be able to create. That system pattern sometimes means that, but I've seen lots of organizations use patterns in a different way. Sometimes a pattern is is an example of a flow. So, for example, a component could be something like a drop down menu. But a pattern could be something like a check outflow. It's up to you. What's a better fit for you? Just make sure you're consistent about how you're using it. If you're a checklist kind of person, there's some great resource is out there for you as well. Designer Nathan Curtis has an awesome checklist for design systems that outlines all of the different parts that you might need in your designed to suit. Now, you certainly don't need all of, um but maybe take a look through them and you'll find that they probably match your list, too. What are some things that you may be? Then think of those of things that you can grab from Nathan's list. These are the parts that you'll need for the first version of your design system. Another really great way to create a design system is to actually take things that are already working and extract all the good stuff from that. Especially if you work at a big organization. You've probably made stuff, and other teams have probably made stuff that's probably really good. So you might have a product out there that has a really good flow in it. Maybe it's a check outflow, log and flow. Maybe it's a really great component, like there's great consistency in that or the typography. There is really good what you can do to start your design system. Off is really look at that stuff and go. You know what's working there? The typography that typography there is what we should use for many more things. So now start to extract that stuff from that project. We call it pilots, right? Use those as pilots and say Okay, wouldn't extract that stuff from the pilot, and that's gonna be the base super design system. If you don't have that stuff, you can start to create it. So let's say you work for an entertainment company, and maybe you don't have the ideal product. Well, you can create it. You can say, All right, we're gonna do a fictional exercise where we create a guide app and you can create that guy tap and then say, All right, we're gonna take this stuff from that guide up. I'm going to use that to start our design system. So the key here, when you're using pilot projects, is to look at things that air riel, not things that are abstract. Sometimes it's hard to design a button if you don't know what it's supposed to do. So instead of designing a button in isolation, designed a whole screen, then take the button out of that screen and say, This is gonna be the button that we use. So pilot products really come in handy. For that is being able to look at things in context and then taking them out of context. If you do it the other way around, it's gonna be a lot more difficult. So that's where things that are really APS come in really handy. So how do you organize all that stuff? Let's say you've taken some stuff out of a pilot project. You've created some of your own stuff. You've made a list of things that you want to dio. What do you do? Well, I think the first step in that is trying to organize it, and that's really up to you and the culture of your organization. So for some organizations, you might already have Ajira board or a cello board or a confluence or something like that , where you can have a nice space to put things and organize them. But you might not. So you might kind of start your own Google doc or an Excel sheet or some folder on your computer as a place of started. That's OK. Any of those ways are the right ways to do things. There's no wrong way to do it. I think that's a good thing that you can dio organize it, and then the next step would be to figure out how to share that. So what's the best way that you can share it? Is it sending an email to the rest of your team? Well, great do that. Is it preparing a base camp poster? A slack post Do that, too? So started thinking about these ways that you can organize some of these materials so those could be the components and maybe the guidelines around it and figure out how you can share it. A good thing to do is look at how other reference sites do it. So if you need an example, it's okay to go on copy material design or bootstrap or the lightning design system and kind of use their thing as a guide. So if you want to structure your your word Doc in that same way, that's all right. That's a good start. There's no wrong way to do this. It's important we organize it and be able to share it, and that'll get you started off on the right foot. As a designer myself, there's one interesting quirk that I find about designers were always so precious about her work. We try to make everything really special, working on a design systems a little bit counterintuitive because the first version of your design system especially if you work in a big company should take care of the boring stuff . My friend Josh Clark has a great post about design systems taking care of the boring stuff , he says. The most exciting design systems should be boring. It should take care of all the stuff that you don't want to dio. It shouldn't be all the special snowflake stuff that you actually do want to do. Save that to yourself and save that for something that you can actually pour your time and effort into. So the first time you started design system, Whether you work at a big company or you're just working by yourself on a project, start with all the boring stuff. Make the buttons, make the forms, make the footers get that stuff out of the way so that you can actually work on the stuff. That's a lot cooler 6. Getting Buy-In: one of the hardest parts about design systems is getting people on board. In my experience, that is the hard work of it. Word designers were developers. We know how to do the design and development really easily. That's what we do. That's what we're really good at. What's hard is actually convincing somebody that they need that and that we need that and that they should be incentivized in that. So that's always the hardest part for me. About design systems is getting people on board. I've had the fortune of being able to work with really great clients who know that, and they've done a good job about kind of setting the tone and setting the table on their end for us to be able to do good work. So as an example, we work with the Seventh Day Adventist Church to help them with the design system, and a year before we did work with them. Our client, Brent, who is the Web manager there, he went to his boss and he did something that was really interesting. They make a lot of websites there, and what he did was he print out those websites in these little thumbnails. He's three inch by three inch thumbnails, and he put them all on mounting boards. And he ended up having six or seven mounting boards, about 150 different thumbnails and all of the look different. And he went into his boss with these mounting boards. And he said, Look at all the money that we're wasting like all of these are custom built, designed from scratch, reinventing the wheel all the time, and we just aren't doing this fast enough. We're not able to do this at the speed and the volume that we want. And so we're wasting money and I know how to fix this. We need a design system, and if you could give me the budget for it, and if you give me the room to be able to create this well, we can get a lot more efficient we get. We can go a lot further in our organization. And so for him, what was really great about that, and for us to is that he really set the table for us to do good work. And he did the work of kind of getting everybody bought in on the idea of it as to why they need it. And so our work became really easy. We could actually do the work that was easy for us, which is the design and development work, because we didn't really have to do the convincing. Somebody else has to do the convincing too. So I think that's an important part of this work. And so how do you get somebody to do something for you? Well, you have to find what their incentive iss, right? Because not not a lot of people are going to just up there Good will do something for you being unselfish. Instead, they got to know what's in it for them. The defense you're talking to and you've got to speak their language rights. If you're talking to a developer, why does the developer want a design system? Will they want it so that they don't have to write code from scratch? Or maybe they don't want to write code That fails because they're doing from scratch every time. So maybe consistency is the language that you speak to them, maybe for your chief financial officer at your company. For them, it's about knowing that we're going to save money doing this because we're not gonna have to spin up as many teams or we're not gonna have Teoh spend as long on projects. So speaking the language of efficiency is probably a good a good thing for them. So really depends who you're talking to you and try to figure out what what's the language that they need? What's the thing that they need to hear in order to to know that maybe it's the CEO of a company? And for that person, it's about delivering on the mission of the company. So maybe for them, it's about how is this design system gonna help us achieve our mission? So I really think about your design system is being able to cater to all the different parts of your organization high level, low level in the weeds, in the in the forest and the trees. And so what's cool about absenteeism is that it has all of those different parts. If you can kind of extract those parts and say, Oh, this part is about finance, this part is about efficiency. This part is about mission. I think you'll be able to convince people ah lot a lot more effectively. So when you convince somebody of anything, you've got to do your research. One of the ways that I find this really effective is just talk to people one on one. So that's that's a good way. And when we start with clients, we talked to them about what their needs are. What really what's the pain? What hurts right now, we're just really slow with this thing. Okay, cool. So if this were faster, how would it help you write? So asking really basic questions is is helpful. Sometimes doing that one on one is less pressure than if it's in a group. And so one of the things that I would recommend is start by talking to people one on one as to how how this thing could help them, or generally, even how they can be helped. So maybe the solution is not a design system, but oftentimes an organization with questions about efficiency and speed and money and time . A design system is really good tool for that. So ah, good way to kind of get set up for that kind of get the buying is to say, Well, everyone, everyone tell me where it hurts right now. Tell me what are the pains and on? And then a design system can be a solution for those pains. I think it's useful to look at other design systems as a way to say Here is a solution to a problem that's similar to what we have. But what's what's tough about that? What's really unclear is, well, people aren't really worried about the solution to the problem. They're really worried about the outcome, right? So it's hard to look at another design system and go, Oh, I see how that has helped efficiency at that organization. So what's really useful? And unfortunately, there's not a lot of statistics about this right now, But more and more coming out, which I think is really great, is not only just saying well, Salesforce has a lightning design system, but instead saying we'll save Salesforce actually cut their time on projects in half because of their design system. I think that's the kind of stuff that really helps people is to understand that and kind of hear those specifics to say Oh yeah, because we're kind of in the same boat and if that's the outcome they got with this tool. Maybe we can have a similar outcome with with a similar tool. A design system is a really big tool for an organization toe. Undertake the process of designing one building one implementing one is a Herculean effort . It's not something that you can probably do in a day. So one thing that you might think about is, well, what is the version of it that you can do in a day? What's the thing that you could set up in a couple of hours and say All right. Over the course of a week on this project, this small tool helped me by cutting down my time in half. So imagine if we scale that tool up that it would cut time in half a swell. So now, if we had the tool that could save us six months on what would normally be a 12 month project, that would be great. So if you don't have statistics, if you don't, if you don't have access to well, here's what another organization has done with this. Maybe you can create your own little test case and say, All right now that if we scale this stuff. If we extrapolate this, we can see that we probably get this much savings. And what's great about that is it will be really specific to your organization. So it won't be anecdotal data. It won't be data that says, Well, these organizations got this so maybe we can get this here. It will really be based on what you have experienced in that particular environment. Approval is really important with design systems, and the reason for that is because a design system is so broad that it touches every part of an organization, right? So it's not just for designers, despite it being called a design system. It's not just for designers. It's for developers and product people and content, people and everyone in the organization. And so everyone has to be bought in because it's gonna be implemented it across the organization. And so for lots of things, I'm a big proponent of, you know, kind of Astra forgiveness instead of permission with a design system that might be the exception. I think that getting people bought in is going to save you a lot of headache later on, because even if you start kind of at the ground level and go, Well, let's just get this started and we'll figure out how to implement it later. You're gonna run into a roadblock with when you get to that point where you're like, OK, we need to implement this. We need to get it into involved in our infrastructure or part of that you're gonna run into a wall there. So getting more buying up front is usually more beneficial. Getting buying in an organization is a little bit different than getting buying on a project. So let's say you're a freelancer. You work at an agency, maybe a small agency, and you're talking to a client about a design system for them. So some of the some of the nuances there are really interesting where where I've worked on design systems for clients sometimes will create a pattern library and a reference guy just for our team. And sometimes the client has no interest in it. So it becomes a helpful tool for our team and say, Here's how we're gonna make the work for the client. And then the client wants the output of network. So I've had some clients say, Yeah, we don't really care about the pattern library or the reference site. You know, we just want the final pages, and that's totally fine. So if you use a design system for yourself to make the output for the client, that's great. You know, it was useful to you. You don't have to feel like you have to hand that over now. I think that you should be willing to hand that over to your client and actually have the conversation with them and be open with them to say, Listen, this is how we were able to make this thing so effectively and at high quality and really quickly. We think that if we gave it to you, too, you would actually be able to do that with your organization. Some clients bite on that, and some clients don't. But if you work in an agency or you're a freelancer, don't be afraid to just use it for yourself to create the output and then offer it as a bonus for the client. If they actually want to have that, that part of the tooling a swell Whether you charge the client extra for this design system is really up to you. 7. Implementing Your Design System: implementation is super important to design systems. Think of your all designers. Think of how many times you've gotten a PdF style guide that some brand has said. Yeah, just use Follow the style guide. And then what we do is we just throw it away, and then we do what we think is right. Anyway, if a design system is really just a reference I and not actually implemented into the tools and the culture of your organization or your project, no one's gonna use it. So making sure that it's like part of the mix is super important to a design system. One of the principles that my team uses a lot when we work on design systems is with one of our favorites is make the best thing the easiest thing. Lots of teams that we work with use bootstrap. And when they start to want a design system, part of our challenge is, well, how do we make the design system better than bootstrap? Bootstrap. It's such a great tool. And so whatever we use that has to replace it has to be better, and there are lots of versions of better of what better congee so as an example, bootstrap is pretty vanilla. If I use Bootstrap and I want to use that for my organization, I still have a lot of work that I mean to do with it. I need to embed my brand fonts. I need to have my organization or my projects color palettes, so there's work that I'll have to dio. So if the design system already had that stuff baked in now, the best thing to use the design system is actually the easiest thing to use, because I don't have to do as much work in it. So one of the principles that we try to use in how we work with clients and how you might be able to do that with your work is how can you make it easier than the thing that people are working with right now? The Holy Grail off a design system, is a tool that is implemented in everyone's workflow, right? So it makes designing easier for designers and makes coding the front and easier for front and developers. It makes coding the back end easier for backing developers that has product management tools for product managers. So the best implementations are the wonders of the Holy Grail is the one that everyone can use the design system now. That's really hard to do, right. There's lots of tooling that needs to be built. There's lots of process that needs to be implemented in a workflow that needs to be implemented. So ideally, a design system would say, have the design references for designers. It would have the front end tools for front of developers, and it would also be integrated into the implementation so that back in developers could use it as well. I've rarely seen that happen, and so lots of organizations are working toward it. But there's only a handful that have actually accomplished it, and even less so that actually published about it. Lonely Planet is an organization that has done it a few years ago. They have a great system called Rizzo that's worth looking into, and very recently, Airbnb has a pretty good system where it's implemented into a lot of their tooling. I think a good way to think about how to integrate a design system in the workflow is to think about it like any new tool, right, so when there's a new tool that you're using. You're probably gonna notice it a lot. You're probably going to be able to call it out. You're probably gonna have to talk about it. You're probably gonna have to remind people that use it right. So when you first implemented design system in your organization, you're probably going to do a project without it. And then somebody will say, Oh, we should be using a design system for that And that's okay. That's probably part of the trial period. The on boarding period of it, as it gets more and more integrated into your workflow. As you get used to it, it starts to become second nature where now you no longer build or design without your design system. Now you're actually reaching for it more frequently. And it just becomes part of your part of your nature, part of your tooling part of the natural part of your workflow. More often in organizations, a design system is really useful for designers in front of developers, and that's a great place to start having some design reference and guidance and also having some front end codes and html CSS and javascript that a friend developer can work with to be able to build interfaces. That's a really good first step. Integrating that into a back end tool is probably the next phase of your design system. What aversion to might look like? It's, um, tooling for for that kind of stuff. And so that's the place that you're starting. That's OK. That's a really good place to be one of the definitions that we talked about with design systems that it is it. A design system is a product, and so you've got to treat it like a product. So how do you get people interested in a product? Well, you have to do marketing for that product that might be email newsletters. It might be a Twitter account. It might be a slack group. It might be just ways that you can get people involved in interested. A design system, even within our organization, is not an exception to that. So you might have to do the same type evangelism that you would if you are making a software service product, except that you're just doing it internally, so that means getting people on board. We talked about buying a bit. It means being able to evangelize to them a little bit, setting materials, sending frequent updates. So you've got to treat it like a full fledged product. It's not just a tool, it's a natural product that you have to support. What's really great about a design system is that it could be opted, right? So not everyone has to use it in the same way that some organizations you don't mandate the design tools or development tools for people to use. People can use their own code editors. Or, if you want to use sketch versus fig mo versus Illustrator, you have the liberty to do so now. You could make an incentive for people to say if we all use this one tool, we all benefit, but it doesn't need to be mandated. I've found that mandating from the top down very rarely works. It has never worked in a sort of forcing all developers to use the same coding platform. It hasn't worked in making designers use the same app. It's not gonna work with doing it with a design systems well. So instead of thinking about how it could be mandated instead of thinking about how you could incentivize people to want to be able to use that incentives are interesting to talk about. Like, how do you actually get people to use something, you know, you appeal to them, and so different things appeal to different people. So certainly efficiency and those kinds of things are really helpful to convince people that owe, you should use this thing. But, you know, sometimes assigned of softer ways to do it. Sometimes people just want to be part of something, you know, And so creating community is a great way to incentivize people to say, Look at all the people that are using this design system internally or look at all the people that can be using it. And don't you want to be part of this club? So I don't think it has to be just the hard, tangible benefits. It could also be that, like, you know, you're joining the Cool Kids Club or you're doing this new thing or you're part of the the cutting edge part of this organization and what we're doing, or even looking out in the world to say, Look at what all the cool companies like Google on Airbnb and Facebook are doing with their design systems. You know, let's make our our organization one of those kinds of organizations. The way that a design systems integrated into an organization is really interesting, because there's a lot of people there before you have a design system. There's a lot of people there that have their old ways of doing things right because you don't have a design system. And so now you you introduce this new piece of tooling to everybody, and that's a hurdle in itself to get everybody who already works there in a different way. On board with this new hires are a bit more of a complication sometimes, but I think there's some benefit to that as well. So as an example. We're working with an organization right now where we're helping them create the first design system, and they're also hiring at the same time. So the people that works that worked there right now, we're kind of working on the design system with them together and so the design system is a little bit awkward, a little bit of an awkward fit for them, but what they're actually doing, which I think is a really great move is as these new hires come on board. They're just making part of the protocol were using the design system. This is part of the tooling that you work here. Here's what you use for your HR portal. Here's what you use for communication with the rest of the team. Here's how you build products. And so even if it's not entirely true at this point, everybody's trying on the costume. They're saying, Okay, let's just act as if this is the tool we're going to use. It has have been always using and let's see how that goes. So for new hires, it's actually you kind of have an opportunity there to, because it's a little bit of a blank slate to say, Well, this is the way that we do things. And for a new hire, they don't know any better, right? They don't know that. You don't use that at that organization. So kind of trying it out on new hires and, you know, maybe being maybe informing them that that like, Okay, this is the way that we wanna work. We don't exactly do that now, but, you know, as you're coming on board, maybe you could be one of the ones to lead the charge. It actually gives a new hire some incentive to say, Oh, this is a way that I could be involved in actually helped the people that are here, as opposed to feel like I'm already catching up. 8. Evolving Your Design System: design systems definitely need to be maintained like we talked about. It's a product, and every product needs to be maintained, and some products get maintained more than others, Right? Some sit there for a year until the team works on it, and then they get upgraded to aversion to seen some design systems that are like that. Others are a product that people are looking on every week and sometimes even every day. It's really up to your organization or your team as to how frequently you want to work on on on the design system, keeping it up to date, keeping the components up to date, the guidance up to date, improving them, iterating on them, doing another version of them that could be a slow or as fast as your as your organization can support and actually should support. So it's really up to the cadence of you know, your effort, how available everybody is to work on it and how often you need it. Governance for design systems It's such a tricky topic. Part of that is just because the idea of design systems, even though they've existed in sort of the print world for a long time they're new to digital. And so I don't know that there's a design system that's been around long enough to actually say, Oh, this is the way that governments should work. So part of it is that the industry is figuring out how should a design system be maintained and who should be in charge of it and all that kind of stuff? And there's a lot of different models of governance. So one obvious model is that while there's one person in our organization and that person is in charge of this design system and that probably that works well. But it only works well for a short time because ideally, you want your design system to be a success, and you want it to be something that everybody uses. So the more people that use it very quickly, that person gets overwhelmed with people asking them questions, finding out how they can integrate with it. So it very quickly outgrows a full time job. So a lot to design systems start with like, Oh, there's a person in charge of that thing but very quickly outgrow that the next step of that is okay, well from one person. Maybe we'll just grow a team around the design system. So instead of one person being in charge of it, there are six people in charge of it, and that's the model that we've seen before and to varying degrees of success. Where that model really breaks down is now. It seems like, Well, there's six people in charge of the design system and they're not actually in charge of making other products for this organization. And so they're a little bit out of touch for what the design sets in action needs to support. So sometimes that team in an organization will work kind of like a internal agency to kind of like farm things out Teoh and take requests from other product teams within the organization. And it feels a bit detached. So one of the models that we've seen work most well, and I think this is also in those articles is what's called a Federated bottle. So there's not a dedicated team to the design system that works on just that, But there might be one or two people that work just on the design system, and then the rest of that team is actually made up of people who work on other product teams. So it's a little bit of a representative model to say some people who work directly on that and only that. But then let's have some people for other teams on. It's almost like a board of advisers, but people that can actually advise to say, Oh, on that one product We did this one thing. Let's roll that into the design system or we need this thing here so that you get varying perspectives from the organization. So that's the model so far that we've seen work most successfully again. I think it's a little too young to say, Oh, that's definitely the model going forward. There are lots of ways to work on components and updating them and guidance and updating that in design system. So on one end of the spectrum, there is updating the whole system all at once, right? So you release it on day one. Ah, years later, you might release version two of the whole design system. Every component gets updated, all the guidance gets updated, its all in one fell swoop on the other side of the spectrum. They're sort of like being ableto work on each component independently. So within the span of a week, you might upgrade a component from version one to version 1.1. Another component might stay version one for another two years, so you kind of kind of work on it at component level. They're pros and cons to each approach, the benefits toe. Working on it at a very fine at level in a very detailed level is that you're actually working on this thing in real time, and you're not waiting a whole year to try and do a whole bunch of work so you can actually split up the work on that into very small pieces, which it's a lot more manageable. The downside to that, though, is that you have to now have dedicated people on that. You have to have people that are working on it full time in order to be working on it, say, every week or every day. Even you know, to know that a component needs to be updated the other side of the spectrum. The benefit to doing it once a year is you can do it all at once. The downside to doing it that way, though, is that let's say you need a component update. Well, having to wait a year for that component update. It's not a great thing, especially for other parts of your organization that go well. Either we need this fix right now or we're gonna deviate from the system. So your mileage may vary depending on the the organization that you work at and how busy they are and how much you get, how much effort in time you could devote to the design system and its maintenance. But but it's probably not one side or the other, but probably landing somewhere in the middle. One of the most questions around design systems is how how much it should change, you know, and should it should it be a one and done things this something that you should be tweeting all the time? One of the things that I love about digital work is that we have the ability to change things as often as we want to write. That's different than doing print work. If you print something wrong on a paper and you you made a typo, you gotta throw that paper away and print a completely new one. With digital, you don't have to weaken literate. You know, that's one of the things that's great about product design and digital design is that we can change things in a small way and change things in a big way. The question of whether or not you should You should do your design system that way. Very broad changes or iterated on it really depends on how good it is. I will say that if it's really great, you can kind of leave it alone. If it's not that great, then you should probably fix it. But what we know from product design from digital pride design is that very rarely can any of us predict something about a digital product. Do it really well the first time around and can nail it, have it perfect, and it never had to touch it again. So the answer is likely that you'll have to touch it someone after after you make your initial hypothesis and make it the first time. There's probably aversion to around the corner somewhere, whether that's a year away or six months away or six weeks away, and it depends on how well you guessed the first time, what's exciting about design systems to its that their foundational, and so you should be able to build upon them and so design systems as we see them today, if you look at lightning or if you look at material, if you look at any of the popular open source ones that are out there, ah, lot of them are for the standard platforms Web and maybe native APS, right? So you might see Android App store for IOS APS. We live in a really cool time today, where those aren't the devices that were interacting with. There's not just the devices were interacting with. Lots of us have Amazon echos in our in our homes or Google homes. We interact with things that air voice on lee or or touch on Lee, and not just things that we use a mouse for tablets and things like that. So I think that how a design, too, seems to support that from a platform and pattern perspective is really up to how you're gonna implement it. But one thing that should remain steadfast the whole way is actually your principles should support those new things. So one test of your principles is to say, Okay, if we look at this principle, does this guide our Web work as well as it can guide? Say, ah, voice only device. And if not, maybe there's some fine tuning to do with your principles. So even though the platforms may come and go right, think about you might support react in one version of your design system. And if raft goes away in a couple of years, you might want to retire that So you're platforms and kind of come and go. But if but maybe think about your principles persisting throughout the whole time. One of the most common stumbling bucks that I see with design systems is getting too specific into a technology, right? So there's always a flavor of the week, a design system from from a visual design and graphic design, and you I design perspective. You know, those things are tried and true Visual design hasn't changed. The principles of graphic design remain steadfast. Those those are great, but there's always a flavor of the week in terms of technology. One week it's angular. One week it's react another week, its view one of the pitfalls that I see with design systems is going all in on a technology . And if you intend for your design system toe last a long time. I would suggest not going too far into the into the flavor of the technology and instead going with something a little bit more agnostic. So a lot of the ways that we build design systems is to support HTML, CSS and vanilla JavaScript and then building layers of technology on top of that. So here are HTML and CSS components on jobs with components. And then here's the reactive version of those components or the angular version of those components, but really making sure that you have both versions. If you go all in and say our design system is only react, then if you move away from react for whatever reason, you have to retool the whole system. So if you think about longevity, I would suggest going down to HTML. CSS and JavaScript technologies that have been around its continue to persist for decades already, rather than something that might retire in three or four years. Part of the trap of a good design system is that it feels like if you have tooling right, that that's all you need, right? If you have a great design system already set up, you've done the work to identify the right components to identify great principles. You've got universal ones you've got specific ones is to say, Well, we've got it. So now we just can make whatever we want without talking. And I think part of the thing that it's easy to forget with a design system is that the design system should encourage collaboration and not discourage it. So if you're a designer and you have a great design system or a developer and you have a great design system, that shouldn't be an excuse for you to go Oh, I could just make this without talking to somebody, even though you can, and I think that's gonna be one of the great temptations of having a good design system is to be able to say this should be a thing that makes me talk to people mawr, the people that I work with mawr rather than something that that makes me go. I don't need to work with them anymore, And that's the way that designed to some improves. If you're not collaborating, your design system will stall out. It will become stale of her to easily. The more you're collaborating, the more opportunities you'll find to actually make your design system better. 9. Final Thoughts: We did it. We got to the end of the class. Now I hope you know everything you need to know to start using design systems. If you haven't used one before, give it a shot. If you have used one before now you know how to make it better. What I hope that you do from here, it's start collaborating more. Start working more with your clients with your projects with your team members with the organization, but how you can implement design systems and use them to the best of your ability. Over the course of this class, you made some lists. You generated some ideas. You've got some thoughts now share those with other people. That's the whole point of a design systems to collaborate. So put that into practice. You can look at the project gallery, can submit your work there. You get feedback on yours and see what other people are doing to, so make sure you take advantage of that. Any good class would probably leave you with more questions than answers, so I'm hoping that's the case here. If you do have any questions or comments, leave them in the project discussion and I'll be checking in pretty frequently to see what you have to say. Thanks so much for taking the class. Can't wait to see what you make. 10. More Classes on Skillshare: way.