Digital Design: Creating Design Systems for Easier, Better & Faster Design

1. Let's Get Started!: I'm Dan Mall, a designer and creative director and the founder and director of SuperFriendly design collaborative in Philadelphia. Today's class is about design systems, how to create them, how to work with them, 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 just 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, or just the things that are really dry about a project. Let's get that stuff out of the way. A design system should take care of that stuff, so that you can 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 going to 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. You'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. Then there's also the guidance and the reference for how you're going to use those things. Those things are usually put together in a reference site. That reference site has all sorts of instructions for you. Things like how to get started, how do I download this and actually start using it 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? 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. 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. This I answer gets super nuanced because what a design system is not is say a sketch file. 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 a component library is not a design system on its own because it's missing the guidance part, just the pieces. A pattern library and a 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. That combination again, has to have a result as well. The design system has to help us collaborate better. As designers, developers, product people, content people, the design system should be a tool that all of us can rallied around and use to help us make better work. If we're missing parts of that our work can't be better. There are lots of great things about design systems. The first great thing is a design system save you time and save you money. That could be you as a freelancer or a single person working on something. Or it could be your whole organization. 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 ten minutes. That's already a day that you save. That's a day that you can do something else. If you are billing for your time, that's a whole day that you don't have to bill for that thing. You can actually bill for something else. It helps you, it helps your clients, it helps your organization. It helps you save time in doing the things that you don't need to do anymore. 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. One of the things that breaks down organizations and breaks down projects at a nuanced level is really about how consistent something is. When things are inconsistent, it makes users uncomfortable, it makes designers uncomfortable. It makes developers have to build slightly different things. Consistency actually helps you to build something once and know that it will propagate throughout the rest of your system. Another way that a design system helps is that it should help all the people on a team collaborate. I know that when I'm working on my work with a team, sometimes I'm the designer and I'll be working with a developer. What I love about having a design system is we can use it as a shared reference. We know the same language. We can sit around a whiteboard and we could say, ''Oh, let's use the drop down component.'' Everybody knows what I mean. What that has done is it saved me time and it saved our collaboration time where I don't have to go away, make a Photoshop or Sketch file handed off to a developer and then they have to build that. We can actually just sketch that together. I sometimes don't even have to jump into Photoshop to do those things. We'll 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. It actually helps collaboration by giving you a shared language that all of you are using the same word, 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 it actually should free you up to do the things that you really want to do that normally 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. Having a design system or something to help me and give me some efficiency there, helps me get to those things. 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 wanted to get to, or maybe that illustration, or maybe try a new technique or learn a new technology, or maybe learned sigma or a new app or something like that. If you have those things already in the can, if you have the components, if you have the principals and you're using them, that just save you time. 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 is pretty abstract so let's look at a few examples to help make it more real for us. 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 this manual is written so well, because this design system is written so well. Let's take a look at the guts of this. You'll see here that one part of this manual is just the parts. You'll see that they have everything from how each letter is supposed to be specified in here. 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. They 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, just do all the rest of them like that." They're going into painstaking detail to show you that stuff. 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. Let me show you an example of that. This page here is a page about temporary signs and this shows the people who are implementing the system, how you can create a temporary sign. There's guidance here that it tells you what a temporary sign is. The nature of the temporary sign requires that it'll be easier to produce, place and remove, and then it has instructions for how to produce a temporary sign. 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. This is great guidance for a design system. This whole book, this whole manual is 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 system hold up for so long. Now both of these books are really great. These are books that were written in the late 70s about architecture. Christopher Alexander basically talks about in these books, how can you approach building architecture in a way that is systematic and like the cover of the book says, "A timeless way of building". This is a part 1 and part 2 in the pattern language side of it is, how do you actually implement those things? This is the theory of it. 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. There's a lot of great theory and 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 Alla Kholmatova, it's called Design Systems. It's about how to build a modern design system. All of the things that we were talking about in terms of theory and in terms of practice and in terms of parts, Alla compiles in this book and talks about how to actually use design systems and make design systems and maintain them as a fantastic reference for anybody that wants to learn more about this topic. Now this is a bit of a non-traditional example here. Most of the things that we've looked at are actually manuals and this book is called Design by Apple in California. It's 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. These are beautiful photos that document what Apple products actually look like. Now, you could call this a photography book more than as a design system, but it does have a little bit of reference for design system. 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 devices that they make, and just getting and seeing them from different angles. What you'll find here is that you can leaf through the couple of 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 their products. You can probably conclude something at the end that says, "Here are the principles that are important to Apple's work." I think that's the job of a good design system too way 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." Even though this is a little bit of a non-traditional example, I think it's still makes a good point as to the job of what a design system should do. 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. This is one example of a design system that Apple might have. They also have another that's maybe a little more popular than this book. It's called the Apple HIG, the Human Interface Guidelines and that's for anybody who wants to build an iPhone app. When we look 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. 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 design for non-Google products, but also Google uses them for Google products. What you'll see here is that it's a unified interface for Android apps, for apps that are by Google, for things like G-mail and Google Maps, but also some of their subsidiaries like YouTube. 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 Develop tab for developers, it's got all the components that we actually need and it's distributed by platform. I've got Android, iOS, Web, and Flutter. 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. Components gives me this whole list of things and I'll just click into one. If I wanted to use a button as part of material design, which gives me an example for what this is and I can scroll down and it gives me all of the guidance as to how to install 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. It's got all the technical work as well as the philosophical work. 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 on the design end for material , this is the coding end, but the design end introduces things like principles so let's look at the color principles for Material Design, for example. What this shows is all the color palettes that come with material and how you might use them. Lots of robust color palettes here for all the way from Shades 50 to 900. They'll show you the primary and the secondary colors, as well as all the variants and the tints and the hues. This also comes with principles so they talk about legibility as a principle, and expressiveness as a principle, and hierarchy as a principle. Again, you see these combinations so it's not just the components and it's not just the guidance, it's all of those things together in context. We jump over to another example. This is sales forces designed system, and this is called the Lightning Design System. 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. If we go and look at the components themselves, you'll see here again, the same thing. Here's 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 variance. I've got all the button based, the neutral, the brand, the outline brand, the destructive, and the success and again, right below is just the code to be able to use that. From a design standpoint, here's how the thing would look, from a development standpoint here's the code that I need to implement this. Then again, right in context is the guidance. Again, here's an accessibility rule of thumb for the button. I don't have to go somewhere else to actually see it. It's in contexts that the component itself. The last example that we'll look at here is Polaris by Shopify. This is a design system and so it's got again, the same things that material and lightening have, but in a slightly different way and I want to point out something specific about this. As 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, and to their customers. 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 purchaser. As an example, go into Actions here and I'll 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 component in action and 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 is an action list renders a list of actions or 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. Again, this is really specific to how they want merchants to be able to use these components. 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 that I use list, its 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 design 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 e-mail 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 the things that you wish you would have gotten to that you didn't get a chance too. This is really like your dream stuff. So think about that animation you couldn't do. That extra little bit of accessibility helped that 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 your paper, you have all the things that you did on the last project. I would 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 that you have all the stuff circled on the left of things that you could be more efficient, I'd like you to draw a line from that thing to something on the right side. This is going to be your trait sheet. For example, on the left, you might have something like I designed all of the buttons. On the right, you might have something that says design custom icon set. 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 icon set. Here's where the magic comes in. You've just created your first wish list for what your design system should do. Now that you know what you want to 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. Once you 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 1 of your design system. This is great when you're working by yourself. What makes this even better is, you can now start to do this with your team and you can do this exercise with your team. You can lead this. You make your list. Maybe you can ask your coworkers to make their list too. If you're a designer, maybe ask you developers that you work with to make their list. What's the stuff that they wish they could do? What's the stuff that they would trade for, something that they could have in the can already. Then ask your team members to trade them around. This is the thing that I do in workshops all the time. I'll 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 that they want to do and everybody else is working on the project. 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 design polish on that thing. Maybe that was a thing on their list. Designers get really fed up with developers like, oh man, they didn't put the time in, but it could have been that they just didn't have the time. So exposing these 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, so 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. Even that 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 to design? Well 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 there, 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 there's specific principles. So for example, a good universal principle could be something like access for everyone. That's something that as you make apps and websites, you want everyone to be able to access. But that's also true of every website too. 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, it's TV stupid. What I love about that principle for TiVo is that it's so great for them, it's a great mantra for them to follow. It's the spirit of them, it's casual, it's a little bit irreverent, it fits their brand and also, it wouldn't work for another organization. It wouldn't work for say, Quickbooks or Salesforce or any of those. A specific principle should be something that's really great for you and your organization, but an awkward fit for someone else. I imagine that if I was working at TiVo, and I would had a problem on something that I was trying to design, then I could look to those principles to go, how can this help me? So principle should really help you in points of tension. So when 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 do. 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 going to have. Text is a good example of that. A form is probably a good example of that too. Maybe you don't need to reinvent the wheel with how you're going to display text. That's fine. But you also are going to want some specific patterns for you, for this project you're working on, or the organization that you work in. So as an example, let's say you work for the IRS. Your design system for the IRS probably should really focus on forums 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 are 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 the language between them. If you look at all the design systems that are public and 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. Patterns sometimes means that. But I've seen lots of organizations use patterns in a different way. Sometimes a pattern 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 checkout flow. 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 are some great resources out there for you as well. Designer Nathan Curtis has an awesome checklists for design systems that outlines all of the different parts that you might need in your design system. Now, you certainly don't need all of them. But maybe take a look through them and you'll find that they probably match your list too. What are some things that you maybe didn't think of. Those other 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. So especially if you work at a big organization, you've probably made stuff and other teams that 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 checkout flow, maybe it's a login flow, maybe it's a really great component like there's great consistency in that or the topography there is really good. What you can do to start your design system off, is really looking at that stuff and go, you know what's working there? The topography. The topography there is what we should use for many more things. So now start to extract that stuff from that project, we call pilots. Use those as pilots and say, okay, we can extract that stuff from the pilot and that's going to be the basis of our design system. If you don't have that stuff, you can start to create it. So let's say you worked 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 going to do a fictional exercise where we create a guide app. You can create that guide app and then say, all right, we're going to take the stuff from that guide app and we're 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 are real, 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, design a whole screen, then take the button out of that screen and say this is going to be the button that we'll use. So pilot projects 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 going to be a lot more difficult. So that's where things that are real apps 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 do. What do you do? Well, I think the first step in that is trying to organize it. That's really up to you and the culture of your organization. So for some organizations, you might already have a Jira board or a Trello board or a confluence or something like that where you can get a nice space to put things and organize them. But you might not. So you might start your own Google Doc or an Excel sheet or some folder on your computer as a place to start it. That's okay. 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 do. 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 e-mail to the rest of your team? Well, great. Do that. Is it preparing a base camp post or a slack post? Do that too. So start thinking about these ways that you could organize some of these materials so those could be the components and some 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 needed an example, it's okay to go and copy material design or bootstrap or the lightening design system and use their thing as a guide. So if you want to structure your Word doc in that same way, that's all right that's a good start, and there's no wrong way to do this. It's important that you 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. We're always so precious about our work. We try to make everything really special. Working on a design system is a little bit counterintuitive because the first version of your design system especially if you work at 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 do. 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 start a 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 forums, make the flutters. 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. We're designers, we're 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. 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 setting the tone and setting the table on their end for us to be able to do good work. As an example, we worked with the Seventh Day Adventist Church to help them with a design system and a year before, we did work with them. Our client, Brent who was the web manager there, he went to his boss and he did something that was really interesting. They make a lot of websites there, what he did was he printed out those websites and these little thumbnails is three inch by three inch thumbnails and put them all on mounting boards and he ended up having six or seven mounting boards about a 150 different thumbnails. All of them look different and he went into his boss with these mountain boards and he said, look at all the money that we're wasting, 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, I know how to fix this, we need a design system and if you can give me the budget for it, and if you can give me the room to be able to create this well, we can get a lot more efficient, we can go a lot further in our organization. For him, what was really great about that, and for us too is that, he really set the table for us to do good work. He did the work of getting everybody board on the idea of a as to why they need it and our work became really easy. We could actually do the work well, 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. I think that's an important part of this work. How do you get somebody to do something for you? Well, you have to find out what their incentive is. Because not a lot of people are of their goodwill do something for you, being unselfish. Instead, they've got to know what's in it for them. It depends who you're talking to and you've got to speak their language. If you're talking to a developer, why does a developer want a design system? Well, they want it so that they don't have to write codes from scratch or maybe they don't want to write codes that fails because they're joining from scratch every time, 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, oh we're going to save money doing this because we're not going to have to spin up as many teams or we're not going to have to spend as long on projects. Speaking, the language of efficiency is probably a good thing for them. It really depends who you're talking to you and try to figure out what's the language that they need, what's the thing that they need to hear in order 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. Maybe for them, it's about how is this design system going to help us achieve our mission? 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 forest and the trees. What's cool about a design system is that it has all of those different parts. If you can extract those parts and say this part is about finance, this part is about efficiency, this part is about mission. I think you'll be able to convince people a lot more effectively. 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 talking to people one-on-one, that's a good way. When we start with clients, we talk to them about what their needs are, what's the pain, what hurts right now. We're just really slow at this thing. Okay, cool, If this were faster, how would it help you. Asking really basic questions is helpful. Sometimes doing that one-on-one is less pressure than if it's in a group. One of the things that I would recommend is start by talking to people one-on-one as to how this thing could help them or generally even how they can be helped. Maybe the solution is not a design system, but oftentimes in an organization with questions about efficiency and speed and money and time. A design system is really good tool for that. A good way to get set up for that and get the buy-in is to say, well, everyone tell me where it hurts right now, tell me what are the pains 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 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. It's hard to look at another design system and go, I see how that has helped efficiency at that organization. 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, well Salesforce actually cut their time on projects in half because of their design system. I think that's the stuff that really helps people is to understand that and hear those statistics to say. Because we're in the same boat and if that's the outcome they got with this tool, maybe we can have a similar outcome with a similar tool. A design system is a really big tool for an organization to 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. 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. Imagine if we scale that tool up, that it would cut time in half as well, now if we had the tool that could save us six months on what would normally be at 12 month project, that would be great. If you don't have statistics, if you don't have access to, well, here's what an 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 up, 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. It won't be anecdotal data. It won't be data that says, well, these organizations got this or maybe we can get this here. It'll really be based on what you have experience 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. 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. Everyone has to be bought in because it's going to be implemented in across the organization. For lots of things on a big proponent of ask for forgiveness instead of permission with a design system that might be the exception. I think that getting people bought and it's going to save you a lot of headache later on because even if you start at the ground level and go, well, let's just get started and we'll figure out how to implement it later, you're going to run into a roadblock when you get to that point where you're like okay, we need to implement this, we need to get involved in our infrastructure or part of that. You're going to run into a wall there. Getting more by an upfront is usually more beneficial. Getting buy-in and an organization is a little bit different than getting buy-in on a project. 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. Some of the nuances there, are really interesting where I've worked on designing systems for clients is sometimes will create a pattern library and a reference guide just for our team, and sometimes the client has no interest in it. It becomes a helpful tool for our team and say here's how we're going to make the work for the client. The client wants the output of that work. I've had some clients say, we don't really care about the pattern library or the reference site, we just want the final pages and that's totally fine. If you use a design system for yourself to make the output for the client, that's great. 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 conversations with them and be open with them to say, listen this is how we were able to make this thing so effectively in that 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 buy on that, 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 part of tool as well. 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. You're 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 site and not actually implemented into the tools and the culture of your organization or your project, no one's going to 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, 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 how do we make the design system better than Bootstrap? Bootstrap is such a great tool and so whatever we used that has to replace it has to be better and there are lots of versions of what better can be. 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 need to do with it. I need to embed my brand fonts, I need to have my organization or my projects color pallets, so there's work that I'll have to do. 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. One of the principles that we try to use and 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 of a design system is a tool that is implemented in everyone's workflow. So it makes designing easier for designers and makes coding, the front-end easier for front end developers. It makes coding the back-end easier for back-end developers. It has product management tools for product managers. So the best implementations are the one and so the Holy Grail is the one that everyone can use the design system. Now, that's really hard to do. There's lots of tooling that needs to be built, there's lots of process that needs to be implemented and 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 end developers and it would also be integrated into the implementation so that back-end developers could use it as well. I've rarely seen that happen, and so a lot of organizations are working toward it but there's only a handful of 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 and 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 into workflow, is to think about it like any new tool. When there's a new tool that you're using, you're probably going to notice that a lot. You're probably going to be able to call it out, you're probably going to have to talk about it, you're probably going to have to remind people to use it. So when you first implement a 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 onboarding 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 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 and front-end developers and that's a great place to start, having some design reference and guidance and also having some front-end code, some HTML, CSS, and JavaScript that a front-end 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 a version two might look like, there's some tooling for that kind of stuff. So if that's the place that you're starting, that's okay, that's a really good place to be. One of the definitions that we talked about with design systems is 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 and interested. A design system even within or organization is not an exception to that. So you might have to do the same type of evangelism that you would if you're making software as a service product except that you're just doing it internally. So that means getting people on board, we talked about buying a bit, that means being able to evangelize to them a little bit, sending materials, sending frequent updates, so you've got to treat it like a full fledged product. It's not just a tool, it's an actual product that now you have to support. What's really great about the design system is that it can be opt-in, 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 sigma versus illustrator, you have the liberty to do so. Now, you can 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 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 going to work with doing it with a design system as well. So instead of thinking about how it can be mandated, instead of thinking about how you can 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 appeal to them. So different things appeal to different people. Certainly efficiency and those kinds of things are really helpful to convince people that, oh, you should use this thing. But sometimes, as kind of softer ways to do it, sometimes people just want to be part of something 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 the like, you're joining the cool kids club or you're doing this new thing or you're part of 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 and Airbnb and Facebook are doing with their design systems, let's make our organization one of those kinds of organizations. The way that a design system is integrated into an organization is really interesting because there's a lot of people there before you have a designed system, there's a lot of people there that have their old ways of doing things because you didn't have a design system. So now you introduced 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 benefits 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 work 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, it's 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 we're 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. So even if it's not entirely true at this point, everybody's trying on that costume, they're saying, let's just act as if this is a tool we're going to use and have been always using and let's see how that goes. So for new hires, you have an opportunity there too 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, they don't know that you don't use that at that organization. So trying it out on new hires and maybe informing them that this is the way that we want to work, we don't exactly do that now but 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 and actually help 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. Some products get maintained more than others, some sit there for a year until the team works on it and then they get upgraded to version 2. I've seen some design systems that are like that. Others are a product that people are working 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 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 can be as slow or as fast as your organization can support and actually should support. It's really up to the cadence of your effort, how available everybody is to work on it and how often you need it. Governance for design systems is such a tricky topic. Part of that is just because the idea of design systems, even though they've existed in the print world for a long time, they're new to digital. I don't know that there's a design system that's been around long enough to actually say, this is the way that governance should work. 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. There's a lot of different models of governance. One obvious model is that, well, there's one person in our organization and that person is in charge of this design system. 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. The more people that use it, the very quickly that person gets overwhelmed with people asking them questions, finding out how they can integrate with it, it very quickly outgrows a full-time job. A lot of design system start with, there's a person in charge of that thing, but very quickly outgrow that. The next step of that is, well, from one person, maybe we'll just grow a team around the design system. Instead of one person being in charge of it, there are six people in charge of it. That's a model that we've seen before to varying degrees of success. Where that model really breaks down is, now it seems like, well there's six people in charge of that 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 system actually needs to support. Sometimes that team in an organization will work like an internal agency to farm things out and take requests from other product teams within the organization and it feels a bit detached. 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 model. There's not a dedicated team to the design system that works on just that. But there might be one or two people that were just on the design system and then the rest of that team is actually made up of people who work on other product teams. It's a little bit of a representative model to say, some people who worked directly on that and only that, but then let's have some people for other teams on. It's almost like a board of advisors, but people that can actually advise to say, 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. That's the model so far that we've seen work most successfully. Again, I think it's a little too young to say, 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. On one end of the spectrum, there is updating the whole system all at once. You release it on day one, a year later, you might release version 2 of the whole design system. Every component gets updated, all the guidance gets updated, it's all in one fell swoop. On the other side of the spectrum, there's being able to work on each component independently. Within the span of a week, you might upgrade a component from version 1 to version 1.1. Another component might stay version 1 for another two years. You can work on it at a component level. There are pros and cons to each approach. The benefits to working on it at a very finite level and 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. You can actually split up the work on that into very small pieces which are a lot more manageable. The downsides of 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, 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 downsides of 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 fixed right now or we're going to deviate from the system. Your mileage may vary depending on the organization that you work at and how busy they are, and how much effort and time you can devote to the design system and its maintenance. But it's probably not one side or the other, but probably landing somewhere in the middle. One of the most frequent questions around design systems is, how much it should change and should it be a one and done thing or there's 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. That's different than doing print work, if you print something wrong on a paper and you made a typo, you got to throw that paper away and print a completely new one. With digital, you don't have to, we can iterate. 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 do your design system that way, very broad changes or iterate on it, really depends on how good it is. I'll say that if it's really great, you can leave it alone. If it's not that great, then you should probably fix it. But what we know from digital product design is that very rarely can any of us predicts something about a digital product. Do it really well the first time around and can nail it, have it perfect and then never have to touch it again. The answer is likely that you'll have to touch it somewhat after you make your initial hypothesis and make it the first time. There's probably a version 2 around the corner somewhere. Whether that's a year away or six months away or six weeks away, I think depends on how well you guessed the first time. What's exciting about design systems too is that they're foundational and so you should be able to build upon them. Design systems as we see them today, if you look at lightening or if you look at material, if you look at any of the popular open source ones that are out there, a lot of them are for the standard platforms, web and maybe native apps. You might see Android apps or iOS apps. We live in a really cool time today were those aren't just the devices we're interacting with. Lots of us have Amazon Echos in our homes or Google Homes. We interact with things that are voice only or touch only and not just things that we use a mouse for, tablets and things like that. I think that how a design system should support that from a platform and pattern perspective is really up to how you're going to implement it. But one thing that should remain steadfast the whole way, is actually your principles should support those new things. One test of your principles is to say, if we look at this principal, does this guide our web work as well as it can guide, say, a voice only device? If not, maybe there's some fine tuning to do with your principles. Even though the platforms may come and go, think about, you might support reacts in one version of your design system, and then if react goes away on a couple of years, you're going to be might wanna retire that. Your platforms can come and go but maybe think about your principles persisting through out the whole time. One of the most common stumbling blocks that I see with design systems is getting too specific into a technology. There's always a flavor of the week. A design system from a visual design and graphic design and UI design perspective. Those things are tried and true, visual design hasn't changed, the principles of graphic design remain steadfast. 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 it's view. One of the pitfalls that I see with design systems is going all in on a technology. If you intend for your design system to last a long time, I would suggest not going too far into the flavor of the technology and instead going with something a little bit more agnostic. 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. Here our HTML and CSS components and JavaScript 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 reacts, then if you move away from react for whatever reason you have to retool the whole system. If you think about longevity, I would suggest going down to HTML, CSS, and JavaScript technologies that have been around and 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 the tooling right, that's all you need. If you have a great design system already setup, 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. Now we just can make whatever we want without talking. I think part of the thing that is easy to forget with a design system, is that the design system should encourage collaboration and not discourage it. 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, I can just make this without talking to somebody, even though you can. I think that's going to 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 that I work with more rather than something that makes me go, I don't need to work with them anymore. That's the way that the design system improves. If you're not collaborating, your design system will stall out. It will become stale very 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 is start collaborating more, start working more with your clients, with your projects, with your team members, with your 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 generate some ideas, you've got some thoughts, now, share those with other people. That's the whole point of a design system is to collaborate. Put that into practice. You can look at the Project Gallery. You can submit your work there. You can get feedback on yours and see what other people are doing too, 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.