Season 2
|
Episode 6
What designers get wrong about design systems
Dan Mall
Founder @ Design System University
Aug 31, 2023
Aug 31, 2023
|
54:15
54:15
music by Dennis
About this Episode
If you’re familiar at all with design systems then I definitely don’t need to introduce you to Dan Mall. He’s as OG as it gets.
In this Deep Dive, Dan shares his take on Figma variables, where design systems are headed in the coming years, and a lot more… 👀
Dan shared a lot of ideas that definitely challenged my thinking on design systems and even AI (hence the title 😅) so I think you’ll really enjoy this episode.
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 6K+ designers
HC
HC
HC
HC
Deep Dives
Get every episode
Free lessons from 👇
Fonz Morris
Lead designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 6K+ designers
HC
HC
HC
Transcript chapters
The problem with too many tools and too few rules
[00:00:00] Dan: I have so many split opinions about variables specifically the figma implementation of it, tokens as an idea in general. I have like things that I'm super excited about and then things that I don't know conservative about
[00:00:12] Dan: So for one the dynamic flipped really quickly. And one of the things that I say when I work with teams and when I'm like coaching people is I think we need an equal balance of tools and rules. And for a long time, we've had so many rules about design tokens and no tools at all.
[00:00:26] Dan: In the last year or two, we've seen great plugins like token studio being the, one of the most popular ones, like those are tools that start to match our rules. And then all of a sudden Figma drops this big function which is awesome and powerful and all of a sudden we don't have enough rules to match that. in my work with teams, one of the things that I see is that the functionality is so good that you can easily create thousands of tokens. And so now we actually don't have enough rules to manage what's going to prevent us from creating thousands of tokens.
[00:00:55] Dan: Like we don't, we can't even name things. Well, so how are we going to name? A thousand [00:01:00]things and then know what they're called and remember what they're called and have other people create them the same way. Like we don't have rules to match that. I was part of the Figma variables beta and my piece of feedback was like what can we do to prevent people from creating thousands of tokens?
[00:01:13] Dan: And the answer is do we want to? I don't know, but what are the ramifications of that for a team that suddenly now has really powerful thousands of tokens in their files that they have to contend with?
[00:01:23] Ridd: I mean, not only that, it's like, it almost feels like we're incentivizing teams to maybe not over architect, but definitely think deeply about what the scalability could be right out of the gate because the cost of getting it wrong with the way that the feature is currently built is pretty high. Like, if you wake up 6, 12, 18 months from now and realize, shoot, I didn't really structure these libraries the right way or I should have thought about these primitives a different way.
[00:01:50] Ridd: We're talking massive amounts of effort. And so it's like daunting. I mean, I'm kind of in the same boat and I feel a little bit better hearing you talk because I'm also thinking about [00:02:00] how to teach this. And I'm like, it's like the ultimate, it depends ever,
[00:02:05] Dan: right,
[00:02:05] Ridd: know, it's like, geez, there's so many different things or, or, uh, outcomes that you would need to take into account when you're looking at your team and, and it's really feeling like.
[00:02:17] Ridd: It's difficult to take baby steps into the feature. You kind of just got a full adopt, which is a little bit scary.
[00:02:23] Dan: I think a lot of our tools are, and rightly so, you know, open ended enough that like you could paint yourself into a really tough corner or you can make something really powerful. It's up to you. It's all in your hands. And that's one of the gripes that I have about tools in general is that they don't help us to take baby steps.
[00:02:37] Dan: One of my soap boxes that I get on with design systems is that, you know, people say, design systems are products. Why don't we do it like, Startups build products then. How do startups do it? They work with one team, and they try to make one feature, and then if that works really well, then they scale that to more customers or things like that.
[00:02:53] Dan: Why don't we do that with design tokens? Why don't we try to make one one set of tokens, six tokens? Six variables, [00:03:00] whatever and then see if that works for three teams, or six teams, or twelve teams, before we make a thousand. There's nothing in Figma or Sketch or in plugins or Photoshop, whatever the tools are that say. I don't know. Do you want to wait to create these other, you know, 900 before, you know, you want to try to use these six out first? Like I wish that there was some of that friction built in . Maybe I'll build a plugin that's like, you know, stops you in your tracks.
[00:03:23] Dan: So it's like, Hey, hang on a sec before you do that, you might want to do something else. You might want to see how this works first maybe we'll call it the scale plug. I think we're coming up with a product idea here, but like, like I want the tools to have that kind of friction built into them to prevent us from doing bad things because we don't even know what the bad things are. You know, we'll wake up six months later and be like, what monstrosity did we just create that we can not wrangle? And by that time it does take a massive refactor rather than what if we created something, knew that it was successful and then scaled that success.
[00:03:53] Ridd: One thing that is interesting about variables is they're kind of putting design systems even more in the spotlight. And now you have this [00:04:00] broad adoption of design tokens and designers everywhere are thinking about these types of design system architecture strategies potentially for the first time ever.
The problem with too many tools and too few rules
[00:00:00] Dan: I have so many split opinions about variables specifically the figma implementation of it, tokens as an idea in general. I have like things that I'm super excited about and then things that I don't know conservative about
[00:00:12] Dan: So for one the dynamic flipped really quickly. And one of the things that I say when I work with teams and when I'm like coaching people is I think we need an equal balance of tools and rules. And for a long time, we've had so many rules about design tokens and no tools at all.
[00:00:26] Dan: In the last year or two, we've seen great plugins like token studio being the, one of the most popular ones, like those are tools that start to match our rules. And then all of a sudden Figma drops this big function which is awesome and powerful and all of a sudden we don't have enough rules to match that. in my work with teams, one of the things that I see is that the functionality is so good that you can easily create thousands of tokens. And so now we actually don't have enough rules to manage what's going to prevent us from creating thousands of tokens.
[00:00:55] Dan: Like we don't, we can't even name things. Well, so how are we going to name? A thousand [00:01:00]things and then know what they're called and remember what they're called and have other people create them the same way. Like we don't have rules to match that. I was part of the Figma variables beta and my piece of feedback was like what can we do to prevent people from creating thousands of tokens?
[00:01:13] Dan: And the answer is do we want to? I don't know, but what are the ramifications of that for a team that suddenly now has really powerful thousands of tokens in their files that they have to contend with?
[00:01:23] Ridd: I mean, not only that, it's like, it almost feels like we're incentivizing teams to maybe not over architect, but definitely think deeply about what the scalability could be right out of the gate because the cost of getting it wrong with the way that the feature is currently built is pretty high. Like, if you wake up 6, 12, 18 months from now and realize, shoot, I didn't really structure these libraries the right way or I should have thought about these primitives a different way.
[00:01:50] Ridd: We're talking massive amounts of effort. And so it's like daunting. I mean, I'm kind of in the same boat and I feel a little bit better hearing you talk because I'm also thinking about [00:02:00] how to teach this. And I'm like, it's like the ultimate, it depends ever,
[00:02:05] Dan: right,
[00:02:05] Ridd: know, it's like, geez, there's so many different things or, or, uh, outcomes that you would need to take into account when you're looking at your team and, and it's really feeling like.
[00:02:17] Ridd: It's difficult to take baby steps into the feature. You kind of just got a full adopt, which is a little bit scary.
[00:02:23] Dan: I think a lot of our tools are, and rightly so, you know, open ended enough that like you could paint yourself into a really tough corner or you can make something really powerful. It's up to you. It's all in your hands. And that's one of the gripes that I have about tools in general is that they don't help us to take baby steps.
[00:02:37] Dan: One of my soap boxes that I get on with design systems is that, you know, people say, design systems are products. Why don't we do it like, Startups build products then. How do startups do it? They work with one team, and they try to make one feature, and then if that works really well, then they scale that to more customers or things like that.
[00:02:53] Dan: Why don't we do that with design tokens? Why don't we try to make one one set of tokens, six tokens? Six variables, [00:03:00] whatever and then see if that works for three teams, or six teams, or twelve teams, before we make a thousand. There's nothing in Figma or Sketch or in plugins or Photoshop, whatever the tools are that say. I don't know. Do you want to wait to create these other, you know, 900 before, you know, you want to try to use these six out first? Like I wish that there was some of that friction built in . Maybe I'll build a plugin that's like, you know, stops you in your tracks.
[00:03:23] Dan: So it's like, Hey, hang on a sec before you do that, you might want to do something else. You might want to see how this works first maybe we'll call it the scale plug. I think we're coming up with a product idea here, but like, like I want the tools to have that kind of friction built into them to prevent us from doing bad things because we don't even know what the bad things are. You know, we'll wake up six months later and be like, what monstrosity did we just create that we can not wrangle? And by that time it does take a massive refactor rather than what if we created something, knew that it was successful and then scaled that success.
[00:03:53] Ridd: One thing that is interesting about variables is they're kind of putting design systems even more in the spotlight. And now you have this [00:04:00] broad adoption of design tokens and designers everywhere are thinking about these types of design system architecture strategies potentially for the first time ever.
The future of design systems 5 years from now
[00:04:11] Ridd: And even turning around and looking back over the last year, maybe two years, it kind of feels like design systems have been having their moment. And I'd love to know, do you think that we'll be talking more or less about design systems in five years?
[00:04:29] Dan: I think we will be talking about design systems more in two years and then not at all in five years. I'm terrible at predictions, so who knows if I'm right about that, but I think the trajectory that I see is it's close to like responsive design. Like we don't talk about responsive design anymore.
[00:04:43] Dan: It's Kleenex now. It has lost it's power as a term. In the same, like, we don't talk about CSS as much. Unless we're talking about craft and implementation and things like that. And so I think design systems are going to be that.
[00:04:54] Dan: I think one of the things that's tough about it and this is why I have a love hate relationship with Figma. And I just, tools in general, [00:05:00] is that, We're talking about incentivizing design systems to be a specific thing, which is a set of components that are wired together and connected in Figma. And so where are the engineers in that? You know, where are the product people in that? Where are the writers? Where are the content folks? Where are the QA people?
[00:05:17] Dan: Like Figma has become so much of a good tool and it is the best design tool that I think we've ever had but it incentivizes people to spend all their time in Figma because the tool keeps getting better and better.
[00:05:27] Dan: When we talk about architecting a design system, there's multiple meanings of the word design system. A design system could refer to all of the components that you have in a library in Figma and has nothing to do with code. It doesn't have anything to do with engineering, you know, or a design system could be a full product that is multidisciplinary, that has a code and a design equivalent that connects that's package manages version control like. So what design system are we talking about there? We don't even know what design system we're talking about now so it's hard to say what kind of design system we're gonna be talking about in the future.
[00:05:56] Dan: I think that Figma incentivizes us to be in Figma. That's what they do.[00:06:00] That's their job. I don't fault them for doing that , people are building full on apps in Figma, it shows the power and the potential of it. And I also think that Figma is doing some great things in like dev mode is awesome it's a big step, I think, in a direction of true collaboration on product teams
[00:06:14] Dan: But I think when we talk about design system, some people think, Oh, design system, that's all the stuff in Figma. And some people think, Oh, design system, that's all the stuff in storybook. And some people think, Oh, design system, that's our brand language
[00:06:25] Dan: and so it's all these different things.
[00:06:27] Dan: So which one of those are we going to be talking about in the future? I mean, we're, we're barely talking about any one of those right now. And I think, so I'm curious to see how all of that converges over the next couple of years.
[00:06:36] Ridd: Yeah, and like, you knew that Figma was going to make some kind of a play to extend the technical functionality of the tool. And it was kind of... Interesting to see, like, are they going to go more of the documentation collaboration route? Are we going to try to eat away at some of the things that we're doing in Storybook, for instance?
[00:06:55] Ridd: Or are we going to go maybe more of the Framer route and start to equip [00:07:00] designers to make and actively contribute to the front end? Which, in my opinion, like, ultimately, that is where the design system lives. Like, if it has to be in the front end. And so, allowing or empowering, uh, designers to make that jump.
[00:07:14] Ridd: Kind of feels inevitable, but that's one of the biggest things that I'm interested to see how it shakes out. And I think it's going to kind of determine where the lines are drawn between, well, where does the design system ultimately live? And where are we, uh, calling our attention and focusing in the future?
[00:07:32] Dan: I'm optimistic about that
[00:07:33] Dan: I have no idea what Figma's plans are. I'm not privy to any of that stuff, but looking at the direction that they've been going, it looks like they're leaning into collaboration. They needed to solve tooling and process for designers first, before they go designers and engineers.
[00:07:46] Dan: And they, and then they would have to solve that first before they go, yeah, designers and engineers and product managers so like, it makes sense to me what their roadmap, what I assume it looks like, and I hope that they get there. You know, I hope that they get to a point where it's like Figma eventually is a tool that all disciplines can use [00:08:00] equally,
[00:08:00] Dan: what do we do in the meantime to bridge that gap?
[00:08:02] Dan: I think dev mode is a great step in that direction. I think that like prior to dev mode coming out, one of the things that I would tell teams is like, who here has ever used the code thing, the code thing in Figma, like no one, because it's all like position absolute and like no, no developer actually builds that way.
[00:08:18] Dan: And with improvements to that, like they move from everything being position absolute to like Flexbox and grid and all good steps in the right direction. So I'm optimistic that that's probably stuff that they're working on and I hope that it goes in that direction.
The future of design systems 5 years from now
[00:04:11] Ridd: And even turning around and looking back over the last year, maybe two years, it kind of feels like design systems have been having their moment. And I'd love to know, do you think that we'll be talking more or less about design systems in five years?
[00:04:29] Dan: I think we will be talking about design systems more in two years and then not at all in five years. I'm terrible at predictions, so who knows if I'm right about that, but I think the trajectory that I see is it's close to like responsive design. Like we don't talk about responsive design anymore.
[00:04:43] Dan: It's Kleenex now. It has lost it's power as a term. In the same, like, we don't talk about CSS as much. Unless we're talking about craft and implementation and things like that. And so I think design systems are going to be that.
[00:04:54] Dan: I think one of the things that's tough about it and this is why I have a love hate relationship with Figma. And I just, tools in general, [00:05:00] is that, We're talking about incentivizing design systems to be a specific thing, which is a set of components that are wired together and connected in Figma. And so where are the engineers in that? You know, where are the product people in that? Where are the writers? Where are the content folks? Where are the QA people?
[00:05:17] Dan: Like Figma has become so much of a good tool and it is the best design tool that I think we've ever had but it incentivizes people to spend all their time in Figma because the tool keeps getting better and better.
[00:05:27] Dan: When we talk about architecting a design system, there's multiple meanings of the word design system. A design system could refer to all of the components that you have in a library in Figma and has nothing to do with code. It doesn't have anything to do with engineering, you know, or a design system could be a full product that is multidisciplinary, that has a code and a design equivalent that connects that's package manages version control like. So what design system are we talking about there? We don't even know what design system we're talking about now so it's hard to say what kind of design system we're gonna be talking about in the future.
[00:05:56] Dan: I think that Figma incentivizes us to be in Figma. That's what they do.[00:06:00] That's their job. I don't fault them for doing that , people are building full on apps in Figma, it shows the power and the potential of it. And I also think that Figma is doing some great things in like dev mode is awesome it's a big step, I think, in a direction of true collaboration on product teams
[00:06:14] Dan: But I think when we talk about design system, some people think, Oh, design system, that's all the stuff in Figma. And some people think, Oh, design system, that's all the stuff in storybook. And some people think, Oh, design system, that's our brand language
[00:06:25] Dan: and so it's all these different things.
[00:06:27] Dan: So which one of those are we going to be talking about in the future? I mean, we're, we're barely talking about any one of those right now. And I think, so I'm curious to see how all of that converges over the next couple of years.
[00:06:36] Ridd: Yeah, and like, you knew that Figma was going to make some kind of a play to extend the technical functionality of the tool. And it was kind of... Interesting to see, like, are they going to go more of the documentation collaboration route? Are we going to try to eat away at some of the things that we're doing in Storybook, for instance?
[00:06:55] Ridd: Or are we going to go maybe more of the Framer route and start to equip [00:07:00] designers to make and actively contribute to the front end? Which, in my opinion, like, ultimately, that is where the design system lives. Like, if it has to be in the front end. And so, allowing or empowering, uh, designers to make that jump.
[00:07:14] Ridd: Kind of feels inevitable, but that's one of the biggest things that I'm interested to see how it shakes out. And I think it's going to kind of determine where the lines are drawn between, well, where does the design system ultimately live? And where are we, uh, calling our attention and focusing in the future?
[00:07:32] Dan: I'm optimistic about that
[00:07:33] Dan: I have no idea what Figma's plans are. I'm not privy to any of that stuff, but looking at the direction that they've been going, it looks like they're leaning into collaboration. They needed to solve tooling and process for designers first, before they go designers and engineers.
[00:07:46] Dan: And they, and then they would have to solve that first before they go, yeah, designers and engineers and product managers so like, it makes sense to me what their roadmap, what I assume it looks like, and I hope that they get there. You know, I hope that they get to a point where it's like Figma eventually is a tool that all disciplines can use [00:08:00] equally,
[00:08:00] Dan: what do we do in the meantime to bridge that gap?
[00:08:02] Dan: I think dev mode is a great step in that direction. I think that like prior to dev mode coming out, one of the things that I would tell teams is like, who here has ever used the code thing, the code thing in Figma, like no one, because it's all like position absolute and like no, no developer actually builds that way.
[00:08:18] Dan: And with improvements to that, like they move from everything being position absolute to like Flexbox and grid and all good steps in the right direction. So I'm optimistic that that's probably stuff that they're working on and I hope that it goes in that direction.
How AI could impact tooling
[00:08:30] Ridd: So I had a conversation a few weeks ago with Louis Oriash, the designer advocate at Figma. And he had an interesting take on, uh, What the future of AI might look like in design tooling. Cause I think I see a lot of people talking about, well, AI is just going to empower us to generate like 10 times as many ideas and it's going to be this like ideation tool and he actually positioned it as more of a janitor or a linter that kind of cleans up after us and [00:09:00]does the mundane organization work that we don't really want to think about.
[00:09:03] Ridd: And you have some pretty interesting thoughts on AI as it relates to.
[00:09:10] Ridd: And so I'm wondering if, if you could talk a little bit about that and maybe how you see AI impacting tooling moving forward and also design systems a little bit.
[00:09:21] Dan: One of the side projects I've been working on just like quietly and like slowly for the last six months maybe is building a full design system with AI, every piece of it generated by AI, because I think that's inevitable I think that's the place we'll go with will that thing be good?
[00:09:36] Dan: Can it be good right now? Will it ever be good? I think is an interesting question that's like part of what I'm exploring. I don't know if I'll ever make that public. I intended to one day, but I'm like, I don't know if this might just be a thought exercise for me. I don't think that AI is good at ideas, like, I think humans are good at ideas because I think humans are messy and AI is not messy. It's deceivingly clean. So there's a little bit of like, I don't know that I trust you fully.
[00:09:57] Dan: I think ideas are messy [00:10:00] and they're random sometimes and they don't make sense for a while.
[00:10:04] Dan: Um, until they do, and I just don't know that AI is capable to replicate our brains
[00:10:08] Dan: I'm not an expert in any of this stuff. Like, I hear the word the words neural network, and I'm like, I mean, that sounds like an important thing, but I don't know so, like large language model it has some of the ingredients, but I don't know how you replicate the human brain.
[00:10:20] Dan: Cause the human brain is so weird and I think that's what makes cool, interesting, new novel, unique things. I'm also the kind of person who doesn't believe in, you know, original ideas. I think there's nothing new under the sun and like everything is a remix. Like I'm very much subscribed to that worldview.
[00:10:35] Dan: So I don't know that AI knows how to remix. I think what it does is remixes usual sources and expected sources in a thing that's like, Oh, that's slightly better than what I could do on my own and slightly faster. So I'm, I'm fully on board with Louie's take
[00:10:51] Dan: I think it's like an intern that never complains. And I don't say that to replace interns because I think interns have ideas. They are interns that are really good at [00:11:00] remixing very fast. And so that's what I use them for is like, as is that level of collaborator. And I think for that, they're really good. Once they start to think, I mean, I don't know, like, I don't know, the sky's the limit on that, I guess. Um, but I, I think AI is not going to replicate what humans can do.
[00:11:16] Dan: I think for a long time.
How AI could impact tooling
[00:08:30] Ridd: So I had a conversation a few weeks ago with Louis Oriash, the designer advocate at Figma. And he had an interesting take on, uh, What the future of AI might look like in design tooling. Cause I think I see a lot of people talking about, well, AI is just going to empower us to generate like 10 times as many ideas and it's going to be this like ideation tool and he actually positioned it as more of a janitor or a linter that kind of cleans up after us and [00:09:00]does the mundane organization work that we don't really want to think about.
[00:09:03] Ridd: And you have some pretty interesting thoughts on AI as it relates to.
[00:09:10] Ridd: And so I'm wondering if, if you could talk a little bit about that and maybe how you see AI impacting tooling moving forward and also design systems a little bit.
[00:09:21] Dan: One of the side projects I've been working on just like quietly and like slowly for the last six months maybe is building a full design system with AI, every piece of it generated by AI, because I think that's inevitable I think that's the place we'll go with will that thing be good?
[00:09:36] Dan: Can it be good right now? Will it ever be good? I think is an interesting question that's like part of what I'm exploring. I don't know if I'll ever make that public. I intended to one day, but I'm like, I don't know if this might just be a thought exercise for me. I don't think that AI is good at ideas, like, I think humans are good at ideas because I think humans are messy and AI is not messy. It's deceivingly clean. So there's a little bit of like, I don't know that I trust you fully.
[00:09:57] Dan: I think ideas are messy [00:10:00] and they're random sometimes and they don't make sense for a while.
[00:10:04] Dan: Um, until they do, and I just don't know that AI is capable to replicate our brains
[00:10:08] Dan: I'm not an expert in any of this stuff. Like, I hear the word the words neural network, and I'm like, I mean, that sounds like an important thing, but I don't know so, like large language model it has some of the ingredients, but I don't know how you replicate the human brain.
[00:10:20] Dan: Cause the human brain is so weird and I think that's what makes cool, interesting, new novel, unique things. I'm also the kind of person who doesn't believe in, you know, original ideas. I think there's nothing new under the sun and like everything is a remix. Like I'm very much subscribed to that worldview.
[00:10:35] Dan: So I don't know that AI knows how to remix. I think what it does is remixes usual sources and expected sources in a thing that's like, Oh, that's slightly better than what I could do on my own and slightly faster. So I'm, I'm fully on board with Louie's take
[00:10:51] Dan: I think it's like an intern that never complains. And I don't say that to replace interns because I think interns have ideas. They are interns that are really good at [00:11:00] remixing very fast. And so that's what I use them for is like, as is that level of collaborator. And I think for that, they're really good. Once they start to think, I mean, I don't know, like, I don't know, the sky's the limit on that, I guess. Um, but I, I think AI is not going to replicate what humans can do.
[00:11:16] Dan: I think for a long time.
Building a design system with AI
[00:11:17] Ridd: Can you share more about building the design system with AI? Like, how are you approaching that? What's the tool you're using? And what is the output? Anything more on that? I'm very
[00:11:25] Dan: Yeah. So, so I think, I think that AI is the fruition of a design system because the thing that we've been talking about with design systems for a long time is it's more efficient. It's more consistent. We get our time back. Well, we don't, we can't do that unless we outsource something to the design system.
[00:11:40] Dan: So that's something could, you know, manual for the last five years or 10 years, we've been talking about design systems is like, I want to outsource to the design system. The fact that I never have to design a table again. So I have to, I have to give it enough inputs here. All the things that make up a table, here's the common combinations of those things.
[00:11:58] Dan: Now, just spit that back at me [00:12:00] whenever I want it, right? Whenever I'm ready for it. So in, in, in a way, that's exactly what you do with AI. You feed it a bunch of ingredients. And it's like, cool, I got those stored. And then you ask for it back in different permutations whenever you want them. So I think that's like, to me, AI is where we've been going anyway.
[00:12:15] Dan: We just didn't know that it was called that until six months ago, until it became more popular, much more accessible for people. I think still we have to reconcile with, because I think it came faster than we thought
[00:12:24] Dan: and so that's the thing that I want to test is like, is this the thing that we've been waiting for? There have been so many experiments about this over the years, can I say into my microphone, to my computer, I want an interface that has a header and a footer and in the middle a bunch of cards that have a like icon, that each of them have an optional title with them? And then an interface just builds. Airbnb did prototypes of that in 2014, Jordan Singer who's now at Figma and, um, oh shoot, I forgot the name of his company, that got acquired. Diagram. Thank you. Like, you know, he's been doing experiments with that for years.
[00:12:58] Dan: You know, like designer [00:13:00] plugins that do that. So that's the thing that I'm testing right now. Could I say to some AI generate some documentation for this component? Here's what it looks like. Here's what it needs to do.
[00:13:09] Dan: Give me some documentation back. Could I generate the code for that, you know, with AI? Could, could I say, I need a component that does this and this and this, give me code back for that. Um, can I generate the design files for that? I need an interface that does this and this and this, give me the design for that.
[00:13:24] Dan: And I think that we already have precedent for all of those things right now. We just haven't seen them put together yet. So what does that look like when it's put together? And how quickly can I build an interface of existing things? If I feed it the right the right training data, how quickly can I get that stuff back?
[00:13:40] Dan: That's the accelerant with design systems that we've been waiting for. And are we ready for it? Or is it six months away or a year away or two years
[00:13:47] Ridd: I love, I love that you brought that up cause it does kind of feel inevitable a little bit. Like we've taken the first baby step where we have this like AI assistant it takes the shape of like typically what looks like either like a command line or a [00:14:00] you know a little intercom chat and it's like those are fine they're just manipulating text they're not really doing anything that is too spectacular in my opinion and immediately they've become commoditized and so it's like what comes next and it's like well.
[00:14:13] Ridd: When does AI start manipulating the actual interface of the product that I'm interacting with? And that's when it starts to get very, very exciting. Because it's like, well then, it's like, okay, I definitely do not believe we're gonna wake up in a world and everything's a, a chatbot and we're just chatting with AI.
[00:14:27] Ridd: That's ridiculous to me. Like there's going to be some structured set of opinionated defaults that are born out of a deep understanding of a problem. So you can build an interface that is more efficient, I fully believe that, but then... When I kind of think about, well, where does design systems go in the future, it's like, gosh, it kind of feels like maybe a world that we could live in is design systems designers are responsible for creating the building blocks that equip AI to interface with a user on a given product or, [00:15:00] or um, website or something like that.
[00:15:03] Ridd: And that starts to get pretty trippy. I mean, it's gonna be very exciting to think about being a design systems designer when You don't actually even know how far the design system can go, like it's gonna really expand the little bubble that we consider, well, the design system lives in here, you know?
[00:15:22] Dan: I fully believe that that's where we're headed. You know, where you can say to a, to a, an AI bot or something that controls a design system or is in charge of a design system, Hey, uh, build me an interface like Instagram
[00:15:33] Dan: I like that you use the word, you use the word commoditize because that's what the design system exercise is anyway, is like, it's taking the things that were, were not commodities before and commoditizing that, commoditizing that for our internal team so that we can reuse those things, you know, much easier.
[00:15:46] Dan: What I don't think that AI is going to be able to do is, is for you to give it a prompt that's like, build me a, an interface for an innovative product that changes the world. It's like, well, there's not enough inputs there yet. If there's not enough inputs to even know what, what is [00:16:00] innovative, what is changing the world mean, what is the current world, what would stand out in the world, what would resonate?
[00:16:05] Dan: Like that's the job of designers and engineers and, you know, people, humans. Um, so I think that's like, that's the upper limit. of where I think AI can, can reach. It's like, I don't think you'll be able to do that, but in order to create an interface that, you know, that is made out of commoditized parts, great.
[00:16:20] Dan: And like the more we can commoditize things that were unique and the more it elevates us to have to come up with innovative ideas. One of the, the, the best examples that I've heard of this years ago that I'm like, now, now is the time for this is I heard it from Derek Featherstone, um, in talking about accessibility.
[00:16:35] Dan: He showed me a prototype for someone who has maybe motor deficiencies, like, and they can't click on buttons that are too small, you know, with their mouse, the buttons would grow in size if it could detect that they missed the click, like they were trying to click this button, but they didn't exactly get it because they have some sort of motor deficiency, whether temporary or permanent.
[00:16:53] Dan: So the button would slightly grow in size so that it gets bigger and bigger so that you hit it
[00:16:56] Dan: now, imagine being able to do that with your voice and imagine being able to say [00:17:00] to an AI, Hey, make all the buttons a little bit bigger, you know, because people are missing them.
[00:17:03] Dan: Imagine if I could do that on its own. We just, you know, Hey, we noticed that people are missing the buttons by like five or six pixels every time you want to grow the buttons by five or six pixels to make the touch targets a little bit bigger. Yes, I do. Absolutely. You know, and the design system and the A.
[00:17:19] Dan: I. Has enough input and enough parameters to go. Yeah, we know how to grow the button by six pixels while still retaining its quality design, integrity, engineering prowess, like all of that stuff. I'm like that. That is an example of a full fruition of an A. I. Design system. In one sense, it feels like, I mean, we're right there right now.
[00:17:37] Dan: And another sense, it feels like, Oh, we're far away from that. You know, we can't, we can't even get form elements on a page quite yet. So like, you know, it's a weird time to be in, because I think we're like, we're equally like that feels like right now, as well as, I don't know, in like four years, maybe we'll be there.
[00:17:52] Ridd: Yeah. It kinda reminds me of the analogy of building like a skyscraper, where they can like throw the [00:18:00] scaffolding up in a weekend. Like you, you drive downtown and it's like, oh my gosh, this giant thing just exists, it came out of nowhere. But then it stays scaffolding for a little bit longer than you'd think, and it takes super long until the actual building is finished.
[00:18:12] Ridd: I can see it shaping up something like that, where we're kind of caught in this middle ground for longer than we think. What I'd kind of like to know is, can we dig a little bit deeper into your experience with any of the tools that you're using? Like, what tools are you using? Are they actually working?
[00:18:26] Ridd: Because I've been running similar experience, potentially, with different generative tools, and it's exciting. But I kind of walk away thinking, yeah, we're still in the first inning.
[00:18:36] Dan: I agree with that. You know, the, my TLDR is I agree with that. We're in the first inning. I think that's a really great way to put it. I don't have a ton of familiarity with AI tools, right? So a lot of them is just seeing what I see and then trying out a bunch of things. Um, it's so dependent on convention.
[00:18:53] Dan: And one of the things that I'm learning is that. Convention isn't at all, isn't all it's cracked up to be like, what is conventional, I think is [00:19:00] actually not as agreed upon as we think it is. Um, so, you know, I'll give a couple of examples and this, this isn't a direct response to the technology and tools question, but I'll get there.
[00:19:09] Dan: Like the, the W3C is trying to standardize on certain elements, right? And, and the way that they do that is an HTML elements. The way that they do that is they see what people have used over an amount of time. After a very long period of time, they go, you know, it'd be easier if we gave people an accordion element, right?
[00:19:27] Dan: So people don't have to build an accordion from scratch every time with writing a ton of JavaScript. We'll just build that natively into the browser, right? We'll just a progress bar, a dialogue box, like all of these things that used to take us a long time to be able to do, you know, there's, there's enough convention around those patterns.
[00:19:42] Dan: It's like, there are some best practices around how an accordion should work. And there, you know, there are best practices around how a modal should work. Like. If I see a modal on a site and I want to dismiss it, I want to hit the escape key. So, like, let's just build, like, enough people have that same convention that we can just, we can do that, we can build that in and know that [00:20:00] 80% of the time that'll be the right, the right choice, you know, and then we'll give people optional parameters to be able to do that.
[00:20:05] Dan: Um, I don't think that we're there in interface design as close as we think, you know, I think some elements are there, you know, and I think those are the elements that we have in HTML, and I think some are not quite there yet and new paradigms are kind of existing. So, all that to say, I don't think AI has that yet.
[00:20:20] Dan: Um, one of the things that I've learned from AI, and I'll just use ChachiBT as an example, um, ChachiBT, I forget who described this to me, I wish I could remember, but like, ChachiBT is a great BSer. It BSes all the time. Like, with everything. And the thing is, you can't tell when it's BSing or not. Until you catch it.
[00:20:39] Dan: And then it admits it freely, but there are times where I'll be like, you know, here's a piece of text, can you, can you summarize this for me? And it'll write a summary. And I'll be, and I'll be, I'll see like a sentence in there and I'll be like, where did you get this sentence from? And I'll ask, where did you get this sentence from?
[00:20:53] Dan: And ChatGPT will say, I'm sorry, I was just summarizing the topic. I wasn't actually summarizing this paragraph. [00:21:00] And it's like, well, wait a minute, bro. Like, like, can you summarize this paragraph? You know, this, this passage instead? And he goes, yeah, yeah, here's another try. And then I'm like, well, where'd you get that idea from?
[00:21:11] Dan: And it's like, again, really sorry. I was just summarizing the topic and it does the same thing with code. You know, write, write me a react component does this and this and this. And I'm like, where did you get that idea from? I'm sorry. Most times people just want to add an icon to this. So I added an icon.
[00:21:27] Dan: I'm like, I didn't ask you to add an icon, you know? And so it admits it freely. You know, it's not lying to me. It's just BS ing me because when it gets caught, it's like, sorry. Yeah, you got me. You're right. So that's what I'm finding with all of the tools is like. It's doing what it's, what the training data has said to do.
[00:21:43] Dan: It's not actually doing what you ask for yet. So that's, you know, that I'm finding that across everything. Mid journey is the same. Dolly is the same. Uh, chat GPT is the same. And these tools are getting better. Um, there are a bunch of tools that specifically are around like documentation and that you can pass training data into, you can say, you [00:22:00] know.
[00:22:00] Dan: Take these 12 websites, you know, I forget the name of these tools, take these 12 websites and then use that as a documentation. So what I've been trying is like, let me feed it material design, carbon design system, Shopify, Polaris, you know, all that, let me feed it all of that and then say. Give me some documentation for a card component.
[00:22:16] Dan: That's kind of like these and it gets closer, but again, it's just based on the, on what it assumes is convention. And I'm like, but that's not applicable to me right now. That's not what I'm trying to do. So that's where I keep running into a wall with these tools. It's like, you're doing what you think. I want you, what you think I want you to do, you're not actually doing what I'm asking for, you know, and I think there's a little, there's a, there's like some gray area in there that I'm like, as that gray area collapses, I think we'll get better results.
[00:22:42] Dan: But right now I keep getting block there where it's like, I want a card that, that, you know, I'll give, give me a design for a card, a card component or a card pattern that has two calls to action. And I just can't generate it because it doesn't know what a card pattern with two calls to action looks like.
[00:22:59] Dan: [00:23:00] You know, and it doesn't have the training data to support that. So it's like, I don't know this. And I'm like, no, this, no. And it's like, I've, and so is that a fault of the prompt? You know, for me, maybe, is that a fault of there's not enough training data to generate that thing? Maybe it's hard to tell right now, you know, what the, what the fault is.
[00:23:17] Dan: So that's where I keep getting blocked on some of those tools.
[00:23:21] Ridd: I'd like to transition just a little bit because I would be dropping the ball if I had Dan Mall on here and didn't ask you some design systems advice.
[00:23:28] Dan: Yeah. Okay. Good.
[00:23:29] Ridd: I'd like to start with a little hypothetical where instead of this big enterprise team, maybe this team has less than ten designers, no dedicated design systems designers, and they have some momentum internally, they have buy in to like Take those first steps and build a system.
Building a design system with AI
[00:11:17] Ridd: Can you share more about building the design system with AI? Like, how are you approaching that? What's the tool you're using? And what is the output? Anything more on that? I'm very
[00:11:25] Dan: Yeah. So, so I think, I think that AI is the fruition of a design system because the thing that we've been talking about with design systems for a long time is it's more efficient. It's more consistent. We get our time back. Well, we don't, we can't do that unless we outsource something to the design system.
[00:11:40] Dan: So that's something could, you know, manual for the last five years or 10 years, we've been talking about design systems is like, I want to outsource to the design system. The fact that I never have to design a table again. So I have to, I have to give it enough inputs here. All the things that make up a table, here's the common combinations of those things.
[00:11:58] Dan: Now, just spit that back at me [00:12:00] whenever I want it, right? Whenever I'm ready for it. So in, in, in a way, that's exactly what you do with AI. You feed it a bunch of ingredients. And it's like, cool, I got those stored. And then you ask for it back in different permutations whenever you want them. So I think that's like, to me, AI is where we've been going anyway.
[00:12:15] Dan: We just didn't know that it was called that until six months ago, until it became more popular, much more accessible for people. I think still we have to reconcile with, because I think it came faster than we thought
[00:12:24] Dan: and so that's the thing that I want to test is like, is this the thing that we've been waiting for? There have been so many experiments about this over the years, can I say into my microphone, to my computer, I want an interface that has a header and a footer and in the middle a bunch of cards that have a like icon, that each of them have an optional title with them? And then an interface just builds. Airbnb did prototypes of that in 2014, Jordan Singer who's now at Figma and, um, oh shoot, I forgot the name of his company, that got acquired. Diagram. Thank you. Like, you know, he's been doing experiments with that for years.
[00:12:58] Dan: You know, like designer [00:13:00] plugins that do that. So that's the thing that I'm testing right now. Could I say to some AI generate some documentation for this component? Here's what it looks like. Here's what it needs to do.
[00:13:09] Dan: Give me some documentation back. Could I generate the code for that, you know, with AI? Could, could I say, I need a component that does this and this and this, give me code back for that. Um, can I generate the design files for that? I need an interface that does this and this and this, give me the design for that.
[00:13:24] Dan: And I think that we already have precedent for all of those things right now. We just haven't seen them put together yet. So what does that look like when it's put together? And how quickly can I build an interface of existing things? If I feed it the right the right training data, how quickly can I get that stuff back?
[00:13:40] Dan: That's the accelerant with design systems that we've been waiting for. And are we ready for it? Or is it six months away or a year away or two years
[00:13:47] Ridd: I love, I love that you brought that up cause it does kind of feel inevitable a little bit. Like we've taken the first baby step where we have this like AI assistant it takes the shape of like typically what looks like either like a command line or a [00:14:00] you know a little intercom chat and it's like those are fine they're just manipulating text they're not really doing anything that is too spectacular in my opinion and immediately they've become commoditized and so it's like what comes next and it's like well.
[00:14:13] Ridd: When does AI start manipulating the actual interface of the product that I'm interacting with? And that's when it starts to get very, very exciting. Because it's like, well then, it's like, okay, I definitely do not believe we're gonna wake up in a world and everything's a, a chatbot and we're just chatting with AI.
[00:14:27] Ridd: That's ridiculous to me. Like there's going to be some structured set of opinionated defaults that are born out of a deep understanding of a problem. So you can build an interface that is more efficient, I fully believe that, but then... When I kind of think about, well, where does design systems go in the future, it's like, gosh, it kind of feels like maybe a world that we could live in is design systems designers are responsible for creating the building blocks that equip AI to interface with a user on a given product or, [00:15:00] or um, website or something like that.
[00:15:03] Ridd: And that starts to get pretty trippy. I mean, it's gonna be very exciting to think about being a design systems designer when You don't actually even know how far the design system can go, like it's gonna really expand the little bubble that we consider, well, the design system lives in here, you know?
[00:15:22] Dan: I fully believe that that's where we're headed. You know, where you can say to a, to a, an AI bot or something that controls a design system or is in charge of a design system, Hey, uh, build me an interface like Instagram
[00:15:33] Dan: I like that you use the word, you use the word commoditize because that's what the design system exercise is anyway, is like, it's taking the things that were, were not commodities before and commoditizing that, commoditizing that for our internal team so that we can reuse those things, you know, much easier.
[00:15:46] Dan: What I don't think that AI is going to be able to do is, is for you to give it a prompt that's like, build me a, an interface for an innovative product that changes the world. It's like, well, there's not enough inputs there yet. If there's not enough inputs to even know what, what is [00:16:00] innovative, what is changing the world mean, what is the current world, what would stand out in the world, what would resonate?
[00:16:05] Dan: Like that's the job of designers and engineers and, you know, people, humans. Um, so I think that's like, that's the upper limit. of where I think AI can, can reach. It's like, I don't think you'll be able to do that, but in order to create an interface that, you know, that is made out of commoditized parts, great.
[00:16:20] Dan: And like the more we can commoditize things that were unique and the more it elevates us to have to come up with innovative ideas. One of the, the, the best examples that I've heard of this years ago that I'm like, now, now is the time for this is I heard it from Derek Featherstone, um, in talking about accessibility.
[00:16:35] Dan: He showed me a prototype for someone who has maybe motor deficiencies, like, and they can't click on buttons that are too small, you know, with their mouse, the buttons would grow in size if it could detect that they missed the click, like they were trying to click this button, but they didn't exactly get it because they have some sort of motor deficiency, whether temporary or permanent.
[00:16:53] Dan: So the button would slightly grow in size so that it gets bigger and bigger so that you hit it
[00:16:56] Dan: now, imagine being able to do that with your voice and imagine being able to say [00:17:00] to an AI, Hey, make all the buttons a little bit bigger, you know, because people are missing them.
[00:17:03] Dan: Imagine if I could do that on its own. We just, you know, Hey, we noticed that people are missing the buttons by like five or six pixels every time you want to grow the buttons by five or six pixels to make the touch targets a little bit bigger. Yes, I do. Absolutely. You know, and the design system and the A.
[00:17:19] Dan: I. Has enough input and enough parameters to go. Yeah, we know how to grow the button by six pixels while still retaining its quality design, integrity, engineering prowess, like all of that stuff. I'm like that. That is an example of a full fruition of an A. I. Design system. In one sense, it feels like, I mean, we're right there right now.
[00:17:37] Dan: And another sense, it feels like, Oh, we're far away from that. You know, we can't, we can't even get form elements on a page quite yet. So like, you know, it's a weird time to be in, because I think we're like, we're equally like that feels like right now, as well as, I don't know, in like four years, maybe we'll be there.
[00:17:52] Ridd: Yeah. It kinda reminds me of the analogy of building like a skyscraper, where they can like throw the [00:18:00] scaffolding up in a weekend. Like you, you drive downtown and it's like, oh my gosh, this giant thing just exists, it came out of nowhere. But then it stays scaffolding for a little bit longer than you'd think, and it takes super long until the actual building is finished.
[00:18:12] Ridd: I can see it shaping up something like that, where we're kind of caught in this middle ground for longer than we think. What I'd kind of like to know is, can we dig a little bit deeper into your experience with any of the tools that you're using? Like, what tools are you using? Are they actually working?
[00:18:26] Ridd: Because I've been running similar experience, potentially, with different generative tools, and it's exciting. But I kind of walk away thinking, yeah, we're still in the first inning.
[00:18:36] Dan: I agree with that. You know, the, my TLDR is I agree with that. We're in the first inning. I think that's a really great way to put it. I don't have a ton of familiarity with AI tools, right? So a lot of them is just seeing what I see and then trying out a bunch of things. Um, it's so dependent on convention.
[00:18:53] Dan: And one of the things that I'm learning is that. Convention isn't at all, isn't all it's cracked up to be like, what is conventional, I think is [00:19:00] actually not as agreed upon as we think it is. Um, so, you know, I'll give a couple of examples and this, this isn't a direct response to the technology and tools question, but I'll get there.
[00:19:09] Dan: Like the, the W3C is trying to standardize on certain elements, right? And, and the way that they do that is an HTML elements. The way that they do that is they see what people have used over an amount of time. After a very long period of time, they go, you know, it'd be easier if we gave people an accordion element, right?
[00:19:27] Dan: So people don't have to build an accordion from scratch every time with writing a ton of JavaScript. We'll just build that natively into the browser, right? We'll just a progress bar, a dialogue box, like all of these things that used to take us a long time to be able to do, you know, there's, there's enough convention around those patterns.
[00:19:42] Dan: It's like, there are some best practices around how an accordion should work. And there, you know, there are best practices around how a modal should work. Like. If I see a modal on a site and I want to dismiss it, I want to hit the escape key. So, like, let's just build, like, enough people have that same convention that we can just, we can do that, we can build that in and know that [00:20:00] 80% of the time that'll be the right, the right choice, you know, and then we'll give people optional parameters to be able to do that.
[00:20:05] Dan: Um, I don't think that we're there in interface design as close as we think, you know, I think some elements are there, you know, and I think those are the elements that we have in HTML, and I think some are not quite there yet and new paradigms are kind of existing. So, all that to say, I don't think AI has that yet.
[00:20:20] Dan: Um, one of the things that I've learned from AI, and I'll just use ChachiBT as an example, um, ChachiBT, I forget who described this to me, I wish I could remember, but like, ChachiBT is a great BSer. It BSes all the time. Like, with everything. And the thing is, you can't tell when it's BSing or not. Until you catch it.
[00:20:39] Dan: And then it admits it freely, but there are times where I'll be like, you know, here's a piece of text, can you, can you summarize this for me? And it'll write a summary. And I'll be, and I'll be, I'll see like a sentence in there and I'll be like, where did you get this sentence from? And I'll ask, where did you get this sentence from?
[00:20:53] Dan: And ChatGPT will say, I'm sorry, I was just summarizing the topic. I wasn't actually summarizing this paragraph. [00:21:00] And it's like, well, wait a minute, bro. Like, like, can you summarize this paragraph? You know, this, this passage instead? And he goes, yeah, yeah, here's another try. And then I'm like, well, where'd you get that idea from?
[00:21:11] Dan: And it's like, again, really sorry. I was just summarizing the topic and it does the same thing with code. You know, write, write me a react component does this and this and this. And I'm like, where did you get that idea from? I'm sorry. Most times people just want to add an icon to this. So I added an icon.
[00:21:27] Dan: I'm like, I didn't ask you to add an icon, you know? And so it admits it freely. You know, it's not lying to me. It's just BS ing me because when it gets caught, it's like, sorry. Yeah, you got me. You're right. So that's what I'm finding with all of the tools is like. It's doing what it's, what the training data has said to do.
[00:21:43] Dan: It's not actually doing what you ask for yet. So that's, you know, that I'm finding that across everything. Mid journey is the same. Dolly is the same. Uh, chat GPT is the same. And these tools are getting better. Um, there are a bunch of tools that specifically are around like documentation and that you can pass training data into, you can say, you [00:22:00] know.
[00:22:00] Dan: Take these 12 websites, you know, I forget the name of these tools, take these 12 websites and then use that as a documentation. So what I've been trying is like, let me feed it material design, carbon design system, Shopify, Polaris, you know, all that, let me feed it all of that and then say. Give me some documentation for a card component.
[00:22:16] Dan: That's kind of like these and it gets closer, but again, it's just based on the, on what it assumes is convention. And I'm like, but that's not applicable to me right now. That's not what I'm trying to do. So that's where I keep running into a wall with these tools. It's like, you're doing what you think. I want you, what you think I want you to do, you're not actually doing what I'm asking for, you know, and I think there's a little, there's a, there's like some gray area in there that I'm like, as that gray area collapses, I think we'll get better results.
[00:22:42] Dan: But right now I keep getting block there where it's like, I want a card that, that, you know, I'll give, give me a design for a card, a card component or a card pattern that has two calls to action. And I just can't generate it because it doesn't know what a card pattern with two calls to action looks like.
[00:22:59] Dan: [00:23:00] You know, and it doesn't have the training data to support that. So it's like, I don't know this. And I'm like, no, this, no. And it's like, I've, and so is that a fault of the prompt? You know, for me, maybe, is that a fault of there's not enough training data to generate that thing? Maybe it's hard to tell right now, you know, what the, what the fault is.
[00:23:17] Dan: So that's where I keep getting blocked on some of those tools.
[00:23:21] Ridd: I'd like to transition just a little bit because I would be dropping the ball if I had Dan Mall on here and didn't ask you some design systems advice.
[00:23:28] Dan: Yeah. Okay. Good.
[00:23:29] Ridd: I'd like to start with a little hypothetical where instead of this big enterprise team, maybe this team has less than ten designers, no dedicated design systems designers, and they have some momentum internally, they have buy in to like Take those first steps and build a system.
Advice for building a robust design system
[00:23:47] Ridd: What advice do you have for them to create a system that they not only adopt, but they actually stick with over time?
[00:23:54] Dan: Can I do some live coaching here? Like, so, so, and, and turn the question back to you that like, if you were a design system team, I'm [00:24:00] okay. Okay. So the question I'd ask you is like. Let's take design system out of it for a sec. Let's say you were building a product, right? And you're, you're well suited for this question because you built products before.
[00:24:09] Dan: So if you're building a product, how would you, what would you do to answer that same question for your product? Right? Like you're, you've got momentum, you've got buy in, you've got a small team, maybe not 10 people, you got maybe two or three people with you. Um, and you're building something, right? You're building a course, you're building a SAS app, you know, you pick.
[00:24:27] Dan: What's the first thing that you would do?
[00:24:29] Ridd: Yeah, it's a good question. I would probably have enough of a baseline understanding that I could create a few different concepts and then I would schedule a bunch of conversations and get those concepts in front of people. And I would try to figure out what resonates and then probably do the exact same exercise a few times.
[00:24:48] Dan: I think that's an answer that a lot of people would give who like work at startups or make products. Almost no one gives that answer with the design system. You know what they say is, all right, let's go build a bunch of foundation. Let's do an offsite, right? Let's, let's do an offsite for a week [00:25:00] or let's spend the next three weeks and build all the foundations that we would need.
[00:25:03] Dan: Cards, footers, headers, table, like they'll build all sorts of stuff perfectly. Right. And that three weeks would turn into nine weeks most of the time. And they, they would build this V1 of a product, not V0. 1. They would build, they would try to build a V1 of a product. That's suicide for a, for a startup. That's a terrible strategy for a startup. If I can speculate here, I bet you would take a day, two days, maybe do some wire frames or some prototypes, rough, not super high fidelity, maybe not super low fidelity, somewhere in the middle.
[00:25:37] Dan: And then you go show them to a bunch of people who schedule a bunch of conversations. You go, does this work for you? If we do more of this, does this work for you? That's what I would tell that team. Stop making the foundation. Stop trying to make the perfect library first.
[00:25:49] Dan: You are making a product. So if you were to make that product, what would you do? You could exactly what you just said. You would make a couple of sketches. You'd sketch, right? Whether that's sketching and code or [00:26:00] sketching and figma. And then you would show it to a bunch of you'd schedule a bunch of conversations.
[00:26:03] Dan: You show it to a bunch of people, you get feedback on it, and then you iterate and you would do that a bunch of times until six times. And you would go, I think our accordions ready for prime time. You know, let's get 30 people in here to use it.
[00:26:13] Dan: So that's the, that's the biggest misstep that I see with teams a lot when they started design system, they go. We got to build a V1 before we released it. And I think it's because people are looking to the material designs and the Polaris's and the carbons of the world and going like, Oh, if that's what a design system is, we have to build something close to that or our version of that before we release it internally to our teams.
[00:26:33] Dan: And I don't think that that's the case at all.
[00:26:36] Ridd: Do you still subscribe to? The mental models of atomic design as much as maybe when it first came out. Like, is that still the way that people should be thinking about things? And is there still merit in like trying to identify, you know, those core atoms, separating them from the molecules and declaring that the starting point, just from a simplicity standpoint.
[00:26:55] Dan: 100%. And like, and, and let me be plain about my bias here, right? Brad Frost is a [00:27:00] good friend of mine. I've worked with him a ton of, on a ton of things. I wrote the foreword with Josh Clark for Atomic Design. So I'm super duper biased in that direction, right? So let me admit that, uh, right up front.
[00:27:10] Dan: All that said, Atomic Design is a great methodology. You know, I still use it to this day. And I think that people misinterpret what it actually means, right? At its base, Atomic Design means... Big things are made up of small things, right? Like, but so like, does that concept hold? Absolutely. Will that hold an interface design for the next hundred years?
[00:27:28] Dan: Yes, because it always has, you know, and so what Brad does, what, what Brad did in atomic design was he canonized the idea that we should build that way too. We should actually have. tools and processes and rules that that tell us about that, you know, that show us how to do that. Um, so I think that holds, I think that one of the things that people misinterpret about atomic design is they think the way that it works is small to big.
[00:27:51] Dan: You, you make all the atoms, then you put them together in molecules, then you put those together in organisms, then you put those together in templates and you put those together in pages. If you listen to how brad [00:28:00] teaches atomic design, there's two ways that he suggests.
[00:28:02] Dan: One is, you make the big stuff and then you pull it apart to get the atoms. And then the other way that he suggests it is, work on the atoms and the pages at the same time. And you sort of meet in the middle. And in the middle is where the messiest part is, right? Like in the middle is where you meet.
[00:28:15] Dan: So yeah, you could throw out organisms and this thing still holds. You could have no organisms in your, in your design system. You can have no molecules in your design system. I've met tons of teams that rename those and they say we're not using atomic designs. Like, yes, you are. You just are doing your version of it.
[00:28:29] Dan: That's fine. You know, so I very much subscribe to Tom design. It's more important than ever, you know, with tools like react. Now in react, everything is a component that goes inside and inside another component, a page is a component, a component is a component, you know, paragraph as a component. So I think it's more relevant than ever.
[00:28:46] Dan: So I still hold to it. I still teach it. I think it's a good thing to learn, especially when you're thinking about building in a systematic way.
Advice for building a robust design system
[00:23:47] Ridd: What advice do you have for them to create a system that they not only adopt, but they actually stick with over time?
[00:23:54] Dan: Can I do some live coaching here? Like, so, so, and, and turn the question back to you that like, if you were a design system team, I'm [00:24:00] okay. Okay. So the question I'd ask you is like. Let's take design system out of it for a sec. Let's say you were building a product, right? And you're, you're well suited for this question because you built products before.
[00:24:09] Dan: So if you're building a product, how would you, what would you do to answer that same question for your product? Right? Like you're, you've got momentum, you've got buy in, you've got a small team, maybe not 10 people, you got maybe two or three people with you. Um, and you're building something, right? You're building a course, you're building a SAS app, you know, you pick.
[00:24:27] Dan: What's the first thing that you would do?
[00:24:29] Ridd: Yeah, it's a good question. I would probably have enough of a baseline understanding that I could create a few different concepts and then I would schedule a bunch of conversations and get those concepts in front of people. And I would try to figure out what resonates and then probably do the exact same exercise a few times.
[00:24:48] Dan: I think that's an answer that a lot of people would give who like work at startups or make products. Almost no one gives that answer with the design system. You know what they say is, all right, let's go build a bunch of foundation. Let's do an offsite, right? Let's, let's do an offsite for a week [00:25:00] or let's spend the next three weeks and build all the foundations that we would need.
[00:25:03] Dan: Cards, footers, headers, table, like they'll build all sorts of stuff perfectly. Right. And that three weeks would turn into nine weeks most of the time. And they, they would build this V1 of a product, not V0. 1. They would build, they would try to build a V1 of a product. That's suicide for a, for a startup. That's a terrible strategy for a startup. If I can speculate here, I bet you would take a day, two days, maybe do some wire frames or some prototypes, rough, not super high fidelity, maybe not super low fidelity, somewhere in the middle.
[00:25:37] Dan: And then you go show them to a bunch of people who schedule a bunch of conversations. You go, does this work for you? If we do more of this, does this work for you? That's what I would tell that team. Stop making the foundation. Stop trying to make the perfect library first.
[00:25:49] Dan: You are making a product. So if you were to make that product, what would you do? You could exactly what you just said. You would make a couple of sketches. You'd sketch, right? Whether that's sketching and code or [00:26:00] sketching and figma. And then you would show it to a bunch of you'd schedule a bunch of conversations.
[00:26:03] Dan: You show it to a bunch of people, you get feedback on it, and then you iterate and you would do that a bunch of times until six times. And you would go, I think our accordions ready for prime time. You know, let's get 30 people in here to use it.
[00:26:13] Dan: So that's the, that's the biggest misstep that I see with teams a lot when they started design system, they go. We got to build a V1 before we released it. And I think it's because people are looking to the material designs and the Polaris's and the carbons of the world and going like, Oh, if that's what a design system is, we have to build something close to that or our version of that before we release it internally to our teams.
[00:26:33] Dan: And I don't think that that's the case at all.
[00:26:36] Ridd: Do you still subscribe to? The mental models of atomic design as much as maybe when it first came out. Like, is that still the way that people should be thinking about things? And is there still merit in like trying to identify, you know, those core atoms, separating them from the molecules and declaring that the starting point, just from a simplicity standpoint.
[00:26:55] Dan: 100%. And like, and, and let me be plain about my bias here, right? Brad Frost is a [00:27:00] good friend of mine. I've worked with him a ton of, on a ton of things. I wrote the foreword with Josh Clark for Atomic Design. So I'm super duper biased in that direction, right? So let me admit that, uh, right up front.
[00:27:10] Dan: All that said, Atomic Design is a great methodology. You know, I still use it to this day. And I think that people misinterpret what it actually means, right? At its base, Atomic Design means... Big things are made up of small things, right? Like, but so like, does that concept hold? Absolutely. Will that hold an interface design for the next hundred years?
[00:27:28] Dan: Yes, because it always has, you know, and so what Brad does, what, what Brad did in atomic design was he canonized the idea that we should build that way too. We should actually have. tools and processes and rules that that tell us about that, you know, that show us how to do that. Um, so I think that holds, I think that one of the things that people misinterpret about atomic design is they think the way that it works is small to big.
[00:27:51] Dan: You, you make all the atoms, then you put them together in molecules, then you put those together in organisms, then you put those together in templates and you put those together in pages. If you listen to how brad [00:28:00] teaches atomic design, there's two ways that he suggests.
[00:28:02] Dan: One is, you make the big stuff and then you pull it apart to get the atoms. And then the other way that he suggests it is, work on the atoms and the pages at the same time. And you sort of meet in the middle. And in the middle is where the messiest part is, right? Like in the middle is where you meet.
[00:28:15] Dan: So yeah, you could throw out organisms and this thing still holds. You could have no organisms in your, in your design system. You can have no molecules in your design system. I've met tons of teams that rename those and they say we're not using atomic designs. Like, yes, you are. You just are doing your version of it.
[00:28:29] Dan: That's fine. You know, so I very much subscribe to Tom design. It's more important than ever, you know, with tools like react. Now in react, everything is a component that goes inside and inside another component, a page is a component, a component is a component, you know, paragraph as a component. So I think it's more relevant than ever.
[00:28:46] Dan: So I still hold to it. I still teach it. I think it's a good thing to learn, especially when you're thinking about building in a systematic way.
Reasons why design systems fail
[00:28:54] Ridd: Outside of not having this lean approach in the early days, what are some of the other [00:29:00]reasons that you see commonly for why design systems fail and don't sustain adoption?
[00:29:06] Dan: I think that, that people want to do design systems the official way. That would be great. But how do you do something the official way when it's not a part of the official way that you do things right now?
[00:29:17] Dan: It can't be official because it's new. And so, what I think a lot of people try to do is they try to set it up perfectly the first time. If we do it right the first time, it'll be perfect and we don't have to go back and do it. I think that mindset is damaging. I think in product design generally, I think design systems for sure, that like, just build in time to refactor. You're going to have to. You will always have to. I've never worked with one team that got it right on the first try. So just build in the time to have a second try rather than crossing your fingers and going, but if we do it perfectly, we will not have to have a second try or a third try. That's antithetical to the idea of product design.
[00:29:54] Dan: The idea of product design is you do a thing as quickly as you can. You get in front of people, you get feedback on it and you [00:30:00] change it. You change it as many times as you need to, to keep serving the need that you're trying to make. So again, why don't we apply that to design systems, that's the other big pitfall is people go like, I want to not do anything, propose an initiative to leadership and get them to approve a half a million dollar budget for us to build out a team and have six months of free time isolated time to build this product.
[00:30:20] Dan: I'm like, what startup gets that luxury? Very few, you know, like unless, you know, unless you're an incumbent, unless you've already raised or you've like. You have to build a prototype. You have to show traction. You have to show that you have a user base and then investors will go, we will give you money to pour fuel on that fire.
[00:30:37] Dan: That's already going to accelerate it. And I think a lot of people try to get buy in to start a design system. And what I always try to say is you get buy in to continue a design system. So in order to continue something, it has to be already started. You have to be a rascal. You have to do it under the radar when no one has approved it. And yet you did it anyway. And I think that's why design systems are so hard. Where do you can find the extra time to be a rascal? You know, it's, sometimes it's non existent.
[00:30:59] Ridd: I love [00:31:00] that so much. And it kind of makes me chuckle. And I have this big smile on my face because design systems at Maven, which is like series a startup. And they were a covert operation in their early days. Like, it was like, we would be at off sites, and like, two or three people would sneak away, and be like, hey, like, let's find, let's, you wanna meet on Wednesday, and just like, make some stuff, and like, like, you know, figure out what the right little building blocks to, to chunk out are.
[00:31:23] Ridd: And so, you had me kind of cheesin over here a little bit. Uh, let's say that, you know, aft the first year or 18 months, like, everything's going right. You are... You've, you've been the rascal, you've, you've made the, the right iterative approach, you've been trying what works and experimenting and, and building up a design system over time, adoption is going well, and now you're kind of at this 18 month mark.
[00:31:50] Ridd: What are the signs that, or the signals that design systems designers can Use or look out for [00:32:00]to maybe cue themselves into the fact that like, okay, maybe we're overextending at this point. Maybe we should start thinking of how we can do less.
[00:32:06] Dan: So a, a couple of threads on that, you know, one is, um, I've had the, the privilege of talking to people who have designed systems for like five years, right? They've had it at the organization for five years. Um, and one of the things that has been surprising to me, but no longer surprising because I've seen it so much, um, is that, What a lot of those teams are doing is they are removing components from their design system, right?
[00:32:29] Dan: They like they've grown to 300 components or a hundred components or whatever it is, and then the next phase of that, after that 18 months, after that, you know, three years, Mark is like, we're going to go down to 50. And I'm like, why are you going down to 50? And they're like, well, because we can support 150, like, okay.
[00:32:46] Dan: You know, with our team of 10, you know, at this point, but we could, we could support 50 components much better at a high level. So what they're doing is they're analyzing. What are the highest impact components that we have, you know, and [00:33:00] components or patterns or whatever it is that that design system has taken on as their chart, what are the highest impact things that we have?
[00:33:05] Dan: And let's support those things fully. And what that means is they, they get to the point where they decide together, we can't cover everything. And I think that's an important point in designs. So that's why I try to teach teams to get to that point earlier. At some point you decide we just can't do everything.
[00:33:22] Dan: So can we pick the highest impact things, the highest, you know, the three components that are highest impact and a lot of organizations, they have, you know, three or 10 components that drive 60% of their product. Just work on those. You don't have to be every component. You don't have to supply every component to every product team because at that point, you just become the, the product team then.
[00:33:43] Dan: And that's not the point of design system teams. The point of design system teams are to work at scale at the highest impact points. Right? So, so that's the thing that I see with teams that are a bit more mature. You know, I've had it for a while. A lot of those teams have, like, when, when they come and talk to me, they're like, we have a hundred percent adoption of our design system.
[00:33:59] Dan: I'm like, amazing. [00:34:00] Like you, the promised land, right? And they're like, well, no, not really. I'm like, well, so what, like, so you have 100% adoption, which is what most people are shooting for. That's the goal. And yet you still have problems. Interesting. What are the problems? And they go, well, we're just not involved earlier enough.
[00:34:13] Dan: Or like, we're just, we're not even seeing any efficiency from that 100% adoption. And, and so what they're realizing is we need to be a different kind of. Uh, service to, to our product team, to our product designers and product engineers. And so they're realizing that that service is more about support.
[00:34:29] Dan: It's more about unlocking them. It's more about freeing the other teams to be able to do stuff. Um, and so if a team, you know, and, and then when I asked them like, well, what's your, what's your regret? You don't have any regrets. And all of their regrets are always, I wish we would've gotten here two years ago.
[00:34:41] Dan: I wish we would've gotten to this point two years ago. Cause imagine the good work that we could have done with that two years. Um, so, so when I work with teams, I go look at what's ahead for these teams. Why don't you try to implement that in the first six months? If you can, rather than 18 months, you know, 36 months, it's, you know, it's just a long time.
[00:34:58] Dan: So, um. [00:35:00] Accepting that you can't do everything as early as possible and then just looking for the high impact points. I think that's a worthwhile habit, you know, that becomes part of a thriving design system practice.
Reasons why design systems fail
[00:28:54] Ridd: Outside of not having this lean approach in the early days, what are some of the other [00:29:00]reasons that you see commonly for why design systems fail and don't sustain adoption?
[00:29:06] Dan: I think that, that people want to do design systems the official way. That would be great. But how do you do something the official way when it's not a part of the official way that you do things right now?
[00:29:17] Dan: It can't be official because it's new. And so, what I think a lot of people try to do is they try to set it up perfectly the first time. If we do it right the first time, it'll be perfect and we don't have to go back and do it. I think that mindset is damaging. I think in product design generally, I think design systems for sure, that like, just build in time to refactor. You're going to have to. You will always have to. I've never worked with one team that got it right on the first try. So just build in the time to have a second try rather than crossing your fingers and going, but if we do it perfectly, we will not have to have a second try or a third try. That's antithetical to the idea of product design.
[00:29:54] Dan: The idea of product design is you do a thing as quickly as you can. You get in front of people, you get feedback on it and you [00:30:00] change it. You change it as many times as you need to, to keep serving the need that you're trying to make. So again, why don't we apply that to design systems, that's the other big pitfall is people go like, I want to not do anything, propose an initiative to leadership and get them to approve a half a million dollar budget for us to build out a team and have six months of free time isolated time to build this product.
[00:30:20] Dan: I'm like, what startup gets that luxury? Very few, you know, like unless, you know, unless you're an incumbent, unless you've already raised or you've like. You have to build a prototype. You have to show traction. You have to show that you have a user base and then investors will go, we will give you money to pour fuel on that fire.
[00:30:37] Dan: That's already going to accelerate it. And I think a lot of people try to get buy in to start a design system. And what I always try to say is you get buy in to continue a design system. So in order to continue something, it has to be already started. You have to be a rascal. You have to do it under the radar when no one has approved it. And yet you did it anyway. And I think that's why design systems are so hard. Where do you can find the extra time to be a rascal? You know, it's, sometimes it's non existent.
[00:30:59] Ridd: I love [00:31:00] that so much. And it kind of makes me chuckle. And I have this big smile on my face because design systems at Maven, which is like series a startup. And they were a covert operation in their early days. Like, it was like, we would be at off sites, and like, two or three people would sneak away, and be like, hey, like, let's find, let's, you wanna meet on Wednesday, and just like, make some stuff, and like, like, you know, figure out what the right little building blocks to, to chunk out are.
[00:31:23] Ridd: And so, you had me kind of cheesin over here a little bit. Uh, let's say that, you know, aft the first year or 18 months, like, everything's going right. You are... You've, you've been the rascal, you've, you've made the, the right iterative approach, you've been trying what works and experimenting and, and building up a design system over time, adoption is going well, and now you're kind of at this 18 month mark.
[00:31:50] Ridd: What are the signs that, or the signals that design systems designers can Use or look out for [00:32:00]to maybe cue themselves into the fact that like, okay, maybe we're overextending at this point. Maybe we should start thinking of how we can do less.
[00:32:06] Dan: So a, a couple of threads on that, you know, one is, um, I've had the, the privilege of talking to people who have designed systems for like five years, right? They've had it at the organization for five years. Um, and one of the things that has been surprising to me, but no longer surprising because I've seen it so much, um, is that, What a lot of those teams are doing is they are removing components from their design system, right?
[00:32:29] Dan: They like they've grown to 300 components or a hundred components or whatever it is, and then the next phase of that, after that 18 months, after that, you know, three years, Mark is like, we're going to go down to 50. And I'm like, why are you going down to 50? And they're like, well, because we can support 150, like, okay.
[00:32:46] Dan: You know, with our team of 10, you know, at this point, but we could, we could support 50 components much better at a high level. So what they're doing is they're analyzing. What are the highest impact components that we have, you know, and [00:33:00] components or patterns or whatever it is that that design system has taken on as their chart, what are the highest impact things that we have?
[00:33:05] Dan: And let's support those things fully. And what that means is they, they get to the point where they decide together, we can't cover everything. And I think that's an important point in designs. So that's why I try to teach teams to get to that point earlier. At some point you decide we just can't do everything.
[00:33:22] Dan: So can we pick the highest impact things, the highest, you know, the three components that are highest impact and a lot of organizations, they have, you know, three or 10 components that drive 60% of their product. Just work on those. You don't have to be every component. You don't have to supply every component to every product team because at that point, you just become the, the product team then.
[00:33:43] Dan: And that's not the point of design system teams. The point of design system teams are to work at scale at the highest impact points. Right? So, so that's the thing that I see with teams that are a bit more mature. You know, I've had it for a while. A lot of those teams have, like, when, when they come and talk to me, they're like, we have a hundred percent adoption of our design system.
[00:33:59] Dan: I'm like, amazing. [00:34:00] Like you, the promised land, right? And they're like, well, no, not really. I'm like, well, so what, like, so you have 100% adoption, which is what most people are shooting for. That's the goal. And yet you still have problems. Interesting. What are the problems? And they go, well, we're just not involved earlier enough.
[00:34:13] Dan: Or like, we're just, we're not even seeing any efficiency from that 100% adoption. And, and so what they're realizing is we need to be a different kind of. Uh, service to, to our product team, to our product designers and product engineers. And so they're realizing that that service is more about support.
[00:34:29] Dan: It's more about unlocking them. It's more about freeing the other teams to be able to do stuff. Um, and so if a team, you know, and, and then when I asked them like, well, what's your, what's your regret? You don't have any regrets. And all of their regrets are always, I wish we would've gotten here two years ago.
[00:34:41] Dan: I wish we would've gotten to this point two years ago. Cause imagine the good work that we could have done with that two years. Um, so, so when I work with teams, I go look at what's ahead for these teams. Why don't you try to implement that in the first six months? If you can, rather than 18 months, you know, 36 months, it's, you know, it's just a long time.
[00:34:58] Dan: So, um. [00:35:00] Accepting that you can't do everything as early as possible and then just looking for the high impact points. I think that's a worthwhile habit, you know, that becomes part of a thriving design system practice.
How to make design systems integral to the product team
[00:35:12] Ridd: You talked about this idea of service, which kind of jumped out at me because it reminds me of something that I saw you write somewhere, which is this idea of customer success metrics within a design system. Can you unpack that for people a little bit?
[00:35:25] Dan: Yeah, totally. So like if you ask, you know, most of the people who work on design systems and you go, what's, what's the one metric for success, they go adoption. And it's like, yeah, I get that. It makes sense. Right? Like what's the one metric for a startup, you know, for the product customers? Like, sure. Yes.
[00:35:40] Dan: Without that, you're not actually a business. Right? So, so that's like table stakes. It's not really a metric of success. Once you have that, it actually unlocks, you know, some, some more possible metrics of success. So I've been in search of, you know, of a better metric than that. And one of the things that I've come across lately, I just wrote an article about this is I think A metric for success is that the design [00:36:00] system team, if I had to pick one, one that you chase, you know, and this is the only one you could chase it's that the design system team gets invited to product team kickoffs earlier that I've seen have major impact if, because what most designs and teams see is like a product team will go through their own discovery.
[00:36:19] Dan: They'll do some sketches, some wireframes, a usability testing, you know, uh, user research, all that stuff. And we'll get to the point where they're going to build that thing. And then they go consult the design system. And then the design system team is like, I mean, if you would have involved a six weeks earlier, we would have saved you all this trouble on this other thing.
[00:36:34] Dan: You actually wouldn't have had to do the research on this because we already have it. We, we, and we built it into the component itself. So like you spun your wheels, reinventing a wheel that we already have here, you know, it's in our, it's in our supply. And so the, the thing that they lament is like, I wish we would have been involved earlier.
[00:36:50] Dan: The design system teams that get involved to product kickoffs, they're more valuable to the organization because the organization sees them as like, in order to do this faster or the, or better, [00:37:00] let's consult the team that already knows what we're doing at scale.
[00:37:03] Dan: And then the, the, the next piece on top of that, if like, if you want even earlier than that, is when your design system product owner gets invited to leadership meetings, that's like, okay, we're gonna do H two planning for the year, you know, whatever, like H one planning for the year, uh, or quarterly planning.
[00:37:17] Dan: Let's talk about what features we need to release for our customers this year. You know, and the design system product owners in that meeting, raising their hand and saying, we have these things ready. We could actually ship this feature in Q one if we want to. Like now you're impacting, like, so, so those are all customer success metric and not customers of the design system, but actually customers of the organization.
[00:37:39] Dan: So if you can transcend like the design system, serving design system customers, which is, uh, designers and engineers that work there and actually like leapfrog that or connect to serving your organization's customers, the people
[00:37:53] Dan: that pay you money for the design system will not get shut down. Right? You'll always have funding because you're always considered part. It would be like saying, [00:38:00] well, we're gonna shut down I. T. here. It's like, that's inconceivable. We're gonna shut down, you know, we're gonna shut down engineering. Like, no one does that.
[00:38:08] Dan: You might re org, you might do, but you don't shut down engineering. But design systems get shut down all the time because people don't see it as valuable enough to keep around. Yeah, it's a nice to have. But if you can become integral in that, like when we do planning, we have to have a representative from the design system here because it actually informs what products and features we're going to offer to our customers.
[00:38:28] Dan: Like, I think that's a, that's a really great place to be. Not a lot of organizations get to that point.
How to make design systems integral to the product team
[00:35:12] Ridd: You talked about this idea of service, which kind of jumped out at me because it reminds me of something that I saw you write somewhere, which is this idea of customer success metrics within a design system. Can you unpack that for people a little bit?
[00:35:25] Dan: Yeah, totally. So like if you ask, you know, most of the people who work on design systems and you go, what's, what's the one metric for success, they go adoption. And it's like, yeah, I get that. It makes sense. Right? Like what's the one metric for a startup, you know, for the product customers? Like, sure. Yes.
[00:35:40] Dan: Without that, you're not actually a business. Right? So, so that's like table stakes. It's not really a metric of success. Once you have that, it actually unlocks, you know, some, some more possible metrics of success. So I've been in search of, you know, of a better metric than that. And one of the things that I've come across lately, I just wrote an article about this is I think A metric for success is that the design [00:36:00] system team, if I had to pick one, one that you chase, you know, and this is the only one you could chase it's that the design system team gets invited to product team kickoffs earlier that I've seen have major impact if, because what most designs and teams see is like a product team will go through their own discovery.
[00:36:19] Dan: They'll do some sketches, some wireframes, a usability testing, you know, uh, user research, all that stuff. And we'll get to the point where they're going to build that thing. And then they go consult the design system. And then the design system team is like, I mean, if you would have involved a six weeks earlier, we would have saved you all this trouble on this other thing.
[00:36:34] Dan: You actually wouldn't have had to do the research on this because we already have it. We, we, and we built it into the component itself. So like you spun your wheels, reinventing a wheel that we already have here, you know, it's in our, it's in our supply. And so the, the thing that they lament is like, I wish we would have been involved earlier.
[00:36:50] Dan: The design system teams that get involved to product kickoffs, they're more valuable to the organization because the organization sees them as like, in order to do this faster or the, or better, [00:37:00] let's consult the team that already knows what we're doing at scale.
[00:37:03] Dan: And then the, the, the next piece on top of that, if like, if you want even earlier than that, is when your design system product owner gets invited to leadership meetings, that's like, okay, we're gonna do H two planning for the year, you know, whatever, like H one planning for the year, uh, or quarterly planning.
[00:37:17] Dan: Let's talk about what features we need to release for our customers this year. You know, and the design system product owners in that meeting, raising their hand and saying, we have these things ready. We could actually ship this feature in Q one if we want to. Like now you're impacting, like, so, so those are all customer success metric and not customers of the design system, but actually customers of the organization.
[00:37:39] Dan: So if you can transcend like the design system, serving design system customers, which is, uh, designers and engineers that work there and actually like leapfrog that or connect to serving your organization's customers, the people
[00:37:53] Dan: that pay you money for the design system will not get shut down. Right? You'll always have funding because you're always considered part. It would be like saying, [00:38:00] well, we're gonna shut down I. T. here. It's like, that's inconceivable. We're gonna shut down, you know, we're gonna shut down engineering. Like, no one does that.
[00:38:08] Dan: You might re org, you might do, but you don't shut down engineering. But design systems get shut down all the time because people don't see it as valuable enough to keep around. Yeah, it's a nice to have. But if you can become integral in that, like when we do planning, we have to have a representative from the design system here because it actually informs what products and features we're going to offer to our customers.
[00:38:28] Dan: Like, I think that's a, that's a really great place to be. Not a lot of organizations get to that point.
Things to keep in mind when considering becoming a design system specialist
[00:38:34] Ridd: I'd like to create another hypothetical. Let's imagine for a second that I'm a mid career designer. I've been working on product teams, I like building components, and I'm kind of thinking about becoming a design systems specialist and kind of positioning that as like my trajectory. And I have some questions around just like, how do I know what my day to day actually is going to be like?
[00:38:59] Ridd: And like, is this going to be [00:39:00] something that I'm going to enjoy? Why should I not consider doing this? And also maybe even a little bit about, am I going to cap my earning potential by going down this route? Do you have any advice for me?
[00:39:09] Dan: Yeah. Meaty questions. I love that. Thank you for these. Um, okay. I'll try to remember them. Uh, remind me if I, if I forget them. So, um, the first thing I think is important is to change your mind or change your mindset. What a lot, the reason that a lot of designers want to move to a design system team is honestly for more control. They're tired of, ah, I designed this thing and it didn't show up this way in dev, or it didn't go this way in build. Or like, I designed this thing but somebody else designed this other thing that's similar to it and now we just don't have any consistency. Those are things that drive designers nuts. So, a lot of designers go, if I had more control over this, that would be good.
[00:39:50] Dan: Good for me. Good for everybody. Right? So it's well intentioned. And so they go, if I can just move one level in or up, you know, depending on where, how you see your design system, then I can control that [00:40:00] better. I can be in charge of telling everybody how this design, how this component should be used.
[00:40:06] Dan: And I think that's a bad motivation for being on a design system team. One of the mindsets that I try to tell people about design systems, a design system team is a, is a team of collectors, not creators. So. If you're, if you are going to a design system to be able to create things that everybody else has used, that's actually not the gig like be on a feature team.
[00:40:26] Dan: The feature team innovates, the feature team creates new things. The design system team is supposed to look at what all the product teams are doing and collecting those and going, Hey, everyone's doing this thing. We're going to collect it and we're going to make it easier for them to use that thing that they've created. So to me, the most successful design systems are creating as a last resort. They're not creating anything. They're just collecting stuff and recognizing and highlighting and pointing. And like, so if you don't want to be on a team like that, like that's what system work is. System work is a collection work.
[00:40:55] Dan: You know, it's, it's assembling work. It's not creation work. So that's the first thing is [00:41:00] like, if you really, if you, if you're tired of creating. Design system team is a great team for you. If you want to just collect, if you want to over, uh, if you want not oversee, but like be, have an overview, if you want to look at things, if you want to see commonalities and patterns, that's great.
[00:41:15] Dan: If you want to create things, maybe reconsider whether or not design system team is, is going to be the right place for you. If you have that, right, then, then your job then is just to, to walk the halls, you know, and collect things and, Hey, what are you working on? What's, what's this thing like, and, and connect people to each other.
[00:41:31] Dan: Like, when you see a team working on something, you go, Hey, I know another team that's working on something really similar. Maybe the two of you should connect. I'm happy to facilitate that meeting. You know, like, that's, that's the job. If you would enjoy that, it'd be great on a design system team. Um, the, the earning potential question is great.
[00:41:46] Dan: To me... It's a weird time in an industry now to talk about earning and all that kind of stuff. There are a lot of layoffs that just happened recently. You know, companies, tens of thousands of people got laid off. It's also, I've seen the most job openings that I've ever seen. So it's like, [00:42:00] it's weird. Like so many people out of jobs and also so many job openings, but also no one's hiring at the same time.
[00:42:05] Dan: Like it's, it's strange. Um, all that to say. I have seen more design system openings, um, than I think I ever have right now at this time. And in terms of earning, I think that design systems are starting to establish their place as a, an important business function and important business functions generally get paid well.
[00:42:27] Dan: That's why engineering teams get paid really well at startups and at organizations and enterprises is because it is a crucial business function. So engineers are well compensated for that. And I think to your question earlier, where design system is going to be in five years, it's going to be the way that we do things.
[00:42:41] Dan: So if you don't know how to run the design system, you actually will be at a deficit. And if you do know how to run or work on a design system, I think you'll be in a high paying, high demand job. I see design system specialists or design system designers or engineers getting paid at least as much as product designers and product engineers, if not more. There's also a lot of potential to, [00:43:00] to grow in that too. There's a lot of management roles. There's a lot of ownership roles. If you're getting tired of your job as a product designer or product engineer a design system role is a way to do the thing that you're already good at but also learn some new skills on top of that too. It helps financially, skillset wise, growth opportunity wise. I think design system is a good track for that.
Things to keep in mind when considering becoming a design system specialist
[00:38:34] Ridd: I'd like to create another hypothetical. Let's imagine for a second that I'm a mid career designer. I've been working on product teams, I like building components, and I'm kind of thinking about becoming a design systems specialist and kind of positioning that as like my trajectory. And I have some questions around just like, how do I know what my day to day actually is going to be like?
[00:38:59] Ridd: And like, is this going to be [00:39:00] something that I'm going to enjoy? Why should I not consider doing this? And also maybe even a little bit about, am I going to cap my earning potential by going down this route? Do you have any advice for me?
[00:39:09] Dan: Yeah. Meaty questions. I love that. Thank you for these. Um, okay. I'll try to remember them. Uh, remind me if I, if I forget them. So, um, the first thing I think is important is to change your mind or change your mindset. What a lot, the reason that a lot of designers want to move to a design system team is honestly for more control. They're tired of, ah, I designed this thing and it didn't show up this way in dev, or it didn't go this way in build. Or like, I designed this thing but somebody else designed this other thing that's similar to it and now we just don't have any consistency. Those are things that drive designers nuts. So, a lot of designers go, if I had more control over this, that would be good.
[00:39:50] Dan: Good for me. Good for everybody. Right? So it's well intentioned. And so they go, if I can just move one level in or up, you know, depending on where, how you see your design system, then I can control that [00:40:00] better. I can be in charge of telling everybody how this design, how this component should be used.
[00:40:06] Dan: And I think that's a bad motivation for being on a design system team. One of the mindsets that I try to tell people about design systems, a design system team is a, is a team of collectors, not creators. So. If you're, if you are going to a design system to be able to create things that everybody else has used, that's actually not the gig like be on a feature team.
[00:40:26] Dan: The feature team innovates, the feature team creates new things. The design system team is supposed to look at what all the product teams are doing and collecting those and going, Hey, everyone's doing this thing. We're going to collect it and we're going to make it easier for them to use that thing that they've created. So to me, the most successful design systems are creating as a last resort. They're not creating anything. They're just collecting stuff and recognizing and highlighting and pointing. And like, so if you don't want to be on a team like that, like that's what system work is. System work is a collection work.
[00:40:55] Dan: You know, it's, it's assembling work. It's not creation work. So that's the first thing is [00:41:00] like, if you really, if you, if you're tired of creating. Design system team is a great team for you. If you want to just collect, if you want to over, uh, if you want not oversee, but like be, have an overview, if you want to look at things, if you want to see commonalities and patterns, that's great.
[00:41:15] Dan: If you want to create things, maybe reconsider whether or not design system team is, is going to be the right place for you. If you have that, right, then, then your job then is just to, to walk the halls, you know, and collect things and, Hey, what are you working on? What's, what's this thing like, and, and connect people to each other.
[00:41:31] Dan: Like, when you see a team working on something, you go, Hey, I know another team that's working on something really similar. Maybe the two of you should connect. I'm happy to facilitate that meeting. You know, like, that's, that's the job. If you would enjoy that, it'd be great on a design system team. Um, the, the earning potential question is great.
[00:41:46] Dan: To me... It's a weird time in an industry now to talk about earning and all that kind of stuff. There are a lot of layoffs that just happened recently. You know, companies, tens of thousands of people got laid off. It's also, I've seen the most job openings that I've ever seen. So it's like, [00:42:00] it's weird. Like so many people out of jobs and also so many job openings, but also no one's hiring at the same time.
[00:42:05] Dan: Like it's, it's strange. Um, all that to say. I have seen more design system openings, um, than I think I ever have right now at this time. And in terms of earning, I think that design systems are starting to establish their place as a, an important business function and important business functions generally get paid well.
[00:42:27] Dan: That's why engineering teams get paid really well at startups and at organizations and enterprises is because it is a crucial business function. So engineers are well compensated for that. And I think to your question earlier, where design system is going to be in five years, it's going to be the way that we do things.
[00:42:41] Dan: So if you don't know how to run the design system, you actually will be at a deficit. And if you do know how to run or work on a design system, I think you'll be in a high paying, high demand job. I see design system specialists or design system designers or engineers getting paid at least as much as product designers and product engineers, if not more. There's also a lot of potential to, [00:43:00] to grow in that too. There's a lot of management roles. There's a lot of ownership roles. If you're getting tired of your job as a product designer or product engineer a design system role is a way to do the thing that you're already good at but also learn some new skills on top of that too. It helps financially, skillset wise, growth opportunity wise. I think design system is a good track for that.
Dan's design system workbook
[00:43:19] Ridd: I think this would be probably a pretty good time for mentioning, like, you have a fantastic workbook on this. Like, design systems in 90 days. Like, if you, if you are on the fence and this is something that you're either considering or, like, trying to actively invest in your ability to execute at a high level as a design systems designer, I'm going to tee you up, Dan.
[00:43:38] Ridd: Can you just give us a little bit about what they can expect to get out of that?
[00:43:41] Dan: Absolutely.
[00:43:41] Ridd: I've seen your work and I've previewed your stuff and it's just incredible.
[00:43:45] Dan: Thank you. I appreciate it. Thank you for the tip. So, um, one of the pieces of feedback that I hear from a lot of teams lately is like, Our main initiative for the rest of the year is to get a design system up and running before, before 2024. Like, so we've got three months to do this. And a lot of teams are like [00:44:00] three months is not a lot of time to do a thing. How do, how do we do that?
[00:44:03] Dan: So what I wanted to do I, I wrote a, the first version of this last year, uh, with my business partner, Crystal Vitale, like we wrote down our steps.
[00:44:10] Dan: Like if we were to build a design system in 90 days in three months, what would we do? And we ended up writing 52 different steps down. It's like the feedback that I got from a lot of people was like, I get all the theory about design. Like I know what they're for.
[00:44:22] Dan: I know they've consistency and efficiency and all that stuff. How do we do it? So I wrote that down and that's what design system in 90 days is, is like, and initially last year when I released it, it was a workbook and it was like, if you just want this, there's no theory in this book at all.
[00:44:34] Dan: There's no like, well, you want to do this because of this and this is how people were like that. You could find somewhere else you can find that on the internet. I'm, I'm writing a book about design systems now that is about the theory stuff. That's like the compliment to that. This workbook is very, very tactical.
[00:44:47] Dan: Do this thing with these people. This person's in charge. Next week, do this thing with these people. This person's in charge. Like, this is, this is what you need from that. Here's a, here's a screenshot of what that looks like. Here's a diagram for what that is. Here's a template for what that is. [00:45:00] So then the, the, the last piece of feedback that I got, you know, after releasing it last year was like, this is awesome.
[00:45:04] Dan: This is helpful. Like, could you just teach it to us? Could you just walk us through it? So that's what I just released, you know, is like, it starts, uh, it starts in, in a couple of weeks, September 12 is going to be the first, the first, um, uh, session and it's 12 weeks, right? It's 90 days and I teach you every week, you know, I treat it like a college class.
[00:45:25] Dan: You know, except that it's for working professionals who are working on a design system team and every week at the beginning of the week, you basically do the reading, you know, here are the seven activities you and your team have to do this week on Tuesdays. I teach like here are the nuances of these things.
[00:45:38] Dan: Here's some things to look out for. Here's some things that you're going to want to do. Here's some things that you need to involve other people in and then Wednesday through Friday, you get to do the work at work and then next week we do it again and we do it from now until December 15. Uh, and, and, and if all goes well, you know, every organization has their own nuances.
[00:45:54] Dan: If all goes well, you'll have an adopted design system up and running before 2024. Um, [00:46:00] so that's the, you know, that's the premise of that. I'm excited for it. I've got some, some really good, uh, good feedback on it so far. So, you know, hoping to get a full cohort of people that I can teach how to, how to get a design system up and running in less than three months.
[00:46:11] Ridd: Super exciting. And I'm such a big fan, obviously, of this model and really believe in it. And, man, what a practical example. Like, you're not just learning theory, you're not just reading and watching videos. Like, you're really actually creating something from scratch. I love that there's, like, this concrete deliverable at the end.
[00:46:28] Ridd: And then, also, I have this, like, deep skepticism of any time that lists are very clean numbers. Like if someone says like, 10 or 50 or 100, I'm like, how much of those are fluff to get to that clean number? So you know it's legit, the fact that there are 52 things, I'm like, yes, that is, it has gotta be gold.
[00:46:46] Ridd: If he stopped at 52 and said, I'm done, I can't do any less, and I can't get to 60 or whatever, I'm like, I have a lot of respect for that, so,
[00:46:53] Ridd: well, we've covered a lot of ground. Uh, are there any other questions that I should be asking, or any other [00:47:00] ideas that you want to talk about?
[00:47:03] Dan: I don't think so what I love about this conversation was, I want to make it very practical for people. I think that learning happens by doing. The American school system in particular. Sets people up for factory jobs and we don't have those jobs as much anymore. We have knowledge jobs that really need people to learn enough of a thing to go do it and try it.
[00:47:19] Dan: And I think the learn more from that. So, um, that's the thing, that's the message that I want to get out. And I appreciate you letting me talk about that and in practice here.
[00:47:28] Ridd: Amazing. Well, for anyone that is inspired and wants to go a little bit deeper, where can they find you online and where can they find your course?
[00:47:36] Dan: So, uh, danmall. com is where I write a bunch of things, most of my thoughts. I have a newsletter there, so sign up for that. It goes out every week. Every Friday I send a newsletter out about that, about just things that I'm working on, things that are helpful to you to grow as a design professional. And designsystem. university is where I put all my design system stuff. So if you're interested in design systems, We have free templates and tools. We have paid courses and all sorts of stuff like that.
[00:47:58] Dan: Designsystem. [00:48:00] university is where you can find that.
[00:48:01] Ridd: Awesome. Thanks, Dan.
[00:48:03] Dan: Great, thank you.
Dan's design system workbook
[00:43:19] Ridd: I think this would be probably a pretty good time for mentioning, like, you have a fantastic workbook on this. Like, design systems in 90 days. Like, if you, if you are on the fence and this is something that you're either considering or, like, trying to actively invest in your ability to execute at a high level as a design systems designer, I'm going to tee you up, Dan.
[00:43:38] Ridd: Can you just give us a little bit about what they can expect to get out of that?
[00:43:41] Dan: Absolutely.
[00:43:41] Ridd: I've seen your work and I've previewed your stuff and it's just incredible.
[00:43:45] Dan: Thank you. I appreciate it. Thank you for the tip. So, um, one of the pieces of feedback that I hear from a lot of teams lately is like, Our main initiative for the rest of the year is to get a design system up and running before, before 2024. Like, so we've got three months to do this. And a lot of teams are like [00:44:00] three months is not a lot of time to do a thing. How do, how do we do that?
[00:44:03] Dan: So what I wanted to do I, I wrote a, the first version of this last year, uh, with my business partner, Crystal Vitale, like we wrote down our steps.
[00:44:10] Dan: Like if we were to build a design system in 90 days in three months, what would we do? And we ended up writing 52 different steps down. It's like the feedback that I got from a lot of people was like, I get all the theory about design. Like I know what they're for.
[00:44:22] Dan: I know they've consistency and efficiency and all that stuff. How do we do it? So I wrote that down and that's what design system in 90 days is, is like, and initially last year when I released it, it was a workbook and it was like, if you just want this, there's no theory in this book at all.
[00:44:34] Dan: There's no like, well, you want to do this because of this and this is how people were like that. You could find somewhere else you can find that on the internet. I'm, I'm writing a book about design systems now that is about the theory stuff. That's like the compliment to that. This workbook is very, very tactical.
[00:44:47] Dan: Do this thing with these people. This person's in charge. Next week, do this thing with these people. This person's in charge. Like, this is, this is what you need from that. Here's a, here's a screenshot of what that looks like. Here's a diagram for what that is. Here's a template for what that is. [00:45:00] So then the, the, the last piece of feedback that I got, you know, after releasing it last year was like, this is awesome.
[00:45:04] Dan: This is helpful. Like, could you just teach it to us? Could you just walk us through it? So that's what I just released, you know, is like, it starts, uh, it starts in, in a couple of weeks, September 12 is going to be the first, the first, um, uh, session and it's 12 weeks, right? It's 90 days and I teach you every week, you know, I treat it like a college class.
[00:45:25] Dan: You know, except that it's for working professionals who are working on a design system team and every week at the beginning of the week, you basically do the reading, you know, here are the seven activities you and your team have to do this week on Tuesdays. I teach like here are the nuances of these things.
[00:45:38] Dan: Here's some things to look out for. Here's some things that you're going to want to do. Here's some things that you need to involve other people in and then Wednesday through Friday, you get to do the work at work and then next week we do it again and we do it from now until December 15. Uh, and, and, and if all goes well, you know, every organization has their own nuances.
[00:45:54] Dan: If all goes well, you'll have an adopted design system up and running before 2024. Um, [00:46:00] so that's the, you know, that's the premise of that. I'm excited for it. I've got some, some really good, uh, good feedback on it so far. So, you know, hoping to get a full cohort of people that I can teach how to, how to get a design system up and running in less than three months.
[00:46:11] Ridd: Super exciting. And I'm such a big fan, obviously, of this model and really believe in it. And, man, what a practical example. Like, you're not just learning theory, you're not just reading and watching videos. Like, you're really actually creating something from scratch. I love that there's, like, this concrete deliverable at the end.
[00:46:28] Ridd: And then, also, I have this, like, deep skepticism of any time that lists are very clean numbers. Like if someone says like, 10 or 50 or 100, I'm like, how much of those are fluff to get to that clean number? So you know it's legit, the fact that there are 52 things, I'm like, yes, that is, it has gotta be gold.
[00:46:46] Ridd: If he stopped at 52 and said, I'm done, I can't do any less, and I can't get to 60 or whatever, I'm like, I have a lot of respect for that, so,
[00:46:53] Ridd: well, we've covered a lot of ground. Uh, are there any other questions that I should be asking, or any other [00:47:00] ideas that you want to talk about?
[00:47:03] Dan: I don't think so what I love about this conversation was, I want to make it very practical for people. I think that learning happens by doing. The American school system in particular. Sets people up for factory jobs and we don't have those jobs as much anymore. We have knowledge jobs that really need people to learn enough of a thing to go do it and try it.
[00:47:19] Dan: And I think the learn more from that. So, um, that's the thing, that's the message that I want to get out. And I appreciate you letting me talk about that and in practice here.
[00:47:28] Ridd: Amazing. Well, for anyone that is inspired and wants to go a little bit deeper, where can they find you online and where can they find your course?
[00:47:36] Dan: So, uh, danmall. com is where I write a bunch of things, most of my thoughts. I have a newsletter there, so sign up for that. It goes out every week. Every Friday I send a newsletter out about that, about just things that I'm working on, things that are helpful to you to grow as a design professional. And designsystem. university is where I put all my design system stuff. So if you're interested in design systems, We have free templates and tools. We have paid courses and all sorts of stuff like that.
[00:47:58] Dan: Designsystem. [00:48:00] university is where you can find that.
[00:48:01] Ridd: Awesome. Thanks, Dan.
[00:48:03] Dan: Great, thank you.
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 6K+ designers
HC
HC
HC
HC
Ⓒ Dive 2023
