 Can you hear us? We're interested in design systems. You are in the right room, and we are going to get going because there's a talk right after this. So, yeah, don't forget this. Real quick, you've seen this before, you know. Well, let me introduce myself. I'm Courtney Clark. I'm the Managing Director of User Experience at Forum One. At Forum One, we design and build cool stuff for clients who are changing the world. So, groups like Peace Corps, MacArthur Foundation, USDA, tons of other groups. It's fun. And this is my esteemed co-presenter. Hello, my name is Amy Vinari. I'm a senior designer at Teori Creative. Got some of our awesome developers here with us today. We essentially do the same thing as Forum One, just for different clients. We also branch out a little bit into commercial as well, but heavily on the nonprofit and government side as well. And Amy and I used to work together, and so we'll be talking about a project that we worked on. But before we get too deep in, I'd love to learn a little bit about you. So get your hands out, get them ready. I'm gonna ask you to raise your hand. How many of you have used a design system before? Not as many as I thought. Okay, and then out of those people, or maybe whether or not you've used one, how many of you are deeply in love with design systems? Hey, we got some mega fans there, okay. And then how many of you are still a little unsure? I used to be one of you, and now I'm standing up here. So there's hope. Convert. Great, well thank you, that's really helpful. So one thing we just kinda wanted to get, to set the stage a little bit. You're sitting here, we're gonna talk about design systems. You may be wondering if the design systems are right for you. We're gonna tell you if they are, yes. But just a couple questions just to think about. It's kind of a Jeff Fox working thing. You might need a design system if your site has 20 different button styles. You may have one of these sites, you've seen them, we've all seen them, they're awful. But it's probably not the designer's fault. It may be that client was controlling it. You know, the site's like 20 years old, who knows. If your site is gonna evolve or grow over time, you probably need a design system. You know, if you're handing off projects a lot, you probably need a design system. And we're gonna tell you why. But if you feel like you've answered yes to any of those three questions, you're in the right place and we're gonna tell you a little bit more. All right, so I wanna make sure that we're all using the same language and talking about it in a similar way. So what the heck is a design system? I like to use a taco analogy when I talk about design systems. So at Taco Bell, who's been to Taco Bell recently? Love it. We had tacos for lunch today. Yes, everyone had tacos for lunch today. This is perfect. So at Taco Bell, they basically have eight core ingredients, maybe a few more give or take. They've got their meat, cheese, lettuce, beans, salsa, tortillas, sour cream. And they also have a little bit of variety. So you've got hot sauces and you've got a range of different strengths there as well. But what Taco Bell and what many other groups have done is they're using these same eight ingredients, but they're mixing and matching them. And that's kind of what a design system is. You've got your eight core elements or design pieces and you're mixing and matching them in different ways for reuse. And what happens is you know that you can make a quesadilla, you can make a Crunchwrap Supreme, you can make a simple taco, but Taco Bell is using those same eight ingredients and they're really using marketing and other stuff to promote those different menu items for design systems or mixing and matching. So it still feels like it's part of the same family. You still know you're within the same system, but you can mix them up. So this is the project we're gonna talk about today. What does a design system look like out in the wild? So last year, two years ago, Amy and I worked on the redesign of pscore.gov. pscore came to form one and they hadn't redesigned the site in seven years. Yeah, like seven years. It'd been a while and they were going through some new branding as well. So they had redesigned their logo with another firm and they needed to extend their new logo and new brand onto their digital presence, their website. So they came to form one. They had the goal in mind, a deadline in mind and said, how are we gonna do this? How are we going to extend this? So we got started and we did a lot of other stuff. We did a lot of discovery. We did a lot of planning, but we're gonna talk to you about the design portion of it and how that piece got implemented. A key part that I wanna talk about, which preceded the design system was the wireframing phase. Amy and I worked on this together and the thing that we did before we drew any gray boxes or arrows was we created the site map and we said for each page, what is the goal? Who's the audience? Where are they coming from? And where do we want them to go? These were really key parts in outlining the purpose of the page and how we knew whether or not it would be successful. So I'm showing you this just to indicate that Amy and I were on the same page around what our goals were and who our audiences were for every page from the very beginning. And that was really key because once we got into the design system you'll see that we were able to speak the same language and carry those really important parts about goals and audiences throughout. So the digital design system itself. For Peace Corps, what were our lettuce, our tomatoes going with the taco metaphor? What did we work with? So when you talk about designs, it goes by many different names. You've probably heard of atomic design, modular design, any number of things. This terminology is kind of different for everybody but these are the phrases that we use to describe the various levels. But the idea is the same for everybody. They just call it different things. So we went with basics, elements. Oh, it's not showing, sorry. Basics, elements, building blocks and pages. So we start from the base level and move up in complexity. So the basics and this is the fun part, right? We get to look at the fun system. Hopefully you like it. I worked with it for a very long time so it's very special to me. So our basics are our colors, your typography styles, any other basic elements that you use to design the site. For Peace Corps, we were essentially handed the basics from the firm that designed the logo. They had chosen a color palette. They had chosen the typography. All we had to do was kind of build it out for the web and think about all your various styles throughout the site. And they also made these lovely icons as well. Next up, we combine our basics into elements. In the Peace Corps case, these were things like buttons and form fields. And this is where we start taking some of those elements like the patterns and the colors and combining them into a button. And this is also where I started working closely with the developer to talk about what are the hover states look like and think about interactions with the form. It's one of those ones where when you click into the form, the input label kind of hops up to the top. So you still know what information you're supposed to be filling in. So that sorts of discussions start happening at this stage. And then, as we move up in complexity, we have our building blocks. And this is where your design system really starts to take shape. And these are the main blocks that you're gonna use throughout your website. So we're putting them into things like calls to action, which you see here on the left. Right, sorry. And stat boxes, which you see on the left. And as you can see, we were talking about how hot sauce kind of has variation. So do our building blocks. So it may be that your text needs to line up on the left for some and in the center line for others. So these building blocks have variation within them so that you're giving your site a little bit of extra feel as not the same thing on every page. But it also is limited so that it's not being so overwhelmingly different on every page that it breaks the system. And the same goes for things like listings and related pieces of content. So you can see these are all clearly part of the same family, but they're a little bit different. So you can, the user can tell which kind of content they're looking at, whether it's a news article or a volunteer opening position. Yeah, one thing I would point out here is those early discussions about what's the primary action or where do we want people to go next, that played into how we were designing these building blocks. Because as you can see, the metadata changes slightly, the use of an image or not, and what button we're using. And actually, if you agree, were you gonna talk a little bit about how you went between these different stages? Sure, yeah, so we kind of, it's a little bit backwards. So we actually, that leads nicely into our next section, which are full pages. So this member when I said I was a skeptic, this is where that kind of skepticism came in, because I went to a presentation years ago about design systems and how everything is gonna be designed in modules now, and there was no need for full page comps, and I got really sad, because that's, if you're any designers in the audience, that's kind of the fun part of a project is to do these full page designs where you see the whole thing come to life. So I was afraid that that wouldn't happen anymore. The truth is, you kind of still need to do that, and there's a couple of reasons. The client probably isn't gonna approve stuff at the module stage, because they like to see things the way that they're used to, which isn't a full page. And also, you need to see how the things are working together, whether the spacing is working. So you need to put it all on a page and see how it's flowing. And that was sort of where we started. We actually started building out full page designs like this one, and then worked a little bit backwards. So, as you can see, this is a full page design for the country page. They work in 60 different countries, so each one gets their own page. And this was a great example of a page that had tons of building blocks on it. So each one of these black boxes here on the right represents a building block. So you can see it was just a matter of slotting them all together. So that was kind of the process that we used. We actually did do the full page comps first, used those to build the system, and then as we moved forward, we had all the building blocks in place, a matter of putting things together in a few minutes. And from a user experience perspective, when we are wireframing this page, we knew that it would need to shrink and scale based on the amount of content that each country had. So you'll see on the left side, that's all the options that they could have as far as how much navigation and how many blocks on that page. But where Amy and I needed to coordinate was, okay, what happens if they don't have the stories bar? Or what happens if they don't have a quote? How will these elements or blocks fit, shrink and expand? And that's where the system was really huge. And where putting it on a page is so vital, because you need to make sure it still goes together. And it's not too overwhelming or underwhelming. So that's the basics of a design system. But why is it a good thing? Well, we've kind of pulled out a few reasons why we think it's a great thing and why it worked particularly well for the Peace Corps project. Scalability, consistency, and efficiency in teamwork. So scalability, this one kind of goes without saying, but I'll say it in any way. It's in the name of our presentation for a reason. Like I was saying, at the end of the day, as we're getting closer to the end of the design portion, I was putting together pages in five minutes and I'm not kidding, because I have all the elements already ready. So if we needed to add 50 more pages, it would have been very easy to do so because we had a design system in place. Secondly, consistency also kind of goes without saying, if you're using the same elements throughout your site, using the same set of basics, your site is gonna look consistent so long as you follow the system. And that was really huge for Peace Corps and for many brands, which is how do you maintain a consistent look and feel across many, many pages, hundreds of pages? And it was huge for them too, because they were rolling out a new brand, so they needed it to feel very cohesive. Exactly. And making it consistent for mobile very easily, because all we had to do is translate those building blocks for mobile and you could do it really easily. And I feel like this is your slide. This might be my slide. The last one is, we can't emphasize enough, which is efficiency and teamwork. The system that has some rules and some building blocks that everyone knows makes everyone's life a little bit easier, not just Amy and me, the UX designer and the visual designer, our friend and developer, our backend developer, our project manager, the client. We all sort of were speaking the same language by the end of it. And like Amy said, by the end, once we were able to identify the content needed on the page, Amy could turn out a design very rapidly and our friend and developer also could whip out a page really quickly. This is Dan who worked on the project with us. Slight exaggeration, but he's a huge fan. He was already doing this on projects where he was trying to figure out how to systematize the design. So we actually started that earlier before he even came in, which made him exceedingly happy, as you can imagine. So the other thing to note here around teamwork is that our team was spread out across the country. We had folks in DC, LA, Seattle, and a couple other places, but I think you said it was one of the most collaborative projects you'd ever been on before. And so from the outset, part of the way that we collaborated was we had working sessions daily, every morning, or it was noon for you. But we would meet, we had this blocked off time where we could sketch together, where anyone on the team could come in and ask a question. Sometimes we used the time, sometimes we didn't, but it created this cohesiveness, and even our project manager set would just listen in on sketching time with us and was developing that language. What that meant was we were all saying the same thing by the end, and we were straightening out issues early on. Now for your team, you may not need to meet daily, that may be overkill, but the main takeaway I would give is creating a space for your team to come in and collaborate with you or ask questions. That's sort of a standing time. That was really valuable. So that's kind of a summary of, these are free benefits that we think you could gain if you use a design system. And after the launch, the story continues. We, the site launched June of 2016, and we're still working with the Peace Corps, we're still extending the system and building on it. And there are unique challenges that come up, right? Because we were moving over some new pages or some new sections onto the new site. We're adding some new functionality and interaction, changing some interactions. And when you're changing the user experience or the journey that somebody might go through, that affects the design system. So there are a couple of key questions that I'd encourage you to ask before, before you're like, let's design something new. The first one is, what already exists? So you might have somebody come and say, we need a new button. No you don't. No you don't. There's like six different buttons you can choose from. Surely you don't need a new button. That's right. So you refer back to it, the system becomes your Bible and you say, what already exists, what can we use? If you identify something that doesn't already exist, your second question is, what is the significance? Is this a game-changing element? Is this vital to that goal that we identified? Is it vital to the audience? And this one's a little squishy, right? Because you need to talk about it with your team and it will vary based on the goal of the page and the site that you're working on. But if this is something for Peace Corps example, their goal is to increase the number of high quality applicants. If this element fits squarely into that, then yeah, maybe we need to add it. But one more question, how will it be used again in the future? Is this a one-off or is this something that can get reused over time? And those are the three key questions that we've been asking ourselves when we think about adding new elements. And just a word of advice. Once you create a system, it's your duty to guard it because it will unravel very quickly. The whole point is that you're not spending time creating tons of unique elements. So if you finish the system and then you start creating new unique elements, you've unraveled all the work that you did and you've lost all the efficiency. And this is just a quick note from the designer that came in. Amy handed it off to Sarah and she is now the one who's extending the system with us. And I asked her, I was basically like, what advice would you give? What did you learn in this experience? Taking on something that somebody else had designed. And the short answer is that understanding where some of these decisions came from is really vital. After she understood that, it made a lot of sense. So one example of that is we are pulling over some pages where people can donate and we needed a button and the question was, should we use another color? And we had talked early about the rules around the buttons and there's a green and a blue one and then there's a red one. And the question was, should we use a red one? Should we add a color? And one of the things that we communicated early was, red means apply, red buttons are only used for apply. You can't use them for anything else. So that rule was really clear for Sarah so that she could make the adjustments that she needed. Had she not known that, that rule completely unravels. And I would have been very sad. We all would have been sad. So how do you get buy-in? We talked to groups who maybe there's only one designer on the team or maybe you're working with teammates where they don't really get it. This is for all of you folks out there. So the first thing I would say is, send them to watch this talk. The second thing is, John Mehta does a report every year called Design in Tech. It's a great report. You should look it up if you haven't seen it before. It just came out in March. He presents it at South by Southwest usually. But as he was sharing the Design in Tech report this year, he talked about how in the technology industry, there's so much design debt. And when he was talking about how do we start to tackle that design debt, this is the quote that he says. He says, you have to scale the company's design function through better managing and leading of designers and through shareable design systems. That's how we're going to be able to extend good design and start to tackle all this design debt. The other thing that I would add that should be appealing to your teammates and your project managers is to really talk about the investment that you're making around design systems and how that helps everyone. If you're doing a traditional process where you're creating page after page after page, that's that dark green line that just goes straight up. That's sort of what you're going to do. You're investing the same amount of effort over and over again, and the level of effort just keeps going up and you don't really gain any efficiencies. With a design system, yes, there is an initial bump in effort, but eventually that sort of mellows out and starts going straight because that seriously happened. Amy could put together pages in five minutes because you're reusing those elements. So a lot of times on projects, especially large projects where there's 500, 1,000 pages, this investment in a design system, you will reap the benefits of that down the road because you're not doing all of these unique one-off pages over and over again. And we really wish we could tell you where that magical intersection is, but the truth is it's different for every project. So there may be small ones where it's not important, but it's important to think about the scale of your project and if this is going to be appropriate for you. And this is something that everyone can benefit from, whether it's your project manager, the brand specialist, business development developers. Developers, that sort of investment resonates with all team members. If you look at design systems around the web, you see a lot of great ones from in-house teams, Airbnb, Etsy has a really good MailChimp, MailChimp, Uber, really good examples. There are a lot of great ones. I don't see a lot from agencies or consultants who are creating these, and we're certainly in-house teams have in-house clients, but we have external clients that we're working with, and we have to educate them along the way if they've never done this before, it might be new for them. So one of, you sort of have to teach them along the way. And again, hopefully this presentation can be a good resource to let them know what direction you're headed and what the benefits are and what to expect along the way. And you have to share this approach so that you can walk them through. So as Amy said, we may be starting with pages, but she needs to communicate with everyone that she's working on the elements and the basics and refining those so that in the end they have that system. Examples are really important to use. The benefit here and why you have to educate and bring them along the pathway is because ultimately they're the approver of the work, obviously, and so you gotta take them along on the journey. The best thing that can happen at the end of this is, and this actually happened, was we'd submitted a design for approval and we were at a check-in call and we asked the client, hey, did you take a look at this? We're ready to move forward. And he said, as long as it matches the design system, it's good to go, I don't need to look at it. They were amazing. Yeah, they totally got it. And it was just because, like Courtney said, we talked to them along the way. We used the same terminology over and over again, so they were following along with us as we built the system out. We never actually showed them the system. We just showed them pages, but they got it because we were communicating clearly and talking to them a lot and teaching them along the way. And it helped them internally to manage their own stakeholders, so they knew what was flexible and what wasn't, and they had those priorities around consistency and scalability. Yeah, because when you have 60 different countries giving you opinions, you'll be like, oh, sorry, we can't use that button because it doesn't match the system, so it gave them a lot of leverage as well. And eventually, there may come a day when they're no longer working with forum one and they have to maintain this by themselves, so it's really important to teach your clients in case they're taking it and running with it. You don't want them to break the rules. Right, and our goal is to give, to provide a system that can live on. That's the whole point, is that we're happy to help, but wanna make sure that you're getting the resources you need for your site to live on. Yeah. And real quick, we're gonna just do a few tips and tricks, mostly because they're GIFs, GIFs, whatever, and we love those. So, be consistent. Your design system's gonna be consistent, but you have to be consistent as well as how you talk about it and how you use it. Be organized. This comes naturally for some than others, but even if you're not an organized person, do your best to be organized. Document stuff, make sure your developers know where all your files are. Just be organized as much as the level you are comfortable doing. This was really huge too, because you created this big spreadsheet that organized our wireframe, our design, where it was in Pattern Lab. We used Pattern Lab here and then where it was on the dev site, so Amy was great at tracking that. Yeah, so it hopefully benefited the whole team. And speaking of the whole team, it's really important that you're communicating. Like Courtney said, we were talking every day, but that also goes for communicating with your client as well. If you guys are all talking together constantly, your project is gonna go a lot smoother just regardless, but especially when you're talking about a system. And this goes with terminology because you're gonna create blocks and name them something, and you and the developers need to be using the same words to describe those pieces. So early on, we were like, this is the quote block. This is a stat box, yeah, so that's consistency. There you go. You should get into code as quickly as you can. I think there's, the evolvement of this process is that we hope to be able to do this stuff directly in code. That would be fantastic, but at the moment, it's more just getting that in code as quickly as you can because that's where your system is ultimately gonna live. It's gonna be on the web, so let's see it in its actual environment. And then finally, this was something we learned with transition, so decide on the afterlife. What does that mean? Decide where your system is gonna live. This was a problem when I handed over the system to Sarah, the designer who took over, because I didn't tell her that we had made changes in the pattern lab that we hadn't gone back and made in Photoshop, so I had handed her Photoshop files that weren't actually right, so that was my bad. So that's something we went to in part to you. Make sure, it doesn't matter where it lives, just make sure everybody is working from the same stuff. So in that case, we decided, or you decided after I had left, it lives in pattern lab. That is where the system is, that is the final version, that is the Bible. That's where the last update is. So it doesn't matter where you decide to do it, just make sure you decide it, and everybody knows that. Because the thing about design systems is they give you opportunities to do the cooler stuff. If you can do a page in five minutes, but you had an hour of time to work on something that day that leaves you, I can't do that. 55 minutes to do something cooler. So in the Peace Corps, I got to do two really fun things that I'd never had the chance to do before because there was never time. I got to build a really cool 404 page. I love this page. I hope nobody ever sees it, but I love it. And I got to do a really cool preloader, which again, I hope nobody ever sees it, but it's there because we had that extra time to put in those pieces of delight throughout the site. Because at the end of the day, who wouldn't want more delight? So thank you very much. We are gonna see the stage for our next presenters. Obviously these are, this is our contact information. If you have any questions, please feel free to email at us, tweet at us. But we're also gonna hang out just in the hallway outside if you wanna talk to us. We won't bite. So thank you so much for coming. Enjoy the rest of your day. Thanks. Totally forgot.