Season 5
|
Episode 4
The new frontier of design systems
Brad Frost
Author of Atomic Design
Mar 21, 2024
Mar 21, 2024
|
52 mins
52 mins
music by Dennis
About this Episode
If you’ve dabbled in design systems then you’re no doubt familiar with Brad Frost and atomic design. He’s laid the foundation for design systems teams around the world. So in this discussion we talk about the types of challenges he faces at Big Medium and how he’s envisioning the future of design systems:
Why we should build a universal design system
How Brad is using AI to elevate design systems
How design systems designers can succeed in an AI world
The highest leverage activities for DS designers to do
How designers can communicate better with engineers
Show Notes
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
Deep Dives
Get our weekly breakdowns
Free lessons from 👇
Lauren LoPrete
Lead designer @ Netflix
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
Transcript chapters
[00:00:00] Overview of Big Medium
Brad: So big medium is in an agency, a consultancy, and we work with organizations of all shapes and sizes. and we help them design at scale. And that entails a bunch of things, right? We help people, organizations adopt new best practices and kind of design for what's next, right?
Not necessarily like what's, what's like the sort of far flung future, but it's like what's stuff that's here and emerging that actually is graspable that, that you could actually kind of implement. So sometimes we're like neck deep into, standing up teams and org charts. But a lot of, a lot of the work that we do is around, you know, helping organizations design and build design systems, evolve their design systems, merge design systems, retire old design systems.
That's been like a lot of our kind of meat and potatoes for, for the last number of years. But all of our work is done kind of through the lens of teaching a team to fish, if that makes sense. I kind of come from the agency world, back in the day, and it was very much the, you know, give us a bunch of money, we will burn down your old website, we will build you a new website, we will deliver you that website, and then we will, like, ride off into the sunset and give us a call in three to five years, whatever that.
new website is old and rickety and we will do it all over again. I really love and find the work super fulfilling to like help organizations really level up and sort of smooth out or remove sometimes entirely. A lot of this sort of friction and frustration that comes with the terrain of making good stuff happen, it really, again, it runs the gamut, but it often is touching, design. The technology and code aspect of it, as well as the sort of people process and really the organizational culture, that's like a lot of the work that we do. Is that more kind of human stuff? that's what all these years later is, is, I think, the most, uh.
Fulfilling is also as well as the most challenging
Brad: with it with it because it's like people, my favorite quote is from like many, many, many years ago, maybe like 11 or 12 years ago, but Mark Bolton is a, is a wonderful designer, wonderful person at a conference somewhere said, the design process is weird and complicated.
Because it involves people who are weird and complicated. that stuck with me all these years later, but that's what, you know, that's what makes the work fun. And that's why things like design systems are not just like a, Oh, here's the design system done, right? It's Like you're talking about people and their relationship to one another. And the good, the bad, the ugly that comes with it. And so that's, uh, a lot of the fun is, is digging into that
[00:00:00] Overview of Big Medium
Brad: So big medium is in an agency, a consultancy, and we work with organizations of all shapes and sizes. and we help them design at scale. And that entails a bunch of things, right? We help people, organizations adopt new best practices and kind of design for what's next, right?
Not necessarily like what's, what's like the sort of far flung future, but it's like what's stuff that's here and emerging that actually is graspable that, that you could actually kind of implement. So sometimes we're like neck deep into, standing up teams and org charts. But a lot of, a lot of the work that we do is around, you know, helping organizations design and build design systems, evolve their design systems, merge design systems, retire old design systems.
That's been like a lot of our kind of meat and potatoes for, for the last number of years. But all of our work is done kind of through the lens of teaching a team to fish, if that makes sense. I kind of come from the agency world, back in the day, and it was very much the, you know, give us a bunch of money, we will burn down your old website, we will build you a new website, we will deliver you that website, and then we will, like, ride off into the sunset and give us a call in three to five years, whatever that.
new website is old and rickety and we will do it all over again. I really love and find the work super fulfilling to like help organizations really level up and sort of smooth out or remove sometimes entirely. A lot of this sort of friction and frustration that comes with the terrain of making good stuff happen, it really, again, it runs the gamut, but it often is touching, design. The technology and code aspect of it, as well as the sort of people process and really the organizational culture, that's like a lot of the work that we do. Is that more kind of human stuff? that's what all these years later is, is, I think, the most, uh.
Fulfilling is also as well as the most challenging
Brad: with it with it because it's like people, my favorite quote is from like many, many, many years ago, maybe like 11 or 12 years ago, but Mark Bolton is a, is a wonderful designer, wonderful person at a conference somewhere said, the design process is weird and complicated.
Because it involves people who are weird and complicated. that stuck with me all these years later, but that's what, you know, that's what makes the work fun. And that's why things like design systems are not just like a, Oh, here's the design system done, right? It's Like you're talking about people and their relationship to one another. And the good, the bad, the ugly that comes with it. And so that's, uh, a lot of the fun is, is digging into that
[00:02:55] What successful communication looks like for design systems
Ridd: Can we talk a little bit more about that? Because I think you often hear the importance of communication in design systems, but also it's a little bit of a black box. Like, what does that look like in practice? Like, are there certain. Models or tactics that you see your clients having success with when it comes to helping the design systems team communicate effectively and keep everyone on the same page.
Brad: it depends on what kind of, you know, circles you want to draw around people, because there's the, the kind of intra team You know, sort of dynamics, right? But then there's the more sort of outward facing stuff, which is like, how does this team interface with, you know, the downstream product teams that are consuming the design system and adopting the design system. And I'd say that that those are sort of some of the most important relationships.
Obviously, you want the team to be working well within itself, but then so much of the work. And I think a lot of teams don't tend to understand this. And this is stuff that we really Enjoy plugging in and sort of riding along and coaching and sort of like helping teams kind of develop those muscles of this kind of service oriented.
How can I help you kind of attitude? that is necessary for this stuff to be successful, when we see it fail. we see the design system team as being kind of like protective or like strong opinions or this kind of off to the side ivory tower kind of thing the most successful ones are the ones that are like how can we help what are you working on how can we be of assistance right because ultimately this stuff that is contained within a design system is the there to make teams lives easier, Rather than harder. we tend to see various degrees of, of folks missing the plot, I think half the time, right? Where it's like, we get kind of like focused on the wrong things, whether that's, the component architecture, like making sure that this stuff is like totally consistent, but it's like at the end of the day, all of this infrastructure is designed to make teams lives easier, make the work better, help people work faster, and focus on more worthwhile tasks, so the, so the more that the design system team could do a lot of really proactive outreach, foster good relationships, and a lot of times that looks different depending on the discipline, right?
So you might have the design system designer attending weekly product, you know, review meetings or something like that, right? That's kind of like weighing in, gathering info. nudging people in the right direction here and there, right? Sort of making themselves available and making them in ingraining themselves and in the process of other designers at the organization.
Similarly, on the code side, it's like, you know, what are teams wrestling with? What are the developers doing? How can the design system? Be a part of that. And how could the humans that are sort of governing the sort of technical aspects of the design system, how can they sort of embed themselves and understand what they're wrestling with and and then asking the questions of how might we do some stuff to make that either go away or easier or whatever, you know, so so that's that's the sort of spirit of it. It is like a proactive, service oriented role. Making it clear that you're here to help getting the ego out of the way and just kind of making yourself accessible and available for folks if they like have questions that sort of proactive, that relationship building that feedback loop of it's like, Hey, what are you?
I'm trying to do this and I have questions or concerns around this. It's like kind of getting into that sort of rhythm of facilitating a conversation whenever teams run into that stuff like that's that's the real sort of sign of success is this kind of cultivating this, culture of Communication and collaboration.
Ridd: I want to double clip on, on the speed element a little bit, because I think there's this narrative that I see popping up from time to time, which is basically like, well, Design systems, they can slow down a little bit. You almost have to wait for the design system to codify something in order to move with the momentum that you want on a product layer.
even in researching this call, I came across the concept of pace layers, which I thought was so interesting. So can you talk a little bit about this relationship and, and how design systems can enable speed as it exists across these two layers?
Brad: Yeah. Yeah. It's a, it's a really fascinating concept what we're often talking about is, different things need to move at different paces in order to accomplish.
What they're trying to accomplish. So the fastest pace layer is that of the product, right? Especially if you consider a startup. You need to be able to sort of move at this like really fast clip, As time goes on, though, especially at a maturing startup, say,
if you only have that layer. You end up with big mess on your hand, especially as you grow, right? You know, organizations, they scale up, they hire a bunch of new engineers and new designers. And if, like, everything's just like, put the horse blinders on and just, like, make things happen, Uh, you're gonna end up with a bunch of design debt, a bunch of tech debt, and stuff like that.
So, there ends up needing to be, okay, we need, a layer beneath this. Like we need like sort of some form of infrastructure and in the form of sort of more the backend world, we're sort of used to this world of, infrastructure, things like payment APIs, like how you actually process people's credit cards for your software as a service company or whatever.
It's like, that is like. Important infrastructure that isn't necessarily like that, that the user facing product itself, but it is an important piece of infrastructure that makes the whole thing go and what design systems are, are sort of this critical sort of front end infrastructure, as we say, Because it's infrastructure, it needs to be sturdy and stable in the same way that a block level foundation for a house needs to be plumb and square and all of that stuff because everything is built on top of this stuff, right?
So it necessarily needs to move slower, right? You don't want to just chuck a bunch of bricks and sort of get it done in an afternoon. You really want to sort of make sure that this. is done right, which necessitates a slower pace than the fast moving kind of product layer, So you kind of have these different layers operating at different speeds.
And the trick is to get the balance right, because a lot of times the design system will be sort of hurried up in order to try to meet the speed demands of the product layer, Also, the, the product layer is, told to slow down in order to let the design system sort of do its thing. So, so the way to sort of get that balance right between these different paces is to let the design system kind of go at its sort of slower, more considered, higher quality.
Pace, And, and those are the values, We're talking about sort of the quality over speed, or we're talking about doing the due diligence. We're not like putting a bunch of just one off crap into the, this infrastructure layer, right? Like we really want this stuff to be well considered and vetted, and that requires that slower pace.
But if the team needs something in the meantime, the product team is like, I got a feature that's going out the door. And we need the date picker design system. Do you have the date picker ready for us? And if the answer is no, that just means that the product team needs to go, you know, hunting on the internet, find a scrappy, you know, third party solution or whatever, which is totally fine and totally valid.
Like if that needs to happen at that moment, the last thing you want to do is Design system team drop everything. We need you to sort of develop a date picker kind of from the, from the ground up in the next week, that's not serving anybody. Well, at the same time though, there, it's important to create a connection between the design system and the product layer.
And so we do this, what, with what we call pilot projects where, where basically there are projects. they are happening. They're in the sort of planning phase. We know this is coming. Let's say it's like the checkout redesign and development or sort of something like that or replatforming. We know we're going to be tackling this in the next quarter.
We could be like, great, this is an opportunity for the design system to really kind of be connected to that. And we will use this project. as a way to sort of seed the design system with all of the things that the checkout redesign and and replatforming needs, right? So we need text fields, we need select boxes, we need drop downs, we need button groups for like previous and next, we need like a stepper navigation and things like that.
So you can do these projects that are very like targeted and very sort of specific to accomplishing the product layer you and the design system paste layer at the same time. But it's good to do that in, in sort of a very deliberate way. And that's like how we tend to sort of like seed a design system with real stuff that really is validated right through the lens of product, I'd say that, the big takeaway is, the design system needs to move at its own pace. Product needs to move at its own pace. It's important to let them operate at their own pace and don't try to sort of force one to speed up or the other to slow down. But also, it's important to sort of, like, get the rhythm and the balance right.
Through the lens of like really sort of targeted applications, really targeted sort of projects where you're sort of like playing all of this stuff out, both the both the components themselves and design and code as well as the sort of human processes, right? Like, here's how you consume a component.
Here's how you get it onto the page. Here's how you ask us questions whenever you run into a wall or something like that.
[00:02:55] What successful communication looks like for design systems
Ridd: Can we talk a little bit more about that? Because I think you often hear the importance of communication in design systems, but also it's a little bit of a black box. Like, what does that look like in practice? Like, are there certain. Models or tactics that you see your clients having success with when it comes to helping the design systems team communicate effectively and keep everyone on the same page.
Brad: it depends on what kind of, you know, circles you want to draw around people, because there's the, the kind of intra team You know, sort of dynamics, right? But then there's the more sort of outward facing stuff, which is like, how does this team interface with, you know, the downstream product teams that are consuming the design system and adopting the design system. And I'd say that that those are sort of some of the most important relationships.
Obviously, you want the team to be working well within itself, but then so much of the work. And I think a lot of teams don't tend to understand this. And this is stuff that we really Enjoy plugging in and sort of riding along and coaching and sort of like helping teams kind of develop those muscles of this kind of service oriented.
How can I help you kind of attitude? that is necessary for this stuff to be successful, when we see it fail. we see the design system team as being kind of like protective or like strong opinions or this kind of off to the side ivory tower kind of thing the most successful ones are the ones that are like how can we help what are you working on how can we be of assistance right because ultimately this stuff that is contained within a design system is the there to make teams lives easier, Rather than harder. we tend to see various degrees of, of folks missing the plot, I think half the time, right? Where it's like, we get kind of like focused on the wrong things, whether that's, the component architecture, like making sure that this stuff is like totally consistent, but it's like at the end of the day, all of this infrastructure is designed to make teams lives easier, make the work better, help people work faster, and focus on more worthwhile tasks, so the, so the more that the design system team could do a lot of really proactive outreach, foster good relationships, and a lot of times that looks different depending on the discipline, right?
So you might have the design system designer attending weekly product, you know, review meetings or something like that, right? That's kind of like weighing in, gathering info. nudging people in the right direction here and there, right? Sort of making themselves available and making them in ingraining themselves and in the process of other designers at the organization.
Similarly, on the code side, it's like, you know, what are teams wrestling with? What are the developers doing? How can the design system? Be a part of that. And how could the humans that are sort of governing the sort of technical aspects of the design system, how can they sort of embed themselves and understand what they're wrestling with and and then asking the questions of how might we do some stuff to make that either go away or easier or whatever, you know, so so that's that's the sort of spirit of it. It is like a proactive, service oriented role. Making it clear that you're here to help getting the ego out of the way and just kind of making yourself accessible and available for folks if they like have questions that sort of proactive, that relationship building that feedback loop of it's like, Hey, what are you?
I'm trying to do this and I have questions or concerns around this. It's like kind of getting into that sort of rhythm of facilitating a conversation whenever teams run into that stuff like that's that's the real sort of sign of success is this kind of cultivating this, culture of Communication and collaboration.
Ridd: I want to double clip on, on the speed element a little bit, because I think there's this narrative that I see popping up from time to time, which is basically like, well, Design systems, they can slow down a little bit. You almost have to wait for the design system to codify something in order to move with the momentum that you want on a product layer.
even in researching this call, I came across the concept of pace layers, which I thought was so interesting. So can you talk a little bit about this relationship and, and how design systems can enable speed as it exists across these two layers?
Brad: Yeah. Yeah. It's a, it's a really fascinating concept what we're often talking about is, different things need to move at different paces in order to accomplish.
What they're trying to accomplish. So the fastest pace layer is that of the product, right? Especially if you consider a startup. You need to be able to sort of move at this like really fast clip, As time goes on, though, especially at a maturing startup, say,
if you only have that layer. You end up with big mess on your hand, especially as you grow, right? You know, organizations, they scale up, they hire a bunch of new engineers and new designers. And if, like, everything's just like, put the horse blinders on and just, like, make things happen, Uh, you're gonna end up with a bunch of design debt, a bunch of tech debt, and stuff like that.
So, there ends up needing to be, okay, we need, a layer beneath this. Like we need like sort of some form of infrastructure and in the form of sort of more the backend world, we're sort of used to this world of, infrastructure, things like payment APIs, like how you actually process people's credit cards for your software as a service company or whatever.
It's like, that is like. Important infrastructure that isn't necessarily like that, that the user facing product itself, but it is an important piece of infrastructure that makes the whole thing go and what design systems are, are sort of this critical sort of front end infrastructure, as we say, Because it's infrastructure, it needs to be sturdy and stable in the same way that a block level foundation for a house needs to be plumb and square and all of that stuff because everything is built on top of this stuff, right?
So it necessarily needs to move slower, right? You don't want to just chuck a bunch of bricks and sort of get it done in an afternoon. You really want to sort of make sure that this. is done right, which necessitates a slower pace than the fast moving kind of product layer, So you kind of have these different layers operating at different speeds.
And the trick is to get the balance right, because a lot of times the design system will be sort of hurried up in order to try to meet the speed demands of the product layer, Also, the, the product layer is, told to slow down in order to let the design system sort of do its thing. So, so the way to sort of get that balance right between these different paces is to let the design system kind of go at its sort of slower, more considered, higher quality.
Pace, And, and those are the values, We're talking about sort of the quality over speed, or we're talking about doing the due diligence. We're not like putting a bunch of just one off crap into the, this infrastructure layer, right? Like we really want this stuff to be well considered and vetted, and that requires that slower pace.
But if the team needs something in the meantime, the product team is like, I got a feature that's going out the door. And we need the date picker design system. Do you have the date picker ready for us? And if the answer is no, that just means that the product team needs to go, you know, hunting on the internet, find a scrappy, you know, third party solution or whatever, which is totally fine and totally valid.
Like if that needs to happen at that moment, the last thing you want to do is Design system team drop everything. We need you to sort of develop a date picker kind of from the, from the ground up in the next week, that's not serving anybody. Well, at the same time though, there, it's important to create a connection between the design system and the product layer.
And so we do this, what, with what we call pilot projects where, where basically there are projects. they are happening. They're in the sort of planning phase. We know this is coming. Let's say it's like the checkout redesign and development or sort of something like that or replatforming. We know we're going to be tackling this in the next quarter.
We could be like, great, this is an opportunity for the design system to really kind of be connected to that. And we will use this project. as a way to sort of seed the design system with all of the things that the checkout redesign and and replatforming needs, right? So we need text fields, we need select boxes, we need drop downs, we need button groups for like previous and next, we need like a stepper navigation and things like that.
So you can do these projects that are very like targeted and very sort of specific to accomplishing the product layer you and the design system paste layer at the same time. But it's good to do that in, in sort of a very deliberate way. And that's like how we tend to sort of like seed a design system with real stuff that really is validated right through the lens of product, I'd say that, the big takeaway is, the design system needs to move at its own pace. Product needs to move at its own pace. It's important to let them operate at their own pace and don't try to sort of force one to speed up or the other to slow down. But also, it's important to sort of, like, get the rhythm and the balance right.
Through the lens of like really sort of targeted applications, really targeted sort of projects where you're sort of like playing all of this stuff out, both the both the components themselves and design and code as well as the sort of human processes, right? Like, here's how you consume a component.
Here's how you get it onto the page. Here's how you ask us questions whenever you run into a wall or something like that.
[00:13:11] How startups should think about their design system
Ridd: I know you typically work with more mature orgs. I'm sure there's also a decent percentage of people listening right now. They're like, you know, my, my design team is four people. How much of this is relevant for me? So can we talk a little bit about like that earlier stage environment and the balance between these layers?
And specifically, I'm interested in this relationship between the size of a design system and. Healthy design debt and how teams can identify where that line should exist for their specific situation. How do you think about that? Hmm.
Brad: always need to be evaluating it, right? There's not like a single answer for a single organization and there's also not a single answer for a single organization over time, right? as time goes on, as the needs change, right?
Like any sort of living system, right? We need to. Just right. I've been asked this. The question before is like, yeah, like for these like large companies and stuff like that, more mature organizations, this all makes sense. But for my super small team, what, what actually makes sense?
I'm of the view that even if you're developing a, you know, four or five page website. You should have a design system to power that. just to sort of use an example, my wife, ran a jewelry company. I created a website for her, And by just sort of designing things and building things through the lens of components and reuse and just kind of defaulting to that mentality, The first template, the homepage, took me 100 percent effort, right?
In order to sort of build all the things that I needed. I needed a hero, I needed like this grid of cards, I needed this kind of like promo, tout, newsletter, sign up, etc, etc. So that took me a lot of effort. But then I went over to the next template that sort of showcases her, her work. And it's like, oh, this is basically just one big grid of cards.
And I actually already built that for the homepage. So, instead of 100 percent effort, I now, And, you know, this is 70 percent effort because it's basically just one giant grid of cards and I need like a couple net new components in order to complete that template. And then I go over to the third template and then all of a sudden now this is taking me like 50 percent effort.
And then by the time I get to the end, I'm not building anything new. I'm just kind of reusing what I built earlier. So, so even in like a design team of one, if you're the only designer, it's in your best interest to design with, components and reuse in mind. Now that doesn't mean that you need a Website for it that rivals material.
io or lightning design system the nature of a lot of the sort of artifacts and assets and documentation and all that stuff and process really depends on the team. And if it's just you and a developer, for instance, you could get away with. Just zoom calls and you're kind of connecting on that thing, you know You you can and should also write things down and like have that for your future selves as well as if the team scales and and so on The the design system should only be as complex as you need it to be I wrote An article recently called the design system ecosystem, and it sort of gets into this, like, really pretty complicated layer cake of like what, a design system ecosystem could look like at an organization.
There's like five different layers. There's all of this stuff going on, but it's so important to stress that nearly all of these layers are optional. Don't start. With a complex system, right? There's a law called Gaul's Law that basically says like a complex system must emerge from a simpler system, right?
You can't just sort of like birth a complex system and have it work like it start as simple as possible and only add layers of complexity when you're really kind of like feeling the pinch, So, so for those organizations that are in the early stages. having a reusable Figma component library, having a reusable sort of code library, even if it's like co located In your products, code base or whatever, like that's totally fine.
That might be all you need there, but as you start growing and you're like, Oh yeah, we now have like our marketing website and our main software product is like, okay, maybe you need to split that out into its own repo that then sort of powers those and feeds those. So you could kind of see this evolution happen where the sort of infrastructure as well as the sort of formality.
The documentation, those assets need to become more fleshed out, more rigorous, and more robust the bigger the surface area is. But don't start there. Don't, again, don't start with your, like, rival material. io website that, you know, has a bunch of sort of splashy graphics and stuff. Like, if you're just, like, in there trying to get work done, Make yourself a reusable component library even if you're not calling it a design system, even if it's just like, ah, yeah, like here's our little component sandbox or whatever it is, have that
Ridd: Yeah.
Brad: with reuse, design with reuse. As you're designing something, cultivate a mentality of how might this be used somewhere else the the more you internalize that mentality the better Off you will be because you'll you'll save yourself future rework.
It's not like a whole hell of a lot extra production effort It's just this like extra kind of like mental How might this be reused somewhere else? And as you implement that even that first draft of it or that first instance of it, you can be anticipating You using this thing sort of elsewhere.
Ridd: I love the point that you don't even have to call it a design system. Cause I think for a lot of, especially early stage teams, there's almost this connotation with the phrase design systems that implies. It's robust. It's comprehensive. And it's like no, no, no, it doesn't actually have to be and like even thinking about your layer cakes like that bottom layer. It's really obvious and it exists in like 99 percent of products. The chances are you're probably going to have a button set with different sizes and inputs with different sizes, and you want them to relate. And the chance that those exist outside of a spectrum of like 40 to 56 pixels tall are pretty small, you know, like you can, you can start with, with, with a very simple reusable system.
So I do think that's a good way of looking at it.
[00:13:11] How startups should think about their design system
Ridd: I know you typically work with more mature orgs. I'm sure there's also a decent percentage of people listening right now. They're like, you know, my, my design team is four people. How much of this is relevant for me? So can we talk a little bit about like that earlier stage environment and the balance between these layers?
And specifically, I'm interested in this relationship between the size of a design system and. Healthy design debt and how teams can identify where that line should exist for their specific situation. How do you think about that? Hmm.
Brad: always need to be evaluating it, right? There's not like a single answer for a single organization and there's also not a single answer for a single organization over time, right? as time goes on, as the needs change, right?
Like any sort of living system, right? We need to. Just right. I've been asked this. The question before is like, yeah, like for these like large companies and stuff like that, more mature organizations, this all makes sense. But for my super small team, what, what actually makes sense?
I'm of the view that even if you're developing a, you know, four or five page website. You should have a design system to power that. just to sort of use an example, my wife, ran a jewelry company. I created a website for her, And by just sort of designing things and building things through the lens of components and reuse and just kind of defaulting to that mentality, The first template, the homepage, took me 100 percent effort, right?
In order to sort of build all the things that I needed. I needed a hero, I needed like this grid of cards, I needed this kind of like promo, tout, newsletter, sign up, etc, etc. So that took me a lot of effort. But then I went over to the next template that sort of showcases her, her work. And it's like, oh, this is basically just one big grid of cards.
And I actually already built that for the homepage. So, instead of 100 percent effort, I now, And, you know, this is 70 percent effort because it's basically just one giant grid of cards and I need like a couple net new components in order to complete that template. And then I go over to the third template and then all of a sudden now this is taking me like 50 percent effort.
And then by the time I get to the end, I'm not building anything new. I'm just kind of reusing what I built earlier. So, so even in like a design team of one, if you're the only designer, it's in your best interest to design with, components and reuse in mind. Now that doesn't mean that you need a Website for it that rivals material.
io or lightning design system the nature of a lot of the sort of artifacts and assets and documentation and all that stuff and process really depends on the team. And if it's just you and a developer, for instance, you could get away with. Just zoom calls and you're kind of connecting on that thing, you know You you can and should also write things down and like have that for your future selves as well as if the team scales and and so on The the design system should only be as complex as you need it to be I wrote An article recently called the design system ecosystem, and it sort of gets into this, like, really pretty complicated layer cake of like what, a design system ecosystem could look like at an organization.
There's like five different layers. There's all of this stuff going on, but it's so important to stress that nearly all of these layers are optional. Don't start. With a complex system, right? There's a law called Gaul's Law that basically says like a complex system must emerge from a simpler system, right?
You can't just sort of like birth a complex system and have it work like it start as simple as possible and only add layers of complexity when you're really kind of like feeling the pinch, So, so for those organizations that are in the early stages. having a reusable Figma component library, having a reusable sort of code library, even if it's like co located In your products, code base or whatever, like that's totally fine.
That might be all you need there, but as you start growing and you're like, Oh yeah, we now have like our marketing website and our main software product is like, okay, maybe you need to split that out into its own repo that then sort of powers those and feeds those. So you could kind of see this evolution happen where the sort of infrastructure as well as the sort of formality.
The documentation, those assets need to become more fleshed out, more rigorous, and more robust the bigger the surface area is. But don't start there. Don't, again, don't start with your, like, rival material. io website that, you know, has a bunch of sort of splashy graphics and stuff. Like, if you're just, like, in there trying to get work done, Make yourself a reusable component library even if you're not calling it a design system, even if it's just like, ah, yeah, like here's our little component sandbox or whatever it is, have that
Ridd: Yeah.
Brad: with reuse, design with reuse. As you're designing something, cultivate a mentality of how might this be used somewhere else the the more you internalize that mentality the better Off you will be because you'll you'll save yourself future rework.
It's not like a whole hell of a lot extra production effort It's just this like extra kind of like mental How might this be reused somewhere else? And as you implement that even that first draft of it or that first instance of it, you can be anticipating You using this thing sort of elsewhere.
Ridd: I love the point that you don't even have to call it a design system. Cause I think for a lot of, especially early stage teams, there's almost this connotation with the phrase design systems that implies. It's robust. It's comprehensive. And it's like no, no, no, it doesn't actually have to be and like even thinking about your layer cakes like that bottom layer. It's really obvious and it exists in like 99 percent of products. The chances are you're probably going to have a button set with different sizes and inputs with different sizes, and you want them to relate. And the chance that those exist outside of a spectrum of like 40 to 56 pixels tall are pretty small, you know, like you can, you can start with, with, with a very simple reusable system.
So I do think that's a good way of looking at it.
[00:19:54] Brad's call for a global design system
Ridd: One of the ideas that you shared recently is this call for a global design system, which I definitely want to talk about. And we'll link the full article for people that want to go like all the way into the weeds. But can you kind of give like an overview of basically like what's in, what's on your mind right now that you are excited about, and maybe we can then kind of get into some of the, the challenges that we're even trying to solve with this thing.
Brad: there's a almost like a guarantee if you look at like a core design system. wherever, doesn't matter what industry, it doesn't matter what sort of size, doesn't matter what it does is a nonprofit is a startup is a fortune 500 company. Is it a whatever you go in to an organization?
And this is again, what I do day in and day out, you know, working with all these different organizations, we see Badges, buttons, form controls, tabs, accordions, and so on and so forth, right? With some extra, you know, some extra flavor in there. effectively, it's The exact same stuff, right? Here's an alert, and it's got an error variant.
It's got a success error variant. It's got a warning variant and so on. You could put an icon there. You can also not. It could be dismissible, whatever, but when you sort of cut across all of these design systems, including a bunch of the more sort of public facing, you know, popular ones, out there, you see, the exact same things basically built and rebuilt and rebuilt again.
And when we work with organizations, a lot of the time, their effort, right? The design system teams effort is spent designing and building and rebuilding the date picker, the badge, the alert, and all of this stuff. And in my view, that prevents them from. Doing what we were talking about earlier, which is like the real hard work of design systems, which is that service more human connection, like, you know, really doing the hard work of fostering these relationships, making sure that the teams are supported, that they have all of this stuff.
And instead, we're sort of like rebuilding the same base, couple dozen components again and again and again and again. Really, really, really minor changes. Differences in the implementation right from one one organization to the next. So the thought is how might we get off of this hamster wheel where we're all just kind of rebuilding and redesigning and rebuilding the same freaking stuff again and again.
And is there a way to sort of establish like. A sort of a canonical home for a lot of those sort of common elements, but also critically, how can this be done in a way that's, that's really sort of sanctioned and kind of formalized and sort of blessed by the governing bodies of the web, right? Like getting the accessibility right of these components is often fraught and hard and all of that stuff.
So wouldn't it be great if it's like, here's the one that is blessed by, you know, WCAG and, you know, ARIA, like this has the accessibility. Best practices baked into it. This has the blessing of the W3C. This is the accordion you want to use. And if you use this accordion, you can trust that it's going to go well.
Cause right now it's just kind of like, eh, I'm going to look across the internet and, you know, Find which ones that I want or, oh yeah, we got to roll our own and, and which is again, uh, all of these options are valid, but all of these teams are sort of burdened with creating this stuff from the ground up.
And that's frankly just not what their organizations are focused on, right? Like building the best accordion does not matter in the slightest to them. an airline or two, like, oh, whatever. Like that's, it's, it is, it is common fair stuff that, that should just be taken care of. Right. So that's what I'm kind of proposing is like, we should have a global design system that contains The common elements found across design systems the world over doesn't, it's, it's kind of like a layer on top of HTML is, is kind of what I'm saying, because like a lot of historically kind of the thing is, it's like, oh, well, should we add a badge?
HTML tag to, you know, the HTML standard and maybe, but at the same time, these couple dozen components are, are mostly sort of compositions of a lot of the, the sort of like low level HTML elements and properties and stuff that we have available to us. So it's like, it's a little bit more like we need like kind of prefab solutions that people can kind of grab with confidence.
That really sort of solves a really pragmatic issue, right? It's like we need tabs Here's tabs, right? It doesn't solve literally every instance of tabs in the world But it gives you like a pretty sturdy meat and potatoes version right that if you are that startup or if you are just Anybody that needs some tabs like you know There's, there's the one and we can sort of grab that and sort of start with that and then the design system teams and digital organizations could then be freed up right there, their heads in their hands could be freed up to be doing.
Things that are more specific to their line of business or, you know, what they're trying, what their mission is at an organizational level, right? So that involves, you know, custom components, but also like, of course, like all like the sort of styling and stuff. I think that one of like the big things with the design system like this is that you, you basically need it to be totally stylists as much as possible, right?
Like a really vanilla base and then people kind of bring their own aesthetic to it, right? Whether that's. Taking existing popular themes like tailwind or, or bootstrap or material or whatever, or rolling their own custom themes that meets the needs of their, organization and stuff like that.
So, so that, that's the spirit of it, is like we need, we need a layer beneath the existing sort of organization wide design systems, right, that we can kind of have this kind of shared. One that that can feed all those other ones and beyond, but we need this or this layer that's also kind of sitting on top of HTML.
So as I kind of see it operating in this new space in between these worlds. And right now there's a gap there. And we see all of these organizations kind of taking the low level HTML elements and trying their best to reproduce or recreate these things using best practices with varying levels of success, right?
We work with organizations all the time. We will audit their code. We will look at the accessibility. We'll look at the performance of these things. And a lot of times we have. a lot of feedback for how best to implement these low level components. So, so yeah, so that's, that's the basic gist of it let's do that and save us all a bunch of time and energy and be able to sort of put our time and our energy to more useful, fruitful endeavors rather than rebuilding the date picker for the 15th time.
[00:19:54] Brad's call for a global design system
Ridd: One of the ideas that you shared recently is this call for a global design system, which I definitely want to talk about. And we'll link the full article for people that want to go like all the way into the weeds. But can you kind of give like an overview of basically like what's in, what's on your mind right now that you are excited about, and maybe we can then kind of get into some of the, the challenges that we're even trying to solve with this thing.
Brad: there's a almost like a guarantee if you look at like a core design system. wherever, doesn't matter what industry, it doesn't matter what sort of size, doesn't matter what it does is a nonprofit is a startup is a fortune 500 company. Is it a whatever you go in to an organization?
And this is again, what I do day in and day out, you know, working with all these different organizations, we see Badges, buttons, form controls, tabs, accordions, and so on and so forth, right? With some extra, you know, some extra flavor in there. effectively, it's The exact same stuff, right? Here's an alert, and it's got an error variant.
It's got a success error variant. It's got a warning variant and so on. You could put an icon there. You can also not. It could be dismissible, whatever, but when you sort of cut across all of these design systems, including a bunch of the more sort of public facing, you know, popular ones, out there, you see, the exact same things basically built and rebuilt and rebuilt again.
And when we work with organizations, a lot of the time, their effort, right? The design system teams effort is spent designing and building and rebuilding the date picker, the badge, the alert, and all of this stuff. And in my view, that prevents them from. Doing what we were talking about earlier, which is like the real hard work of design systems, which is that service more human connection, like, you know, really doing the hard work of fostering these relationships, making sure that the teams are supported, that they have all of this stuff.
And instead, we're sort of like rebuilding the same base, couple dozen components again and again and again and again. Really, really, really minor changes. Differences in the implementation right from one one organization to the next. So the thought is how might we get off of this hamster wheel where we're all just kind of rebuilding and redesigning and rebuilding the same freaking stuff again and again.
And is there a way to sort of establish like. A sort of a canonical home for a lot of those sort of common elements, but also critically, how can this be done in a way that's, that's really sort of sanctioned and kind of formalized and sort of blessed by the governing bodies of the web, right? Like getting the accessibility right of these components is often fraught and hard and all of that stuff.
So wouldn't it be great if it's like, here's the one that is blessed by, you know, WCAG and, you know, ARIA, like this has the accessibility. Best practices baked into it. This has the blessing of the W3C. This is the accordion you want to use. And if you use this accordion, you can trust that it's going to go well.
Cause right now it's just kind of like, eh, I'm going to look across the internet and, you know, Find which ones that I want or, oh yeah, we got to roll our own and, and which is again, uh, all of these options are valid, but all of these teams are sort of burdened with creating this stuff from the ground up.
And that's frankly just not what their organizations are focused on, right? Like building the best accordion does not matter in the slightest to them. an airline or two, like, oh, whatever. Like that's, it's, it is, it is common fair stuff that, that should just be taken care of. Right. So that's what I'm kind of proposing is like, we should have a global design system that contains The common elements found across design systems the world over doesn't, it's, it's kind of like a layer on top of HTML is, is kind of what I'm saying, because like a lot of historically kind of the thing is, it's like, oh, well, should we add a badge?
HTML tag to, you know, the HTML standard and maybe, but at the same time, these couple dozen components are, are mostly sort of compositions of a lot of the, the sort of like low level HTML elements and properties and stuff that we have available to us. So it's like, it's a little bit more like we need like kind of prefab solutions that people can kind of grab with confidence.
That really sort of solves a really pragmatic issue, right? It's like we need tabs Here's tabs, right? It doesn't solve literally every instance of tabs in the world But it gives you like a pretty sturdy meat and potatoes version right that if you are that startup or if you are just Anybody that needs some tabs like you know There's, there's the one and we can sort of grab that and sort of start with that and then the design system teams and digital organizations could then be freed up right there, their heads in their hands could be freed up to be doing.
Things that are more specific to their line of business or, you know, what they're trying, what their mission is at an organizational level, right? So that involves, you know, custom components, but also like, of course, like all like the sort of styling and stuff. I think that one of like the big things with the design system like this is that you, you basically need it to be totally stylists as much as possible, right?
Like a really vanilla base and then people kind of bring their own aesthetic to it, right? Whether that's. Taking existing popular themes like tailwind or, or bootstrap or material or whatever, or rolling their own custom themes that meets the needs of their, organization and stuff like that.
So, so that, that's the spirit of it, is like we need, we need a layer beneath the existing sort of organization wide design systems, right, that we can kind of have this kind of shared. One that that can feed all those other ones and beyond, but we need this or this layer that's also kind of sitting on top of HTML.
So as I kind of see it operating in this new space in between these worlds. And right now there's a gap there. And we see all of these organizations kind of taking the low level HTML elements and trying their best to reproduce or recreate these things using best practices with varying levels of success, right?
We work with organizations all the time. We will audit their code. We will look at the accessibility. We'll look at the performance of these things. And a lot of times we have. a lot of feedback for how best to implement these low level components. So, so yeah, so that's, that's the basic gist of it let's do that and save us all a bunch of time and energy and be able to sort of put our time and our energy to more useful, fruitful endeavors rather than rebuilding the date picker for the 15th time.
[00:27:27] Exploring AI in design systems
Ridd: Speaking of useful endeavors, one of the things in your article, you talk about being able to unlock is basically giving design systems teams, more time to experiment with different AI automations. And I know that you've been doing a lot of experimenting with big medium. So can you give us a little like sneak peek, like what are you currently tinkering with, or what are you excited about in terms of how AI can supplement design systems work?
Brad: Yeah. I mean, it's a, it's a big area and I think that it, it kind of travels with this idea of a global design system, which is like, really, I think having a pretty frank conversation about what are we doing here? what should we be doing? I think as time goes on, we shouldn't be rebuilding a badge, right?
We're better than that. We can, we, we have more pressing and more important things to do than, than just kind of like producing and sort of replicating and sort of building this stuff and hand crafting this stuff. Right. So whether it's a global design system, giving us a leg up and a, in a a sturdier, foundation to start with, or if it's Automation. Whether AI or otherwise, helping give us a leg up, that's a win, right? So, again, how AI sort of fits into this is that it can supercharge, accelerate the effort that goes into, the most kind of obvious example is helping produce results. component code for a design system, you can tell AI based on our code standards, this is the work that we've been doing at Big Medium. Kevin Coyle, uh, has been really leading the, the way. My, our colleague there basically said, AI on our design system conventions, on our code conventions, on, on our standards, on our context. now AI, I want you to create a new badge that has an alert and an, you know, that has an error, a success, a warning, kind of variant to that.
And what it'll do is it will produce results, right? Produce that code that looks pretty dang good, right? It's, it's maybe not 100 percent of the way there, but it's basically like a solid, 80 percent of Started a lot of the scaffolding, a lot of the options, a lot of this stuff are like shared, reproducible. maybe the machines should be handling that so that the teams can instead be focused on Whether it's the styling of it, or working with the developers to adopt this stuff and so on and so forth. And I think that that's like the thing to really triple underline here As we have been sort of playing around with this stuff It's really critical You to be moving with a solid set of various human centric principles, Because it's, it gets gross pretty quickly. I think that there's, there's a lot to be afraid of. There's like a lot to, to, to worry about. But when we view it through the lens of other tools, right? How could we use this to enhance our work and elevate ourselves and, take care of more of the mundane, the rote, the, the burdensome, How can we then use our human brains for more pressing things, right? We're figuring out the why, we're figuring out the how, we're figuring out like the sort of like big picture, and then we have the machines to sort of assist us in implementing that. So it's like, I see that As a more respectful use of these tools, rather than like a, we're on autopilot.
We're just sort of clicking buttons or writing just prompts and like, that's the end of it. We're able to sort of express our, human agency a lot more instead of again, we're head down building the button. So we don't have time to do a lot of the more human things that we should be doing.
[00:27:27] Exploring AI in design systems
Ridd: Speaking of useful endeavors, one of the things in your article, you talk about being able to unlock is basically giving design systems teams, more time to experiment with different AI automations. And I know that you've been doing a lot of experimenting with big medium. So can you give us a little like sneak peek, like what are you currently tinkering with, or what are you excited about in terms of how AI can supplement design systems work?
Brad: Yeah. I mean, it's a, it's a big area and I think that it, it kind of travels with this idea of a global design system, which is like, really, I think having a pretty frank conversation about what are we doing here? what should we be doing? I think as time goes on, we shouldn't be rebuilding a badge, right?
We're better than that. We can, we, we have more pressing and more important things to do than, than just kind of like producing and sort of replicating and sort of building this stuff and hand crafting this stuff. Right. So whether it's a global design system, giving us a leg up and a, in a a sturdier, foundation to start with, or if it's Automation. Whether AI or otherwise, helping give us a leg up, that's a win, right? So, again, how AI sort of fits into this is that it can supercharge, accelerate the effort that goes into, the most kind of obvious example is helping produce results. component code for a design system, you can tell AI based on our code standards, this is the work that we've been doing at Big Medium. Kevin Coyle, uh, has been really leading the, the way. My, our colleague there basically said, AI on our design system conventions, on our code conventions, on, on our standards, on our context. now AI, I want you to create a new badge that has an alert and an, you know, that has an error, a success, a warning, kind of variant to that.
And what it'll do is it will produce results, right? Produce that code that looks pretty dang good, right? It's, it's maybe not 100 percent of the way there, but it's basically like a solid, 80 percent of Started a lot of the scaffolding, a lot of the options, a lot of this stuff are like shared, reproducible. maybe the machines should be handling that so that the teams can instead be focused on Whether it's the styling of it, or working with the developers to adopt this stuff and so on and so forth. And I think that that's like the thing to really triple underline here As we have been sort of playing around with this stuff It's really critical You to be moving with a solid set of various human centric principles, Because it's, it gets gross pretty quickly. I think that there's, there's a lot to be afraid of. There's like a lot to, to, to worry about. But when we view it through the lens of other tools, right? How could we use this to enhance our work and elevate ourselves and, take care of more of the mundane, the rote, the, the burdensome, How can we then use our human brains for more pressing things, right? We're figuring out the why, we're figuring out the how, we're figuring out like the sort of like big picture, and then we have the machines to sort of assist us in implementing that. So it's like, I see that As a more respectful use of these tools, rather than like a, we're on autopilot.
We're just sort of clicking buttons or writing just prompts and like, that's the end of it. We're able to sort of express our, human agency a lot more instead of again, we're head down building the button. So we don't have time to do a lot of the more human things that we should be doing.
[00:31:17] Where AI can raise the ceiling
Ridd: Like, if you think about the, role and responsibilities as it exists today of a design systems designer, I also have a high confidence level that there are clear applications specifically on like the code creation front that. Are going to make it so that AI can, can basically just allow us to be way more efficient, do more with less, putting that aside, you used the verb elevate a couple of times. That is something that I I'd be interested in talking a little bit more about because it's like, outside of just making us more efficient, are there things that maybe have a lower confidence level about, but different applications where AI could actually raise the ceiling. Rather than just accelerate our existing workflows that we're more comfortable with today.
Brad: Yeah, no, I think that that's great and I think that's good for you to bring it up to because yeah, it's, it's a little less like, here's the world that we're used to, and there's absolutely applications for AI to sort of make that world more useful. But then there is the, also the, hey, Here's our design system components.
Give me 700 versions of a login page using, using these components, And AI will be like, no problem boss, you know, and just kind of do it. the teams can assess and evaluate and look at that stuff. And I think that that is some of the really wild, ramifications of this stuff is that obviously, you know, machines think differently and sort of come at things from a different angle than humans do.
humans have blind spots, machines have blind spots, and so it really is in like the sort of like combination of oh, let's point it at this thing. Let's have it generate a bunch of ideas. And then sort of from there we can kind of curate things and make some calls, right?
That's still using good human judgment. But I do see like AI in both the creative process as well as just kind of like decision making process. let me just try this like from a whole different angle.
Or like I, I could trust that this weird machine world is going to give me a different perspective. And that helps me think, right? Like that helps me make calls. It helps like either validate my thinking or maybe gives me something else to chew on. And I think that that's really exciting in this world because we kind of have this stuff at the ready.
It's like, show me, show me this, show me it as a short story, show me it as a play, show me it as a, as a comedy, right? It's just being able to sort of like, receive this stuff pretty instantly. can be tremendously empowering from a creative perspective.
Ridd: Yeah. I mean, I've obviously been thinking a lot about it from a UI generation standpoint, something that even going through the big medium blog has got me thinking about too, is just the different ways that AI can level up internal processes as well. I'm like, you know, what would it look like for. A design systems team to be able to communicate guidelines that are dynamic to each individual based off of the context, they'd have their seniority, how long they've been at the company.
Like that stuff is that opened up a whole other can of worms for me. Or I'm like, man, that that's wild.
Brad: Yeah. it's like design system documentation is, is like, there's an unfortunate paradox with it. It's like really important. But nobody wants to write it, nobody wants to read it. it's such like a challenging issue to solve. But also, historically we've thought of documentation as this very static thing that's either like living on a website or living in confluence or sort of something like that.
Which is just like, kind of gross and you have to sort of seek it out It's singular, right? It's written in a certain way, and I do think that there is this opportunity to have this Babble fish like thing that translates it and personalizes it to the individual that's that's receiving it and that if it can sort of come to you in a just in time way, that's really, really powerful, I think that the tools in the in our ecosystem could be better in this respect. So things like Figma, it's like as you're as you're dragging that button, um, From that left sidebar on your canvas, that's a perfect moment for that buttons documentation to find its way to you and better yet, if it's if it finds its way to you and says, Oh, hey, Brad, is who has been
Ridd: I know you.
Brad: many years?
And yeah, yeah, yeah, it's like, here's, you know, here's some stuff, right? Clippy on steroids.
Ridd: I think, uh, you know, if I'm listening to this as a design systems designer, I always try to have. The optimistic lens. I am an optimist. That being said, we've talked about, you know, different elements of the practice that AI, you know, maybe you could see it as supplementing. Maybe you could see it as cannibalizing a little bit, whether it's code creation, maybe documentation.
You know, you can almost feel part of your role slipping through your fingers a little bit. But like AI allows us to do more with less. So. I want to have like a really specific hypothetical just to make this as practical as possible. So let's say, I don't know, a year from now, literally like half of your job.
[00:31:17] Where AI can raise the ceiling
Ridd: Like, if you think about the, role and responsibilities as it exists today of a design systems designer, I also have a high confidence level that there are clear applications specifically on like the code creation front that. Are going to make it so that AI can, can basically just allow us to be way more efficient, do more with less, putting that aside, you used the verb elevate a couple of times. That is something that I I'd be interested in talking a little bit more about because it's like, outside of just making us more efficient, are there things that maybe have a lower confidence level about, but different applications where AI could actually raise the ceiling. Rather than just accelerate our existing workflows that we're more comfortable with today.
Brad: Yeah, no, I think that that's great and I think that's good for you to bring it up to because yeah, it's, it's a little less like, here's the world that we're used to, and there's absolutely applications for AI to sort of make that world more useful. But then there is the, also the, hey, Here's our design system components.
Give me 700 versions of a login page using, using these components, And AI will be like, no problem boss, you know, and just kind of do it. the teams can assess and evaluate and look at that stuff. And I think that that is some of the really wild, ramifications of this stuff is that obviously, you know, machines think differently and sort of come at things from a different angle than humans do.
humans have blind spots, machines have blind spots, and so it really is in like the sort of like combination of oh, let's point it at this thing. Let's have it generate a bunch of ideas. And then sort of from there we can kind of curate things and make some calls, right?
That's still using good human judgment. But I do see like AI in both the creative process as well as just kind of like decision making process. let me just try this like from a whole different angle.
Or like I, I could trust that this weird machine world is going to give me a different perspective. And that helps me think, right? Like that helps me make calls. It helps like either validate my thinking or maybe gives me something else to chew on. And I think that that's really exciting in this world because we kind of have this stuff at the ready.
It's like, show me, show me this, show me it as a short story, show me it as a play, show me it as a, as a comedy, right? It's just being able to sort of like, receive this stuff pretty instantly. can be tremendously empowering from a creative perspective.
Ridd: Yeah. I mean, I've obviously been thinking a lot about it from a UI generation standpoint, something that even going through the big medium blog has got me thinking about too, is just the different ways that AI can level up internal processes as well. I'm like, you know, what would it look like for. A design systems team to be able to communicate guidelines that are dynamic to each individual based off of the context, they'd have their seniority, how long they've been at the company.
Like that stuff is that opened up a whole other can of worms for me. Or I'm like, man, that that's wild.
Brad: Yeah. it's like design system documentation is, is like, there's an unfortunate paradox with it. It's like really important. But nobody wants to write it, nobody wants to read it. it's such like a challenging issue to solve. But also, historically we've thought of documentation as this very static thing that's either like living on a website or living in confluence or sort of something like that.
Which is just like, kind of gross and you have to sort of seek it out It's singular, right? It's written in a certain way, and I do think that there is this opportunity to have this Babble fish like thing that translates it and personalizes it to the individual that's that's receiving it and that if it can sort of come to you in a just in time way, that's really, really powerful, I think that the tools in the in our ecosystem could be better in this respect. So things like Figma, it's like as you're as you're dragging that button, um, From that left sidebar on your canvas, that's a perfect moment for that buttons documentation to find its way to you and better yet, if it's if it finds its way to you and says, Oh, hey, Brad, is who has been
Ridd: I know you.
Brad: many years?
And yeah, yeah, yeah, it's like, here's, you know, here's some stuff, right? Clippy on steroids.
Ridd: I think, uh, you know, if I'm listening to this as a design systems designer, I always try to have. The optimistic lens. I am an optimist. That being said, we've talked about, you know, different elements of the practice that AI, you know, maybe you could see it as supplementing. Maybe you could see it as cannibalizing a little bit, whether it's code creation, maybe documentation.
You know, you can almost feel part of your role slipping through your fingers a little bit. But like AI allows us to do more with less. So. I want to have like a really specific hypothetical just to make this as practical as possible. So let's say, I don't know, a year from now, literally like half of your job.
[00:36:25] Higher-leverage activities for design systems designers
Ridd: AI is meaningfully contributing to where you have more time on your hands to pursue some of these higher leverage activities. say a design system designer opens up their laptop on a Monday morning. What are some of those activities that you would like to see design systems, designers able to do more of in an AI world?
Brad: rather than opening the laptop and firing up the Figma art board with the component, it's like AI took care of that. Let's just say it's
Ridd: Yep.
Brad: The components, bones are there. The different variants are articulated.
Ridd: And maybe some bad ass documentation exists that
you didn't have to do from scratch.
Brad: exactly. So, so that already, great. You didn't have to do that. The design system designer, What I would love to see them be doing is, Reaching out to the different teams like we've been sort of talking about to sort of get a sense of what they're working on, what they're what they're struggling with, what good ideas are happening at that product pace layer that might be good candidates to sort of consider for the design system, right?
So that's like the other part of this pace layer thing is like, That fast paced layer exists, and a thousand flowers bloom, and different teams have different sort of solutions for the same thing. The role of a design system designer is one of curator, but in order to do that, they have to have their heads and hands free to be able to do that curation work.
So, going outward and connecting with other people. So, hey, how's this been working out for you? Let's like Pull up the analytics for this thing. How did this thing perform? Oh the blue buttons are doing better than the purple buttons Oh, that's interesting and stuff like that, right? So so there's this like more again this sort of discernment this curation this this connection That's happening instead of just I am creating rectangles in an art board, right?
So for a lot of people, that is scary. And I think that, that you're right to say is like, I think that a lot of folks feel like their jobs are sort of slipping between their fingers. We love to hand craft and carefully curate, you know, that this stuff, right.
In the same way that in artisanal knife maker, it, the process is enjoyable. It's very satisfactory. It's, it's truly amazing to sort of witness this at the same time, open up your silverware drawer in your kitchen. That's not how we acquire knives these days, right?
Like, It's a reality that. certain aspects of our job, the rectangle creation, the code creation and stuff like that are increasingly becoming a commodity.
I think that's, that's fair. But again, the sort of human work, the connection work of like figuring out like, what should we be doing? How? Oh, here's these like sort of new upcoming objectives or this new thing that we are launching a brand new product or a brand new feature or whatever. How might we be supporting that?
Like, what can we be doing? That more sort of strategic architectural support service human work creating this connective tissue between the humans that make up an organization is like increasingly going to be the job, right, as the sort of nuts and bolts of it are commoditized, it's scary if you only see your job as a rectangle creator for what it's worth before all this AI stuff, you know, just even as, as design systems entered the scenes, we saw a lot of people threatened by that, Because they're like, wait, what do you mean? Like you have the button, like I, I make the button and you're telling me I don't make the button anymore.
And, and it is, it's like that same like level of existential, Well, what do I do? what I would really encourage everyone listening to this is like, really understand what your value is as a human being. Like you are more than a rectangle creator or just a rote you know, sort of producer of some front end code, like, like you're problem solver.
communicator, all of these, these more sort of intangible aspects of what it is to be human or, and even what it is to be a designer, right? Sort of like solving these problems, thinking about this stuff, considering things, critical thinking, good ethical, again, sort of thinking and stuff like that, that stuff is going to matter more and more and more and more.
And hopefully that is what. consumes more of our day as you sort of fire up your laptop on Monday. It's, it is less about the let's produce some rectangles and more lights. Let's go out, see what kind of problems we're all trying to sort of work through and figure out how this critical infrastructure that we help manage can help facilitate what we're trying to accomplish here and to do it in a thoughtful, human centric, ethical, respectful way.
Ridd: Before I let you go, I want to take advantage of your skill set as someone who understands like the design side of things, but also is really front end savvy, because I think there's kind of this pull and AI is playing a big part of it is there's this pull where designers are feeling like, okay, maybe I should embrace a little bit more of a technical skill set.
I think that starts with Figma because. Whether designers want to or not, Figma has with their new features, kind of inserted designers into more technical conversations around props and tokens and different component library structures. You know, I teach a lot of people about Figma and this comes up a lot, which is basically, Hey, I know that I'm supposed to be having these conversations with my engineers.
I know that we're supposed to be on the same page and using the same language. Those conversations are not happening. And actually I'm a little bit scared of it because I don't know how to break the ice. I'm afraid of looking stupid.
[00:36:25] Higher-leverage activities for design systems designers
Ridd: AI is meaningfully contributing to where you have more time on your hands to pursue some of these higher leverage activities. say a design system designer opens up their laptop on a Monday morning. What are some of those activities that you would like to see design systems, designers able to do more of in an AI world?
Brad: rather than opening the laptop and firing up the Figma art board with the component, it's like AI took care of that. Let's just say it's
Ridd: Yep.
Brad: The components, bones are there. The different variants are articulated.
Ridd: And maybe some bad ass documentation exists that
you didn't have to do from scratch.
Brad: exactly. So, so that already, great. You didn't have to do that. The design system designer, What I would love to see them be doing is, Reaching out to the different teams like we've been sort of talking about to sort of get a sense of what they're working on, what they're what they're struggling with, what good ideas are happening at that product pace layer that might be good candidates to sort of consider for the design system, right?
So that's like the other part of this pace layer thing is like, That fast paced layer exists, and a thousand flowers bloom, and different teams have different sort of solutions for the same thing. The role of a design system designer is one of curator, but in order to do that, they have to have their heads and hands free to be able to do that curation work.
So, going outward and connecting with other people. So, hey, how's this been working out for you? Let's like Pull up the analytics for this thing. How did this thing perform? Oh the blue buttons are doing better than the purple buttons Oh, that's interesting and stuff like that, right? So so there's this like more again this sort of discernment this curation this this connection That's happening instead of just I am creating rectangles in an art board, right?
So for a lot of people, that is scary. And I think that, that you're right to say is like, I think that a lot of folks feel like their jobs are sort of slipping between their fingers. We love to hand craft and carefully curate, you know, that this stuff, right.
In the same way that in artisanal knife maker, it, the process is enjoyable. It's very satisfactory. It's, it's truly amazing to sort of witness this at the same time, open up your silverware drawer in your kitchen. That's not how we acquire knives these days, right?
Like, It's a reality that. certain aspects of our job, the rectangle creation, the code creation and stuff like that are increasingly becoming a commodity.
I think that's, that's fair. But again, the sort of human work, the connection work of like figuring out like, what should we be doing? How? Oh, here's these like sort of new upcoming objectives or this new thing that we are launching a brand new product or a brand new feature or whatever. How might we be supporting that?
Like, what can we be doing? That more sort of strategic architectural support service human work creating this connective tissue between the humans that make up an organization is like increasingly going to be the job, right, as the sort of nuts and bolts of it are commoditized, it's scary if you only see your job as a rectangle creator for what it's worth before all this AI stuff, you know, just even as, as design systems entered the scenes, we saw a lot of people threatened by that, Because they're like, wait, what do you mean? Like you have the button, like I, I make the button and you're telling me I don't make the button anymore.
And, and it is, it's like that same like level of existential, Well, what do I do? what I would really encourage everyone listening to this is like, really understand what your value is as a human being. Like you are more than a rectangle creator or just a rote you know, sort of producer of some front end code, like, like you're problem solver.
communicator, all of these, these more sort of intangible aspects of what it is to be human or, and even what it is to be a designer, right? Sort of like solving these problems, thinking about this stuff, considering things, critical thinking, good ethical, again, sort of thinking and stuff like that, that stuff is going to matter more and more and more and more.
And hopefully that is what. consumes more of our day as you sort of fire up your laptop on Monday. It's, it is less about the let's produce some rectangles and more lights. Let's go out, see what kind of problems we're all trying to sort of work through and figure out how this critical infrastructure that we help manage can help facilitate what we're trying to accomplish here and to do it in a thoughtful, human centric, ethical, respectful way.
Ridd: Before I let you go, I want to take advantage of your skill set as someone who understands like the design side of things, but also is really front end savvy, because I think there's kind of this pull and AI is playing a big part of it is there's this pull where designers are feeling like, okay, maybe I should embrace a little bit more of a technical skill set.
I think that starts with Figma because. Whether designers want to or not, Figma has with their new features, kind of inserted designers into more technical conversations around props and tokens and different component library structures. You know, I teach a lot of people about Figma and this comes up a lot, which is basically, Hey, I know that I'm supposed to be having these conversations with my engineers.
I know that we're supposed to be on the same page and using the same language. Those conversations are not happening. And actually I'm a little bit scared of it because I don't know how to break the ice. I'm afraid of looking stupid.
[00:42:30] How designers can communicate better with engineers
Ridd: What advice do you have for that person to get some momentum and just to really build some of those initial communication bridges with engineers when they don't really have the lingo, even
Brad: the word that comes to mind is just humility and like getting over that. Like, I'm afraid to talk to this other person because I don't want to, you know, feel like I'm, I'm stupid. I encourage everyone to get over that and just be like, Hey, you know, I'm about to start working on this developer.
what do you have to say about this? Or how do you, how do you tend to do this? Or it'd be welcome for me or helpful for me to sort of get a better window into your world and how you're sort of coming at this. I think that that just a little bit of that goes so far. Especially because, and, and, and I think that you are right in that, like, as Figma has evolved as a tool, as like the world of UI development has, evolved a bit more, things like props, token names, the architecture, auto layout, like a lot of these like kind of conventions are Getting closer and map to how developments been happening for a whole lot longer than figmas had these features, right?
So so it's it is Important for designers to understand a lot of these concepts Here is what it looks like a variant name is, and here's the values that it has. And like, this is work that, you know, again, developers have been doing for a very, very, very long time. So they're actually, like, really well positioned to be guides and sherpas for the designers.
What we tend to see in our work is that, yeah, the designers are kind of, like, off, and they're kind of, inventing their own language, and it's like, oh no, meanwhile, the developers have had these conventions in place for a long time, so that language, a shared language, prop names and values and things like that, token names, token values, and organizational structures around that stuff, that's really important.
It's not that designers need to learn how to code necessarily or anything like that, but having a solid understanding of how to the box model works and stuff like that so that they're creating solution Positioning and stuff like on the web for instance. It's like having a solid understanding of how that works will make you a better designer but More importantly, it is, again, sort of cultivating that relationship with these people who really are a lot closer to this stuff.
And I think that, again, it requires, like, a little bit of humility on the designer's part. Where it's like, yeah, I don't know all the intricacies of, like, how this stuff is implemented in a browser or whatever. So, having a conversation with a developer. is in my best interest, but in all of our collective best interests, because so much waste happens whenever designers just kind of go off on their own, produce stuff, worse if they get feedback and approval, and then it gets handed off to developers, and then developers have to be the gross naysayers who say, no, this is wrong, and here's why, and blah, blah, blah, and we have to do this sort of back and forth.
That, like, couple minute conversation to just kind of be like, Hey, can you show me, like, how you tend to do things here? I'm about to embark on this, and I would love to sort of have a better understanding of it, so that I'm matching your world as much as possible. whenever you get enough of a sketch of something in place, reconnect with that person to validate it and then you're you're able to sort of like go from there
Ridd: I like the humility where, cause it does, it ties back to this idea of the service design, even if that's kind of your role a
little bit and.
Brad: You you you're all on the same team producing Real software that real human beings use it's important for designers who are working in figma to realize that there is like Work that happens beyond your world and it's in your best interests of people who ultimately want to make You Produce not just good pictures of software, but good actual software.
It's in your best interest to Build bridges and connections with the developers and better understand how this stuff actually plays out in the real medium That real human beings will interact with your design Like the more you're able to do that the better of a designer you you will be
Ridd: now I want to end with the single most important question of all, which is, can you tell us what is happening on August 17th?
Brad: Yeah, so on August 17th, uh, I'm, I'm throwing a big, uh, concert. I kind of use my upcoming 40th birthday as an excuse to sort of throw this big benefit concert. And, uh, as you know, our, well, you have a keyboard behind you. So you, you of course know. I know, uh, A bunch of designers and developers who are all very musical, some of which who like were professional musicians before you realize is like, Oh, it's tough to have a family and stable income as a, as a working musician.
But so anyway, so like through my adventures in my career, but also just in life, right from, from my university days and, and even my, my family and stuff, I know a bunch of really talented musicians. so I got this crazy idea of it's like, let's get all of those really talented musicians together. a whole year of planning.
Let's, let's do this one night only show on August 17th in Pittsburgh. And what we're going to do is we're going to Figure out what we're going to play and then we have like a year to like have everybody learn, rehearse, practice, record, do a bunch of stuff. And then basically one night only we're all going to get together and play a show.
So it'll be like a 40 plus person super group. So like, you know, a few people are on like a couple songs, a few people are on like a few more. We've got like. A load of different guitarists, a load of different keyboard players, a load of different vocalists. We, and we're like cutting across genres. We're cutting across like time and space and it's going to be just one big freaking party, fun show.
I'm, I am so incredibly excited about it. Yeah.
Ridd: So very excited about it. You heard it here first. The, the, the concert to end all concerts, August
Brad: Yeah. And it's, and again, it's a benefit show. It's, it's, it's benefiting, um, Project Healthy Minds, which is a mental health nonprofit, as well as, um, My cousin, uh, is going to be, um, opening a spinal cord injury rehabilitation center in Pittsburgh. So those are the kind of two beneficiaries of it, but yeah, so it's, it's going to be a lot of fun.
So if you, if you want something fun to do on August 17th, come to Pittsburgh and party with us.
Ridd: I love it. Well, Brad, this has been a blast. Thank you so much for taking the time today and just sharing a little bit about what's going on in your world, what you're thinking about. It's been super insightful and appreciate it.
Brad: Yeah, thank you so much for having me. This has really been a treat. So thank you.
[00:42:30] How designers can communicate better with engineers
Ridd: What advice do you have for that person to get some momentum and just to really build some of those initial communication bridges with engineers when they don't really have the lingo, even
Brad: the word that comes to mind is just humility and like getting over that. Like, I'm afraid to talk to this other person because I don't want to, you know, feel like I'm, I'm stupid. I encourage everyone to get over that and just be like, Hey, you know, I'm about to start working on this developer.
what do you have to say about this? Or how do you, how do you tend to do this? Or it'd be welcome for me or helpful for me to sort of get a better window into your world and how you're sort of coming at this. I think that that just a little bit of that goes so far. Especially because, and, and, and I think that you are right in that, like, as Figma has evolved as a tool, as like the world of UI development has, evolved a bit more, things like props, token names, the architecture, auto layout, like a lot of these like kind of conventions are Getting closer and map to how developments been happening for a whole lot longer than figmas had these features, right?
So so it's it is Important for designers to understand a lot of these concepts Here is what it looks like a variant name is, and here's the values that it has. And like, this is work that, you know, again, developers have been doing for a very, very, very long time. So they're actually, like, really well positioned to be guides and sherpas for the designers.
What we tend to see in our work is that, yeah, the designers are kind of, like, off, and they're kind of, inventing their own language, and it's like, oh no, meanwhile, the developers have had these conventions in place for a long time, so that language, a shared language, prop names and values and things like that, token names, token values, and organizational structures around that stuff, that's really important.
It's not that designers need to learn how to code necessarily or anything like that, but having a solid understanding of how to the box model works and stuff like that so that they're creating solution Positioning and stuff like on the web for instance. It's like having a solid understanding of how that works will make you a better designer but More importantly, it is, again, sort of cultivating that relationship with these people who really are a lot closer to this stuff.
And I think that, again, it requires, like, a little bit of humility on the designer's part. Where it's like, yeah, I don't know all the intricacies of, like, how this stuff is implemented in a browser or whatever. So, having a conversation with a developer. is in my best interest, but in all of our collective best interests, because so much waste happens whenever designers just kind of go off on their own, produce stuff, worse if they get feedback and approval, and then it gets handed off to developers, and then developers have to be the gross naysayers who say, no, this is wrong, and here's why, and blah, blah, blah, and we have to do this sort of back and forth.
That, like, couple minute conversation to just kind of be like, Hey, can you show me, like, how you tend to do things here? I'm about to embark on this, and I would love to sort of have a better understanding of it, so that I'm matching your world as much as possible. whenever you get enough of a sketch of something in place, reconnect with that person to validate it and then you're you're able to sort of like go from there
Ridd: I like the humility where, cause it does, it ties back to this idea of the service design, even if that's kind of your role a
little bit and.
Brad: You you you're all on the same team producing Real software that real human beings use it's important for designers who are working in figma to realize that there is like Work that happens beyond your world and it's in your best interests of people who ultimately want to make You Produce not just good pictures of software, but good actual software.
It's in your best interest to Build bridges and connections with the developers and better understand how this stuff actually plays out in the real medium That real human beings will interact with your design Like the more you're able to do that the better of a designer you you will be
Ridd: now I want to end with the single most important question of all, which is, can you tell us what is happening on August 17th?
Brad: Yeah, so on August 17th, uh, I'm, I'm throwing a big, uh, concert. I kind of use my upcoming 40th birthday as an excuse to sort of throw this big benefit concert. And, uh, as you know, our, well, you have a keyboard behind you. So you, you of course know. I know, uh, A bunch of designers and developers who are all very musical, some of which who like were professional musicians before you realize is like, Oh, it's tough to have a family and stable income as a, as a working musician.
But so anyway, so like through my adventures in my career, but also just in life, right from, from my university days and, and even my, my family and stuff, I know a bunch of really talented musicians. so I got this crazy idea of it's like, let's get all of those really talented musicians together. a whole year of planning.
Let's, let's do this one night only show on August 17th in Pittsburgh. And what we're going to do is we're going to Figure out what we're going to play and then we have like a year to like have everybody learn, rehearse, practice, record, do a bunch of stuff. And then basically one night only we're all going to get together and play a show.
So it'll be like a 40 plus person super group. So like, you know, a few people are on like a couple songs, a few people are on like a few more. We've got like. A load of different guitarists, a load of different keyboard players, a load of different vocalists. We, and we're like cutting across genres. We're cutting across like time and space and it's going to be just one big freaking party, fun show.
I'm, I am so incredibly excited about it. Yeah.
Ridd: So very excited about it. You heard it here first. The, the, the concert to end all concerts, August
Brad: Yeah. And it's, and again, it's a benefit show. It's, it's, it's benefiting, um, Project Healthy Minds, which is a mental health nonprofit, as well as, um, My cousin, uh, is going to be, um, opening a spinal cord injury rehabilitation center in Pittsburgh. So those are the kind of two beneficiaries of it, but yeah, so it's, it's going to be a lot of fun.
So if you, if you want something fun to do on August 17th, come to Pittsburgh and party with us.
Ridd: I love it. Well, Brad, this has been a blast. Thank you so much for taking the time today and just sharing a little bit about what's going on in your world, what you're thinking about. It's been super insightful and appreciate it.
Brad: Yeah, thank you so much for having me. This has really been a treat. So thank you.
Deep Dives
Get our weekly breakdowns
Insights + resources from top designers 👇
Lauren LoPrete
Director of Design Systems @ Cash App
David Hoang
VP of Marketing and Design @ Replit
Adrien Griveau
Founding Designer @ Linear
James McDonald
Designer @ Clerk
Femke
Design Lead @ Gusto
Join 10K+ designers
HC
HC
HC
HC
hello@dive.club
Ⓒ Dive 2024