On Theme: Design Systems in Depth

All the things you shouldn’t do for design system success, with Dan Mall — #04

• Elyse Holladay • Season 1 • Episode 4

Share episode

📲 Text the show your thoughts!

I'm thrilled to have the one and only Dan Mall on the show, and in this episode, we get deep into all the things you maybe don't want to do if you want your design system to be successful. Dan shares his experiences with failed design systems, one very failed attempt at pitching a system to leadership,  why he thinks design systems should be specific not generic and maybe... not include foundations? Plus, we talk about useless documentation, what's next for systems, and THE spiciest take on tokens.

(Honestly, there are so many 🌶️ Spicy Takes™️ in this episode, we might have to rename the show to Design System Spicy Takes!)

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!

Links & References


🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Dan Mall:

And they said because the promise of tokens is if we have tokens set up, then whenever like a rebrand comes along or we need to change the brand color, we could just flip a switch and, and the brand color will change everywhere. I'm like, cool. Can you show me how you flip that switch? Like where do we log in to flip the switch? And they'll go, no, no, like in theory, that's how it works. I'm like, okay, does it actually work though? And they're like no, we'd have to do more work to get that to happen. Like how much more work? Six months more work. How long did you spend on tokens in the first place? Like six months to a year. Okay. So you spent you spent a year and it would be a year and a half doing something that actually doesn't work right now.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today, I am super excited to have Dan Mall on the show. If you're in the design system space, you probably know of Dan from his excellent book, Design That Scales or his course, Design System in 90 Days. He ran a design agency, Superfriendly, for a decade, where he got to work on design systems and products for clients with names you definitely know, like Nike, Eventbrite, Twilio, Harvard Business School, FX, and a lot more. He's a well known speaker at more events than we have time to name here today. He's a dad who's also podcasting and writing resources to help parents raise amazing kids called Great Job. And on the side an incredible photographer Recently, Dan's been focused a lot on design system consulting and the design system in 90 days program. I really wanted to have Dan on the podcast because I love his focus on serving product teams with the system, like your ability, Dan, to cut through a lot of noise to get to the real point of why we do this work. And of course, because as a consultant, you've seen so many systems I think you should have a really, really interesting perspective. So thanks for coming to hang out with me and to chat.

Dan Mall:

Oh, absolutely. I love talking about this stuff, Elyse, thank you for inviting me, and giving me an excuse to soapbox about a lot of this.

Elyse:

Yeah we love a soapbox. I mean, if you don't love a soapbox, did you, do you even have a podcast? So one of the big questions I really want to explore on this show is what are successful design systems doing now? There's a lot of noise out there, there's a lot of jargon, there's a lot of things that you like must do, but standards or air quote design systems, if you will, have been around the design space for ever, right? I mean, we've got New York Transit Authority, we got NASA graphic standards manual It's certainly not a new concept, if we think about how do we actually describe and codify and explain to other people what this brand is supposed to be from a design perspective, and I think the newest thing in the last, 10 or 15 years has just been codifying ways to do that on the code side. I want to hear about how you see current day design systems evolving from like the design guidelines because I think in some ways modern day design systems did come from that, but I think in other ways, it came from a bunch of the code tools that we were just building to solve reuse problems, and so I'm curious how you see those things having converged into modern day design systems.

Dan Mall:

Yeah, totally. I think we definitely stand on the shoulders of the giants that came before us. A lot of good design system practices nowadays are like software development practices that have been around for decades, right? Encapsulation, composability, like those are things that programmers have been doing for a long, long, long time. And, I like that you brought up that design systems are not a new concept. The way that we execute on them today are, in the last decade or so. But, cave paintings were a design system, you know, in some respect, right? It's first icon library, I guess, right? Like this is the symbol that represents a buffalo or an arrow or, or people. And so like design system has been around for a long time. We're just now figuring out how it applies to the design tools, I think, that we're talking about, and it is, I think, a little bit disingenuine to say, oh, yeah, on the code side too this is new, because I think engineers have been doing this actually longer than digital designers or UI designers have been doing it. And we're just now applying some of those things. And what I like about that, is what you had said, in, they are converging, in that now designers as we are learning some of those things that software engineers and software developers have been doing for a while, we actually are now able to speak the same language with them. When they say encapsulation, we now know what that means. When they say composability, we now know what that means. Whereas 15 years ago, if you would have said composability to a designer, that either means something very different or means nothing at all. And so I think that I think this is really gonna unlock the next level or layer of technology and us being able to use certain language to describe things. And of course, what would a design system podcast be without talking about AI? That's what powers AI is us being able to use language to mean something that represents a whole set of ideas or a set of visual solutions that robots, machines, can actually take and go I know what that means, I'm going to represent it back to you in a bunch of different ways. So in a lot of ways, I think design systems and all of those things converging right now really is unlocking what comes for the future of technology, you know, for better or worse.

Elyse:

Yeah. And I think we're at a really interesting moment for design systems. systems had this arc of being like, we're building our own tools, we're trying to figure out new ways to build websites, first it was website right, now it's new ways to build React, software, web apps. Now we're doing multi platform, right? Before React, you couldn't put your JavaScript and your HTML and your CSS physically together, we were doing it in different layers, but we were still thinking about those concepts, like the tools have changed in a way that makes it more possible for our mental conception of, isolation or of a component of a piece of design to match reality. And I think that's so interesting because software design or web design, is one of the few, or maybe only places where designers are not working in their medium. You're painting, you're working in paint, you're drawing, you're, you're taking photos. When you are doing UI for the web or a webapp, you're making a picture that has to then be translated into its real medium, which is code. We talk so much about the design engineering gap, like bridging the gap, it's like the phrase for design systems, but that gap is only because, as designers, we're not working in our medium.

Dan Mall:

Yep. Totally agree with that. Yes, one of the toughest things that I talk to teams that I work with about is, the system part of design system just means that things are connected, right? If they're not connected, they're not a system. And so when we talk about connections, we can talk about lots of different connections in design systems, but one that's almost impossible to do right now is to literally connect design and code. Lots of startups are working on that problem right now, but you can't create a Figma file right now and connect it to a piece of React code. You can design a Figma file that inspires a piece of React code, you can design a Figma file that outputs React code that then you have to put in some other environment. You can write React code that then generates a Figma file, but those aren't real connections, those are like cause and effect things. And I think that maybe there's a spicy take, I don't know, I think that design systems are a transition phase. I think that what the next phase or the next few phases will be, is that they will allow designers to actually be working in the medium, I don't think that design and code are going to exist as two separate things anymore. You're not going to be coding and that's like real, working on the web and design is not, it's you're going to be making websites, and, and however you do that, with your voice, with gestures, with a tool, with a GUI, in code, by writing, writing machine code, however that's going to be, I think it allows us to get closer to the medium, and I think that's what design systems are teaching us, is that there is this divide in how we make things, because I think both parties are so removed from working in the medium. Maybe web engineers are closer to it. But if you think about something like iOS, or native, like those things have to be compiled. So even there, you're still not working on the medium, you're working on something that gets compiled to the medium. So we still have layers in between even code and some of the mediums that the code expresses to, I think that's gonna change, five years, 10 years, 20 years, I don't know, but I think, and I hope, that we'll get to a place where we actually get to work in the medium, whether that's through drawing or that's through writing or that's through talking or that's through gesturing, you know, however those things are gonna be. And I think that hopefully that will lead to some better products out in the world. I'm sure it will lead to worse ones, too. But I think that's part of the democratization of, of anything of any technology is, we get that proliferation of it too.

Elyse:

I think the future of oh, just generating things off of sketches, or like generating Figma off of code, I don't know, like I'm here for that future, but I want to bring it back to modern day, to right now. I want to hear about the kinds of design systems that you see as the most successful in organizations. And I know that's a really broad question because all kinds of different businesses of different sizes have different needs, and different kinds of design systems succeed in them. But what does it look like for a design system to be successful in an organization now, to actually serve its purpose and it's teams, it's business,

Dan Mall:

I'm gonna say something a little bit cryptic, but then I promise I'll qualify it, I'll walk it back a little bit. I think that the most successful design systems, at least that I've come across lately, and seen, is our design systems that are doing something. And what I mean by that is, they are not design systems that are trying to do everything or anything. They're actually trying to do something specific. And I think that's something that I'm learning a lot lately. Maybe there's something that's always been there, but it's kind of dawning on me that I think the most successful design systems that I've seen are specific and not generic. So I've been writing about this a lot lately, too, is when we think about design systems, or at least a certain type of them, we think about the, you know, the foundations, the building blocks, the atoms, the, the buttons and the cards and the footers. And those are things that are generic and abstract. And there's value in that stuff, too. But a lot of the design systems that I've seen lately and been working on, myself and consulting with teams on, we're trying to do something specific. We're trying to make dashboards. We're trying to make admins. We're trying to make marketing experiences, we're trying to make something specific, not anything possible. Cause it's one of those things where if you try to design something that's applicable to anything and everything, you're not able to do some specific thing really well. And I think a good example that I give a lot of times is like bootstrap, you know, bootstrap is an excellent tool, but it's made for, for something specific, it was made to build Twitter, right? That's what bootstrap originally was for. It was built to make Twitter, and then it was abstracted from there, and so a lot of people that use Bootstrap myself included, you end up removing more from Bootstrap than you're actually using of Bootstrap. You have to disable a bunch of things, you're like, I don't need that, I don't need that, I don't need to import this file, and you're using less of it than you're actually trying to exclude from it, and it's because it has been abstracted to be general purpose. I think the same thing a little bit of Material Design, like the originally Material Design was made to make Google products, it just so happens that there was a lot of Google products, so they were like, we might as well, bring this out to the world and let the world use it, and there's a lot of customizability and all that stuff in it, but that is because they've been able to work on it for the last 10 years. Material Design came out in 2014, and they've been working on it for that long and have built some of these things in, a lot of organizations that I work with, they're working on a design system that's supposed to have impact in the next year or two, and that means we can't build for everything. As an example, one of the organizations I've been working with for the last year, we spent the last year working on iOS messaging. That's what the design system was. It's basically it's an iOS messaging design system. There's not a lot outside of that. There are a couple of things outside of that we need, but it's specifically for that, because that was the biggest problem that needed to be solved at that organization at that time. So it was doing something. It wasn't trying to do everything, and it allowed the team to have focus. It allowed the work to be able to be evaluated. To say Oh, is it doing that particular job? Not, is it powering all of our UI ever? Which I think is such, such a big mandate that who can fulfill that.

Elyse:

My biggest pet peeve.

Dan Mall:

Yeah. So I think, the successful ones, to me are the ones that have a very specific remit to them.

Elyse:

That's so interesting because, a lot of design systems, they got started in that much more specific vein. I'm thinking about early systems that I worked on, the first design system that we built at Indeed was to get engineers to stop writing the front end in Java and start writing React. And we built it very specifically for Indeed. com, the job seeker side rather than like our employer, the employer side of Indeed, and so we built all these very specific indeed. com looking components.

Dan Mall:

Yep.

Elyse:

I think a lot of early design systems were like that because again, we were, we started building these things to solve our own problems, to solve reuse problems, to solve inconsistency problems that we were seeing in our organizations. And inevitably after the initial success of that system, we got to a point where what we were hearing throughout the organization from all these other engineers and designers was, it doesn't have the things that we need, it doesn't have employer side related components, it's too specific for job seeker. Then I think design systems as an industry, grew into to have a design system, you have all of the standard foundations, you have to build all of those things, it has to serve everybody, and that's how we got to like small teams who are trying to build like, Material internally, they're like, we don't have a real design system unless we have every standard component. Like then you have this thing internally, that's not actually serving anybody. Did you see that same kind of parallel over the last, maybe 10 years? Why do you think we're circling back around?

Dan Mall:

Oh for sure. Time is a flat circle. It's it's like we keep coming back to the same problems, because if you take that story that you just told, like, have something specific, you make something that is reasonable within that specific set of constraints, right? And it serves that really well, so what naturally happens after that is, you know, what you said? It doesn't work over here on the other side. And I think in hindsight, what we should have done as an industry to say, yeah, you're welcome, that's right. But instead, what we did was like, Oh, you're right. Okay, let's abstract it one level further so that it works for now these two places instead of this one and eventually if you keep following that all the way down, what do you end up with? You end up with HTML, right? If it does work you end up with HTML. That's what you and I think that HTML is a really smart spec, because we've been able to build things with HTML for the last 40 years, the same spec basically, you know, it's like we have HTML has not changed that much. The last big update was HTML five, right? Added a couple of tags, that we use more regularly. Cool, that's great. And things are changing now, but the initial spec remains the same. And I think what we did poorly as an industry, of course easy to say in hindsight, like what we did poorly as an industry is I think that, we got to the point where we started to optimize for the problems that we had, and then we did that, we got to that point, and then we started to pre optimize for problems that we don't have yet, but we don't want to have in the future. And it's that's where I think the slippery slope goes. It's like we started to go, what we don't want to do is we don't want to reinvent the wheel, so let's create some things that prevent us from reinventing the wheel.

Elyse:

the wheel now so that we don't have to reinvent the wheel in the future.

Dan Mall:

Which is that actually doesn't work very well as we're seeing now, we're trying to pre optimize, and again, back to software development— I think that I get a lot of inspiration from software development practices that have been long established—back to software development, you don't pre optimize. One of my favorite quotes that I use with design system teams a lot comes from Andy Grove who was CEO of Intel at one time, and in one of his management books, he said, let chaos rein, then rein in chaos. And I think that's the process of design systems. It's you have to be able to observe some amount of design debt and technical debt to be able to go, oh, we actually reinvented cards a little bit too much, okay, let's rein that in now, and that let's come up with a card pattern or a couple of them that we can use in the future. So we don't have this problem again, not so that we never have this problem in the first place. And I think that's where we are with design systems, so a lot of teams are trying to solve problems that they never even had, so how do you, you don't even have a use case yet. How do you actually solve those problems? And the only way to do that is to solve it so abstractly that it jus t doesn't really apply much to anyone. It applies equally, a little bit to everyone, but really not much to solve any specific problem. And so I think that's where we are in design systems that, that I think is starting to get tailored back a little bit.

Elyse:

There's, we'll call it a trend that I've seen around the space a little bit about your design system should have less stuff, like you should be removing things, you should be taking things out. Is that a thing that you're like talking to teams about or working with? Like, What would you say about this you should have less stuff in your system kind of trend."

Dan Mall:

I think that is a solution to a specific problem. In general, I'm in favor of it, but I want to qualify that a little bit more than that. I think it's a solution to a specific problem, which is that you overreached with your design system. So if you overreach right, then you scale back a little bit. To me, the, the preferred solution, it's it's that anecdote where it's like, when's the best, if you want shade in your front, right in your front yard, when's the best time to plant a tree 60 years ago, when's the second best time to plant a tree like today, let's go plant a tree today. So it's kind of like that. It's ideally what you do is, you plant a tree 60 years ago. Ideally, what you do is you create design systems in a way that are from products that are based in product design, you make products and you make features, and you pull things out of those product and features as they become reusable. If you do it that way, then you always have a hundred percent adoption with your design system. Basically at any point, right? Because everything that is in your design system has already been adopted before you officially made it part of the system. Now that's ideal. That doesn't always work in that way. What a lot of teams do is they start design systems by trying to solve any imaginable UI problem. Let's make cards, avatars, breadcrumbs, grids, dividers, all those things. And then what ends up happening is your design system gets 1 percent adoption because out of 100 components that you just created in advance, one of them gets used. So at that point, 1 percent of your design system is used. And I think that discourages teams. I think it's actually like a psychological problem more than it is a technical problem. I think it's man, we spent, we spent six months working on this, kit of parts or whatever you want to call, and only one out of 100 components are getting used. And I think those are the teams that are going, okay if breadcrumb hasn't been used in the last six years, why don't we remove breadcrumb? And now we went from 100 to 99, so actually, our adoption goes up in that because we've actually scaled back. And I'll admit, I do suggest this to a lot of teams when they're like, how do we prove to our stakeholders that our design system utilization is going up? I was like, remove components and statistically like using math, your adoption actually goes up if you have less components, if you just take out the ones that aren't, yeah, exactly. So it's those are the reasons that I see a lot of teams bringing those out. And you know, some of those are the ones that I recommended teams. Yeah, take them out if they're not being used, take them out. Because from a usability standpoint stuff

Elyse:

that. You have to maintain and we are all maintenance like, oh, the contribution, like keeping things up to date. It's oh why

Dan Mall:

That's a lot of stuff.

Elyse:

for? Do you see that a lot? Do you see teams trying to start design systems by building like every foundation? This is a trick question because I know that the answer is yes.

Dan Mall:

The answer is yes. And I try to fight them on it whenever you know where I can, politely, and they do fight me on it, because, I think that this is why I don't like this term foundations with design system, or at least I think it's applied to the wrong thing, that's a nuanced take on it. When we think about foundations for design systems, we often think about, like tokens and atomic level components and colors and typography, and things like that. I'm like, I don't think those are the real foundations of a design system. You can always do those later. And in fact, I consider tokens an advanced level concept in design systems, not a basic level concept.

Elyse:

say more.

Dan Mall:

It's so hard to do. It's hard to create one color, five shades of gray, the brand primary brand color, secondary brand color, and then scale that across an entire organization, centralized that, like, so I work with a ton of organizations that, when I asked them, I'm like, why did you work on tokens first? And they said because the promise of tokens is if we have tokens set up, then whenever like a rebrand comes along or we need to change the brand color, we could just flip a switch and, and the brand color will change everywhere. I'm like, cool. Can you show me how you flip that switch? Like where do we log in to flip the switch? And they'll go, no, no, like in theory, that's how it works. I'm like, okay, does it actually work though? And they're like no, we'd have to do more work to get that to happen. Like how much more work? Six months more work. How long did you spend on tokens in the first place? Like six months to a year. Okay. So you spent you spent a year and it would be a year and a half doing something that actually doesn't work right now.

Elyse:

the thing that really makes me crazy about that is when you have a full redesign or full rebrand, your patterns and your components suddenly don't make sense anymore. It's not just you're not just like changing the color scheme on top of these existing patterns. You're like, oh, we don't even do cards like that anymore, everything is totally different. I mean, look I spouted this stuff like early in the design systems—

Dan Mall:

Me too!

Elyse:

ohh, we'll like do the redesign, it'll be so easy. And I don't know if I've really ever seen that materialize, because that's not, that's not, I'm going to say it, that's not a real use case for design systems, it's not a real use case for software development. Right, when you have that big of a pivot from a design perspective, or from a product perspective, you are in a lot of ways going back to the drawing board. Your APIs don't make sense anymore. Your database structure doesn't make sense anymore. The ways that you've organized your IA doesn't make sense anymore. Your whole like visual language is different now. And only when you get extremely generic in the like Bootstrap or, maybe like Material UI, like any of these we'll call them foundational component libraries, right? Sure, like you theme it, you put a different, color on a button, whatever, and at that level, sure, you can do the the redesign air quotes, but at every other level of the organization, that doesn't happen.

Dan Mall:

I totally agree. I've worked on thousands of projects in my career. I've worked on one where we've actually done that. And that had that one had very specific constraints. It was I think 2004 or 2003, something like that, and my client was I worked at a company called Happy Cog then, one of our clients was Thompson, which we made like textbooks and stuff, and we built a whole website for them and then at the last minute, we were about to launch it, a couple weeks away from launch and then they merged with Reuters and became Thompson Reuters. And it was like, we still need to launch same deadline, but the branding needs to be updated. So it was like, okay, we changed some colors and we changed some typefaces and there was no such thing as design tokens then, we didn't build it that way, you know, it was like, all right, we'll change a couple of things in the CSS file and then that was it. That was the only product that's ever, I've ever done that way, and it was because the constraints were so specific. We had to launch, we couldn't change much, and also because the content team and the design team that were working in house there also agreed to the constraints of, we are not changing anything, even though we know we should, we'll do that after the launch. So it was like, okay, so we all had to agree to that to make that promise actually come true. You know, that was the only project I've ever done that way, out of thousands where, that promise is it's in theory, it works like you just flip the switch and everything's changes. It's not that easy.

Elyse:

So you would tell a team don't start with tokens or don't even do tokens. yes. Spicy take. I love it.

Dan Mall:

You want me to say more? I can leave it there.

Elyse:

Say more.

Dan Mall:

So part of this is just self selecting, a lot of the teams that I work with don't have a lot of experience with design systems. If they do, they don't need me to come in and help them. So a lot of those teams are often like, they haven't built their first component yet or the first set of components, partially because they're like we read your articles and you said, don't do that yet, okay, what should we do? And so they bring me in debt to help them with it. To me, to do tokens at scale is an advanced level thing, so cut your teeth on something a little bit simpler first. Cut your teeth on a component that doesn't apply to the rest of the organization, thousands of people, hundreds of products. Pick a, pick a component, size of component, that's like maybe three to five teams need this thing, and then you could work with those three to five teams. See how that process goes and then scale it. Then once you get a really good rhythm of like, all right, we've done that with a bunch of components already, you can always go back and retrofit those components with tokens. That's what's great about software development is, you can always do that. You can always refactor as long, as you've got the time built into refactor. I think that with design systems, I think a lot of times we overreach and we're overambitious about the scale. Ultimately, yes, you want the scale of it to be your entire organization and all your customers, but like the first one you build, don't don't do that's not how startups build products, and if design systems are products, Facebook did not launch to the entire world when they started. They were for Harvard University, like just for the people at one school, right? And then they expanded to other colleges and universities and then geographically and then eventually to the rest of the world. But they didn't launch to the rest of the world. So why try to launch your, your first component or your first thing that you do with design system to an entire organization? You have no idea what the governance is going to be like, what the reception is going to be like, what the adoption is going to be like, start in a small contained area, try to pick a component that's, maybe a handful of teams need. That's why I also suggest not starting with button. It's not that button's not a good component. It's that it's too overreaching, like usually buttons have multiple states and everyone needs it immediately. So so why start with that? Why not start with auto complete or the event date picker or something that's a little bit more specific just to get the rhythm going, just to understand what your practice is and then scale it scale it afterwards. So usually I use that as my argument for why not to start with tokens, it doesn't always work but that's usually my pitch.

Elyse:

I'm curious so I come from a little more of an engineering background than a design background, and the like rise of tokens as a thing in the design system space has always baffled me a little bit because there's part of me, designers, forgive me, there's part of me that's like, congrats, you invented variables.

Dan Mall:

Right.

Elyse:

Do you feel like there's a difference in this coming from design? Like design as a industry maybe is picking up on this idea of reusability and like refactoring because now you can do it in a design tool, right? Like you can have variables in Figma, so there's this sense from designers that were like, oh, what if we abstracted this? And that's very exciting. Even though that concept has been around in software engineering, is that a sense that you are getting a little bit too,

Dan Mall:

Yes. And I'm a bit torn about it. In general, I'm like, I'm here for it, I'm here for if that's what it takes for designers to learn a little bit more about how code and software works, I'm like, cool, like it sometimes it takes a concept from over there coming into your world until you're like, oh, I see, now I understand what variables are, now I understand why programmers use this and why this is valuable. So I'm generally here for that. I don't like it as an execution of design tokens, at least in that way, the, in the way that Figma has implemented it, because I think there's not enough controls and constraints around it. It's very easy. It's too easy in my opinion, in Figma, to start one day with I'm going to play with this variables concept, and by the end of the couple hours, have a thousand variables. Now what are you going to do with those? Cause the challenge with variables or tokens in programming or design has never, the challenge has never been creating them. The challenge has always been maintaining them and using them. But we don't talk about that part. We don't, there's no guidance around that in Figma. There's no guidance around how you would, you reuse, maintain, prune, like none of that's none of that functionality exists, but that's what organizations have to deal with, right? That's the hard part about tokens is all that where do I use this one when? Documentation is not enough. It's got to be built into the workflow and into the tool, so while I'm here for designers becoming closer to not just the web and the material and the metal, but also closer to how their counterparts are actually working, with concepts like variables and encapsulation and stuff like that, I'm cool with that. I think the way that they've showed up in our tools, I think, is misleading us a little bit,

Elyse:

Hmm. Question. Maybe this is like a whole can of worms, but it is my belief that design systems teams are increasingly becoming responsible for more than just building components, right? I'm seeing it also become how to help a product team think about UX, front end code guidelines, Figma skills, training I mean, accessibility, obviously, but training in things like how we do process. I know you've spoken a lot about design system guidance being too generic or like design systems in general being too generic, but I see this in docs, right? It's like a button is a clickable element where a user can do an action.

Dan Mall:

Right?

Elyse:

Literally nobody needed to read that, and I did not need to spend my time writing it. How are you seeing successful teams guide their product teams, like, how do you see successful design system teams managing this massive scope?

Dan Mall:

A couple of different ways both macro and micro. So I think in general, part of my approach to problem solving as a consultant is like, there's almost always micro things that you can do, and there's almost always macro things that you can do. And without both of those, something is missing, right? So you can solve it on the macro level, but if you're not implementing it on the day to day, it doesn't work. If you do the day to day stuff, but at the macro level, it had nothing has changed, then hard to have impact. So I try to look at both of those places to go okay, what do we need to change in both of those places? So one example on the micro side, is I try to reframe the idea of documentation, I say, let's not worry about documentation. I say that to the designers and engineers and writers that are working on the team. I say, let's not try to worry about documenting the components. I instead say, let's try to chronicle the process. And so which begs the question of like the process of what, the process of using the components. And in my, my cohort design some 90 days, we just went over this two weeks ago where I had everybody open up their design system and read through their documentation, and lo and behold, one of the designers was like, you know, reading through his button documentation, he's like a button is a clickable element that you know, and I was like, cool, who do you think that sentence is written for? And he's designers. I'm like, you think designers don't know that? And he's junior designers are like, how many junior designers are using a design system? It's zero, like none. I'm like, so why is that sentence in there? And he's I don't know. I'm like, i, that's an honest answer. I don't know. We think that's the sentence that's supposed to go and button, and sure, one sentence about that, cool, but I've seen like three paragraphs about that, like the concept of a button, like who needs to know this? This is not a, a master class, nobody's writing like a doctorate on this here. That's not what design some documentation is. So what we did as the exercise was like, why don't you teach me how to use your button? And he was like, okay, so you know, we went through the exercise, and he was like, okay, so if you're doing this, then you use the ghost button for this because the ghost button actually doesn't support— and I was like, whoa, I'm a professional designer. I've been doing this for a long time. I didn't know that about your button. It's not because I'm stupid. It's because that's the part that needed to be chronicled. When I'm trying to design this kind of button, I need to use this particular variant because this particular variant supports this thing that I'm trying to do in this use case. And it was like, Oh, that's what we're supposed to be documenting. We're supposed to be chronicling the process of using the components, not necessarily the documentation for it. I'm not saying the documentation is not important. We do need the API definitions and we need to know the parameters and all that kind of stuff.

Elyse:

But that can be

auto-generated.

Elyse:

It's the usage. It's the why.

Dan Mall:

Totally.

Elyse:

Those are the hidden things that I think almost never get written down, but that is, I think, in a lot of ways, the promise of design systems, right? Is that it helps your product teams build their UI. It helps them make these decisions.

Dan Mall:

Yes, totally. On the macro side, I think some of the stuff that you had talked about where like, design system teams are either inheriting certain things that in my opinion should not be inherited, like design standards. To me, a design system team is not inherently a design standards team, but at a lot of places there is no design standards team, so they're the closest fit. Yeah, there's the brand team, but they cover other things, right? They cover like the uniforms and all that kind of stuff too. Okay. So design standards around digital interfaces, who does that fall to? No one. And a lot of times the design system team doesn't have the discipline or the permission to say, no, we don't do that. And so one of the most difficult conversations I've had with a few teams is is around icons as an example. So I've worked with a team lately and, and no one manages, there's no icon team, that seems like it would be silly. There's also no like digital asset management team either. So it's, where do people get icons from? And a lot of times design system will go we'll do that. Why? Because we're already distributing typefaces and colors. So why not icons too? And I'm like, that's a slippery slope. What if we said we don't do icons? And it really sends the team in a tizzy where they're like, what do you mean? We can't say we don't do icons. Like, why not? Who said we had to. And they're like, what? And it's it's brain breaking to be like, but then who else would do it? It's that's a question for the organization to answer. Not for the people on the design system team. Cause that's a lot of where the burnout comes from for design system folks is, we take on too much. And then all of a sudden there's too much for us to do that we can't deliver on it. And then people go out as design systems, useless anyway. And it's no, no, no. It's because we took on too much, but we didn't feel like we had the permission to say, we can't do that and we don't do that.

Elyse:

Yes, 100%. I'm just like crazy nodding my head, I feel my bobble head doll over here. Like there's so many things that a design system touches that fall into other parts of the organization, right? Shipping icons is like front end DevOps. It's like that belongs—

Dan Mall:

right.

Elyse:

—our platform engineering team.

Dan Mall:

Yes.

Elyse:

some ways, like there's

Dan Mall:

Yes.

Elyse:

overlaps. And i've been saying this, is a Jina- ism that I've really picked up is this idea that design systems are just how we build UI now. It's just how we build web apps, it's how we build software, it touches all of those things. It goes all the way from brand to you know shipping and build, and deployment, and the idea that, a design system can be a failure is really interesting to me, if we look at it through the lens of design systems are just how we build UI now. Because, if this is just how we're building UI, there are organizations that are doing it really well, there's organizations that are doing it okay, there's organizations that are doing it pretty bad, but even an organization that's designing and shipping kind of crappy software is still actually successfully shipping software, and frankly, if they have customers, it doesn't matter if the software is kind of crappy. And especially from an early stage startup perspective, your first 10 iterations should be kind of crappy, right? If you're spending all your time making it beautiful and perfect and wonderful, you are wasting energy that could be better spent on other things, and if you have customers that really want what you're selling, they will use it even when it is kind of shitty. I think we have this idea that like a design system is somehow above it all, maybe that you could have a successful design system or a failed design system, and then you have to make a new design system on top of that. But if we're just using design systems as a tool to build UI, what does it even mean to have a failed design system? I know you've talked about like design system graveyards, you probably get brought into organizations when their design system has quote unquote failed. Tell me a little bit about how you're thinking about that concept and what you tell teams when they're like, oh, we tried to do a design system it and it failed.

Dan Mall:

Yeah.. Um, my average is that most of the organizations I work with are on their like third or fourth try at a design system. And they've considered it as we failed three times, we don't want to fail the fourth time, so we're gonna bring in some help. And so one of the first questions I ask is so what were the expectations? Because failure or success are usually against a criteria. You can't just like generally fail at what life, I don't know, like we, we failed at doing something in particular or we succeeded at doing something in particular. So what was that something in particular? And a lot of teams don't have an answer to that. They're like, we failed at powering all of the UI that our company ships. Makes sense that they've, yeah, so has every other company in the world. Google has Material Design. It is the oldest, maybe most famous design system in the world. It's great. They've been working on it for 10 years. Not all of Google is powered by Material Design. I could pull up a bunch of Google products right now that aren't powered by Material Design. So.

Elyse:

And even the ones that are, it's not a hundred percent.

Dan Mall:

Exactly. There's some custom code in there. There's some forks. There's some, there's all sorts of different flavors of it. So whose expectation was that? And a lot of times it is the teams themselves. They think that's what they're supposed to do. And then even worse, sometimes then they promise that. And it's that was always, that's the failure. I think was failing to set the right expectations about what you could do with a not dedicated team, that only had one person on it for the last six months. Of course, of course you didn't do that stuff. Who would be able to do that stuff? Be kinder to yourself, set different expectations next time. So one of the first things we do is we go, what are we not going to do? What parts of the organization are we not gonna touch for the first year or six months or quarter or whatever time frame we have? What are we gonna focus on? And the more important part of what are we gonna focus on, is what are we not gonna focus on? Let's give ourselves permission to do that by setting expectations with everybody else that we're not gonna do that thing in this time frame. Then we can evaluate whether or not we did, we succeeded or we failed. So a lot of the teams that I work with go, okay, we're gonna we're gonna work on forms for the next six months. Great. Excellent. I mentioned earlier, we're gonna work on iOS messaging for the next year. Great. So what does that mean? If somebody needs a autocomplete, for web for android, go build it on your own. We're not gonna do that. We're not doing that. We already said last year in the planning session, we already have on our road map that we're not doing that thing. So if you need it, you're not gonna get it from us, unless it's a year from now, then maybe you'll get it from us. And I think that there's a lot of fear in saying that to the organization because it feels like, yeah, but we're not like serving everybody, and but like that, what that is what makes our I've never put this together. The fact that a lot of designers are built in React, we're just reacting to things that come in, you know? And so we have to have a model that is like that just allows us to that thing, then that thing, then that thing. But what if we were a little bit more deliberate about our plan? About what we're doing and what our remit is, then we could say, did we succeed at powering 100 percent of forms at our organization? Even saying that out loud would make any stakeholder be like, you're gonna power 100 percent of our forms. Surely not 100 percent of our forms even need that, right? So what's a better number? Oh, 14 percent of our forms because we actually need to do an audit now. Okay, so and then that becomes OKRs, that becomes KPIs, and that becomes things that we could actually meet that are much more realistic. That's how every other product team does it. Why aren't we, if designs are a product, why aren't we doing that too? Why do we suddenly we're a product just like everybody else, but we're understaffed and we have to power more. That doesn't make any sense, you know? And so there's things that I think are natural to the way that we work, that we have discarded because we have to be above all of it, we have to be better. We have to be the standards bearer, we have to be all these things that no one ever said we had to be, but we wanted to be that, which is cool, we put that on ourselves, which is not cool. And then of course we're crushed under the weight of that. And so I think that a lot of it starts with us saying this is what we do and this is what we don't do. A lot of teams have never gone through that part of the process before.

Elyse:

Yeah, I love that because, I'm sure you've heard the, oh, like the broken promises of design systems, and I'm like, yeah, who's been saying who's been promising that stuff?

Dan Mall:

That's right.

Elyse:

Oh, it's going to be a, flip the switch at the redesign. Who's been saying things like, it's going to power all of our UI. It's going to, provide all this reuse, and then we have shock and horror that the executives are like, what do you mean? It's not a hundred percent of our UI?, and we're like, how could you ever think that

Dan Mall:

Yeah.

Elyse:

Because we've been going around conference talks being like a design system is going to help us have full UI consistency— I think we are the ones who made all of these promises, and I don't even mean that in a bad way, I think we had a vision of things could be better. You know, instead of having to throw a picture over to an engineer and have them rebuild it, what if it was just, consistent all across the board and reused all across the board? I mean, I think we really wanted that, and you take that to its inevitable magical fairytale conclusion in which everything is consistent and reused and maintained in a single place. And I just don't think that's even realistic.

Dan Mall:

I totally agree with that. And I also think is it even desirable? And maybe this is a spicy take, but I hate the idea of a global design system. I know that's been making the rounds lately that, oh yeah, we could make it so that we just use the same library on everything, everything we ever do. That sounds really bad for lots of reasons. As designers, we've fallen in love with this idea that efficiency and consistency equals better or equals higher quality. And it doesn't always. I've never heard that articulated before, but that seems like the sentiment, that like design systems give us efficiency and consistency in user interfaces, and so that somehow is going to equate to like, that's going to make things better for someone. Like who is that, who is that going to make things better for? And I like, I've, I've heard it and I've pitched it before too. You know, I'm as guilty as anybody else is.

Elyse:

It's very compelling.

Dan Mall:

It's totally compelling. It's a great theory, but it's like, where's, where are the examples of that happening? And if we are hard pressed to think of the examples, is it possible that we could be wrong about that promise? Like maybe.

Elyse:

Yeah. I mean, I see this in engineering, the, I think this is like the promise of React, right? It's going to be performant, it's going to be better. We can do this rerendering and it's like, software apps are getting bigger and more bloated, the reuse promises are not there, the performance promises are not there, and everybody's still oh, but React is amazing, and it's like doing all of this modern stuff. And I'm like, oh, I'm going to like, stop for a second and look at these things to be like who is this easier for? And a lot of times it's us, it's the engineers or the designers. It's not actually the end result or the end user.

Dan Mall:

Yeah, and a lot of times it's not even easy for us. That's the, that's part of the irony of it is Even for designers and engineers, we're also complaining about it. We're also like, ugh, this, this is worse. We made this bed, you know, more and more I'm leaning more toward, if we can solve small problems then we can figure out how to scale those, and I think the things that needs a little bit correction, I think, is we've jumped to trying to solve really big problems at scale immediately. And we've skipped the part where it's we need to test those things in a small constrained area first and see if it works, and then we can figure out how to scale it. I have been guilty, and people like, like me and like us are also guilty of spreading that message that just turned out to be not true.

Elyse:

Yeah, I think in our defense, we wanted it to be true.

Dan Mall:

Oh, for sure. For sure. Yes.

Elyse:

Just thinking personally about your long career in design systems and in design in general, tell us about a moment or an experience that really shaped your opinions or your mindset about design systems.

Dan Mall:

You want positive or negative?

Elyse:

Either one. I'm just thinking about cause I know I have a couple where I'm like, if I had not gone through that, I would be thinking about design systems really differently, like that absolutely changed the way that I do my work. It changed the way that I see the value of design systems in organizations, just like these really pivotal moments that we have in our career that are like that really shaped how I think about this.

Dan Mall:

Um, I worked with an organization a couple of years ago. We were doing some e- commerce work, right? The design system work was around the e commerce, and that was that company that I worked with had some of the best telemetry data team that I've ever worked with. So we were able to do things like, okay, let's project and extrapolate, if we're able to save like this many hours using design systems or this many components, like what would we unlock? And so the telemetry team did a bunch of projections and, some data science stuff that's, I don't know, and they were like, we project we'll save about a hundred to 200,000 hours of work over this time period, which will probably unlock anywhere from a hundred to 250 million of additional revenue 250 million dollars!?. That's that's the largest number I've ever worked with So I was like, giddy and excited, and like we've got the pitch. And part of what we were doing was putting together a presentation to the executive leadership team, and I was like this is a no brainer, why wouldn't we do this? Why wouldn't we invest in this? Walk in the meeting and our team, you know, pitched all this stuff to one of the executive leaders, I think it was like in the CTO or, somewhere in technology group, and I was like, this is what we unlock, this is what happens, if we invest in this way, and this is what the plan would be, and he was like, Dan, what, why do you think we should do it this way? And I was like as opposed to what other way? He's like, well, the way that we'd been doing it before, like why shouldn't we do it that way? I was like cause. I've seen a lot of results this other way. And he's like, yeah, I don't know if we're gonna do that. And I didn't have a rebuttal to that because, it's an opinion, it's not like, we weren't talking facts against each other. He was just like, yeah, I don't think we're gonna do that. And I was like, okay. And that was the end of the meeting. The meeting ended like shortly after that. And the impression that made on me, you know, first I was like sad and the team was like shocked, and it was like, sometimes no matter what data you have, the thing is just not going to convince. It's not going to be the thing. And so what I would have been inclined to do is I'm going to put my head down again and we're going to redo this, and it was like, it's actually not worth it to do that. We have to find some other way around this. I give a lot of credit to the team for just pivoting around that and going okay, I know we worked on this presentation for the last seven weeks and we pulled all this telemetry and all this data and all this stuff, but we have to come up with a different way that we can actually be valuable for this organization. And that to me showed a lot of resilience, that that particular team had, which is why they were as successful as they were and had been, prior to me being there too. Like that to me was like a big mindset shift for me, cause I thought if we just had a good enough pitch, of course, everybody's going to say yes to it. And it was like, we had the pitch was, it was solid. And he was just like, no, you know, and I don't know why he said no. There might have been competing incentives. There might have been some ego involved. There might have been some facts that I was unaware of, and the team was unaware of, like a whole host of circumstances that could have contributed to that. That taught me that no matter how good the pitch is, sometimes that's just not the way to do it. And I think we spent a lot of time on, if we could find the one metric, we unlock this amount of money or is it like if we could find the thing that, that's the thing, and sometimes it is and sometimes it's not. And that moment was really important for me in my career to just figure out that we have to have multiple ways to go about this. You know, it can't be the one way. If it's not components, go do something else. One of the teams that I'm working with recently, I had a call earlier this week where the product owner said to me I thought we were doing pilots, I'd like you kept saying we need to pilot and we need to do all this stuff and I was like, we tried that it didn't work. So we're doing this other thing and they're like, yeah, but that doesn't that go against your whole like approach to design system? I'm like, it does. But if it doesn't work, we got to try something else. And they're like, Oh, interesting. There are things that are likely, to get done in design systems, but there is not a formula for how design system work gets done, just like there's no formula for how you would do a project or ship a product or create a company. And it's not like you do this thing and that thing, and then you have success. You can do those three things and still not have success. So you know, that was a, that was an important one for me because I thought look at these numbers, these are so good. And and it didn't turn out to be the thing.

Elyse:

That's a good takeaway. We got very distracted by this idea of a metric. It's if we have the one right metric, then the executives will get it. And I think, from down in the weeds, we feel like it's very self evident that a design system is going to be successful, right? Like I've been making this joke, you build a design system and then you shake it hard enough and efficiency falls out. And it's that's what we thought was, did we really think that's what was going to happen? And we just thought it was so self evident, but, if we're just using design systems as a tool to build UI, there are lots of ways to go about it and lots of ways to do that successfully. And there's no one. Like single perfect playbook way to do it.

Dan Mall:

I wish there was.

Elyse:

I wish there was. We're trying to, we're trying to see what people are doing and see what kind of playbooks plural that we can write about doing this. So, last couple of questions, I feel like we've talked a lot about the current state, but you also mentioned a number of things that I thought were really wonderful about the future of design systems. And I think that's we've seen this like up and down for systems of just like building our own tools and like peak design systems, and now we're like, maybe some of these things are like, not as good or they're not like delivering— what is something that you are really excited about for the future of design systems or the design system industry?

Dan Mall:

Maybe it's top of mind because this is the last conversation I just had right before I recorded this, but I was talking to a design system product owner who is about to walk into her executive's office and show them a prototype of a future product in their business that the design system team was able to put together and prototype very, very quickly. And I was like, this is gonna be game changing for them, I think. And I think that design system teams are well suited, maybe the only team suited, to be able to connect the dots of an organization, right? Like a lot of times, a lot of these, new apps or new lines of business, they come from like R and D teams or skunk works teams, but those teams are actually not as well suited as the design team, because they're usually off in a corner. They're not distracted by or encumbered by the rest of the organization, that's the advantage. But design system teams have a different advantage in that they know what every team is doing, or they should, because they're like looking what they're doing and they're doing and they're doing and they see all these dots and they are one of the only ones able to connect it. And that's what, this product owner that I was talking to, she's starting to connect the dots there to go, oh, I see what's coming up. I see what people are doing and I see how we get ahead of that. Like I see how this if we do this, it shapes the next five years of our business and it's like, she's not a business analyst, she's not a strategist, she's not a VP, she's not any of those things, she's someone that is actually working on in the trenches of what is being made. And that's one of the best viewpoints for knowing where a business can go, if you're able to see that thing. And I think design system teams are well suited for that. We're just stuck in but how many tokens should we have? Like it's such a, it's such a low level question as compared to if we elevate, if we are able to rise above it and see and have perspective over these are the things that are happening, this is where as a business, we could go as an organization, we can go, I think there's a lot of really good opportunities there that only the design system team is able to see, if they are willing and able to see that. And so that's what I'm excited for is, I hope we get out of the discussion of like component APIs and figma variables and all this, I know it's important to the craft and to the process, I'm not saying we skip that stuff, but there's more that we can do. And I don't mean more like adding something. I'm saying like actually removing a bunch of stuff so we get to do that. That's the whole promise of design systems. Taking away the boring work so that we could actually do the important work. We never defined what the important work was. And so I think I'm lucky to be working with a few teams who are starting to define that for themselves. I think that's super exciting because I think for practitioners, to be working at a very strategic level, I think is new for a lot of organizations. Oftentimes those are VPs or those are people who are higher up that are removed from the work, and I think design system teams are in the work and able to see that. I think a lot of good stuff can come out of that.

Elyse:

That's fantastic, and this has definitely been my experience at Color currently, like I'm seeing what all the teams are doing, and so I'm seeing like where we're moving as an organization, like even just from a visual design perspective, right? I'm seeing that shift in real time in a way that, we haven't got together as a team to like codify, and I don't even know if I or anybody else could really put it into words, but I'm like seeing it move a little bit and working on components and working on products and working on things for teams that are new and coming down the line. And I think the idea of design systems as this very generalist space, you know, we think about it, it's it's a niche. It's specialist, like I'm a design system, I'm like a subset of designers and engineers. I'm like, I think this is the most generalist space in all of software and design. You're touching everything. You're in the code, you're in the design, you're in design standards, you're in content, you're in shipping icons, like deployment, like you're in everything. And so being able to pull that up and say, how is this actually shaping how we build UI? How is this shaping how we do design, how we do design process? How is this shaping the products that we're building? How is this shaping the experience of a user using our products and like where they go next, and how we move the organization forward in the way that we build UI. I think it's a really it kind of beautiful space to be in.

Dan Mall:

Yes, absolutely. I love that.

Elyse:

I love that too. I feel like we've had a number of spicy takes, so I don't know if there's anything else to add to this question, but tell us a Dan Mall spicy take on design systems.

Dan Mall:

Oh boy. Yeah, we covered a few here. Um, maybe the most infuriating one is that design tokens are an advanced level concept. I guess maybe the umbrella version of that is that, foundations are not worthwhile, uh, to to invest in. That's probably the one that I think rubs rubs a lot of people the wrong way.

Elyse:

I love it. That's going to be the lede.

Dan Mall:

Okay, I like it. And it's not clickbait either. It's actually something that we talked about.

Elyse:

You're like, no I believe that. I know.

Dan Mall:

I do.

Elyse:

Dan, thank you so much. This was a delight of a conversation. This was so fun to record and so fun to chat with you. Thank you so much for coming on the show, doing this with me. And thank you for all of your multiple spicy takes. I'm going to rename this show design system spicy

Dan Mall:

honestly. I like it. Hopefully I will be culprit number one and all that.

Elyse:

Yes. Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!