Episode 2 - Selling the value of your design system

Josh Clark: A design system should bear the burden of the boring so the designers and developers don’t have to. 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.

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.

MAIN TITLE: DESIGN SYSTEMS—MASTERING DESIGN AT SCALE

Brad Frost: 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?

Josh Clark: 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 sell a design system project within an organization and get it going?

Dan Mall: 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 designers and developers who aren’t management, but are 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.

If you’re a designer or a developer, how do you actually convince your peers, or how do you convince your managers that a design system is worth it?

SECTION TITLE: PITCHING THE PROJECT

Dan Mall: 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 Day 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 3x3 inch cards and every website that they made that year, and they printed out. They did a couple hundred. And then he pasted those onto mounting boards, black mounting boards, and then he brought them into his boss’s office, this was about six or seven mounting boards, and he just showed him and he goes, ‘this is how much money we’re wasting.’

What he was doing was really just kind of showing, 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.

SECTION TITLE: SHOW ME THE MONEY

Josh Clark: When you’re also going and looking for funding, it’s like when you’re getting down to the brass tax 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?’

Josh Clark: I think that there are some things, 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.

They now are saying that they are making products ten 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 on to other projects that otherwise would have languished.

When we built Exxon Mobile’s Unity design system, in the first ten months, they built fifty new web apps using this system. This is 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? So that’s a big pitch to make when you’re 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. Maybe it’s not specifically about money, but it’s about convincing people of your cause, or whatever the case is. How can we be more effective with our products?

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, ‘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.

Dan Mall: I think part of the moral of story, too, is not to fall in love with the design system itself. You know, for some people that will be very attractive, but for others it won’t be important at all.

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 that 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’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.’

SECTION TITLE: THE CAT IS OUT OF THE BAG

Brad Frost: Now that the design system cat is out of the bag, I mean, you have Material Design out there, there’s freakin’ videos being made about design systems—

Josh Clark: Who’s making those?

Brad Frost: I know, it’s crazy. But at the same time, now that it’s a thing, people are then selling the thing. So okay, yeah, we need to build this design system and what ends up happening is that you start getting a lot more pushback because it’s not an actual product, right? It’s not an actual thing that you’re going to launch to your end users. Your customers get the benefit of having a design system, but all of that stuff happens behind the scenes.

Dan Mall: One of the common stories about say, the jobs to be done framework is that when people are trying to buy a drill, nobody wants a drill. Nobody wants a 1/4" drill, they want a 1/4" hole, right?

Brad Frost: Yeah.

Dan Mall: And you can take that even further. Nobody wants a 1/4" hole, they want a picture hung on the wall.

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 would be like walking in and trying to sell someone on the virtues of Sublime Text Editor. No one cares about Sublime Text Editor. Developers do, but really people want the code that you write and the thing that you make.

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’ve talked 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.

Then, what they have to do, the hurdle is, ‘Well, now we have to get IT on board.’ So IT’s like, ‘yeah, but we already kinda have something like that. We have mobile developers that have 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.’

The designers are going, ‘Yeah, 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.’

So the story that we should’ve told to the IT team is, ‘We’re going to help you make the product. 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.’

SECTION TITLE: ASK FOR FORGIVENESS NOT PERMISSION

Brad Frost: 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.’

I think that some teams will get deflated, and we find ourselves 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 systemic 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’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, that once the launch party happens and everybody’s super happy with the result and the boss and everyone’s thrilled, it’s sort of at that moment you could say, ‘psst, come over here. Let me show you what we actually did to create this thing. Here’s this set of well-constructed, robust, flexible, assessable, performant components that we used and reused and reused across the site to build this thing at a higher quality.’

Once you go through the lens of one product, then you can start to say, ‘hey, we have something here. Maybe we want to build on that.’ And that can go up to the higher ups, where you’re not just 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 you go, ‘okay, here’s how we scale that, and here’s what we need to scale that.’

TOP-DOWN OR BOTTOM-UP?

Dan Mall: I think it’s important to note, that has to exist within the context of your organization’s culture, right? 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 from there.

Dan Mall: Other times, it’s top down. The CEO or a VP or something says, ‘We’re using this design system. Everyone has to use it now.’ And everybody scrambles a little bit. 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, they won’t work if the culture of your organization is not set up in that way.

Josh Clark: One thing that we’ve noticed is that really high-performing organizations that 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 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.

I think one of the things about preparing for a design system 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 designers over here who are enthusiastic about it, but that the designer’s colleagues and development are ready for it, or that the manager’s in product are ready for it.

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.

SECTION TITLE: NEXT EPISODE PREVIEW

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

Brad Frost: Our bodies, this floor, this stool, the planets, the stars, are all built from the same stuff.

SLATE: FROM TEMPLATES TO THE ATOMIC

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

SLATE: EPISODE 3. PILOT PROJECTS. TECHNICAL FEASIBILITY. ATOMIC DESIGN. TECHNICAL INDEPENDENCE.

Brad Frost: Buttons, and form fields, and images, and typography headings.

SLATE: EPISODE 3. PILOT SCOPE. STYLE GUIDES. AGNOSTIC DESIGN SYSTEMS.

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

Brad Frost: We're able to apply the same process that happens in the natural world to our user interfaces. Hence, atomic design.

Josh Clark: Obviously in a perfect world, you would snap your fingers and everything would be—tah dah!