Wrangling Design System Planning for 2024: A Step-by-Step Guide

All right, y'. All. Hi everybody. Hope you're all doing well today. Lots of people in the chat. This is so cool, so active. If you missed it, I put, I put a note in the chat. Zoom has this weird thing where it defaults to hosts and panelists if you're typing a message in the chat. So if you're intending to send a message to everyone, you're saying hello, posting where you're from, make sure you select everyone from the dropdown. Otherwise it will just send to me. And while I'm happy to receive your hello and know where you're from, probably meant to send it to everybody. So if you, if you did just send to me by accident. Host and panelists, feel free to post again. It's awesome to see where everybody's from and where. Where around the world everyone's dialing in from and calling in from. This is so cool. Oh, Ottawa, California, Italy, New Zealand, Brazil. Greenville, Dublin, Estonia, Germany. Oh, this is so cool, so awesome. And yeah, I see some folks posting their Twitter handles and LinkedIn URLs. Please feel free to do all that stuff. Connect with folks here. This is a, a webinar full of people that are interested in design system planning. So I imagine a ton of design system enthusiasts here. So do as much connection as you can and want. Good question. In the, in the Q and A panel already, will this be recorded? Yes, it will be recorded. Hopefully you all got that notification that, that it is recording. You will get a, a recording link afterwards. So if you miss it or if you have to jump early or whatever, you can always review it and, and kind of send that around to other folks too, who might be interested, who can't. Who can't join now. All right, let's get started here. This one's been answered. Cool. All right, let's get started here. A couple of housekeeping things before we get started. Some of you may have seen this. If you haven't. I'm super excited about it. This is. This is my new design system book. It is recently published. I just received this on. What was it, Friday. I unboxed it this weekend, so I have the first physical copies and in my hand. Thank you to all who shared that link and shared the book with others and retweeted and all that kind of stuff. Partly what we're doing here. For those of you who don't know about the book, it's a design that scales.com. it's a book about design system practices and design system process and all that kind of Stuff I'm giving away a couple signed copies. So I mentioned on Twitter and on LinkedIn that I'm giving away a copy. I decided to do two. We'll do two signed copies. So here are the two things that you can do one of one or both of these things to qualify for a free signed copy. And we'll do a little raffle at the end of today. So the first thing is we're going to have some time for Q and A. At the end, we'll have maybe about somewhere between 15 and 20 minutes of Q and A. If you have a question, post in the chat in the. There's a Q and A box. Excuse me, not the chat. If it's in the chat, I probably won't see it's a post in the Q and A box. The most upvoted question that you that is put in the Q and A box will win a signed copy of my book. I have all of your email addresses from when you registered so I can get in touch with you. So the most upvoted question will will be eligible for a signed copy of my book. So that's, that's way number one. And then way number two is please share stuff from this webinar. If you, if there's a quote that you like or a diagram that I show on screen or something and you want to take a screenshot of it, you're welcome to do that. Post it on Twitter or on LinkedIn or Instagram or wherever and tag me in it. And whoever has the most liked post, wherever you, wherever you post that, you will win a signed copy of my book as well. And I'll get in touch with you afterwards to make sure I get your shipping information and all that kind of stuff. So for those of you who don't win, but you do want to get a copy of the book again, designthatscales.com, you'll find a link to pre order there. I think the official Release date is November 29, so at the end of the month is when it starts shipping. Until then, you can pre order for the next two weeks and you get a discount for pre ordering as well. Awesome. So, yeah, please fill the Q and A box with all of your questions and things like that and upvote others and upvote your own and have other people upvote your own. Yes, totally. Shout out to Rosenfeld Media for publishing. Great publisher to work with. Awesome. All right, so let's get started today on the topic of the hour. The topic of the hour is planning. That's why we're here today. We're talking about design system planning. And you know that's important, right? Like, after all, probably all of you or most of you here have heard the famous quote, if you fail to plan, you plan to fail. Hi roll. Probably set by some boring guy who didn't have any friends or didn't have any fun, but probably got stuff done. So kind of cuts both ways here. The reason that we're here is that we acknowledge that planning is important. And for a lot of us, myself included, I've done design system planning with many, many teams. It's still difficult every time I do it. And so the goal for today, for today's session, I have one goal which is planning continues to be important. Let's try to move it more towards easy than being difficult. So what I'd like to share with you is I want to share with you some ways that planning has gotten easier for me as I've done it over and over and kind of developed some templates and some tools. I'm going to share those templates with you here. You can take screenshots of the slides and again you'll have a recording afterwards to reference. So I want to give you just a couple of tools that I use every time I start planning. I'll always riff off of that from there, but at least hopefully they can be some good starting points for you as well. Okay. I think all of these tips apply to all kinds of planning, right? So whether you're planning strategic endeavors for your products or product design or your family planning or whatever, like we're going to apply this to design system planning today, but I think it applies to, to all sorts of kinds of planning. We're going to use design system planning as the example for today. As I know a lot of you are in the middle of that right now. You're doing things like H1 planning for 2024. Especially as we're approaching the end of the year and holiday season, a lot of us, our mindset is kind of in that end of the year. What should we do next year? So one of the things that helps me make work easier is when it's closest to real life because it feels more natural that way. Because let's be honest, sometimes work, especially the work that we all do, designers, engineers, product folks, writers, UX people, it feels like a made up world, right? We use words and terms that we would never ever say in any other situation. Like when's the last time you were hanging out with some friends or having dinner with your family, and you use the phrase burn down chart, it really is like a foreign language. Sometimes it feels like you're speaking Klingon or something when you use words that you only use at work. So instead of using a work phrase like 2024 H1 design system planning, instead, I want to think about it like something that's a little bit more applicable to real life. And maybe we can apply some lessons, things that we already know and already are good at and already have experience at with some of the planning stuff, that maybe it's the first time you've done it or you're new to it, or it's the first time you're working on a design system. So it's a little bit unfamiliar and kind of hard to deal with. So the example that I want to use here is imagine that you and a group of friends or your family are doing some planning for a 2024 summer road trip. I think this analogy could make it easier to spot where we do things poorly and what might be some easier alternative. For those of you who have planned road trips before, Great. A lot of that. A lot of those lessons apply here. And so we're going to try to apply them in a way that feels natural, feels less like work, feels less like it's cryptic, and kind of apply that to how we can plan for design systems. So when I'm working with a lot of teams, helping them with design system planning, I think one of the most common pitfalls is how they start. I think this is usually the first question that is raised in a planning session. Like, all right, it's 2023. 2023 is coming to a close. What components should we work on in 2024? So you might be thinking, well, what's wrong with that? It seems like a reasonable question. Yeah, I agree. You know, it's kind of difficult to tell what's wrong at this level. But again, here's where the road trip analogy comes in. Right. If we bring that back, it's kind of like this. It's kind of like asking. This is the first question, you know, what route should we take? And so hopefully it's a little bit clearer now, like, what the gap is in all of that. The components are. The components that you choose are a route, you know, so it's like saying, like, what route should we take? When, you know, the biggest pitfall that I've seen is that you haven't even picked a destination yet. Like, you get together with your friends and you haven't even picked where you're going, but you're like, what route should we take? Should we take the highway or should we take the scenic route? It's like, well, how do you plan the route if you don't know what the destination is? And yet I see a lot of folks doing this with design system planning. I think that one of the biggest reasons that design systems fail is, is that the team working on it never actually chooses a destination. So I'll talk a little bit about that today. We're going to talk about how to choose a destination, what destinations in design system planning actually look like so that we can plan appropriate routes to actually get there. Right. Imagine planning a road trip where you never actually pick where you're going to go. You would really just end up driving forever and never actually getting anywhere. And for some of you, that kind of sounds like what your design system team has probably been doing for the last year. Right? So, okay, time to stop that. Time to actually get some, some progress, make some progress toward a destination. So we need a better first question than what components should we work with and what component should we work on before we get to what a better question is? We will get to that. I think it's important to talk about where we should be asking that question. So for some of you, your calendar looks like this. A lot of times my calendar looks like this as well. You know, especially for those of you that work in house, you've got something like this. You've got design system planning sandwiched in between a one on one with some dude named Ed and some working lunch meeting somewhere. Right. This is the, this is the worst way to do planning. Just sandwiched in there, in between there's like ton of context switching. Yeah. 30 minutes of deep work. Yeah, like what a, what a bananas calendar here. No wonder planning is often difficult and boring and tactical. It's like you don't have time to do it well. And more importantly, you don't have the headspace to do it well. You're not giving yourself the appropriate headspace. So I want to give you three tips to start on this. On like how to even get in the headspace of this. And then we'll get into some, some tools and templates for what to do with that. That afterwards. By the way, these three tips come from a book that for any of you that has done a workshop with me or coaching with me, I reference this book a lot. You know that it's book. The book is called A Vision. Sorry, the Vision Driven Leader by Michael Hyatt. And these are three tips that are kind of inspired and kind of come from this book. The first tip that he gives and the first one, the first thing that I do with design system teams is you have to get away from, to clear your head. You can't do planning in the middle of stuff. In fact, there's a really great quote from the book from Michael Hyatt. It's nearly impossible to craft a vision in the midst of the day to day. The future doesn't happen in the present. I think it's such a great quote. I love that idea here that like you have to step away from your present in order to be able to clearly see what the future might be and envision this future. So I think that's a, that's a really important thing is just get away from the day to day somehow. Like that could be doing an offsite with your team. If you can afford to do that. It might just be like just changing location. Like go across the street to Starbucks, you know, and do the meeting at Starbucks. Just get out of the regular day to day just to clear your head and have a good headspace about it. The second thing that he, that he mentions in this book, and I love this one and it's a, it's a small one, it's a little bit woo woo. But I believe in it too, is you have to believe that the best is yet to come. I have been in rooms with lots of design system teams that are just so burnt from doing it poorly and doing it in ways that have failed before. Most successful design systems that I've worked on, most of those organizations are on their third or fourth try at design systems. And so it is a hard thing to get right, especially to set up a sustainable practice of design systems. And so a lot of folks end up being burned and bringing that cynicism to the planning process. And that's a really hard place to operate from. So in order to do good planning, in order to know what's coming up ahead, you have to believe that the best is yet to come. If you don't perhaps excuse yourself from the process, you know, you won't be a good contributor to that process because I think a lot of the stuff that you'll be thinking about and thinking on is just how it's failed in the past and how it's not going to work this time. And that's not really helpful to the team. So you might be a detractor to the team accidentally or someone else Might be a detractor to team if they don't believe the best is yet to come. So this is something that's really important to planning is you've got to, you got to believe that what's coming ahead is going to be better than what you've done before, especially if you've had a couple of false starts before. So I think this is a really important prerequisite to, to good planning. All right, third one. Once you get those things though, this is where it gets really exciting. Is. And this is a prompt that I usually give to teams when I'm, when I'm doing planning with them. I say imagine. I want you to imagine design system utopia and I want you to describe what you see. So I want you to picture the future of your design system and I want you to step out of the present and step into the future and look around and describe what you see as if it is the present. It's an interesting exercise to do. If you've never done it with anything, you know, much less design system planning, it's worth doing. Like where do you want your family to be in 10 years? Or where do you want your career to be in five years? Like step stepping out of, of the present and then picturing the future as if you're in it and then looking around and going like, what does it look like out here? Who's in the room? Who's not in the room? What am I working on? What does my lifestyle look like? You know, all of those kinds of things. That's really helpful for planning. This is my favorite part of design system planning. Because this is the part if you do this, this is why planning doesn't have to be boring. You know, if you just approach it like, eh, it's an hour block on my calendar, like it's boring. It sucks. If you're trying to fill out a roadmap or a Gantt chart, the work becomes really practical and it's fine, we need to get there somewhere. But. But that's when it becomes boring, is when we're only doing the practical stuff. The thing that we often miss and we skip is the part where we get to dream. Right? That's what good planning actually is supposed to be, is you dream for a while and then you figure out how to make that dream practical. Right? Dreaming is the part that makes planning exciting and fun, but we rarely take the time to do it. So I think these, these three steps are a prerequisite to being able to do good planning for whatever the half or the year or the next 10 years or whatever. I think this is really important. So once you're able to do this, great. Like, we need some better questions in this. So let's. Let's think about what to replace this with. What components should we work on in 2024? So, again, let's. Let's go back to our road trip. Our road trip analogy here. What route should we take? Well, if we're asking, if we're thinking about our road trip, one of the first questions, like we talked about before, is, where should we go? Right? You're planning with some friends, where should we go on a road trip? We all have, you know, six weeks off this summer or two weeks off this summer. Let's plan a road trip. Where should we go? That is a much more useful question, but that's a hard question to answer, right? It's like, it's really difficult. And the. The reason that I think it's difficult is it implies that there's a smart way to answer this question. And when you're trying to decide this in a group, what people often do is the temptation is to go with the smartest answer. Right? To illustrate the silliness of this approach, let's go back to this. This road trip thing. If you're taking a road trip in the US for example, I know there's a bunch of people not from the US Here. I know the US Well. I'm such an ignorant person of the rest of the world. So forgive me on this shallow example. Here in the US there are 19,495 cities to choose from. So how do you pick one? How do you pick one out of 19,495? Well, what a lot of people do is they make, like, a pros and cons list of every city. They narrow it down to some subset of, you know, something on the east coast or something on the West Coast. Like, they find some subset, and then they do kind of a pros and cons thing. You could take a vote. You can make it democratic. You could look up online reviews or articles or suggestions. But that is super nerdy. And so that only applies to the folks that really like that nerdy stuff. It doesn't apply to everyone. And it takes really long to do that. Some of you, I include myself in this. We love doing the research. You know, we love compiling notes, and, you know, that's cool for us. But some of you are like, ugh, that's. That's a lot of work. I don't want to be Doing all that because it is. You're right. And so I think the reason for the pushback here is I think people just want some time to dream, you know, and so, so that's what, that's what I would suggest doing is instead of, instead of answering this, like, logically, let's answer it emotionally. Let's. Let's answer it about, like, how we could dream about this stuff. So now's the time to do it. So instead of this, maybe it's more like, what experience do we want to have? And I suggest this question as a starting point, as an interesting starting point, because this one is easier to answer because I think we can answer this with our gut. We don't. This doesn't need to be a logical answer. Oftentimes when somebody says, like, what experience do you want to have? You know, or something equivalent to that, we tend to use feelings words and visceral words to answer this question. So, you know, when we plan a road trip or a vacation, we dream about the experience we want to have. What is the ideal vacation or utopia vacation for you? We say stuff like, I want to go somewhere warm, right? Like, that's illogical. You know, like, it's the summer, you probably are already in some in a place that's warm. But I don't know, some people still want to go to place this warm. Great. All right. Other people say, like, I want to explore a rainforest. Like, cool. I want to eat my way through a city. I want to do, you know, a foodie tour. Awesome. I want to go somewhere that has vibrant nightlife. Like, these are easy things to answer because we can answer these from our gut. We can answer this in our dreaming state, you know, And I bet for some of you, a place already came to mind for one or more of these. Like, as soon as I said a place that's warm, you're like, oh, I know a place that's warm that I would love to go to. And I bet some of you got excited about that. And then others of you probably are like, oh, no, no, I don't want to go there. And that's really what we're looking for. We're looking for that gut reaction from a gut level dream, you know, for a destination that everyone on the trip, or at least as many people as possible, are excited to go to. I think the same is true for design system planning, right? So the last time I helped the team do planning, which was last week, um, I ask each person, like, where do they want to go? What's Their destination. What experience do you want to have with this design system? A year from now, two years from now, five years from now, 10 years from however long in the future, you know, what is your dream destination? What does design system utopia look like to you? And they had equivalent answers to the ones that you see on a road trip. So I heard things like, well, I want to be involved with product teams from day one. Right? That's not a logical answer. It could be. There's some logic that comes from that, but that's like a gut feeling. That's like, that's something somebody being like, ah, I just wish we had this. Like, I wish I could wave a magic wand and be involved with product teams on day one. I want to give teams peace of mind. You know, I want our design system to give team peace of mind. Other people were very tactical about this. I want easy to implement fluid typography to be all over our system. Like, that's the thing that I want to have. That's their version of design system Utopia. Some people want their design system to have a vibrant nightlife. I'm just kidding about that. You know, one person said, like, I don't want to have to prove the value of everything that we do, right? And that's like. And, and I love this one. And this one is a, this one is from a person who really is dreaming. And they actually prefaced it in, in our session. They preface it by saying, I know this is probably highly unrealistic, but. And I think that's a really great way to think about dreaming and to think about any statement to a way to start that statement when you're thinking about design system utopia and where you want to go, right? So, so in the same way that we talked about these things, as soon as you talk about these things from a gut reaction, they, they imply destinations, right? So like for all of these, it's like, I want to go someplace warm. Well, Miami's warm in the summer, all right? Or I want to explore a rainforest, while Alaska has rainforests. You know, Charleston is a great city to eat your way through. Vegas has a vibrant nightlife. So a lot of these gut level things, they inspire answers. And really that's what we're after. And so how do we apply that to design system work? In the same way, these are also different destinations. You know, the components and the patterns and the guidelines and the workflows that you might need to be involved with. Product teams from day one might be very different than the components and patterns and guidelines and Workflows, you might need to get to a point where you're not proving the value of everything you do. Those are different destinations, right? So you need to take different routes to get there. We can't take the same route to Miami that we take to Las Vegas. They're different routes. But once we identify the destination, then we, then it becomes much more sensible what route we actually take. So. And yes, there's also some common ground that you can find, too, right? Depending on how much you're willing to compromise, some of these things actually apply to multiple gut feelings. You might decide, like, yeah, Miami's warm, but Las Vegas is warm, too, and it has a vibrant nightlife and it's a good town for foodies. So maybe we get all three of those things if we go to Vegas, whereas we only get one of those things if we go to Miami, you know, so you, you won't get to explore a rainforest, right? Maybe a rainforest cafe, I don't know in Vegas. But, like, three out of four is not bad. So what you can do there is given that you can pick, say, Las Vegas as a. As a destination. And so now you can start planning the route. So I want to give you some tips on once you plan it, once you pick a destination. And it doesn't have to be a final choice. It doesn't have to be locked in at this point. It's just a working theory that you're going to use because it might change later. But the working theory is like, okay, cool, we're going to. We're going to pick Vegas. We're going to go to Vegas. Let's see if that actually holds, and let's see if we can disprove that. Or maybe some factors appear that make us pick a different destination, you know, or anything like that. So the next step, the thing that I like to do next when I'm doing planning is I like to write a goal story. And the template and the format that I want to suggest comes from my friend Sean Blanc. He runs this great course called the Focus Course that just helps you get focus in your work and career and life. It is awesome. I just went through it. I recommend it to everyone, you know, to anyone who needs focus in their life. The FocusCourse.com, it's great. And Sean has really good formats for this that I pulled right into design, system planning, and really strategic planning for anything. So what we're going to do is I'm going to show you a couple clauses at a time. It's pretty Thorough. So we'll just kind of build it up. We'll start from a simple part and then we'll kind of build it up from there. So here's how Sean's goal story template works. It starts like this. The first piece of it is we want to blank, buy blank. Because blank. I like mad lib style things. I like fill in the blanks because it's easy. I like having these formats as these starting points. So this is the starting point for us. We want to blank. We want to do some goal, achieve some goal, get to some destination by some time in order to create some accountability. Because blank, because we have some reason, some motive, some incentive to be able to do that. So if we look back at our, you know, our possible destinations that as, as we were dreaming about design system utopia, let's pick one of these. Let's say like, you know, give teams peace of mind. Let's fill in the blank here. We want to give teams peace of mind by some deadline because of some motivation, right? So we'll fill it, we'll fill in the rest. We don't know if this is a good goal or a good destination yet, but that's okay. We don't need to know those things. We can kind of revise it as we, as we go along. So let's fill in the next part, let's fill in the, the deadline part because that's the part where it starts to really get real. So as an example, let's, let's pick a timeframe, let's say 2033. So this becomes our 10 year goal story. We want to give teams peace of mind by 2033 because of some incentive or some motivation. As soon as you fill in a date there probably some of you had a gut reaction to that and maybe that gut reaction was like, oh, that's way too far away. Like, no, no, we definitely want to do that way before 10 years. Way before 10, you know, 2033. And for some of you, you're like, yeah, I mean that feels right. The way organization's going. Yeah, it probably was. Is going to take 10 years to get to that point. Right? For some. So the, the gut reaction that comes from that you can use as a way to revise and refine some of this stuff. So you know, for me, I look at this and I go, well, that's, you know, 10, 10 years from now. That's, that's a lot. Maybe we'll move that to like five years from now. We want to give teams peace of mind. By 2028 instead of 2033 because of, you know, some reason that feels much more realistic for some teams. It's like, no, we want to do that way before that. So, you know, for that, for some teams, it becomes a two year story, a two year goal story. We want to give teams peace of mind by 2025, you know, because of some reason. And that feels more realistic to some teams. So cool. Wherever it feels realistic to you, you know, filling in that timeframe helps to make it more real. And we'll start to move, we'll start to move from, from Utopia, you know, and this unrealistic thing to something much more pragmatic, something much more practical in this. And as we fill in the blanks, hopefully it becomes more and more practical. Okay, so now the, the, the next thing is, is motive. This one's hard, this one's really difficult to do. And I think the reason that it's difficult is because it lacks context. So in order to answer this question, sometimes we need to put more context around it to understand where your design system lives or, or where this motivation even comes from. And what I like using as a, as a context is the natural, broader context is that your design system likely sits in the context of your company, right, with all the other systems that might be in play there, the brand system, the content management systems, you know, all of those kinds of things. So let's add some company context here. And so this is the next clause that Sean kind of suggests in his format, which I appreciate, which is this part at company, at our company name our mission is. And then you put your mission statement in there and then that gives the context to the phrase we want to give teams peace of mind by 2025 because of some motive. So let's use an example here. I like using Uber as an example. I don't think I saw anybody here from Uber. Otherwise, I, I don't know. I guess. This is a free consulting on Uber's website on their about page, they have their mission statement right there. We reimagine the way the world moves for the better. So if I worked at Uber and I was doing design system planning for Uber, I would bring that into our planning as a piece of context and I would fill this in to say, at Uber, our mission is to reimagine the way the world moves for the better. We want to give teams peace of mind by 2025 because of some motive. Now just looking at that, now that we have some additional context already, to me, I'm like Oh, I don't think that our destination makes much sense. Then, like, I'm not sure what that has to do with reimagining the way the world moves for the better. So this is the point where I might actually switch destinations. And this would be similar to. Go back to the road trip analogy. This would be similar to going like, ah, I really want to go to Alaska. And then I Google it and it's like, oh, that's 65 hours of driving. I'd rather not do that. So, okay, now that I've discovered some fact and added some more context, I'm going to change the destination. Let's go to Vegas instead. You know, it's 30 hours of driving instead of 60 hours of driving. So what I would do is I would go back to some of the other possible destinations and I would go, okay, well, you know, what else from here could we take? What might be more in line with the context and the mission? You know, instead of. Instead of give. Give teams peace of mind, right? So instead of this, maybe we insert a different destination, like be involved with product teams from day one. You know, maybe doing that actually helps my. My company reimagine the way the world moves for the better. Okay, and now, now if it makes more sense to me and if I. If I understand that a little bit better, the team understands it a little bit better now we can actually fill in that motive, right? We might say something like, at Uber, our mission is to reimagine the way the world moves for the better. We want to be involved with product teams from day one by 2025, because it'll give us a better understanding of how their work impacts, how their work helps to impact the company's mission, right? So now we're filling in more context and we're becoming more practical. We haven't gotten to the how yet. This is still the what and a little bit of the why, you know, so we'll get to the how. But part of getting to the how is actually adding context here. All right, so let's add the next piece now, right? This piece is important. More context here. Now we talk about obstacles. So this, this latest clause at the bottom here, bottom right, a potential obstacle is. And then you write the obstacle, but we believe we can overcome it by strategy. And this is the part where. Where the believing the best is yet to come is here. If you don't believe the best is yet to come, you will run right into this obstacle and stop. But if you believe the best is yet to come, you might have a proposed solution or at least an idea as to how to get over that perceived obstacle. You even, or especially if it's the same obstacle that you've run into the last two times that it didn't work. Right. So believing the best is yet to come comes really into play here when you talk about the obstacle and strategy. And of course, you can add as many obstacles here as you see. So sometimes when I write a goal story and I'll have one obstacle, other times it'll have three obstacles, you know, that each have different strategies to help overcome. So, you know, here's an example of one obstacle. We kind of fill this in. I'll keep reading the entire statement for context. At Uber, our mission is to reimagine the way the world moves for the better. We want to be involved with product teams from day one by 2025, because it'll give us a better understanding of how their work helps impact the company's mission. A potential obstacle is the lack of visibility of team roadmaps, but we believe we can overcome it by refusing to work on any Sprint that doesn't have a product requirements document created in advance. Okay, that might be a good way to help. To help that obstacle. Somebody might have this idea in a meeting or a session or a planning session, and somebody else might disagree with it. Well, that's great. Like, that's what this is designed to surface. Somebody else might have a different strategy to. To overcome that obstacle, a different way that they might approach that. And this is what this conversation is designed to do is, is bring those things up. All right, next piece of this, there's two more pieces to add to this and this. That'll be the full template that I'll show you. And I'll have a slide, two slides where you can kind of screenshot these if you want to use these templates or these as kind of fill in the blanks. All right, so the next piece here that we add is. And this is where it gets into the how is critical actions. And so one of the things that's different about this piece is that all the rest that we've gone through so far is really about the outcomes that we want to see. Right? We want to. We want a better understanding of how teams work. That's an outcome that we want, but the problem is we can't control that. Right. That's something that we can maybe influence at best, but we can't actually control that. The only thing that we can control is, are our actions. So that's why it's important to keep our actions in here is we, we believe that if we do these actions, it will help influence, to the best of our ability, these outcomes actually happening. So I think it's important in this planning session to go, okay, if we want these things to happen over the next two years or by the time, you know, two years arise, 2025, we have to commit to doing these things. And that is our best effort at actually accomplishing that. So here's some examples of that. You know, at Uber, our mission is to reimagine the way the world moves for the better. We want to be involved with product teams from day one, by 2025, because it'll give us a better understanding of how their work helps impact the company's mission. A potential obstacle is the lack of visibility of team roadmaps, but we believe we can overcome it by refusing to work on any Sprint that doesn't have a product requirements document created in advance. Therefore, we commit to these critical actions. And I have two here. The first one is we are going to join weekly product open door sessions. Right? They happen. We haven't been joining them. From now on, we're going to start to join them. Number two, we are going to prioritize three components that emphasize movement and direction because that's directly tied to the company's mission. So we're going to work on the map. Our motion guidelines and our call to action component. These are ways that we can directly impact the mission of our company through our design system. So these might be bad examples or good examples, but they're examples. Hopefully they get the wheels turning for you and how those things might be applicable to your particular situation. So here's what the whole thing looks like, right? This is, this is the, this is a goal story. Right over here on the left is what we've gone over. And then the last piece, and this is one that I really, really love. This last piece is a definition of done. And I use this often when I'm working with teams and when I'm working with people. I use this with my assistant all the time. You know, is like, how do we know when we're done? And there are three pieces to this, which I love is facts, feelings, and future. All right? And again, those are Mad Lib style. So in terms of the facts that might appear here, you know, this business metric is going to improve by a certain percentage. You know, the deliverables we expect to see are. And then you list the deliverables. The feelings part is one that I think gets overlooked all the time. So the feelings part is this person will feel some feeling and you can list as many people in there as you can. This is the one that I enjoy the most, this is the one that I try to fill in the most. And then future this one's really important. This is what unlocks the next level goal story is this person will be able to now do a new thing as a result of accomplishing or reaching this, you know, finishing this project or this quest or whatever it is. So you know, here's an example of what that actually looks like. This is an example of a two year goal story. You can take a screenshot of this one if you want. This is a filled out version. I'll read it out here. When this goal is achieved, here's some facts. Team Velocity will improve by 25%. The deliverables we expect to see are calendar invitations from all 11 consumer teams at the beginning of their sprints. Right. These are things that we can measure, we can look at, we can have accountability. If you have some sort of framework that you use at your, at your company like okrs or KPI's or things like that, these play right into those or you can actually borrow from those, those KPIs or those OKRs and put them in the this goal story template. What about feelings? Well, Charles will feel certain that our design system is crucial to the product design process. Gene will feel trusted every time they're included in a leadership off site. And then same thing on the future side, Aurora will be able to increment the official version number of our Design system from 2.4.2 to 3.0.0. Right. So these are all great things that you can use to define when we're at done. So this is a version of a filled out template. These might be bad examples but again hopefully they give you, they get the wheels turning in terms of things that might apply to you. Things that you feel comfortable measuring, things that you feel comfortable saying, this is how we'll know we're done. And then last thing that I'll show you here for this is this is a fill in the blank template. So if you want to take a screenshot of this one, this shows you all the things that you might need to fill in. I have a Google Doc that I use for this but you know, you can make it an easy one for yourself. You know a figjam or something like that based on this. So this is the kind of the template, this is the fill in the blank version that I tend to use. All right, hopefully everybody's good there. I see a bunch of questions in the chat. We'll get to those at the end. So here's. If we, if we take this example, the two year story goal example, what we can do with this is we can now use it to go, okay, we have a full story for our two year goal. So what do we need to do in order to get there? Right. Let's go back to our road trip analogy here, right? Because to make it, to make it a bit more actionable, a bit more tangible. So each of these road trips, I want to go somewhere warm, great, Miami. Or I want to go somewhere where I can eat my way through a city, Charleston. We picked Las Vegas. That was the destination. Each of these destinations has different mileage associated with them, right? And so if I live in Philadelphia, right outside of Philadelphia. So for me to drive from Philadelphia, take a road trip from Philadelphia to Las Vegas takes 37 hours, would take 37 hours to drive straight, and I'd be driving 2,500 miles, you know, to get from Philly to Vegas. So if the entire trip is about 2,500 miles and take 37 hours, then I can measure along the way my progress around. Where should I be at the halfway mark? All right, well, the halfway mark I should be. I should have driven around 1250 miles, right? About half the distance. I should have driven about half the time in about 18 hours or so. And so what's around halfway? Well, maybe we'll stop at around Kansas City and we'll spend a few hours there to kind of break up our trip, because that's about halfway and we can measure that we're halfway. We'll know we're halfway there if we've driven 1200 miles, if we've driven for about 18 hours and. Or if we've reached Kansas City. Now, Kansas City is not our final destination, but we are going there on the way to our final destination. So it is kind of a destination of sorts, right? And so we can have some mini celebrations for reaching halfway when we get there. Like, we can have gas station hot dogs and we can have potty breaks, right? These are ways that we can celebrate the, you know, mini celebrations along the way along our trip. And so you can do that with your goals or with your destinations as well. So if you take a two year goal, you can say, okay, well, what's halfway to a two year goal? Well, we should probably have a one year goal so that we can measure that. If we have met this one year goal, then we can actually we're halfway toward our two year goal. So let's figure out how to apply that. We can take our two year goal story. All right, and that goal was to be involved with product teams from day one and we can grab our template again and we can start to make a one year goal story. Right? So let's add the context back in. At Uber, our mission is to reimagine the way the world moves for the better and we can have a new one year goal that should be about halfway. So this one year goal as an example could be. We want to create useful boilerplate tools and templates by December 31, 2024. That's a year from now because it'll make us more valuable to product teams in day one conversations. And so hopefully you can see how if we meet this one, it's a stepping stone, it's a halfway point, it's a mile marker to our actual destination of our two year goal or our two year story. So I won't take this too much farther. We're kind of getting close to the end of time and I want to make sure we have time for Q and A. But this is the process of doing planning is once you have a two year goal, then cut it in half and do a one year goal. Maybe you, you wrote a ten year goal story. All right, so split that in half and, and scope the, the five year goal and then the two year goal and then the one year goal. And what I hope you can see from this is I do this in a Google Doc sometimes to start and the Google Doc ends up being maybe nine or ten pages where the first page is kind of an overview of what we're doing with our design system. Here's our five year goal story, our one year goal story, and our quarterly goal story. Right? You got to break it down so that we know what we're doing at every level and it becomes a Google Doc to start. And I'll tell you where that actually goes. But you can see how all of the goals fit as a subset of themselves, you know, into the other ones. So our 10 year goal is made up of our, you know, our five year goal and our one year goal and our quarterly, quarterly goal and all of those things, they should fit together. If you're working on a five year goal, that doesn't help you get toward your ten year goal with your design system. You need a new five year goal, right? So you want to make sure all of those things are in alignment. And of course, you know, probably all of you are thinking this, you can also break it down even further than that, you know, so quarterly goals might not be. Sorry, they definitely are not enough, you know, to just have a quarterly goal, you need to know what critical actions you can take at a smaller level. So of course you're going to have monthly goals and, and weekly goals and daily goals, but those things don't need to live in the Google Doc. It just takes too long to update those and it's not worth it. Right. So don't put those in the Google Doc. Where do you put those? You put those where you do the monthly and the weekly and the daily work, which is if you have a Jira or a Kanban board or a Trello or something, whatever you use to manage your work, that's where those goals sit, right? The monthly goals, the weekly goals, the daily goals. Right. So, so it. When a lot of times we talk about a source of truth in our design system, and to me a lot of source of truth is not just references and not just documents. Documents, because documents die and they get forgotten and they get lost. But source of truth really means it's in it. It is ingrained in the way that we work. So moving from our largest goal story, five year in this case, how do we make that actionable? Well, that five year goal, a subset of that turns into a Trello card or turns into a JIRA task, or turns into something in linear. It turns into something that we can do that we can commit against or design against or do something about taking action against those things. Right. And so, so how does I kind of describe how the monthly and weekly and daily stuff becomes actionable? Okay, so what about this other stuff? Is it too lofty to actually make actionable? I don't think so. And I'll give you a suggestion to kind of round out here. I'll give you a suggestion as to where to actually do that. Some of you have seen this site before. This is the, the wise design and this is their design system. And more than that kind of made the rounds maybe a couple of months ago. Really beautiful, great work. And you'll see here across the top, the nav. This is the reference site. You know, you'll see the navigation, design, it wise, foundations, components, patterns. I suggest you put a new link up here, right in here. And that new link is all of the stuff that you put in your Google Doc. Put that in your reference site. Right? So you might have, you might put it somewhere here. Something like design Vision or you know, design system goals or you know, whatever you can come up with, whatever brand related title exist there. But now you're bringing it into the flow of work. Now you're bringing it into a place where people are actually working, ideally. And hopefully people are using the reference site as they're using your design system, figuring out how to do it so that, that documentation is not in a Google Doc, somewhere that's just linked off to and gets lost. It can come to them because it's right here, it's right in their faces as they're doing work, this idea. You know, we talk about design system, sorry, we talk about just in time documentation. When someone is working on something, maybe that's the time where they want to know like, where is this design system going over the next five years? How do, how do I want to get on board with that? How can I, how can I use a design system in a way that actually aligns with that? So rather than being a Google Doc and then, you know, Jira, maybe this lives, becomes more living in your documentation site, your reference site, your style guide site, and, and your Jira or your Trello or things like that. So you have places where you can reference all these things in the place that you work on every day. Right. The broader goal stories become more on the reference site because that becomes a piece of marketing for your design system and a piece of vision for your design system, as well as documentation and reference. And also it becomes, you know, your, your monthly and weekly and daily goal stories are really infused into your work. So the last kind of thought that I want to share here before we kind of break for questions and things like that is what, why do all this stuff like this seems like a lot of work, you know, a lot of, a lot of work. Is it worth it? And I think the answer is yes. And for this reason why I love this quote. This is from David Allen, who wrote this book, Getting Things Done. Kind of pioneered the getting things done methodology. And he says you can do anything, but not everything. And I think that's one of the things that design system teams suffer from a lot is they, the scope is so broad of their work because design systems have to work at scale. That's the job. And so it's hard to know what stuff am I not supposed to do. And when you make a good plan, especially farther out and you write good goal stories, it's really good indication for the stuff that you don't have to do. Right. If you have a thing that you are going to do it implies the things that you are not going to do because you're on a particular mission. And I've seen a lot of teams actually make that explicit. And I think that's a really great thing. We are not working on forms for the next year because we're actually working on our table experience. Right? Because that's the mission that we have, that's the destination we want to get to, is helping our customers or our constituents or whatever it is. And the way that we do that through our interfaces is largely table based on. So it helps you to figure out what you're not going to do. So the last thought to leave you with is I think when you have a compelling mission, people want to join you on that trip. You know, they want to arrive at that destination with you. And then hand in hand, what goes with that is when you have a compelling mission, people will help you to avoid distractions so that you all arrive at your intended destination. If you have a strong vision and a strong destination, it's like we are really optimizing forms this year. Well, great. Then people who are really interested in that destination with you, they will help you not work on tables because they really want you to work on forms so. So that they benefit from that too. Right. But a lot of that only comes when you are diligent and vigilant about the fact that you are on a particular mission. And that means that there's other places that you're not going. If you're going to Vegas, you're not going to Miami. Right? Nothing against Miami, it's just not the one that you picked. Right. And so by virtue of picking a destination, you, you are able to say we're not going there right now, so we don't have to pack these things. So in summary, you know, here are kind of the three tips. Here is, is first thing is I think it's really important that you choose a destination. The second thing is once you choose the destination, write as many goal stories as you can. You know, sometimes you write a five year goal story and a one year goal story and that's enough to take action. Great. Sometimes you have to go like, ah, I need to see where this thing is going over the next 10 years, you know, to really be able to take action. Well, great, then do that too. If you want to write a nine year goal and an eight year goal story and seven a year and six year, if that's what helps you move along, great. You have a format for that now write as much as you can, tell the stories as much as you can, to the point where you take action. And then the last thing here is it's so important to share those stories far and wide. I see a lot of design system teams that do get a chance to choose a destination, and they do write the goal stories or their equivalent of that, but they never share it. So people don't know where they're going. Some of you have seen this product that I have. It's a workbook called design system. In 90 days, there's a live cohort that I'm running. I'll tell you about the next one that's running too. But it's essentially, it's 52 activities that I would do with a design system team when we first start, like here, if you're starting a design system and you need to get it up in three months, these are the 52 that I would do. And so I'm gonna go over these in detail. But These are the 52 activities of these, look how many are actually sharing stories? Like, more than half. It's so important to be able to share those stories because that's what you're doing with the design system. You're connecting your entire org together. And you can't do that just with components. You have to connect the people, you have to connect the stories, you have to connect what you're doing. You have to align the missions, you have to align the destinations. All of that work is so important. It's more important, in my opinion, than the component work, than the figma work, than the API, the props, the react, the web component. All those things. Those things are important, but connecting the. Org is more important than that, and sharing the stories are a way to do that. So all of these points where you're sharing stories are. Are all potential and probable points where someone's gonna ask you why you're doing what you're doing. Right. Okay, cool. Yeah, I know you want me to use the button component that you made, but, like, why that? And if you don't have a good answer for that, they're usually not interested. But if you have a good plan, if you have good goal stories, it helps you to get to the point where you can explain those things to people. You can share those things with people, you can point them to resources. Hey, we have this great page on our reference site that explains a lot of that stuff. I'll send you there. Happy to answer more questions. Other than that, you know, after that. So these are all things that you're able to share stories. I didn't talk about the sharing stories part today because we kind of ran out of time. That's the thing that I do teach in my, in my cohort, the design system in 90 days, the next one is running is the first time I've actually committed to any dates here. It's going to run February to April of 10, 20, 24. I will share the specific dates soon. If anybody is interested in taking this cohort, sign up on the Design System University site. That's Design System University, and sign up for the Design system in 90 days mailing list and I'll send all of that stuff around. So the sharing part is something that maybe we can do in a future webinar. If you all are interested in this. You know, if this was helpful, we can kind of tackle that, that topic maybe next month or something like that. I definitely tackle it in detail with the folks that are in my cohort. So if that's something that you're interested in and working on in detail with your teams, this might be a good fit for you. Check it out. It might be interesting with that. Thank you all. Thank you for being here, for listening. There's a ton of questions in the, in the Q and A panel. I know the chat has been, has been vibrant too. So I'm just going to go through as many of these questions as I can. There's a lot. I don't know if we'll get there in 10 minutes. There's 43. Wow. Okay, so let's just go through and I want to try to see if I can sort these. Okay, so let's just go through and I want to try to see if I can sort these. I think there's a way to sort these. All right, well, I'm just going to go through as many of these as I can. And here we go. Okay, so first thing is someone asked, Valentin asked, how can I get the book? So hopefully I've answered that. But just in case, if you are interested in my Design System book, which I'm going to do a giveaway here before end of a signed copy, designthatscales.com and that'll get you to the pre order page where you can pre order that book. So hopefully that that's helpful, that's where you can get that. What did you name your first design system? Lydia asked. Thank you for that. That question. What did you name it? So I've never worked in house anywhere, so I've never actually had a design system of My own. I've worked with, with teams and helped them name their design system. So I'll give you some examples of those. The team at Exxon Mobil named their design system Unity. I think it has a different name now. They re released it or did a version 2 of it. I think it's called Standard or Standards now. So that's that one. At United Airlines, the design system there was named Atmos. At Eventbrite, the design system there was called Marmalade. So, you know, I love fun names. I think it's really good when a design system has its own brand. I think it's a good signal that you're taking it seriously. You know, like you took the time to, to name it, you took the time and a lot of teams make a logo for it and even some swag for it too. You know, T shirts or notebooks or water bottles or, you know, whatever. And I think it's a signal to everybody that like you took it seriously. So they can take it seriously too. So I'm a big fan and a big proponent of naming and branding your design system and not just calling it like, you know, design system, university design system, you know, like that would be like saying Coca Cola is like carbonated water. It's like, you know, I think it needs a brand to help carry it forward and feel like a product that is sustainable and, and is worth putting time and effort into. All right, Jenny's got a question. How do you get people to actually use a design system? That's a great question, Jenny. Thank you. Thank you for that. How do you get people to use a design system? I'll answer a slightly broader question that how do you get people to do anything which is it's got to have something in it that they want. So I think a lot of teams don't spend the time to figure out what teams want out of a design system. They just think that they should make all of the common components that you might need in an interface. And I think there's a big difference between might need and definitely want. So, you know, a lot of teams make like the buttons and the tables and the forms and the footers and the headers and like all the, you know, standard HTML elements or iOS elements. And there's a good chance that other teams might want those things and probably will have to use those things. But because it's not a user driven process, a lot of times they're not built in a way that design system, that the people can use the design system in the way that they want to. And so I think it has to be a much more customer driven process to build components and have components and prioritize components that people actually need in the way that, you know they're going to use them. And I think that only comes from spending time with them, spending time with the designers and the engineers and the writers and who are going to be using the design system and building it in a way that they actually need. If it was just about components, material design is amazing. So why doesn't everybody just use material design or Tailwind or Chakra or, you know, any of those, the great open source design systems that are out there? It's because it wasn't built for them, you know, it wasn't built to have their specific needs in mind. I think that's one of the benefits of an internal design system is it helps with that. Thanks for that question, Jenny. All right, question from Ty. What's the biggest barrier to adoption of design system with non design leadership? Oh, interesting. With the biggest barrier of adoption of design system with non design leadership. In my experience, it's that design systems are never more important than the number three priority that the organization is working on. So oftentimes there are mostly, you know, often two, two things that are more important. And that's usually something like, well, the re platforming is what we're focusing on for this year, you know, or the, the content migration or the rebranding, you know, something like that. There's usually some big organization wide change that's happening and design system usually doesn't get higher than that. So I think that's the thing that, that's really tough about design systems, especially for non design leadership is like their priorities are usually on those things. So when folks try to take the design system work and make it higher priority than those, it creates a conflict. So the solution to that is somehow tie in the design system work to some of those other pieces. So if a rebrand is happening, try to get your design system as the solution to the rebrand. Oh, you all, you know, we need to migrate to new colors and new fonts. Well, we have that stuff in our design system and implementing our design system is actually the easiest way to adopt the rebrand, not the easiest way to adopt the design system, even though that's a side effect of it. So those are the things I generally recommend to teams is like try to tie the design system effort to some change that's already happening or already in progress because it's a good Trojan horse in that way. Great. All right, five minutes left. Yoko has a question. If you are a design system team of one, what do you suggest would be key people to bring into the planning sessions? Ooh, this is a big topic. I've been working on a course for Design System team of One for a long time. It's a tough one. There's so many different factors and different variables that are just small nuances away from if you're on a design system team or of, you know, five people or 10 people or things like that. So design system team of one, you know, who are the key people to bring into the planning session? People who will do the things that you can't or won't do. So, you know, for example, if your design system of one and you're a designer and you don't know how to do or can't do or don't have the time to do some of the engineering work, make friends with an engineer right away, you know, someone who will. Who will share that load with you. Someone who will be able to do that work and take that work on on your behalf. That's way easier said than done. You know, they're probably going to be a lot of people who are interested in the work with you and are willing collaborators, but whether or not they have time, whether the roadmap allows for it, like, all of those factors play a role in that. So design SEMA1, I think, is a big role, is just making friends and finding people who have both the capability and the bandwidth to help you implement things that you are just not able to implement because of whatever factors, because you're not in the room, because you're not on that team, because you don't have that skill set, because that person won't listen to you. You know, it's a. It's a very diplomatic job. So you have to be a diplomat. You have to be kind of making friends all across the org, you know, shaking hands, kissing babies, all of that kind of thing. So I think that's the major role of a design system team of one, which is why it's so hard, is that, you know, it's hard to do that in addition to your job. Great. All right. Ted has a question. Sorry, not design system related, but do you wear a headband when you play basketball for that flow? Absolutely. Yes, I wear a headband. I also sweat a lot when I play basketball. So headband for sweat and then also a hair tie for the hair. Cause I don't like it in my eyes or anything like that. That's probably the most valuable part of this webinar. So thanks for asking that question, Ted. Appreciate it. All right, Admiya has a question. In an ideal design system Utopia, what elements do you envision and how would they contribute to the design process? Ooh, I like this question. Thank you for this, Admir. In an ideal design system Utopia, to me there is no ideal design system utopia in general. I think there is an ideal design system utopia for every organization. And I think it looks really different depending on the mission of the organization. That's why I kind of structure the goal stories the way that I do is it needs to have the context of the organization. If you're an organization that only builds iOS products, well, your ideal design system utopia is not going to have web components in it. Why would it? It's unapplicable or inappropriate to the work that you're doing. If your company builds everything on angular, your angular design system utopia is going to be very different than somebody else's. React Design system Utopia. So I think it's very context dependent and I think it's about the, the major needs of that organization. What can you take the biggest chunk of? Right. So if you're. I have worked with a couple of organizations that like almost every interface they build is tables. So when we tackle tables with the design system that took care of 30% of the interface needs there, like that was a form of utopia for them. It was like, oh, we don't have to do that part. Great. You know, it doesn't take care of everything, but it saves us a significant amount of time. 30%. That's awesome. So you know, utopia doesn't mean everything is perfect and everything is, I guess literally the word does. But design system Utopia doesn't mean that everything is going to be perfect. It just means that like this is pretty sweet, you know, and I think if you reach that point or are, are progressing toward that point, I think that's a really good thing. All right, last question. I think we've got a minute left. My asked what's the first decision you make when embarking on work for a design system? Oh, that's a good one. Let me look back at the, you know, the design submit 90 days workbook. So it's this one, this is the, the first, the first step is assemble the North Star. And what does that mean? Is like why are we here? Like we don't. If we don't know why we're here, you know, what is, what is the mission of our not of our design system but of our organization, like, what are we actually working towards? You know, for some organizations, it's to help people with their finance. For some organizations, it's to help people travel better. For. For other. What is it that your organization does to help its customers? Your design system should aid in that process. If you don't know what that thing is, you can't build a useful design system. All you'll build is a library. You'll build a library of components. And that's different than a design system. A design system is connected. And mostly what it's connected to is it's connected to your organization's purpose. That's the thing that kind of underlies and undergirds it. So first step for me is often like, what are we trying to serve here? Because then it allows the next natural question, which is, okay, what are some good ways to actually do that? All right, everyone, thank you so much for these questions. I mentioned earlier that there was going to be an upvote mechanism. Apparently I lied. I didn't realize that that was the case. So I'm going to pick a winner here for the signed book. I really appreciate the question that I had answered from Atmiya Jadwani. So Atmiyya, congratulations. You get a signed copy of the book. I will get in touch with you over email and just get your shipping info so that I can send you send you a signed copy of my book. Thank you for being here. Thank you for that question. Thank you everybody for being here as well and for these great questions. Please get in touch with me if you have more questions. Connect with me on LinkedIn or Twitter. I'm going to look at my social media feed after this and look for the most liked, you know, tweet or screenshot or Instagram post or LinkedIn post or whatever. And I'll get in touch with the other winner for the other signed copy of the book. Last thing, you all will get a recording of this. You'll get an email with a recording of this once it's uploaded so that you can reference it. Hope this was helpful. I hope it aids in your design system planning. If it, if it does or if it did, send me a message. I'd love to hear how it affects the stuff that you, that you are doing and the stuff that you're doing for next year. I'd love, I'd love to hear that kind of stuff. So please do drop me a line. Thanks everybody. Have a good rest of your Wednesday and a good rest of the week and hopefully we will see each other soon. Maybe on another webinar. Let me know if you like it. We'll do more. Thanks, y'. All. See you soon.