 In this episode, you're going to learn how you can use design systems to deliver better services in less time and with less resources. Here's the guest for this episode. Let the show begin. Hi Superfriends, I'm Dan Maul and this is the Service Design Show Episode 116. Hi I'm Marc and welcome to the Service Design Show. My goal with this show is to empower you with the most effective skills and strategies so you can design services that win the hearts of people and business. The guest in this episode is Dan Maul and if that name sounds familiar it might very well be because he was the guest in episode 107 while we talked about how to sell design. Great episode and I really recommend you watch that if you haven't done so already. In the preparation for that episode I learned that Dan has a big passion next to explaining how to sell design and that is design systems. That's actually the core offering of his agency called Super Friendly. They're all about design systems. If you haven't heard about design systems yet don't worry I'm not an expert either but luckily Dan is. So in this episode we're going to explore what our design systems, why should you care, what value do they bring and how do you actually create them. So at the end of this episode you'll know how design systems can make your life as a service designer much easier. If you're new to this channel welcome and I'd love for you to subscribe because we bring a new video at least once a week that helps you to level up your service design skills. Now if you haven't done so already click that subscribe button and that bell icon to be notified when new videos come out. That's all for the intro and now let's quickly jump into the awesome chat with Dan Maul. Welcome back to the show Dan. Thank you, thank you for having me. It's good to be back. And a happy Christmas. Yeah, same to you. Although over here we say Merry Christmas. I don't know why it's different but Merry Christmas and a Happy New Year. Exactly. Yeah. Yeah. And also to everybody who's listening and watching of course depending on when you're listening and watching this. Then I have to congratulate you on setting a new record. What's that? What record? What record? You're reappearing on the service design show in the fastest way. Any guest has done before. There were also a guest on episode 107. So that's nine episodes ago. Congratulations on making a reappearing. Great. I feel like I'm going to go, I'm going to also make the fastest record of people getting sick of me the fastest too. So we'll see. I'm not sure about that but the last episode was all about sales and selling design. And you recommended a great book there that I immediately picked up and read. The Challenges Sale. Really recommend that episode but in preparation towards that episode we talked about one of your other passions and that's what we're going to address in this episode. It's going to be a lot of fun. I think we can learn a lot. We're not going to do a 60 second quick intro because we've done it already in the previous episode and the thing we're going to discuss today is design systems. Now the first question I have already for you then is, is it going to be service design systems or is it going to be design systems for services? Yeah, all of those things I think and probably more. Sometimes it's design systems as a service. It's a popular concept. It's gaining traction. I think we can talk about all the versions of combining the word service and design and system. Awesome. Looking forward to that. So I have seen the concept of design systems coming by. I think it's hard to ignore when you're in the design space but it's not something that has I think found its way into the field of service design. So maybe for the people who are listening, including myself, could you give like a brief introduction in what are or what is a design system? Yeah, absolutely. And if you don't know what design systems are, you're not alone. And in fact, people who work on design systems also even argue about the definition of it anyway. So much so that on our site, at the super friendly site, we have a glossary. So we have like, here's a glossary of terms and we define what the terms mean. And for our design system definition, we even have multiple definitions that other people have said. So the definition that we use on design systems is that it's the smallest set of components and guidelines that your organization needs to make digital products consistently, efficiently and quickly. Right? So there's a lot of concepts packed into that so it's not the simplest form either. And then there are lots of other definitions around that but that's the place that we generally start. It's basically the smallest set of things that you need to make stuff. To make stuff. Okay? We're going to dive very deep into that. Now then, when I was preparing my notes for this episode, I'm always curious, when did you get excited about design systems? What triggered it for you? What let you down this path? I think there's two answers to that. One is that I think as a designer, you know, I went to design schools. I was trained as a designer. And I think designers are generally trained to think in systems anyway. We don't call them design systems but you learn about systems. You learn about typographic systems and you learn about systems of interaction. And you learn about systematizing things, whether that's a brand or that's a design language or things like that. So I think as a designer, I think every designer has, or at least formally trained designer has some affinity towards systems. And then the second version of the answer is that probably five to 10 years ago, somewhere in there, the term design systems in digital has become a more popular term that means a very specific thing. And so we've always kind of done that work. We just didn't really call it design systems. It used to be called, you know, style guide development or style guide driven development or, you know, component libraries are kind of a part of that. And like a lot of people in digital have been making these things for a long time. And it's not until maybe in five years ago or so that we started to really officialize that as a discipline. And now there's conferences and a Slack channel and like all sorts of stuff around the idea of design systems. And before people start tuning out of this episode, you promised me that design systems are applicable beyond digital interfaces. They are applicable to services, right? So we're going to dive into that because I've heard the term digital coming by already a few times in this, this chat. We talked about stuff, but we're also going to look at design systems for intangible stuff. Absolutely. What do people use design systems for? Like you already mentioned that we had them, they just didn't have a label. What is the common, common use case for design systems? Yeah, so let's take the word design out of it for a sec. Like, what do people use systems for? It's mostly for things that are repeated, that you want to have some sort of consistency or efficiency with. So that could be, you know, in digital, that means maybe our interface is going to be, you know, we want it to be more consistent. But if you take the digital part out of that, you know, for a service, you know, you want your onboarding to be consistent, right? And that's the thing that applies to all different kinds of companies, whether digital or not. And so I think that the idea of systems is we do a thing over and over again. How can we not reinvent the wheel every time and instead actually have a process for doing this and have a way that we do this. So I think design systems in general follow suit because a design system is a system. So design system really is a way to do design systematically, you know, or a way to do, if you're talking about service design, a way to do service design systematically or a way to do any kind of design in a very intentional way. And when you say do design systematically, are we talking about the design, doing the design process systematically or is it something else? It's all of those things, right? And that's why design systems are such a far reaching thing. And I'll use the context of a digital company, mostly because it's what I know well, but I'll talk about other things too. So in terms of a digital company, if you're making lots of digital products for people to use, you don't want to do all of those things one by one, each thing individually starting from scratch every single time. It's a waste of time. It's inefficient. It's inconsistent. And so, you know, that's the reason that I think lots of people want systems is to be able to do better things with their time than do the same things over and over again. Whether that's designing an interface or it's delivering a particular service or it's having a process for, I think that that's kind of the impetus for all of it. And like you said, I think we're quite familiar already with, and we're going to talk about that with standardizing things, whether it's in a brand manual or style guide or we want to describe in whichever way we can, the things that we sort of agreed upon and we can reuse so that we can get to the real stuff faster, right? That's absolutely. And that's so in the context of a company, you want to be consistent about the design that you're outputting. You want to be consistent about the experience that you're outputting. You want to be consistent about maybe the code that you write if you're a digital company. You want to be consistent about the language that you use, whether or not you're a digital. So all of those things can benefit from consistency and benefit from efficiency, which is why a design system usually is not just relegated to, oh, that's just for the designers or that's just for the engineers or that's just for the UX folk. It's actually for everybody. It's for copywriters. It's for product managers. It's for managers. It's for directors. It's for everyone. And that's why a design system is such an important thing for an organization. And that's also why it's so difficult to implement very well is because it's not just for one slice of an organization or a company. It's for everyone to be able to use collectively. And how should we perceive a design system? Like, we can understand what our style guide maybe is. I see a PowerPoint presentation with some guidelines on how to use the logo, which call us, which backdrops. That's very tied to the specific medium we're using, 2D or print or... But how does this work for design systems? Like, what are they? How do we make them tangible? Yeah, so specifically you talking about design systems in a digital context. A design system has in it a library. And that's usually a library of components both in a design medium like UI kits and applications like Sketch or Figma or Photoshop or things like that. And also generally have code components too. So some version of coded components, whether that's a React library or that's HTML and CSS or whatever languages those are. And so you can think about something like Bootstrap is a component library and can be used as a design system. A lot of people are familiar with the idea of material design, which is Google's design system that if you open up the Gmail app or the Google search app or whether it's on your phone or on a desktop computer or wherever it is, all of those, they look consistent, at least they do now. A lot of them do now over the last couple of years. And that's because Google has been implementing that design system in all of their products so that whether you use Gmail or you're using Maps, you know where the search bar is going to be. You know where the action button is going to be. All of those things are consistent so that you can set expectations well with users and with people. Yeah, so visual consistency is one. And the other thing you already also touched upon is like, which is probably much harder to achieve, experience consistency. Like that they feel the same that you feel like you're using a Google product. Oh, exactly right. And I think it's important that you brought that up too is like, it doesn't necessarily mean that they have to be consistent more than they have to be cohesive. So there's a guy named Danny Banks who wrote great articles and he works at Amazon. And he talks a lot about how these experiences should be cohesive across medium, not necessarily consistent. You know, so an example is that we worked with United Airlines last year to help them with the design system and create a design system for them. And one of the things that we realized was a button when you check into the kiosk at the airport is not the same button that you use on your mobile phone or on the desktop. When you log in, it shouldn't be, you know, the heuristics are different. The form factors are different. All of those things are different, but it should feel cohesive still. It should feel like it's the same airline, you know, that you're checking into, even though we're not using the exact same thing. So consistency across platform or across medium isn't as important, I think as as cohesiveness. Yeah, I can imagine that a lot of people, again, who are listening still see design systems very much tied to digital interfaces. Maybe it's interesting if we dive into a very simple and concrete example and try to unravel how a design system could work in a very physical service environment. Are you up for that? Cool. Yeah, let's do it. You have an example in mind? Yeah, sure. So one of the classic service examples is maybe a restaurant. Like there is and these days we are unfortunately don't get the opportunity to visit them as much as we'd like. But I can imagine that it would be fun to explore a design system within a restaurant context. Now, maybe the first question to start with then is what would be the incentive for somebody who's running a restaurant to explore design systems? Is it what you already mentioned about not repeating stuff that you're already doing? I think that's the first place, right? The first place where a design system becomes valuable is a lot of people realize that they just have a lot of waste in their companies, whether that's a small restaurant or a giant enterprise. It's just a lot of waste and you waste things when you reinvent the wheel. You waste things when you don't have process. So process, the reason that most companies have process is to make themselves more efficient to reduce waste most of the time. So for a restaurant, why would you want any sort of system like that? Well, think about if you had to fulfill orders without a system. You didn't have a front of house and back of house. You didn't have a ticketing system. It would be bananas. You don't know what order to make. Some customer is waiting for 45 minutes while the person who just walks in and gets their food, like you would have unhappy customers. You would be a mess in the back of house. And so a lot of just system management in general is about getting organized so that you know what you're doing and you can be calm and you can be composed and you can provide a good service and a good experience for your customers. So I think a lot of the impetus for design systems initially is just like, how do we do this better? How do we not pull our hair out every time we're trying to do something? And so a system applies to everything from how you fulfill orders all the way to how you speak to your customers. And then and then it helps really what the point of design systems is that it helps with scale. So if you're the only person in your restaurant, you are the chef, you are the server, you're the host, you know, that's one thing. But then when you hire your first five employees, well, they have to talk like you. You know, they have to serve like you. They have to order, you know, fulfill orders like you. And I think a lot of that is about scale, right? So if you don't have those processes in place when you're smaller, imagine now you expand to 10 chains and you have, you know, 100 employees for each restaurant, it's going to be a disaster. Yeah. And and you said they have to speak like you. And that's not not so much because, for instance, you would like as a restaurant owner for your employees to speak as you know, it's because you want to deliver that consistency and that cohesiveness in terms of experience for your customers, right? And unless non-consistency and non-coheat cohesiveness is part of your brand experience, but yeah, I don't know any brand that can that can market that chaos as a selling point. And in fact, the other way around, wait, what was did you give an example of that? Well, no, I was thinking chaos as a brand value. Right. Yeah. I don't know who can market that very well. But but the opposite is true is very true, which is that a lot of a lot of brands do market themselves on their consistency, right? Like that's that's the whole point of franchises, you know, whether you agree with them or not, you know that if you go to McDonald's in Berlin, it's that it's the same burger that you're going to get. If you go to McDonald's in New York, you know, it's the same that consistency, that brand consistency is important. And I think the same thing is true, you know, for every brand. And in fact, a lot of brands have built their brand on consistency, have built their brand on the fact that no matter where you interact with us, this is the tone or this is the style or this is the thing that you're going to get so that you know what to expect from us. And I think that's a really good kind of customer experience. Tenant is that when people know what they can expect from you, then you're in a really good place. Let's let's let's make it even more tangible. So we understand why we would like to have a design system as a restaurant. Now, how would you start? Let's say I approach you as a client and you say, yes, sure, no problem, we can help you with that. What would we do in the first few steps? All right, so I'm going to I'm going to start with digital and we'll go to go to kind of a non digital example after that. So in digital, the way that most teams think that they started design system is they go, you know, we need a set of standard things that we can just reuse over and over again. And so what they do is they go, well, let's just make those things. So in digital, they go and they make websites that have the pieces right headers, footers, cards, tables and things like that. And then they try to use them and then it doesn't work because and well, I'll tell you what I'll tell you why why the because they end up with a design system graveyard is the thing that I call it where they where most organizations have tried to start abstractly and then create something and then it just doesn't work or it doesn't take and people don't use it. So instead, what we recommend to them is don't worry about making the thing first, let it be emergent. So instead, make a product, you know, if you're if you're a financial advising company, the first thing you can make is maybe a dashboard for your customers to see their financial activity. Don't worry about the system part yet. And then after you're done making that thing, then you look at it and go, how do we extract all of the parts from that? We call that piloting a design system. So you think of it like a TV pilot when when TV shows pitch a network, they pitch a pilot, right? They don't just say, Oh, we're thinking about a show that has these characters and these are the situation. No, what they do is they film one episode and then you can see, Oh, that's how it actually works. So same thing is true in creating a digital design system and also a non digital design system too is rather than if you're a restaurant, you know, what I think a lot of restaurants will do is they go, Oh, let's let's write an employee handbook, you know, and we'll define all the things that people should do as employees. That doesn't work very well. Instead, see how employees are actually treating customers and then write the handbook out of that. Go, Oh, actually, we see success when all of our servers, you know, recommend a dessert to an, you know, to a customer. And so that becomes a thing that is emergent, that becomes part of your handbook is go, All right, now in our handbook, we'll say, These are things that we're already doing. Let's make that consistent. Now let's make that a thing that everybody should do in a way that that lets us scale. So those are the first steps as a little bit long winded, but those are the first steps that I generally recommend is see what you're already doing that is successful and then figure out how to scale that thing rather than trying to find it from scratch and then hoping that people will do that thing. That that tends to be a less successful way to do it. Yeah, starting from the concrete rather than from the abstract. Now, I can, I would be curious in a in a restaurant, if we start looking for patterns, what would be the things that we would be looking for? So, yeah. Yeah, it's good. I have this book, I was preparing for this, this book here by Louise Down, Good Services. You mean, you mean this one? Hey, that one right there. That's the exact one. So one, one thing that I love about this book is how she talks about, you know, the the 15, I think it's 15 common patterns, common service patterns. And so, you know, every organization has their own patterns or some some column principles, you know, that kind that apply across the board. So if I just leaf through the table of contents here, you know, one of the principles is be consistent throughout principle number nine, you know, one of the principles is set a user's expectations of the service. One of the principles is work in a way that is familiar. Right. These are things that apply to just about any business, any service business. So I think all of those things are are a good place to start. Those are sort of like universal principles of like, if you're on a restaurant, you want to be consistent. You don't like, you don't want to, you know, change your tone of voice every day, you know, because people don't know what to expect. You don't want to be a diner one day and then you switch to only high-end food the next day. People are going to be very confused about it. So know what you serve and know what you offer. So I think that's, that's maybe a place to start is, you know, what are the patterns that, what are the universal patterns that good service businesses can use? And then what are the ones that are actually custom to your type of business, right? Restaurants have probably different service patterns than say, you know, pharmaceutical companies or something like that. Um, and then even more specific than that, what are the things about your particular brand that are service patterns, you know, Virgin as a brand has very different service patterns than, you know, American Airlines as a brand, right? And those are, those are very different things. So I think those are the, if you think about it as like a hierarchy of needs of patterns, there's like, what are all the universal ones and then what are the ones that apply to your industry, you know, and then what are the ones that apply to your specific brand in particular? Would a question, uh, like what, how do, how do customers actually recognize that they are dealing it? Yeah, that they are dealing with us, not a competitor. And I'm not talking about brand here per se, but in the actual service delivery. So you step into this restaurant or this, this coffee bar, how do you actually know, how do you actually recognize in the service delivery that it's specific to this specific restaurant? Right? Would that be a question? Valid question? Yeah, yeah, absolutely. Um, I think some of that has to do with brand, but I think some of it has to do with like, who cares? You know, like I think that a brand spend a lot of time thinking about how people can think about them as Starbucks or them as a coffee shop or them like, and I think that that's the second question. Maybe I think the first question is how do we provide a good experience, you know, period. Um, and then I think people will start to over time consistency in the experience will start to make them go, actually, I'm going to keep going back to that coffee shop because they always know my order, you know, like every day they already have my order ready for me because I go in at the same day every time. It reminds me of a story of the Ritz Carlton. And at the Ritz Carlton, I don't know if this is true or not, or if this is a fiction, but at the Ritz Carlton hotel, they have a policy that every employee gets to spend something like they have $200 or $250 that they get to spend on every guest. So for example, if you check into the hotel and you forget your shoes, they'll just go and buy you shoes, you know, you can say like, Oh, I forgot my Cole Hans at home and, you know, I'm a size nine, they'll go buy your shoes. And that's just part of the service that they deliver. Now, if that only happened once, you could even, you could still make the point that like, that, all right, maybe I'll go back there one more time. But if that happens every time I stay there, then I'm going to be a customer for life, even if it's higher price than their competitors. But that consistency of delivering that is a thing that then I start to associate with their brand, you know, and I think that like from a brand standpoint, I don't mean visual brand. I mean gut feeling, feeling that if you have the experience of that. Yeah, yeah, yeah. Yeah. And we might get confused here that it's about sort of attracting customers. But like you, like you already mentioned, design systems primarily are interested in increasing efficiency, doing things more streamlined so that you can actually focus your efforts on the things that require creativity and other things. Right. So that's right. My friend, Josh Clark, I set this article all the time. He wrote this article called the most exciting design systems are boring. And he talks about how the point of a good, a good design system or the point of good patterns in general is that you don't have to think about those things anymore. Right. You don't have to think about them every single time because they're ingrained because they're already taken care of. And now that you have all this extra time and all this extra mind space. Now what do you do with that? Now you can figure out how to go above and beyond for your customers, how to create customer value because you're not worried about the little things that normally occupy your time. How do we fulfill tickets? Well, that's taken care of now. So now what do you do? Oh, now we can figure out how to make our customers even happier in that way. You mentioned that design systems consist of two things. If I remember correctly, like the components and the patterns, the flow, the interaction. Right. And I can imagine that totally in, again, a digital setting where you have the visual components, the buttons, and then you how the screens flow through a checkout page or something like that. Let's take this to our restaurant example. What would be the components or what would be the patterns here? Yeah. So a component in a restaurant might be something like a fork. Right. Like that's like some restaurants have different forks for every table, but most restaurants don't because because that's not that becomes hard to manage then. Right. It becomes hard to order. It becomes hard to have the equipment. It becomes hard to reinforce your brand with the customer. So there's a lot of problems that come from the inconsistency. So instead, what do most restaurants do? They order one type of fork from a supplier. They know they can get it in bulk, you know, and they know how to wash it. They know how to how to use it. They know what to set. You know, they know all of those things come with the consistency. So something as small as a fork or a plate or the table or chairs or, you know, all of those things are the components. And then the patterns are things that that flow that use the components in a flow. So an example of that might be, you know, dessert is a flow that's different than the main course flow or that's different than an appetizer flow. And so, you know, those are different ways that a server knows how to set a plate down or how to introduce it or how to order it or how to fulfill it. So each of those things have their own components. A salad fork is different than the fork that you, you know, then you then you eat a dish with a main dish with a steak knife is very different than a butter knife, you know. And so each of those components support different flows and they can be they can be agnostic cross flows, but each of those flows and patterns, I think, use those components. So those are both an important part of a restaurant service. You can't do it without the components. You can't have a service without utensils. You also can't have a service without knowing we're going to have three courses or we're going to have eight courses or, you know, whatever the the actual patterns become makes complete sense. Now, one question I can imagine people would have is doesn't this take out all the doesn't it take out the human aspect out of in this case, delivering a service? What would be your answer to that? The answer is that if you do it poorly, then yes. But if you do it well, right, if you if you see it as an enabler. And so, you know, one of the things that I talk about is there's two main things in a design system, efficiency and consistency. But there's a third thing that no one really talks about. And I think that the third thing is relief. So it should provide relief to the people using or in the system to go, Oh, I don't have to take care of that. So as an example, my wife and I went out to a restaurant a couple of weeks ago because here in Philadelphia, they're shutting everything down because of covid and so we kind of went to a restaurant as like, OK, let's do last restaurant for a while. And then we know we're not going to we'll do take out instead. So we went to a restaurant and the system we went to a nice restaurant and the system they had was down. They had it great. And so what that allowed the server to do is because he knew exactly what he was doing, it allowed him to talk to us more. And we actually had a really good conversation with him about how when the restaurants were shut down in the last kind of heavy period of covid here, he and his girlfriend went on a road trip around the U.S. And we talked to him for maybe 20 minutes, you know about that because he wasn't worried about taking our orders so much. I mean, he did all of those things very well already because he knew what he was doing. So it's not that he ignored those things. He knew what he was doing there. He didn't have to reinvent the wheel. He knew the system of how to take orders, how to fulfill them, how to send them back to the kitchen. And then it came out and talked to us and we had a really great conversation with him, which is the experience that we wanted at that dinner was to be able to to, you know, hang out with each other and also to be able to meet people and talk to them about their interesting stories. Like those are the things that made it a great dinner. And so overall it made for a good experience for us because all the boring stuff was taken care of. And then we could talk about this thing that was totally not planned, but was just creativity happening in the moment between all of us. And it freed him in this case to make a difference in the way sort of a human only can. Like delivering your meal in the right way, that's sort of the replaceable part. Like if you teach that to, you can teach that to anyone. Having that conversation is the thing that's not replaceable and that's unique and that's providing the experience. Is there, have you found a threshold in as in when does it become to standardized versus when does it become to rigid versus when is there still too much flexibility or is that something that you need to that it needs to needs to emerge as well? I think I think it is a little bit emergent, but I think that there is some patterns in it as well. So when it becomes too rigid is when you're systematizing things that don't need to be systematized. Right. So from a from a digital context, I'll start there. One of the things that we're seeing with companies that have mature design systems that are in version four or version five of their design systems is that they're actually taking things out of it. They're not continuing to add to it. Right. So companies that have 120 components and, you know, 12 patterns in their design system are now for the next version going, actually, you know what, we're going to reduce it down to 60 instead. And we're going to support those really well. So I think that's where it becomes overly rigid is when it gets to a point where you're systematizing things that don't need to be systematized. Right. If if you were, for example, at a restaurant, if you gave a server a script that they that only they can they can say that script and they can't say anything else to a customer. Well, that makes it cold then and that makes the experience not good for the customer. You can systematize that. It's possible. It's not a good idea to do that, though, you know, because you're removing that warm that you're the freedom that people get from having a system. You're actually taking that freedom away. So I love how you said the freedom. And so I think a design system has to stop where it gives people freedom. You know, once it gives people freedom back, then you can take advantage of that freedom. But if it then goes farther than that, then it starts to remove that freedom again. Right. So there's a sweet spot right in the middle there where you're you're making the system to help people to deliver better experiences. And then if you go too far from there, then you get, you know, a restaurant full of robots, which which there are, you know, there are. And those are those are gimmicks and those are fun and cool. But nobody wants to go there every time because it's because they missed the human experience, I think. So the things that you can automate, absolutely automate. But there are things that you can't automate. And even if you even if you can, there are things that you shouldn't automate. And I think that's the point that that everyone has to kind of look out for. How would you? How would you, again, capture a design system in the context of a service? Is it is it a document? Is it a movie? Is it what would it be in the in in our in a restaurant? Yeah, sometimes it's conversation, right? So I think a lot of a lot of design system stuff is about culture, right? It's about creating culture and sometimes you document culture and things like a handbook or in, you know, whatever, sometimes your corporate bylaws, you know, sometimes in reference material or stock guides or things like that. But I think a lot of it has to be lived because if it's not lived, you know, how many times are people going to reference the handbook? You know, like exactly. Yeah. So so if that becomes a dead artifact that it doesn't matter, one of my favorite restaurant examples is the the what are they called Union Square Union Square Hospital something like that. It's you don't have to me. No, I think I think it's they started in New York. I think it's spreading around the US, but that's they had their their big flagship restaurant is Shake Shack. That's probably their most popular one that would make really great burgers. And they have a couple of kind of like taverns and restaurants and things like that. It started by a guy named Danny Meyer. And one of the things that he realized when he had his first restaurant and then was expanding to two was that people were doing the things that they would do because he was hiring servers who worked at other restaurants. They were doing things that they would do at other restaurants and he had to constantly remind them. No, no, no, that's not what we do here. That's not what we do here. And so and a lot of that just came from conversation. So as an example, you know, somebody would would be unhappy with their dish. A customer would be unhappy with their dish and they would return it back to the kitchen and the servers would be upset about that because that they were trained to be upset about that at at the other restaurants and he had to train them that that's not how we do things here. The way that we do things here is instead we do this and that he had to reinforce that every single time and then eventually over reinforcing and reinforcing and reinforcing. Then it became part of the culture, then it became part of, you know, we treat customers with with delight with jokes sometimes. So, you know, they had a customer who would order the same dish every time they came in and one time it was actually it was not good. And so they sent it back. And so the next time that customer came in and they knew that that customer was coming in because they have made a reservation, they actually set. I think they played a joke on them where they set the dish in front of them before they were there done really poorly. And then, you know, so they were establishing some rapport, whether or not that tone is something that, you know, that gravity that you gravitate towards is up in the air. But I think that experience is something where they're starting to make a connection with the customer and they weren't encouraged to do that at previous restaurants. And so the owner of this restaurant said, well, this is the way that I want us to do things. And he had to kind of reinforce that message over and over. And then eventually that became part of the culture that now customers know that brand for doing. So design system in many cases is a lived thing. Has to be an yeah, experiential thing. Is there I was making some notes here. Is there a benefit towards using the word systems versus principles or guidelines or patterns? Like, is there something intrinsic in in systems that people are adopting it as much as they are? I think it depends on the on the context. So I think that there are as an example, we worked with Exxon Mobile a couple of years ago and we helped them with their design systems. And one of the things that we talk about when we talk about design systems is we talk about how it helps designers and how it helps engineers. When we use the word engineers, they were very allergic to that to that word. And we're like, well, why are you so allergic to that word? And they were like, well, because we have engineers here and engineers aren't people who write code. Engineers are people who go out and work on oil rigs. All right. So that word meant something different in their context that we had to stop using that word because it was totally making them think over there when they should have been thinking over here. And so the word system same thing, you know, some people have an allergic reaction to the word system either because they don't know what it means or because it has a specific meaning already. So I think it depends on the context where that word means mean something. In general, what we find is that the word system doesn't really mean a lot to people. So it so we don't use it a lot. And in fact, we tell a lot of a lot of our team members don't use the word design system, because it tends to be a distraction to what people actually care about, you know, what people actually care about in a digital organization is, you know, a rebrand or a replatforming or content migrations or things like that. And when you say design system, all they hear is just not that thing. You know, and so in the context of digital, you know, system means a particular thing that sometimes can be too distracting. And in the context of non digital in the context of, you know, just any general service system might need something very specific, whereas the word principles actually might not. So maybe you have the ability to fill in the definition of that, if it's a word that people don't know as much. Yeah, it's I think it's with a lot of language in the design community. It can distract from the actual thing you're trying to do. And if your client cares about getting great services out the door faster, then that's the thing you need to talk about. And that you're going to create a design system in order to help them to achieve that. Like, you might sometimes just want to keep that within your team. Now, I'm curious, like, you mentioned that a design system has to be used by everybody. And whose job is it then in the end to come up with the design systems to capture the data, the inside, the patterns that emerge? Someone's. I don't think it's important who that someone is, but I do think it's important that there is a someone, because I think the answer can't be, oh, it's everyone's job, because that's just a fancy way of saying it's nobody's job, right? So I think it's got to be someone's job. And one of the things that we recommend for organizations that have design systems is that you eventually have a team to, to staff it and support it. So one of the one of the big mantras of design systems in digital is that a design system is a product. And so it has to be treated like a product. So if you think about, you know, what's a product you use? Harvest or, you know, your invoicing tool or your accounting software, what, how do you sustain that product? Well, the product has to have designers on it. It has to have engineers on it. It has to have UX people. It has to have a budget. It has to have a roadmap. It has to like all of the things. If you think about you, this a product that you use where that's digital or physical care goes especially a digital care goes into constantly maintaining that, you know, software as a service design systems are are sometimes a software as a service. And so it has to be sustained that way, you know, and it can't be like, Oh, you know, we'll get to it when we get to it. You know, imagine if the software that you used every day was like, Oh, we'll get to it when we get to it. You know, people flip out when Gmail changes something, people flip out when, you know, when, when their email software like a design system is the same thing. So it's got to be sustained by a particular team whose job it is to sustain that actual product that that that everyone is using. And it's really simple in the end, because it's an asset. It's a it's an asset to an organization. It helps you. It has a specific goal on that goal is to become more efficient and then have time to do to do other stuff. So it's not I can imagine that people see design systems as an cost or are afraid of the upfront investment. But that way of thinking is very short when you decide it, when you don't consider that design systems should actually help you to run more efficiently, consistently, all that kind of thing. So totally, right? Yep. What are some of the reasons that you've seen? Give me top three reasons why design systems aren't adopted. Oh, OK, so market fit, right? That's that's one that folks that service design folks will be familiar with. I think it's like market fit. You can make a product. But if it doesn't fit your market, people won't use it. Right. And so design systems are the same way if it's a it's a product. And and the way that they generally start is that people go, oh, let's just make a bunch of things for other people to use. And then they kind of cross their fingers and hope that somebody will use it. That's not the way that you assess market fit. For any product, the way that you assess market fit is you probably are doing customer interviews before you have a product. You're probably defining a feature set that you know the customers are going to use. And then you're going to release a version one or an alpha or beta or something like that that then serves those particular needs. Right. And design systems generally don't start that way. They start as a side project. So thing number one is that they don't get adopted because they don't have the things in it that people actually need to use. You know, so the a lot of ways that we start is we start with interviews. We start by going like if you had, you know, what are your top three components that would make your life easier? And they go, oh, if we had a, you know, drop down custom drop downs and if we had this and if we had that, you know, that would be great. And we go, cool, we'll go work on those things first. And then you, and then that's when you get market fit. So that's, that's the number one reason is that design systems don't get adopted. Is that the second one is usually a little bit farther along where some folks are using a design system, but it's still treated like a side project. You know, so it's like, you know, it doesn't have funding. There's no dedicated person to work on it. And so it just loses steam after a while. That's one side of the coin. There's, there's a kind of a part B to that. The other side of the coin is it actually is too in demand where everyone's like, this is great. This is awesome. We need more out of it. And then the one person who is in charge of working on it is like, oh, I'm too busy to work on this too. So they just get inundated with the request and then they can't fulfill all of them. So people go, ah, we'll just make our own. We'll just use our own thing or we'll go find, we'll use material design, you know, or something like that. So, you know, two sides of the same coin. It's either underfunded and understaffed or it's or, or there's too much demand, you know, for that, for that person to be able to keep up with. So those are, those are the common ones. And then, and then related to that one, I guess this is kind of a third one is lack of funding from the top or lack of maybe not, maybe not financial funding, but lack of buy-in. Is it buy-in? Thank you. Yeah, exactly. Yeah. You know, if your leadership doesn't care about it, if your leadership doesn't think it's a tool that the rest of the organization could benefit from, they're going to go look to other things. And so it makes it hard for an organization to adopt that when your leadership are like, ah, we don't care about that actual thing. So definitely buy-in is one of the sticking points of a design system. Yeah. And I was thinking like, how do you get buy-in for such a thing? And, ah, it's, I'm curious to hear your experience, but I think I would look at inefficiencies in your existing service offering or seeing opportunities to do things more efficiently and then presenting that almost as a business case and say, hey, look, we have two different service offerings over here. Um, we are doing things differently. Maybe if we look at the things that overlap, we could increase the quality in, do them fast and do them cheaper, something like that. Would that be a viable strategy? Yes, but I think there's a, there's a nuance of that because, and I love the way that you described it. What most people do is they go, they have the plan for a design system and then they go, ooh, it would be great if we had this. Let's go get buy-in for it. And so what they do is they put together their, you know, their talking points, their ROI, their metrics, their all that stuff and they go and pitch to leadership if we had something like this, it would save us, you know, 10% of our costs on projects or 20% and leadership goes, it would save us that. Cool. Like, we have other things that we could invest that money in anyway. And it's because you don't have anything tangible to show, right? You have the hope of a plan. It's like asking somebody like, do you want to lose weight? And they're like, yeah. And they're like, cool, you should go to the gym. And they're like, cool, I know I should. And then that's it, right? Like, there's nothing actually tangible about it. So instead, what we suggest is that this is the pilot thing. It's like, use it on one product. You know, do a design system without the funding, without the buy-in, without the investment, without do it under the radar. Do it as a weekend project. Like, do it. And then what you can do is you can go to leadership and you can say, we already saved 10% of that. We finished this project six weeks ahead of schedule. Would you like us to finish other projects six weeks ahead of schedule? And they will say, yes, I do, but you already have one use case. You already have a pilot. You already have one episode of film so that you can show it off and go, this is what the rest of the show is going to look like. And so I think that that's why I like how you phrase that is you already have to have the service in order to sell it. You can't sell the vaporware, right? You can't sell the like, oh, if we had this thing, it would be great because everyone, no one would disagree with that. Everybody would be like, yeah, that would be great. We're not going to do it though, but it would be great. And so instead, if you say, we're already doing this, now we just need the money to sustain it. We need the investment. We need the buy-in to sustain it. That's a much easier thing for people to buy. I had a different post over here which said no prototype, no meeting. And I think that goes in many scenarios, including this one. And then it's so much easier to, you don't actually have to sell anything. You just invite somebody to continue with this initiative, which has already proven itself. Absolutely. Is there a question that I forgot to ask about the design systems that I should have asked? Ooh. Hmm. One of the ones that we get pretty often is, how do I know when to stop selling? So like, I think a lot of folks think, well, I need to get buy-in once. Once we get buy-in, then we got buy-in. And so, I don't know exactly what the question is. I don't know what the phrasing is, but it's something in the effect of like, what happens after I'm done getting buy-in? Right? Something like that. And it's kind of a rhetorical question. The answer is, you're not ever done getting buy-in. You have to constantly, again, back to the product thing. You know, that's like saying, oh, all we have to do is pitch the product once, and then people will buy it for the rest of eternity. It's like, no, you have to continually sell your product. You have to show it to new customers. You have to continue to keep your customers by investing in the product, by making new features, by continuing to solve problems for them. So I think the evangelism never stops. You know, I think that's a lot of the answer is like, you have to constantly do that, and that's partially why the design system needs a team, needs a product owner, needs a champion to be able to evangelize the benefits of it to both the people who already use it, as well as to new people. Hmm, makes sense. I would love to hear from the listeners and viewers of the show, like what are their thoughts on using the concept of a design system onto service delivery? Because I think that's the main focus. Have you tried it? Have you done it? What are your experiences? What are the pitfalls that we haven't discussed? Why wouldn't this work in a service context? Leave a comment. We'd love to know. Then I can imagine that some people got excited through this conversation. What are some recommended resources to continue learning about this topic? Yeah, well, shameless plug. It just released a course about design systems to cover a lot of the topics we talked about. Less so about service design, more kind of on the digital front, but it's still kind of high level. It's more for managers and directors. It's called make design systems people want to use because that seems to be the big thing where like lots of people make design systems and doesn't necessarily mean that people are using them. So how do you make one that people want to use? What's the process look like? What does the workflow look like? How do you get buy-in? What do you say? All those things are ones that I covered in the course. So that's just released about a month ago. And I'll share some links to that as well. Yeah, and we'll be in the show notes for sure. Cool. Lots of good books around design systems, too. There's one called Design Systems. It's by Ala Colomatova. It is a wonderful book. There's another one by Jacenia Perez-Cruz called Expressive Design Systems. Both of those are great books. Again, both of those relate to digital. In terms of non-digital things, there's a great book called Thinking in Systems by Danela Meadows. It is wonderful. And it doesn't relate to digital. It just talks about systems in general and why they're important and what things are needed in the system, whether that applies to service delivery or that applies to whatever you're actually doing, what are the connection points and the interconnections that you want to build. So that's a really good one. Those are probably my three or four go-to resources. Awesome. Again, I'll make sure to link all to all the books in the show notes and also to the course. Highly recommended. Then it was an honor having you on the show, back on the show. I'm curious what episode number three will bring because we need to finish the trilogy at some point. Yeah, once again, thank you for being on. Merry Christmas and talk to you soon. Thanks, Mark. Have you used Design Systems in a service context? Let us know. What challenges did you encounter? What worked really well? We'd love to know. So leave a comment down below and let's continue the conversation over there. If you know somebody who needs to hear this conversation, grab the link and share that with them. That way you'll help that person to learn something about Design Systems and you'll help me to invite more inspiring guests like them here on the show for you. If you want to learn more about how to design services that win the hearts of people and business, check out this next video because we're going to continue over there. See you.