Design Systems at Scale // Episode 2: Selling the Value of Your Design System

A design system should bear the burden of the boring so that designers and developers don't have to. And what I mean by that is there are a whole set of common scenarios that any given company will solve over and over again for their products. Let's solve them once and steadily improve them, rather than constantly invent them over and over again. And to do that, we need to bring those solutions into one place where they're available to all and create a repository of institutional knowledge for the company and its product organization.

There's so many different facets and avenues to kick off a design system initiative that it can almost become paralyzing. Right? Where do we start? Where do we put this stuff?

Building a design system is complicated. And as difficult as that can be, sometimes it seems like the hardest thing is just getting the project started, getting everybody on board with the effort, with the investment. How do you sort of sell a design system project within an organization and get it going?

Yep, there's a bunch of levels to it, right. So a lot of it is where you exist on the org chart and what your job is at the organization. So lots of times we see, you know, designers and developers who aren't management, but that are the, you know, the worker bees, the people working on the products. They see the value of a design system, but maybe their manager doesn't, or maybe their peers don't. So that's kind of one level is if you're a designer or developer, how do you actually convince your peers, how do you convince your managers that a design system is worth it? I think one of the things that maybe applies to all of the different levels of this is that you have to speak the language of the person that you're talking to that you're selling to. So if you're selling to your boss who is in charge of managing design, maybe one of the languages that you have to speak is the language of efficiency, right? To say here's the way that we're not doing things as efficiently as possible, and a design system could be one of the tools that we use to solve that. I know when I was working with the Seventh Adventist Church to help them build a design system, the web manager there, Brent, he did this great exercise that I love referencing. What he did was he printed out every website that they made on these little 3 by 3 inch cards and every website that they made that year. And he printed out, they did a couple of hundred, and then he pasted those onto mounting boards, black mounting boards, and then he brought them into his boss's office, there's about six or seven mounting boards. And he just showed them and he goes, this is how much money we're wasting. And what he was doing was really just kind of showing, like, visually literally showing the pain as like, we could be doing this a lot more efficiently. We're wasting a lot of money. And this is why I need a budget to do a design system. And he walked out of that room with a budget. So I think part of it is, depending on where you are in the organization, you have to speak the language of the person that you're talking to.

When you're also going and looking for funding, it's like when you're getting down to sort of the brass tacks of budget, that's a different consideration than some of the pain that designers and developers feel from doing reuse or seeing inconsistent work across the board. It's a different matter than production. So when you're talking about budget and when you're talking to the people being sort of like, we need a little bit of extra funding for this, it really comes down to how are we going to make more money from this? Or how are we going to save a lot of money from this? And I think that there are some things that some examples out there that you can really point to. We helped a big retailer create their design system, and the before and after of the process that that design system unlocked, as well as having those assets in place, was remarkable. That they now are saying that they are making products 10 times faster with teams a quarter of the size. So they can do enormous amount of work now because they can deploy those extra people onto other projects that otherwise would have languished. When we built ExxonMobil's Unity design system, in the first 10 months, they built 50 new web apps using this system. Just this enormous acceleration. So there's a clear cost savings there. Well, you can take it in one of two ways. Either we can save money, or we can do a lot more with our money. Right? And so that's a big pitch to make when you're sort of going for budget. The other thing is, how can the products we make make more money, you know, do more conversions, get more out of it, or whatever the goal is of the organization. You know, maybe it's not specifically about money, but it's about, you know, sort of convincing people of your cause or whatever the case is, how can we be more effective with our products? And I think that clearly one of the big benefits is improved consistency, improved quality, improved accessibility, that you get by instead of constantly reinventing, is constantly improving on them gradually so that all of your products get those benefits. So I think that those things of sort of like, here's the way that consistency and quality will help us make more money and that efficiency and reuse will help us save money are really big, important levers to pull when talking to executives about this stuff.

I think part of the moral of the story too is not to fall in love with the design system itself. For some people that will be very attractive, but for others, it won't be important at all. And so we come across a lot of teams that fall in love with the idea of a design system. And that's not to say that it's not advantageous, but if you're selling the design system to someone who doesn't care about a design system, it's not going to sell well. So how do you actually talk to them in a way that speaks their language and gets them to go, oh, I really, I've wanted that for a long time and is this thing going to help me get it? Okay, then, now I'm invested in it. Now I'm interested in having it here.

Now that the design system cats out of the bag. I mean, you know, you have material design out there. There's freaking videos being made about design systems. Like, who's making those? I know it's crazy, but at the same time, like, you know, now that it's a thing, people are then selling the thing. So it's like, okay, yeah, we need to build this design system. And what ends up happening is that you get to start getting a lot more pushback because it's not an actual product. Right? It's not an actual sort of thing that you're going to launch to your end users. Right. Your customers get the benefit of having a design system, but all of that stuff happens sort of behind the scenes.

One of the common stories about the say that the jobs to be done framework is that when people are trying to buy a drill, nobody wants a drill. Nobody wants a quarter inch drill. They want a quarter inch hole. And you can take that even further. Nobody wants a quarter inch hole. They want a picture hung on the wall. And I think that oftentimes we forget and the industry forgets because design systems are becoming more popular and more prevalent. We forget that no one needs a design system. They need the thing the design system makes. It'd be like walking in and trying to sell someone on the virtues of Sublime text editor. And it's like, well, no one cares about Sublime Text Editor developers do. But really, people want what you can, the code that you write and the thing that you make. And we've experienced that a lot recently. Where I can think of one example where the design team at this one organization, they really wanted a design system and for good reason, for all the reasons that we're talking about and all the reasons that we know, and they are making a good pitch for this idea and really working on it in a great way. And then what they have to do, the hurdle is, well, now we have to get it on board. So it is like, yeah, but we already kind of have something like. Like that. We have mobile developers that have kind of their own library. We have enterprise architects that have kind of their own. We have some of this stuff already. We don't really need a design system. We're actually going to focus our attention on that product that we need to make right now. And the designers are going, yeah, but the design system will help us make that product. And they're like, no, no, no, we just need to work on the product. And so the story that we should have told to the IT team is, we're going to help you make the product. And if you want to know how, it's this thing called a design system. But really what we're going to do is help you make this product.

You could have all the metrics in the world and other people's case studies and all of that stuff, talk about the different benefits. All of that stuff is great and important, but they could still go, yeah, no, we got bigger fish to fry and stuff like that, like building this one product. And I think that some teams will get deflated and we find ourselves sort of sometimes in that boat where we're like, well, back to the drawing board. But I don't think that that has to be the end of the story. There are many things that individuals can do on a team to arrive at more systematic approaches to design and development. And that all works within the constraints of whatever the current budget is, the current scope of the current project that you're working on. And I think that that's great. And I am a huge fan of asking forgiveness, not permission, because at the end of the day, these teams are tasked with building a product. Right. How that product gets made is inconsequential. Right. So the cool thing is, is that once the launch party happens and everybody's super happy with the result, and the bosses, you know, everyone's thrilled, it's sort of at that moment, you could sort of say, come over here, you know, let me, let me show you what we actually did to sort of create this thing, right? Here's this set of well constructed, robust, flexible, accessible, performant components that we used and reused and reused across the site to sort of build this thing. Higher quality. Once you sort of go through the lens of one product, then you can start to say like, hey, we have something here, maybe we want to build on that. And sort of that can go up to the higher ups where you're not just sort of coming to the people with the money with an idea, but you're coming with a freaking case study of something that actually worked really, really well for the specific product. And go, okay, here's how we scale that and here's what we need to scale.

I think it's important to note that that has to exist within the context of your organization's culture, right? Like, we've seen two ends of the spectrum. One is that sometimes a design system starts really grassroots, where it's a handful of designers or developers or product people that say, well, let's come up with a set of standards and principles and maybe a little library of tools that we can use. And then it grows kind of from there. Other times it's top down, right? The CEO or a VP or something says, we're using this design system, everyone has to use it now. And everybody sort of scrambles a little bit. And so I think it's important to understand the culture of your organization and know which approach is going to work with the organization that you have, because they're not mutually exclusive, you know, they won't work if your culture of your organization is not set up in that way.

One thing that we've noticed is that really high performing organizations that can just consistently create new products and new work, almost all of them have a design system of some form. The best organizations have a design system. I think it's important to understand that a design system will not make you one of the best organizations, right? That part of the reason that these design systems work in these organizations because they have them, is because they are naturally suited to them. They have a culture where the design system can take root and process, where they can be used. And so I think one of the things about preparing for a design system is, is not only how do we convince people to make one, but also how do we make sure that we're in a good position to use it, that we are in a practice that will be collaborative, that it's not just sort of designers over here who are enthusiastic about it, but that the designers, colleagues in development are ready for it, or that the managers and product are ready for it. And so I think part of this thing is often not only finding funding or finding resources, but finding allies and kindred spirits and paving the way for a new kind of work.

It reminds me of the Seth Godin quote that the stuff that makes a museum is the stuff that's not on the walls.

Our bodies, this floor, this stool, the planets, the stars are all sort of built from the same stuff.

It's kind of like a pilot for a TV show. The point of the pilot is just to test out a concept.

Buttons in form, fields in images and typography, headings.

Trying to design a kit of Legos and going, well, I guess we have to have wheels in it, but if you're never ever going to build a car, you don't need to have wheels in that kit.

So we're able to sort of apply the same process that happens in the natural world to our user interfaces, hence atomic design.

Obviously, in a perfect world, you would snap your fingers and everything would be.