I'm Luke Murphy, and I'm joined by my co host Michelle Chin. We're both design advocates of zero height, the design system management platform, and this is Design Systems WTF. So, Michelle... First, first episode, first question. How do you make the rest of your org and senior leadership care about design systems?

I was just going to ask, why did you pick a hard topic to start with?   But it is a really important one. I think a lot of people do have this question.  And I think  a lot of times , we push for, "oh, it's efficiency for designers and developers."

And yeah, that's true, but that doesn't affect most of the people, especially senior leadership.  They don't really care as much about efficiency because they just want the work to get done. And if the work gets done, the features get shipped, they're happy.  So I think it's really coming to understanding , what are, their motivations, what are their pains and gains and how can you relate design system work to that?

Yeah. To start with, the reason that I picked this topic is because we're hearing it a lot at the moment, right? Like, it's, it's a tough climate out there. And I think that, especially because design systems, you know, started not too long ago. I mean, the official Atomic Design release was, what, 2016, when Brad released the book.

But even, going back, it's only been 10 years in total since people have been really talking about this and it started to, like, hit. mainstream companies. So it's still relatively new. And I think that we were going through that lovely heyday of people hearing about design systems and hearing it from important people.

So going, "Oh yeah, that's important. We need to do that." Without actually thinking about that.  How you show the value and that's what it comes down to, right? It's exactly what you said.  I think a lot of people don't realize or appreciate this is that it is, it's, you need to understand what the pains and gains are for the people you're talking to,  what their motivations are,  what they care about, right?

And that's different for the different people. 

Yeah,  it's super  different. So, for a while, I pitched, efficiency for engineers. Don't you want that?  But executives don't really care. So  what's a good tactic is , I worked with a vice president of design who was like, let's  figure out  what these executives' motivations are. What's really important to them. 

And at the time, it was like mergers and acquisitions. So you're like, if we have a design system, we can easily acquire companies and then give them our design system that they can quickly  rebrand their product to be our product.  and that was exciting for executives, right?

They're just like, oh, yeah, let's fold that in. Because I think looking at that, it's like, when they do their performance review with their CEO or something. It's like , we folded in this product into our portfolio within three months versus three years. 

Yeah. And I was going to say, and things like, I think rebrands as well, like is one that, a lot of people use as a great example, because if you've got the infrastructure, the design system even though it feels like it might still be a hard thing to do. It makes it so much easier and quicker to end up, especially if you've got things like token sets and whatnot set up.  If you've got strong foundations, it's the same concept with like a merger and acquisition to stand up a product or a brand becomes so much easier. 

Yeah, exactly. And then innovations too. So it's like, if you have an idea, if there's already a component library that devs can use, they can quickly make a prototype that looks very realistic that can demonstrate the concept pretty easily versus, "Oh, I have to design all this stuff; I have to make all this stuff. I have to code these components." 

I worked on another product that  the Product was going to get done by another team, who didn't have web development experience and the web development team that I was on those developers were going to not have any work. So there was like a little risk of them losing their jobs. So,  what they ended up doing was they used the design system coded up the prototype to show that they could make the product  on their team, versus the other team who they only coded, desktop apps. So they weren't coding web apps, so they had to learn. So there they had that learning curve.  So the executives realized, "Oh, this team just did this in like a day and a half and it was  a working prototype that didn't have everything connected, but the UI was there. And so that work ended up coming to that team instead. And so I think,  maybe they were able to keep their jobs. Happy ending.

Which is always a plus, right? It's funny because we were talking about this the other day, and, we've got quite different backgrounds and that  my background is a little bit of enterprise, but mostly sort of startups and scale ups.

Whereas you've been in the enterprise game for quite a while.  I always had the assumption and I think a lot of people do. I think a lot of  the people who are in the weeds of design systems have this assumption that the thing that people care about is the efficiency and the speed, which you were saying before. And that made sense to me as a way to like sell it into  to senior leadership, because when you're in that startup and scale up environment. Speed of delivery is such a pain point. And it's such an area that people they care so much about improving your processes so that you can ship product faster.

But it was something that never occurred to me that that just becomes less of a, I mean, it's still a pain, but it's less of a like burning pain in large enterprise. Cause I suppose that, you know, people get to the point where they understand that this stuff takes time. And,  when you've got large enterprises, you've got lots of moving parts, things just end up being a lot longer.  And it was interesting because you shared with me that, sometimes it is just playing to stakeholders vanity. 

Yeah,  I think  stakeholders and senior leadership have very different mindset than, like, the and the makers. I was  part of an org that worked on a design system where it wasn't ready but the senior leader insisted that it go public and everyone's like, "well, it has, 2 components and some color ramps and a typography scale. And that's it, and he's like, "I don't care. It's going live." And so it went live. And then it was, it was really, abysmal for the people who worked on it, because everyone knew that it wasn't complete.

But I think, we realized that this was this person's, legacy piece. So, the senior leader wasn't a designer. They were really high up and they wanted to establish, a legacy of, "I was part of launching this design system publicly," and it had nothing to do with the actual product.

But that's the thing is that it is, and I think that this is something that's really important is, and it's something that I've definitely learned over my career is sometimes the things that you think are the most important aren't the best way to get the job done. And sometimes you just have to work within the, the constraints that you're given of what the people who make the decisions above you care about.

And, yeah, sometimes it is playing to people's egos. But, sometimes, if that's gonna get it done and make sure that you're not defunded or deprioritized, hey,  it's a bad way to get to a good solution.  I think one of the things that it's important as well.

And I think that we sometimes get caught up in senior leadership being  the only people that we need to convince or whoever the budget holder is, whoever the decision maker is.  But actually also, there's a big piece around making the rest of your org care, because it's one of those, the easy way to keep a product is if your users are very happy with it.

And you have a lot of you, you know, you have as much penetration as possible into your market, not to talk about design systems as a product. I know you're not a fan of that.

It's infrastructure.

It's also like getting other people on board, but it's the same thing, right? It's understanding the language  that they understand and enjoy, um, their motivation, uh, so therefore, like, what it is that you're trying to play to, and the message that you need to sort of send to them. And then, I think, one that's, very tactical, but underappreciated is the channels they actually care about. It feels like a very minor point that, shouldn't make that much of a difference, but if you're putting all of your design system communication onto an internal blog that nobody reads, it's not a very useful way to spend your time.

I think a lot of it's like trust building too. So depending on the collaboration and the rapport between design and engineering teams,  that might need to be worked on a little bit more.  I've been on teams where we didn't exactly have the greatest working relationship with developers.  They just thought  we made things look pretty.

And then they also thought we were a bottleneck at one point because it was like, "Why is design taking so long?"  So our director kind of forced us to go out to lunch with the developers. So, every 2 weeks or so, we would all go out to lunch, like, reluctantly.  I think, over the course of a couple of months, we ended up building a good rapport of getting to know each other. So we established a trust to be like, "Hey, I'm gonna try this thing." or, "What do you think about?" And this is before we had a design system, so it was like working toward a design system. So I think there's definitely some ways you can  help win, people over to adopt the design system. And yeah, hashtag better together for sure. 

And like what Luke was saying is, go to where they are. Join their standups, their scrum meetings, their planning, their engineering monthly team meetings or what have you, just get a little time. Because I think the other thing is, chances are engineering managers won't say, "No." They just don't think to ask you  to come. So just  mentioning, "Hey, I'd like to join and talk about the design system and these coded components or what have you.

Yeah, I think it's  just reminding me of building bridges. And if anybody's watched the amazing series, Derry Girls of the Protestants and Catholics coming together. It was, uh, we're not getting into that.   I think  it's and what you're talking about as well as what you mentioned very briefly is around like building community as well. I think that's one of the easiest ways. Just build a community. It's super easy.  I think that community building is such an important part of  setting yourself up for success in the future when it comes to being able to sell in the value of a design system. Because if you have a strong community behind you, you've got those advocates, those champions around the business  who are going to be there to like fight for your survival and be able to provide those  qualitative feedback that you can then give back to your stakeholders.

And it got me thinking that basically there is, especially because I don't know if folks are in the startup world, but we talk about this thing called like category creation, right? Which is when something doesn't already exist and you've got to find that product market fit and create the category.

Design systems are still in category creation mode within businesses, right? And so I think that actually it is a part of most, unless you're really lucky and you have, amazing design system  comprehension within your business. There is always going to be an education part.  And it made me realize that  similar to what we do at zero height where we're in the sort of design relations part, which is strongly built on dev relations that happens at other companies, any company that has developers as an audience.

That's what we do. Like we were all about building community and educating. And it was one of those things that made me go, "Oh, maybe folks need to read up on developer relations if they're in design systems so that they can learn some of the tactics, running webinars, running ask me anything sessions, writing articles, doing lunch and learn sessions, trying to do that education piece."

And I know that time is, time is tight for everyone. But finding those little ways and the little effective ways to get out there and actually spread the, spread the gospel of design systems. 

Yeah, for sure. I think that's the other thing is once you get some advocates, some of your biggest advocates won't be your design system team. It will be others around saying, "I use the React library, and it was great. It was awesome.  it made my job easy. "Right?  And they can go to their managers, their leaders that way as well.  But I think, it is a little bit of work, but I think getting creative and then even if you were like, "I need ideas," maybe you go to the marketing team. "Hey, what's a good way to get engagement? Or program managers are also really good at coordinating sessions. If you have an idea and you just want to talk about the design system, maybe you have a design ops person that could coordinate the lunch and learns and get things moving.

It's one of those things where try a couple of things  and see what works.  And yeah,  it also takes a little bit of time too, but I think everyone gets there at some point. 

Yeah, I think that's true. And I think what you just said there is super important around the  tests experiment, fail, iterate. Like that is, it's, God, we're talking about design systems as a product again, Michelle. Um, but it should be infrastructure. But I do think that sometimes the product mentality...

In some aspects, I think the biggest  sticking point about calling it a product is that usually like products are like, "Okay, check. I made it. Now, we can move on and do new innovations or new products."  I think that's kind of where a lot of  stakeholders like, "Oh, I heard, this company said, we need design system. Let's make a design system. Okay. We have a design system. Our work is done." But  infrastructure is kind of like that utility.

It's like, you need plumbing. You need electricity. You need Internet and that needs ongoing maintenance and upgrades. So, thinking of it that way just means it's something that has to be part of the foundation to what you're doing. 

Oh, it's like music to my ears. So we have a great question here that's building off of  the same conversation we've been having around, which companies are building strong relationships between designers and developers.  Which  we're not going to list off a bunch of companies, but I think that there are some tactics and some markers that sort of show what goes well. I'm just curious, apart from actually getting them to talk to each other .

Are there any other things that you've seen that is like a good practice to get into or like a good way to get to that harmony between designers and developers?

I've seen, and I've done this as well is like,  working with engineers and  people early on, just like anyone you can think about, even if they're not able to contribute or it's not the right time for them to  come in. Like, maybe we'll have a content designer who's just kind of going to  one of our  quarterly kickoffs of like, this is what we're going to do. They just kind of sit and listen. So they know by the time we need them to help with content design patterns, they can step in.

And I think engineering realizes that they're part of the conversation early on that this is very much something that they can contribute to and own as well.  Then one company, I would say, I'm not going to name them, I don't think they have the best product, but they have the best design team and I love them.

They have a dedicated user researcher, a dedicated content person, a dedicated IA, dedicated developers and designers, like, dream team design system team.  You can tell when, when I talk to them, the synergy is really great. It's there.  It just makes me really happy.  So I think starting early on is really good. 

it is, I think it, it's like talking in the same language as well. I know one tactic that I've used in the past that works really well  is the concept of pairing.  I know that it's something that's quite common in engineering orgs for engineers to pair together.

One of the things that we started  at my last place to work was design engineering. So like front end engineering and design works very well because you've got a lot of the same problems and  you understand sort of similar language. But  I do think that it's a really valuable way to  not only really strengthen those bonds and get that shared language happening and that shared understanding happening on not just like what each other does, but the problem space and the way that you both approach the problem space. But also and this feels so wrong that it's, you get so much more work done  in those sessions than you do when you're working by yourself. Which I don't know, it makes no sense, but it just works. And there there must be some signs behind it; I'm sure.

Yeah.  Especially with accessibility and making your components accessible. I worked with an engineer and we  pair designed and coded on how to make a toggle accessible. It required them knowing more about the ARIA attributes and I am talking about  the user with a screen reader should have this experience.

 Sorting through things, testing things out. We were, like, messing stuff up. Things would work. Like, I would test it with a screen reader. They would continue coding. We would test it. It would break  and I think showing that, openness to  learn and learning together and showing that we all make mistakes and we don't know everything I think is a really great experience to have a bond over to be able to work together.

100%. There's another great question here around enhancing adoption by non designers. So stakeholders, well, they're specifically calling out, stakeholders, design managers.  it's an interesting one. I don't know if you have any thoughts on it. 

I think, you know, it's...  It is interesting because it's still it's similar to thinking about, what are their motivations? So if you can think about what they're held accountable for, like, product launches, feature launches,  and if you can tie some of the work that you're doing, or tie the fact that if we adopted this design system, this will be guaranteed to happen on time. Because I think a lot of times,  features and all this stuff kind of get delayed, but showing the value of, "I know your goal is to launch this product by the end of the year. And we're not going to meet that. But if we use a design system, this is how we could meet it."

You don't have to have like accurate metrics and data, like, math done, you can do some estimate because  the time it takes to create a component every time versus reusing a coded component. The difference is so  big that you don't have to have that accurate, "Oh, you know, it saved us 6 hours." You can say, "It saved us roughly 75 percent" or whatever, but really kind of pulling at what their managers and their bosses are holding them accountable to. 

I think  it's interesting actually. I mean, if you want those stats,  not to plug our own stuff, but,  we've been collecting loads of case studies that have been pulling those stats. So, you know, we've got them already. Just go onto the case study section in the zero height website and you'll have those stats to share. I think you're right.  I think it's like, don't labor over them too much.  I think also like understanding what does adoption mean for those people?  I think it's what you're measuring there whether they look at the documentation or whether they jump into the Figma file, like that probably doesn't matter. It's actually probably more around. That, going back to like the education piece, so it's like if you are doing  all hands demos, or if you are doing learning sessions or whatnot, making sure they're in the room, and there's like attendance there, and probably doing some kind of like qualitative surveys to then sort of gauge how successful that's going.

Because I think it is like  you need to really understand, " How much do they need to care?" Because there is a threshold there of how much they need to get.  And I think  that's really important. It's understanding what is it that you need from them in order for you to be successful.  Which sounds, I don't know, sounds a bit transactional. But still, it is,  when it comes down to brass tacks that's really what it's about.

 And I think it's interesting,  I was talking to a customer of zeroheight the other day and they were talking about the fact that they did a big survey for everybody in the company, who would potentially touch their design system. And one of the questions was just, "Have you heard of this and what does it mean to you?" and it's the name of their design system. And they were quite shocked at the amount of people who came back and said, "I've never heard of this." And so it showed that they still had some work to do, which is really great. 

I think we're at time now. So there are some amazing comments and questions in the chat. So we will make sure that we continue that conversation and take some of those into future, future episodes, as well as continue the conversation on Slack. That's it for today. Thank you so much, Michelle.  If you have any questions that you want to fire to us for the next episode, please send it through either via the zheroes Slack community, which you can really reach at zero height. com slash Slack, or on X @ zero height.  But until then, see you next time.