Dan Mall: I think that's the first time that's ever been said, I got some value out of a LinkedIn newsletter.

(Laughter)

Dan: (Laughing) So, um, maybe I can get a LinkedIn sponsorship or something for that. I'll be the first.

(CATALYST INTRO MUSIC)

Gina Trapani: Hello. Welcome to Catalyst, the Launch by NTT Data podcast. I'm Gina Trapani, and as always, I'm joined by my business partner, Chris LoSacco. Hey, Chris.

Chris LoSacco: Hey, Gina.

Gina: How are you doing?

Chris: Great. How are you?

Gina: I'm doing great. We're here in the New York City office. We're sitting across the table from one another, which is such a delightful treat...

Chris: It's a wonderful thing.

Gina: ...these days. It's a really wonderful thing.

Chris: Look another human being in the face.

Gina: Yeah. I'm very excited about the episode today, because we have a very special guest.

Chris: I know.

Gina: Someone whose work we have both admired for a long time.

Chris: It's true. This is a heavy hitter in the design community.

Gina: Yeah. This is... This is a big one. I'm excited. I'm a little bit nervous.

Chris: (Laughs)

Gina: Does that mean I care? I think that means... That means I care.

Chris: I think that means you care.

Gina: Yeah. Welcome, Dan Mall. Hey, Dan.

Dan: Hello. Hello, Gina. Thank you. Hello, Chris. I'm also fangirling over here, too. So... 

Gina: (Laughs)

Dan: You both are OGs, and I'm excited to sit across from you virtually. I'm not in the same room as you all, but maybe one day, maybe one day soon.

Chris: That's right.

Gina: It's wonderful to see you, even in a box on the screen. And I gotta tell you, our listeners can't see you, but you have just such a good camera setup, the lighting, the depth of field.

Chris: This is the thing. I said it before the show. I...

Gina: I just, I just want everyone to know, this is just a premium experience we're having right now.

Chris: It's top notch. I feel like I'm talking to someone who's in a studio. Like, I'm so inadequate right now with my webcam.

Gina: And I'm pretty sure it's your home. (Laughs)

Dan: Yes. That's right, this is my home. But, you know, if anybody wants a studio in a box, too, I wrote a blog post about this, so maybe we can link it up in the show notes.

Gina: It's so good. 

Chris: We will definitely link it up.

Gina: Yes, that's perfect. We will link it up. Because I was like, I need Dan's camera setup, and, like, lighting setup. Like, this is good. It looks really good.

Dan: It's documented somewhere. So yes, anyone can have access to it.

Gina: Dan, we're thrilled to have you on the show. You are a design leader. You are a voice in the community. And I feel like design kind of hems you in. I mean, you've been a creative director. You were a founder of an agency, you ran an agency for many years, so I feel a kinship with you in that sense. And, you know, to me, I followed your work for a long time. I really never thought this sentence would come out of my mouth. But I love your LinkedIn newsletter. It's so good.

(Laughter)

Gina: Dan Mall teaches. You know, my team is probably getting tired of me linking to it in our Slack channel, being like, look at this thing that Dan wrote. This is really smart. Um... (Laughs) 

Chris: I can vouch for this.

Gina: Yeah. 

Chris: That's true. 

Gina: That's true. I share a lot of links to your newsletter. I love that you have a new parenting site out that I love. The design is so good and the voice is so good. And you're here today because you've just released a new book, which I'm really excited to talk about. Tell us about the book. What's the book called?

Dan: Yeah. Cool. So, the book is called Design that Scales. And the subtitle is Creating a Sustainable Design System Practice. It's published by my friends at Rosenfeld Media. This is, like, right up their alley and their readers and stuff. And so, they were kind enough to let me write this book with them. It's basically a book about design systems. There are a lot of really good books about design systems out there, too, and I didn't want to rewrite one of those. So basically, this is my book of stories, my own stories about design systems too. It's less of a, nuts and bolts, here are the definitions, although there's a couple of things like that in there. And it's more about, like, okay, so how do we actually do this in practice? How do we do it in a way that, big enterprises that are invested in designing at scale, like, what are some stories that they can be inspired by so that they can figure out how to make it applicable to them? So, that's the book that I wanted to write. It was a long time coming. Way longer than I expected to do the writing process.

Gina: It always is.

Chris: But I'm happy that it's in my hands.

Chris: That's awesome.

Gina: It's exciting.

Chris: It's always great when you can hold up a physical thing and say... 

Chris and Gina: I made this. 

Chris: You know. 

Gina: Also terrifying.

Yeah. Especially as, like, a digital designer, right? Like, I'm just making a lot of things that are digital and feel ephemeral and is just ones and zeroes. It's like, I got two boxes shipped to my house that I had to cut open, and, like, I got to hold a book in my hands. So that felt pretty special.

Chris: Yeah. That's very, very cool.

Gina: It really is. 

Chris: So, we got a copy of the book. We were able to look through it.

Gina: It's great.

Chris: It's really good. It jumped out to me that it's not a nuts and bolts book. It's not a how-to guide. Like, there are some practical tips on implementing design systems, but it's really much more about the rationale around, what and why would you want one of these? Which is really interesting.

‍Dan: Yeah.

Chris: And early on you make this point about design system, like, ghost towns, right? Where it's like, you know, there are lots of trial and error that you see when you look inside of a company, of all these different groups who have done something, but it hasn't really come to fruition. And I'm curious, like, was that part of your motivation? To be like, I've seen it done wrong a lot of the time, and I want to write down how you can do it right?

Gina: I'm surveying the graveyard and I need to make it right.

(Laughter)

Chris: That's right.

Dan: That's right, that's right. I think my... My advantage as a consultant is that I've seen a lot of different design systems and how they work, and how the shape of them and who works on them, and all that stuff. And I think that's the advantage that I bring to a team when I work with them is like, I'll never know as much about their design system or their culture as they will. Like, no matter how long I'm there... Because they just live with it and I don't. What I hope that I bring to the table is like, well, I've seen 400 of these. And so let me tell you some of the patterns that emerge from this. And as you mentioned, almost everyone does it wrong, you know, for lots of different reasons. And that's not because they're stupid. It's not because they don't know what they're doing. I mean, it is a bit of an ignorance, in that a lot of times it's a company or a team's first try at design systems. And so, of course they don't know what they're doing. You know. Of course. Like... And I don't mean that in a bad way, I mean that in like, the most positive way. And so, they do the things that feels most intuitive, and what feels most intuitive for a lot of designers and engineers, who are usually the ones starting a design system, is like, I don't know, we got to make some stuff, right? So let's make some stuff. And it ends up working at a small scale. And then they go, like, well, it works for us. And so, let's figure out how we spread this around the company. And then that's where things usually go wrong, is like, they don't treat it like an internal product. They treat it like an internal project. And so it doesn't really have legs of its own, and so what they end up doing is, they end up... The project is successful. So they go, well, let's do a bigger project. And then they make lots of general components, like buttons and tables and footers and headers and all sorts... And then they build this big monolith, and then no one uses it. And so that, you know, that's what I call a design system ghost town. It's like, you built this entire town, it just wasn't close enough to water, so, like, you know, no one ever wants to live there. Because it's just not connected to any source of life. And I think that's a thing that people just don't know, because they've never done anything like that before. So, I wanted to expose some of those stories and say, like, this is what happens. It's cool if it happens to you. Like, it's natural. Most of the organizations that I've worked with with design systems are on their third or fourth try at it.

Chris: Yeah. Yeah, yeah, yeah.

Dan: So it's like, I want to normalize a lot of that stuff and just say, like, it's cool. Here are some stories that will help you maybe get it on your second try, or maybe your first try. You don't have to learn from your own mistakes. Maybe you can learn from other people's mistakes, and then hopefully learn from your own successes too.

Chris: Yeah, I love that.

Gina: Yeah. I want to go back to bases. So we're talking about design systems, and I really love the way you laid this out in the book. So that, for the folks that don't really know a lot about what that means, right? So, like, you know, you use this great example in the book about Google products, right? When you use a Google product, you know, the search box, the action button, the hamburger menu, the whatever it is, they all feel and look the same. Across products. And that's good. That's good for everyone, because people just know how to use all, you know, Google products, right? And that's true for lots of different companies and systems. And so, you know, when you're thinking about a design system, you've got a company that produces two or more digital products, right? And so the system is like, how do we create that kind of unified... On a small scale. (Laughs) How do we create that unified look and feel, so the user knows what to do and feels at home, and is like, oh, I get this. I see what I have to do next. So I love how you laid out that, you know, you've got design teams inside of big orgs. Product teams are often small teams in silos. They are building their own thing. And we're all systems thinkers, right? We're product people. We're like, how do we make this a little bit more standardized? How do we make this a little bit more efficient? How do we make these components a little bit more reusable, right? And these are how the design systems start to spring up. But they're often happening in the different silos, right? It sounds like you've seen this, Dan, where you've got a couple of different systems happening at different levels of maturity, in different parts of an org, that are early here, and this contributes to the ghost town. So it's not just one ghost town, it's like a... (Laughs) A collection of little ghost towns. That can happen over time. And the thing that I think really made such a huge impression on me, because I come from an engineering background, I hadn't really thought this through. I went into the book thinking, oh, this is going to be a book about making buttons and forms and headers and footers. But what it is actually about is organizational change...

Chris: Mhm.

Gina: And design systems as a practice. When you talk about project to product, that makes a lot of sense to me. I get that a project has a deadline and then it's done. A product is a continuously iterative thing. But a practice is even a bigger thing. That's a cultural, that's a mindset shift. 

Chris: A way of working. 

Gina: A way of working. Yeah. And that was like, oh, that was my, like, (explosion noise) moment in my head. Because, you know, we talk to a lot of execs, uh, at our clients. And that's, I think, a really useful framing for what a design system is and what it's supposed to do.

Dan: I think part of the danger of design systems is that we don't have a lot of parallels for what they are. So like, the closest is like, oh, it's like a library of stuff, right?

Gina: Yeah. Right.

Dan: It's like a code library. And it's like, yeah, I mean, that's a part of it, but that's like, that's really selling it short there. I wish I had come across this quote when I was writing the book. It was, it's from my friend Lauren LoPrete, who at the time was at Dropbox running the design system team there. And in her talk for Figma's conference, she said design systems are cultural change disguised as a UI kit.

Gina: Mm.

‍Chris: Wow. 

Dan: I love quoting that line. It's because of that that we... Like, we relate it to projects or we relate it to tools, right? Those are all kinds of design systems. And that's what's difficult about even defining them is like, there are some tools that can be considered design systems, and some templates, and some products and projects and services. Those are all kinds of design systems. And a practice is a different kind of one, you know? And so, it depends which kind of one we're talking about. And it's that cultural change piece. The closest that I've seen, the closest parallel that I can make to design systems is Agile.

Gina: Hm. Yeah.

Dan: I think that's the closest. It's like, in order to implement Agile at an organization, you have to change your whole way of doing things. Like, you have to get training. Right? You have to have people get, like, learn the processes and all that stuff. And then you can implement different kinds of rituals later on. And that's like, you know, whether your Kanban or your scrum or your XP or, you know, whatever flavor of Agile you decide to implement, and whatever rituals you decide to adopt, as an organization, you sort of have to adopt the idea first. And then you can start to bring in the tools, and okay, we're going to use Jira this way, or we're going to use Trello this way. You know, whatever the tools that you have with that. But that's the closest parallel that I've found, is it requires everyone to buy into that way of working. And even Agile isn't quite at the scale that design systems are, because Agile, oftentimes when people do Agile, organizations who aren't doing Agile very well, what it means is, design is waterfall and product is waterfall, and then when we get to engineering, it's Agile, right?

Chris: Right. That's right.

Dan: So okay. You're like, okay, close enough. That's fine. But I struggle to find a parallel where design, product and engineering have to buy in to a shared way of doing things. And that's what I think is so hard about design system work.

Gina: But it's so critical, because those teams have to work together.

Chris: Right. 

Gina: That collaboration between those teams, those cross-functional teams, it's critical to the success of the product.

Chris: It's the name of the game.

Gina: Yeah, it's the name of the game. Exactly.

Chris: Yeah. So, I want to bring this back down, though. Like, is there a better way to do it? Right? Like... Because we're talking about some very big, lofty, like, hey, we have to change the way our organization works to do this right. And I think that's intimidating. Like, that is, you know, if I'm thinking about, you know, running a small team within a large company, and figuring out how to, like, upend the culture to be like, no, we're going to think in a, you know, design systems first mentality. Like, that's hard. And not a lot of people will have the organizational capital to be able to just push that through. And I think...

Gina: Fortitude. (Laughs)

Chris: And fortitude, right. You've gotta, like, break down a lot of barriers to really have that happen.

Dan: Right.

Chris: But I think... You know, and I don't want to put words in your mouth, Dan, but like, your approach is a little different, actually. Right? You don't say, let's step back and solve all the problems and then force this on people. Right? There's a different way to go about it. So can we talk about, like, what do you think works here?

Dan: So I think one of the biggest changes that an organization has to adopt to do good design system work... A lot of times for me, I'm like, let's not even talk about design system work. Because no one knows what that is, right? It's such a new thing. It's been around for... I guess design systems as an idea have been around for centuries, right? Cave paintings are design systems. But like, in digital, maybe it's been around for the last ten years, and certainly popularized over the last five. So it's still relatively new. So, we have to put that aside, because when we say let's do good design system work, everyone thinks something different about that. So, maybe something that's a little bit more familiar is like, internally at big organizations, at enterprises, we have to adopt more of a product way of thinking, or maybe more of a startup way of thinking. And that in itself is really tough for a lot of organizations. Like, entrepreneurialism inside a big organization is almost nonexistent. And so, I think that's the thing. If I were to boil it down into, like, what should we do first? Well, what would a startup do if they were building a new product? The first thing they would do is they would talk to a bunch of customers. Good startups, I guess. Right? Like they would talk to customers, and they would just go like, what are the pains that actually exist here? They might have some hypotheses, they might build a couple of prototypes to test some things out. But before they got too far, they would go, like, let's make sure we're actually solving a problem for a person. Or a team. Or, you know, in a small way. And then if that works, then we'll build more around that and we'll scale that and we'll figure that... And if that doesn't work, we'll pivot and we'll build something else. So, that's the way that I suggest for a design system team to work, is like... What most people do is they go, let's do something that's the most widespread ever, which is button. Let's tackle button component.

Gina: Let's make the one button that's gonna be the button everywhere.

Dan: Right. It's like, how adorable, you know, that you think you can...

(Laughter)

Dan: You know, like, there's a lot of problems with button. One is that, first, no one wants someone else to solve button for them. 

Chris: Right.

Dan: Like, any designer and engineer is like, I got button. You know, I think I'm alright on that. Whether or not they're right, you know, they're like, I don't need someone else to solve button for me. And that's how you end up with 400 different kinds of buttons across an organization, is everybody thinks they can do it, and so they do it their own way. So the other thing is, even if people did say, okay, we do need an external-internal team to solve button for us. So you think that your first component, before you serve anyone, you're now immediately going to turn the firehose on and then solve button for 400 designers and engineers? Like, what startup would immediately adopt 400 customers? Like, it's a bad way to scale things.

Chris: Right.

Dan: It's just... Like, you don't want to turn the firehose on like that. You want to control, you want to throttle. Well, let's work with, like, let's solve it for like two or three folks right now, and then maybe we'll expand to six, and then 12, and then 18, and then go from there. And that's an entrepreneurial way of thinking. That's a startup way of thinking. And that kind of thinking usually doesn't exist inside of enterprise. Or it's few and far between. And so, that's the place that I would start is like, let's find one specific thing that we can do, not one general thing that we can do. And I think design system teams are generally prone to want to solve general generic abstract things.

Gina: Mhm. Yes.

Dan: And it's like, you can't solve abstract things if you don't solve the specific things first. Let's solve the specific things, and then let's figure out how we can abstract it, and scale it a little bit more.

Chris: Such good advice.

Gina: Right. So, find your first customer and then expand.

Chris: That's right.

Gina: Second customer, third customer.

Dan: Right.

Gina: At some point you have to get a leader to say, here's your budget and time to work on this thing. And that point might not be in the beginning.

Dan: Yes.

‍Gina: I mean, that's a reality of big orgs. But that makes a lot of sense, that you get started by finding your first customers.

Dan: Well, but does a design system necessarily need a dedicated team? Like, is that the only way they're successful, is if they have a team that is wholly focused on building, maintaining, evolving, enhancing the system?

Dan: Let me ask a question back to you. Does Gmail need a dedicated team?

Gina: It does. Yeah. Does a product need a dedicated team? Right? Like, it's a product.

Chris: It's a product. 

Dan: That feels like a no-brainer.

Chris: Yeah. 

Dan: Like, yeah, I hope Gmail has a dedicated team. Like, because I don't want Gmail to go away.

Chris: Right. 

Gina: Right.

Dan: So if Gmail needs a dedicated team... And of course, Gmail is a massive scale, but if we want design systems to be massive scale within an organization - and not just within, but all the vendors that you might be working with, and like, outside of the organization as well, shouldn't it have a dedicated team too? Shouldn't there be people that work on it, at least for the majority of their time, if not full time? A couple of people. They have a roadmap. They have a budget, they have longevity. They don't get pulled from project to project. Like, that's what I want for the Gmail team. I want it for Zoom. You know? I want it for every product that I use all the time. I hope that they have a dedicated team there. So why is it different for design systems? And I think that's the difference in thinking on like... You know, well, if it's just a project, we don't need a dedicated team, right? We just need people to have six weeks here and there to carve off, you know, maybe part time. But if it's a real product that has a roadmap that we want to improve, that has versioning and has version control and is package managed and is all that stuff... You know, if we want Gmail to have it, why not the design system too?

Gina: I mean, it's a great point. I want to play devil's advocate though, and I want to be an executive, like an executive that we would work with.

‍

Dan: Excellent.

‍

Gina: Okay. I'm a digital leader in a large enterprise. I've got quarterly goals. And I've gotta ship a thing. A tangible product. A thing that is going to drive revenue. Maybe it's going to open up a new revenue stream, maybe it's a modernization of an old thing, and that has to be better. This design system business that we're talking about, this sounds like meta work. This sounds like busywork. This sounds like very expensive work that is not going to actually lead to any return on investment. (Laughs) And I'm just going to be honest. When I hear design ops or when I hear product ops, I think, oh no. Oh no. I have really smart, talented people who are like, figuring out meta work that isn't real work, and that's going to create more work for us, and it's going to be expensive. I... (Laughs) I'm a little embarrassed saying this to the person who wrote the book about design systems. But I think that this is a mindset. I think that this is a real mindset.

Chris: You gotta talk it through.

Gina: Yeah, I want to talk about that. How do you see a return on investment? How do you see this as like, this is going to propel our business forward? How do you draw that line? Because it's real money. I mean, designers are expensive. Good ones. (Laughs) And that's real.

Dan: So many good things to talk about there. So, first of all, I agree with this executive. Right? So, an executive that says that to me, and they're like, convince me otherwise. I'm like, oh no, no, I'm on your side about this. Like, I don't... I don't disagree with any of those things. And I think that's part of the, like... Well, first of all, that's also a tactic too, which is like, hey, I'm on your side, right?

Dan: I'm a salesperson. I'm very...

Gina: (Laughing) Yeah, yeah, yeah. Very good salesperson, Dan.

Dan: But it's also true, right? And maybe that's what makes me a good salesperson, is that it's true. There's a big contingent of folks right now who talk about design systems and the value of positioning it as infrastructure. And I'm like, I get the value of that, I just disagree with that positioning on it, because then it becomes a cost center immediately.

Gina: Yes.

‍Dan: If you think about it as ops, if you think about it as infrastructure, then it's operational. It comes out of a different budget, even. Like, the way that it's allocated, the way that it's paid for, the way that it's funded, comes out of a different bucket of money than other things come out of. And what comes out of the other bucket of money? Usually things that the company looks favorable upon. Right? They go like, that thing was really cool. That was worth the investment. Infrastructure usually isn't that kind of stuff. So, I don't agree with the positioning that we should talk about design systems as infrastructure. I think about it like, let's talk about where it actually has business impact, but we're not trained at talking about how it has business impact. I just had this conversation yesterday with somebody that I was coaching on a design system team. You know, what is it that design system designers and engineers usually do? Is they go, let's talk about the business impact of modals. And I'm like, modals don't have business impact. 

(Laughter)

Dan: Like, it's just... It's just not there to be had.

‍Chris: Yeah.

Dan: What does have business impact is what you put in those modals. Right? Like, if you're messaging about new products that are coming out and you're using modals to do that, that has business impact. If you are using, you know, whatever tool tips to be able to instruct a user about how to upgrade their plan, that has business impact. So, when designers and engineers go to executives and say, we want to spend time on modals and footers, executives are like, what are you talking about? Why would we do that? But if you go to an executive and you say, I would like to spend time on messaging our customers on their upgrade path, now we're in...

Gina: Now we're in business. Yep.

Dan: We're having a different conversation now.

Gina: Yep.

Dan: And design system folks generally don't have the practice, right? They don't have the muscle memory. They don't have the muscles to do that. Because they've never done that. They've never had that kind of conversation before. So, this is what I mean about talking in specifics. Like, let's not talk about modals, that's talking about abstract things and generic things. Let's talk about things that you put in the modal. And you know that you're going to do this through good abstraction and through scaling, but you don't have to sell that part, right? To me, the parallel's like, it's like saying, well, what we're going to do is we're going to use this line of CSS on this thing. 

Gina: Right. It's a meeting... no one cares about that.

Dan: It's... No executive cares about what CSS properties you're using. Like... 

Gina: Right. Right.

Dan: What are you talking about?

Gina: What I'm gonna do is I'm going to pour concrete in this box, and I'm gonna wait for it to dry, and then I'm gonna put the...

Chris: (Laughing) Exactly. 

Gina: And it's like, what? Yeah. You're building a house.

Dan: Why are you explaining chemistry? It's like... You don't need to know that.

Gina: Right. 

Dan: It's that idea. It's like, we gotta talk about the business impact of this stuff. And the business impact is usually in the specificity, because that's where you can tie it to OKRs, to organizational goals, to things like that. You can't really tie, you know, cards to organizational goals. I remember working with a sportswear company, and we had that conversation. I remember sitting in front of an executive and he was like, why are we talking about cards? And it wasn't until we shifted the conversation to, actually, the way that we do product cards here actually can be consolidated in a way that it helps us sell 2 or 3 different lines this way. And he was like, oh, that makes more sense. Let's talk about how we do that. And it wasn't a conversation about design systems. Design systems were just the vehicle. It was a conversation about product and revenue and, you know, and the things that actually move business impact. So like, we need more reps in talking about that kind of stuff. I think design system engineers and designers and product owners, they just don't have the reps. And because what's attractive to them is the abstraction of it. Right? Is that idea.

Gina: Right. They're craftspeople.

Dan: They want to be removed from business impact. So...

‍Chris: Right. But the reality is, it's an implementation detail. Like, you know. 

Gina: From one point of view, right?

Chris: That's right.

Chris: So, if you think about implementing a product feature that is going to have business impact, but you think about doing it in a design system, you know, manner of thinking or manner of acting, does it take longer, like is it more effort, and if so, why would I want to do that? Right? If I'm the exec?

Dan: Yeah. 100%. It takes longer. It takes more effort. It's more difficult. Right? So all of those things and more. Why do you want to do that as an exec? Because it's an investment. And there's one other thing that I want to say about this, is like, the way that most people sell design systems is, they have an idea for a design system and what it would do, and then they go and pitch it. And they go, we need a million bucks, right? Because that's usually, that's about what it costs, you know, plus or minus. It's about $1 million a year. To fund a design system, have a dedicated team on it, get the training and the licenses and all that kind of stuff. About a million bucks a year. So that's not chump change. That's a lot of money.

Chris and Gina: Mhm. Mhm.

Dan: So when you go to an executive and you go, give us a million bucks because we have a good idea, what would you expect them to say? Of course they're going to say no. It would be, again, back to the startup metaphor, it'd be like going to a VC and being like, we have an idea, give us a million bucks.

Chris: Right.

Dan: Most VCs, unless you're someone special, unless you're someone who already has a track record or, you know, a former founder or whatever, they're going to laugh you out of the room. They're going to say, like, come back to us when you have some traction with users. So that's the way that we need to pitch design systems, is we need to actually build traction first, and then get buy-in to fund scaling that traction, increasing that traction. Not to start the traction. Because essentially you're funding vaporware. So I think that's part of the buy in quest too, is like, you have to build traction already on your own in a small way, and then you get executive buy-in to then fund the scaling of that traction. So I think that's, you know, that's definitely one part of it. Once you're doing that, then the conversation changes. And what you're pitching the executive is not, I have a good idea, help fund it so that we could see if it actually works. It's, we have this thing that's already going, and we already have some traction. So what does that look like? We worked with two teams and we saved them an average of about two weeks on their product sprint.

Gina: That's huge. Yeah.

Dan: So, okay. If we were to do this with 20 teams, we think we could save 20 weeks' worth. Now we can translate that into business metrics. We can say, that actually saves us X amount of dollars. So yes, you put $1 million over the year. We think it'll return $2 million over the year.

Gina: Right. By this time.

‍Dan: Who wouldn't invest a dollar to get two? 

Chris: Right.

Dan: You know...

Gina: Right.

Dan: The conversation changes. 

Chris: Right. Yes, it's an investment, but you have to look at the return. Right? If you're getting 100% return, that's a pretty good investment. (Laughs) 

Gina: Right. And being...

Dan: That's pretty good. Beat the stock market.

Chris: Yeah. Right.

Gina: Right. And being able to say, like, this is the point at which we earn back your initial investment...

Chris: Yes. 

Gina: ...and this is the potential to go above and beyond your million bucks is going to turn into. That's huge. I mean, I think there is a misconception about venture capital that you do just go and say, I have a great idea.

Chris: You're right.

Gina: And you get money. That is not true.

Chris: It's not true.

Gina: You have to show that there's a market for the thing that you... You have to have users to start.

Dan: Yep.

Gina: So, Dan, do you think that it's important... My brain immediately goes to staffing, because we run an agency and that's what we do. When we talk about a dedicated team working on a design system, there's some part of my brain is like, you know what would be really good? If a designer was like, staffed 50% on an actual product that's shipping and then 50% on the design system, because that person could be the bridge between, you know, be both the customer and the creator of the system, and can be that person who is kind of in both worlds. Right? Because if you have someone totally dedicated to the system, they're thinking about the system, and maybe not the actual products that are going out into the world and the thing that users are touching. Do you have an opinion on that, or is it just... does the stage, the point of maturity of the thing, determine that?

Dan: Yeah. I have an opinion on that, lots of people have opinions on that. There's really good articles written by people like Gina Ann and Nathan Curtis around different models of staffing a design system team, and the one that you're talking about is a popular one. It's called the cyclical model. Which is like, the idea that someone would maybe be part-time on a design system team or kind of an ops team, and then part time on a product or a feature team. And I think what that does is, it builds good empathy. Right? So that's great. Like I think there are other ways to do that, but I think that's a really good model. A lot of folks have run that successfully. I think when Gina Ann was at Salesforce, she had talked about that model, you know, working there. I know a lot of teams have done that. I think what is tough about it is that people try to implement it from the very start. And I think it's tough to implement a cyclical model when you don't even know what you're actually doing quite yet. So, I think a cyclical model is something that you can move toward. I think it's tough to start with that, or at least from my experience, the teams that I've worked with have had a lot of trouble kind of doing that, because what often happens is they go, oh yeah, well, let's have the cyclical model, and it automatically puts them in part time territory, and then they're expected to actually have full time gains or full time returns with a part time status. And I think it just sets the expectations poorly about what that model can actually prove, and what that model can actually serve. So, I think it's a little bit of a later stage in the model. I think full time is the place to start, and then reducing to part time eventually, you know, is possible. But to me, it's simpler to go like, it's a feature, it's a product. It needs a team. You know, just like every other product in our company. If we have something that's customer facing, yes, of course we dedicate a team to it. Even if it's two people or three people, that's fine. So, I think it's just a simpler model to figure that out, because there's a lot of mechanics to things like cyclical models where, okay, so we have like a six month tour of duty, or how long do we rotate? And then, you know, who rotates in? Does everybody rotate out at the same point, or like, do we have overlap? So there's a lot to figure out in that. And so, I think that it's a bit more of a mature model. And so I generally tend to go, like, let's get set first, and then let's figure out what kind of models that we have. That said, there have been mature teams that have done that really well. I think Etsy, I don't know if they still do this, but I think Etsy at some point had something similar, where people could opt in and out of teams and say, like, I want to do six months on there and I want to have six months, you know, over there. And that was a larger design thing. It wasn't just on the design system, it was design ops. It was like, you know, you can go anywhere you want. And design system was just another one of the teams that you can go on. And I think that's the state that we want to get to, is like, everyone sees it as just another feature team, just another product team that's dedicated the same way, funded the same way, is just as important as all the other ones. Like, I think that's the status that we want design system teams to get to. Not, there's some other weird thing that like, they have their own model and they have their own staffing and their own funding. It just ends up being other. And I think you want to be like everyone else when you're a design system team.

Chris: Yep. Do you think that people starting on their design system journey should start from scratch? Or should they take something else that's out there and build on it?

Dan: I think this is another Lauren LoPrete thing, I just quote her, you know, forever. (Laughs) I think it was her that said, like, there's always a system. So, no one is ever starting from scratch. There is always a system.

Chris: Oh, interesting. Hm.

Dan: It just might not be apparent. It just might not be codified. But there's always something there, right? So, if you think about something as simple as... I mean, we all use brand red. We don't have to have a design token that represents brand red. Like we all use it. Now, we all might use slightly different shades of it across teams, right, and that leads to the inconsistency. But we all use it. And that's a form of a system. Like, system just means, like, a way of doing things that's connected. So, like, you know, the connection part is a little bit loose there, but it's still kind of a way of doing things. We all know how to do this thing. We all know how to use brand red, or we all know how to use the corporate typeface. We might not just be following the rules well enough because the rules aren't with us, you know, when we need them. So those are the kinds of things that, to me, the way that I talk about it with teams is, that design system designers or engineers are not people that need to create the system, they need to collect the system. 

Chris and Gina: Mm.

Dan: Because it's already, it's always there. Especially because when I work with enterprise teams, they have a lot of products in flight, even if they don't have a design system. So they've got, customers are using hundreds of products and they have, you know, hundreds of thousands of customers using these things. So how do you build a design system in that mist? Well, what you do is you collect things that are already there. Are already a system. Like, hey, we already do this thing a bunch of times. Let's just put it somewhere so that it's more easily accessible. So that's the thing that I encourage teams to do is like, go look for something that's already happening three or more times. It might be happening in a messy way. It might be happening in an awkward way. It might be not happening on purpose. But let's go collect the things that are already common. And the way that I like to talk about design systems is, I like to talk about things that are common, not necessarily things that are... I don't like words like foundational, or words like standards, because I think they divert from what a design system team actually is. So when teams are like, are building their first design system and they go, let's call it foundations, I'm like, oh, I think that sets the wrong precedent. I say, let's call it common. Because it's really, it's the common stuff that we're putting in there. Not necessarily the foundational stuff, for lots of reasons. But I like calling it common. And in order for it to be... You cannot create something that is common. If you create it, it's new, which means it's not common. It can only be common after it's been used a bunch of times.

Chris: Of course. Right.

Dan: Even just the wording of that, it kind of makes you think about something different, or think about the work differently. That's the way that I've been successful doing it is, let's go see what's common. There's always something common. It just might not be noticeable enough. So let's call it common, let's put it in a place, and then let's spread the word about it. And that is a good place to start.

Gina: This is... This is so true. When groups of humans get together to do something, ways of working emerge. I mean, this is true for, you know, culture. This is true for engineering. There's just, there's ways of working. And I really like this framing, because I think that you can think about a design system as a bunch of, like, very high-minded, high -alutin' designers getting together and declaring the correct and right and perfect way that you should do the thing. And then they look down from their ivory tower... 

Chris: Right. There's a decree. 

Gina: ...at all the actual... Right, all the actual limitations, and go, got that color wrong. Oh, that typeface not right. You know? 

Chris: Right. Tsk, tsk, tsk.

Gina: Right? I can't believe you're not compliant. Right? And then everyone's just like, ugh, these guys. You know? And that's how you get a ghost town, right?

Dan: That's exactly right. -Nobody likes the design police, right? Nobody wants that.

Gina: Nobody likes the design police. Right. And if you're saying we are making the common ways of working explicit versus implicit, because they exist. (Laughs) Whether or not we acknowledge that, I think that's so important, right? Like, this is the way that we're all, you know, together deciding, right? Because... How to work together.

Chris: Right.

Dan: Yeah. I think a lot of folks are drawn to design system work because they want to be the design police. They don't realize that they want to be the design police. I think it comes from a good place. They're so frustrated about the lack of standards, the lack of consistency. They can see what it could be. And so they go, I want to be the person to set it right. And like, I think that's a well-intentioned thing, but it's like, that's a hard place to start from. You know? That's a hard place to say, like, my way of doing things or our way of doing things is better than yours.

Gina: Right. You need to fix yours.

Dan: And now I have to convince you to use it.

Gina: Right. (Laughs)

Dan: Oh, that's... that's a tough sell.

Gina: Yeah, that's a real tough. No, it's true, it's true. (Laughs) But as a person who notices details that aren't the best practice and desperately just wants to fix it with a golden rule that I can just hang over...

Chris: Oh, totally. I empathize with that person.

Gina: I really empathize. I really empathize. Yes! (Laughs)

Dan: Totally. Same, same.

Chris: Yeah. 

Dan: Yeah. 

Gina: (Laughs) 

Chris: Yeah.

Gina: You just want to make everything better. It comes from a good place.

Dan: Yeah.

Gina: But maybe not received well.

Dan: Yeah, totally. I think a better place is... What our job is is, it's a service job. You know, as design system designers or engineers or product. It's a service job. So what we're going to do is, we're going to collect all of the great stuff that is already happening here, and we're going to celebrate the people who did it. It's not our stuff. I'm not making a new dropdown and then convincing everybody that my dropdown is better than their dropdown, and they should use my dropdown as... Like, that's a tough sell. Instead I'm going to go, you know what? That one over there is really really good. Chris's dropdown that he made is excellent. So let's put Chris's dropdown here because people are already picking that up. They just want an easier way to do it. And let's celebrate Chris, for making something that's really good that other people here want to use. Like, there's already traction there. So let's be the firepower or the accelerant underneath that. You know, we can be the, we can be that team. We can be the team that highlights people, that celebrates people, that elevates their work, that centralizes their work. We can be the team that does that. And I think that's a much better posture for people to want to be your friends. And use the thing that you make.

Gina: Yeah.

Chris: Such a good technique.

Gina: Yeah, it makes sense.

Chris: That's the thing. You got... It has to be used. For it to be successful, it has to be used. And for it to be used, it's gotta be embraced by, you know, the many teams, the disparate teams across your organization. So if you're not thinking about that, if you're not, um, investing in that part of it, then it's not working, right? The job is never done here. Like, you always have to be pushing out your work, just like as you think about, you know, when you release a product, it's not done when 1.0 goes out the door. Like, you've got to keep investing in it and thinking about it and evolving it. And the same thing is true of a really good design system and a way of working is, the job never stops.

Dan: This is why I'm so bullish about ghost towns and graveyards is like, I've worked with so many organizations that have beautiful design systems that no one has ever used. Like, gorgeous, like, beautiful design and art direction, excellent code, well crafted, well written, well architected. No one's ever used it. So it's like, so what was the point of all that? Like, now it's just, you just, you just made, like, a museum piece. You know? 

‍Chris and Gina: Right. Right.

Dan: And like, I think that doesn't help people. That doesn't help the people that you want to use it. It doesn't even help you as the maker of that thing, because, you know, for most people who are making things, they want people to use the things that they make. So, you know, so, we gotta do it a different way if we want this stuff to really be used and be adopted.

Gina: Do you think that one of the main objections to using a design system, though... Like, I'm imagining the product leader or the team leader saying, you know, the thing that we're building is special and unique, and I can't be hemmed in by these standards. Like, we're innovating over here. We need things that your design system doesn't cover. So I just, you know what? I need to, you know, I need to think big here. I don't want to think inside of an established system. Have you heard that? Have you gotten that? Because I think sometimes teams, you know, ignore design systems for that reason. Like, you know what, we just want to blue sky, blank slate. Like, we don't want to be limited here. You know, innovation happens when you're... starts from scratch.

Dan: This is why I love stories so much. Because when we don't tell the stories and we just resort to the definitions and the, like, what it should be and the objectivity and all that stuff, I think a lot of assumptions sneak in with that. You know, that are unstated. And one of the assumptions that I see in like, almost every time, and I'm like, where did this come? Like, I wish I knew where this came from. One of the assumptions that comes in is, once we have a design system, everything that we design and build will come from the design system. 100% coverage. And I'm like, what? That seems... weird. Like, why? Why that? Why? Like...

Gina: (Laughs) Why would you assume 100% coverage? Like, that's just not... (Laughs)

Dan: Why would we do that? Like, even if we could do that, why would we do that? That seems odd. But I think that's the assumption that a lot of people have, because no one, like... People don't think that far, usually, they just go like, oh, if only we just got to the point where we had this, then we could talk about using it. And so they think, well, anything less than 100% usage or 100% adoption or 100% coverage is not good enough. And I'm like, I don't think that that's right at all. So, what I try to do with teams is, I try to give them explicit permission to do their own thing. And what I tell them is, let's start with an 80/20 rule. At the most, your interface that you're designing or building should be 80% made up of stuff in the design system. At most. If it's 40, cool. If it's ten, cool. Like, if you use one component, awesome. That's great. Like, if we saved you two weeks that you didn't have to build that thing from scratch, that's great. Our job is well done. Hopefully it helps you. Yes, you still have to do other work. You would be doing that anyway, right? So, we're not losing anything. We just saved you a week here and there. Maybe, you know, as it gets more mature, three weeks, four weeks. Awesome. That's great. And the other side of that is, and we encourage you, and we, in fact, want you to at least 20% of your interface should be designed and built from scratch by your team. Because that's what you're here for. And when I say that to teams, they go, oh yeah, that sounds cool. Like, we're fine with that.

Gina: (Laughs) Right. Right. 

Dan: You know, it makes sense.

Gina: Deal with the interesting problems. Right. Like, use the stuff that's useful, and then build the stuff that's new and important, you know. Right. That makes a lot of sense.

Dan: And then what they find is, they go, okay, 80% stuff with the design system. And then they find how difficult it is to actually power 80% of their interface with the designs, and they go, oh, but it's okay, though, that we just did 10% this time, because maybe next time we'll get to 15%. Maybe by the time we do our next sprint or our next epic or, you know, whatever that, our next project, maybe there'll be more in the design system that we could actually cover more of the stuff so that it saves us time, so that 80% of our project time is actually taken up by the 20% of interesting things that we're doing.

Chris: Exactly.

Dan: And we could actually reverse that. You know, whereas right now, we're spending 80% of our time reinventing the wheel, right? And then we only have 20% of our time to do, like, the really cool stuff that we want to do. And so, like, it just opens that door to go, like, we want you to do some cool custom stuff, and we want you to use the design system where it helps you. Like, that seems like a pragmatic approach, and I think that kind of opens the door to like, okay, so how realistic are both of those targets anyway? And what they realize is like, oh, we're not even close to any one of those. We actually can create our own split of what feels right for us. And I think that's the point. Is like, find your split that works right for you, where you're not reinventing the wheel, you're saving some time, and you get time to spend on the cool stuff, too. That seems like a good split.

Gina: The new stuff. Yeah. And I imagine in a healthy culture that has a design system practice that, you know, the new stuff or the new innovation, it's like, oh, is this a candidate to roll back into the system? Like, that'd be... 

Dan: Yes. Yes.

Gina: That would be, you know, a huge feather in my cap as a designer of this organization.

Dan: That's where true contribution comes from, right? It's like, if everything is powered by the design system, we will never make anything new and we'll never have anything to contribute back into a design system. Like...

Chris and Gina: Right. Right.

Dan: So we have to make new stuff. That's the point. 

Gina: Right. 

Dan: Otherwise our company innovation is stifled right there. The design system becomes the ceiling of innovation for our company. But it should be the floor.

Gina: I mean, there's also the opposite, I think, misperception for an executive or a leader who feels like, well, we have a great design system. We have 100% coverage. And that means that I can put a web producer or a marketing person or an editorial person, I can hand them this, you know, toolkit of components, and they can just kind of drag and drop a bunch of things onto a page and boom, we've got a new landing page. And, you know anyone... We don't need a designers anymore, because we just have these, a bunch of reusable components, right? Isn't that what that means? (Laughs)

Chris: Wah-wah.

Gina: Uh huh.

Dan: Unfortunately, that is what it has meant for a lot of organizations. And I think those are organizations... And I'm, you know, I'm overgeneralizing a bit here, but I think those are organizations who have not tackled the value that design brings to their organization. They haven't crossed that bridge. They haven't even had that conversation. So of course they're going to see it as, like, oh, this is a way that we can automate some of the work that is expensive for us. That is a commodity to us. So if they see design as a commodity in their organization, then yes, the design system is a good way to accelerate that. So they haven't had that conversation. What does design actually mean here? Because if they had that conversation, then hopefully they would realize, like, design means something more, we gotta get our designers out of the commoditized world. We gotta, we gotta stop our designers from designing tables. You know, I've met so many designers that are like, the last seven years of my career, I just designed tables. It's like, seven years?

Chris and Gina: (Laughter) 

Dan: Like, what are you talking about? You know? Like, it's so sad. And so, like, let's get them out of that work. Let's promote them into something else. Let's elevate them into doing something more than pushing pixels around. You know, some designers enjoy that, and that's cool. Let them live there. Some designers don't, but what else is there to do? You know? And so I think that's, that becomes a problem. And if organizations that haven't solved that problem or even like talked about that problem could easily see a design system as like, oh, we could just reduce our design workforce by 80% now, because we got all this stuff that designers would do anyway. You know, and I think those are the same organizations that are threatened by AI, and threatened by automation.

Gina: Yes. 

Chris: Mhm.

Dan: And, you know, I think it all kind of comes in the same package.

Gina: Yeah. Yep. 

Chris: Totally agree. So, Dan, where can people get this book? I feel like, you know, hopefully if you're listening to this, it's triggering some thoughts. You know, what I appreciated about the book is it's not academic. It's not philosophy. It's not like, here are the best ways to do it. It's the kind of stuff we're talking about. Like what are, what is the practical guidance that you can use to, you know, put a design system or this way of thinking into practice on your team, at your organization? So, I hope people connect to it. If they do, where can they get the book?

Dan: Yeah, cool. Designthatscales.com is the book's website. If you can, please buy it from my publisher, Rosenfeld Media. Support independent local small publishers, indie, you know, I think that's an important thing. That's part of the reason that I published with them. If you can't get it from them because of where you live or where they don't ship to, then you can get it on Amazon. I would hope that you do it in that order, please. If you do buy it from Rosenfeld, you get the e-book for free, too. So that's a good incentive to do that.

Chris: There you go.

Dan: So that's where you can find it. You know, designthatscales.com. And if that doesn't ship to you then you could probably find it on Amazon.

Chris: Wonderful. 

Gina: Fantastic. And I encourage everyone to subscribe to Dan's LinkedIn newsletter, and to even just check out your site at DanMall.com. So, you've made a career out of serving clients, but also just sharing what you know and what you've learned. And I just have such great respect and admiration, I've really benefited from a lot of your insights and I just appreciate it. I really appreciate it.

Chris: Absolutely.

Gina: Thank you. 

Dan: Thank you, thank you. And yeah, I think, you know, to something you said earlier, I think that's the first time that's ever been said, I got some value out of a LinkedIn newsletter.

Chris and Gina: (Laughter)

Dan: So, um, maybe I can get a LinkedIn sponsorship or something for that. I'll be the first.

Chris: There you go.

Gina: Well, we absolutely loved having you on the show today. Thank you so much for your time, Dan.

Chris: Thank you, Dan.

Gina: It was so great to catch up and talk to you. Congratulations on publishing the book. That is no small thing.

‍Chris: No, it's a huge accomplishment.

‍Gina: It's a huge accomplishment. It is a big deal.

Dan: Thank you. Thank you.

Gina: It's really great. We're going to link the book and a few other things that we discussed today and where to find Dan in the show notes. And... Yeah, thanks for everyone for listening. Chris, what is Launch? 

(Laughter)

Gina: I was supposed to do this spiel at the beginning of the show, but I didn't.

Chris: So, Launch by NTT Data is a group that does high-end, design-driven, product-led, custom software development for clients.

‍Gina: That's right.

Chris: And we love building big, beautiful platforms for the internet. We work with clients large and small. We have big enterprise clients. We have startups, we have everything in between. And we staff cross-functional teams of product managers, designers and engineers who come together to actually put great software out into the world. We're not going to give you the PowerPoint deck. We're not going to give you, you know, the guidance on how you should be doing it. We're going to ship a product. 

Gina: Working software.

Chris: And we're going to talk to your users and help you achieve something for your business. So that's what we're looking for. We love talking to people. And sometimes that starts with a conversation about a challenge. Come talk to us. We would love to have that conversation with you.

Gina: We love hearing from you. Send us a note. Catalyst@NTTdata.com. We read every one.

Chris: We'll talk to you all soon.

Gina: Bye.

(CATALYST OUTRO MUSIC)