Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS
Dan MallThe basics of building a design system are fairly simple. Ensconcing a system in an organization’s culture so that it’s actually adopted and used is a more complex undertaking.
Dan Mall takes a content-first approach as he helps organizations evolve their design systems from projects to products and ultimately to firmly embedded practices that let teams deliver the efficiency and consistency benefits that such systems offer.
We talked about:
- his Design System University
- an overview of the professional challenges that come with building and running a design system
- his new book Design That Scales: Creating a Sustainable Design System Practice
- his addition to the conventional list of design-system benefits – in addition to efficiency and consistency – relief
- the tragically common story of how design systems can end up becoming “ghost towns and graveyards”
- how to ensconce good design-system ideas and practices in company culture
- how you can benefit by adopting a humble attitude toward design-system work
- how good design systems evolve from a project to a product and ultimately to a practice focus
- the importance of repetition in design system messaging strategy
- the crucial role of content in design systems
- how, when he teaches design-system process, he always starts with plain, unadorned text
- how design systems make it possible to quickly iterate on possible ways to present content to users
- how new technologies and practices like headless CMSs and microservices-based architectures work with design systems
- his thoughts on content orchestration and experience orchestration
- how AI fits into the design-system world
- the importance of having a vision for your design system, but to also appreciate and embrace detours and serendipity along with way
Dan’s bio
Dan Mall is a husband, dad, teacher, creative director, designer, founder, and entrepreneur from Philly. He runs Design System University, where he creates, collects, and curates curriculum, content, and community to help enterprise teams design at scale. Previously, Dan ran design system consultancy SuperFriendly for over a decade. Dan writes about design systems, process, and leadership and other issues on his site danmall.com and in his weekly newsletter.
Connect with Dan online
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 169. The basic idea of a design system is simple enough to grasp and easy enough to prototype, but turning a collection of components and design guidance into a coherent system that people actually use – that’s a whole other story. Dan Mall helps organizations embed design systems in their organizational culture so that designers, engineers, and product folks can efficiently and consistently deliver excellent experiences, always starting with content concerns at the forefront.
Interview transcript
Larry:
Hi everyone. Welcome to episode number 169 of the Content Strategy Insights podcast. I’m really excited today to have with us Dan Mall. Dan is like, if you google design systems, his name pretty much comes up, I think, and part of it, and what he does nowadays is he, he’s the founder and runs the Design System University. So welcome, Dan. Tell the folks a little bit more about what’s cooking there at Design System U.
Dan:
Yeah, awesome. Thank you, Larry. Thank you for having me. Design System U is a place where people can get support and content and community around designing at scale. That’s something that I think a lot of us as designers and engineers and content folks and all those things, we just don’t get training in that kind of stuff.
Dan:
And so I wanted to create something that allowed people to have some support and community and content and training to really work at scale when we make digital tools and we make digital things for people… Now for millions and millions and billions of people, people like us are making for and who has that training coming out of school or learning how to do this from our parents’ basements.
Larry:
That’s right. And as you say that, I’m reminded there’s that, well-known trope now that you go from practicing to managing, but then from going from managing to building a whole system around a thing. That’s like an even bigger leap. Is that a challenge for both… it’s like senior level ICs and managers that are working with design systems?
Dan:
Oh, one hundred percent. I mean, you talk about the Peter Principle, right? It’s like you go from, if you’re in design school as a designer, you go from making posters or books or a website or an app or things like that to now you’ve got to support all these different types of people and you use cases and needs and abilities and all that kind of stuff. I mean, almost all of it is trial by fire and some people decide, “Not for me.” And that’s okay. And then some people go, “I really want to do that, but I don’t know how to do that.” And a lot of times we learn at user’s expense and I think that there’s probably a better way to do it. Maybe we can learn from each other’s mistakes, maybe we can learn from each other’s stories and successes in addition to our own failures.
Larry:
Yeah. And you’ve been doing this a while, so this is ensconced in your curriculum at Design System U, but you also, and that’s how we ended up connecting. You also wrote a book. Tell me a little bit about your new book.
Dan:
Yeah, cool. So it’s published by Rosenfeld Media, my friends at Rosenfeld Media. It’s called “Design That Scales” and the subtitle, it’s “Creating a Sustainable Design System Practice.”
Dan:
So it took a while for us to land on that title. We had a bunch of different variations, but that’s one that once we got there I was like, “Yeah, that’s it. That’s what this book is about and is about how to create design that’s not just one website at a time, one app at a time, one digital experience at a time. But how do we do things that impact lots of people? How do we do…”
Dan:
And part of that impact is how do we do design and engineering and content in a way that impacts our coworkers and our colleagues at scale? Not just our end customers, but even the people making the stuff. How do we do that in a smarter way? How do we do that in a more efficient way? And also how do we do that in a more innovative way? And then the last piece that I like to add to that, because I think those are the typical stories around design systems. The one that I like to add to that is how do we do that in a way that relieves us, in a way that gives us more rest, in a way that gives us more energy? I think that one gets talked about least and perhaps is maybe the most important, or at least my favorite of the bunch. So I think that’s an important piece.
Larry:
Yeah, I was totally intrigued by that because everybody talks about, well, and actually you almost always just hear efficiency and consistency. Those are the two main benefits. And the innovation is sort of like, I always pictured it, not to diss you guys, but as a way to say, “Oh, no, no, no, no, we’re not constraining you with this system. It gives you more room to innovate.” But there is a genuine opportunity to innovate in there, of course.
Dan:
There is. And also you’re right, it’s like a lot of times it’s like, “Oh, by the way, oh yeah, we do get innovation. How, we’re not sure.” But it is a way to say, “This is not going to make you less creative. This is actually going to help you be more creative too.” So sometimes it does feel like a little bit of a gimme.
Larry:
Yeah. But at the same time, having worked in and around design systems, it’s true. You free up designers through other stuff. But also I love the fourth thing, the relief, because one of the things that I think we’re increasingly concerned about with as designers is reducing the cognitive load and emotional burden on our users, but also internal users. Is that where that relief idea comes from?
Dan:
That’s definitely one piece of it, which is something that used to take us six months to do. If we have smart systems that are helpful to us that we’ve made that we know how to use, maybe instead of taking six months, it takes three months. And so we’ve got three months of savings there.
Dan:
So what do we normally do with that three months? We’ve tried to pack more work into it. So this typical story is double the amount of work in one amount of time, and it’s like, well, what if we just get it done in three months and then give ourselves a break? It’s still doing one thing in six months, but we have better mental health because of it.
Dan:
And I think that that story just, that’s less attractive, it’s less appealing, especially in a very business-centric culture that we live in, especially where design systems tend to live, which is at enterprise, things that are reaching lots and lots of people. And so we try to pack in as much as we can. “We got to be more productive. We got to ship to more users.” Everything is more more more. And you see the toll that that’s having on people in society. We’re burning out faster, people are leaving their jobs, people are quiet quitting. I think those things are not a coincidence how tied together they are.
Larry:
Yeah, and now I’m jumping ahead towards the end of the book. When you talk about Dan Pink’s work around what actually motivates workers in the modern cognitive economy and a lot of that like, “Oh, we got to do more because we finished early.” It’s like, “No, that’s a 20th century thing. We’re in the 21st century now. It’s all about autonomy, mastery and purpose.” Is that, yeah…
Dan:
One hundred percent. We do knowledge work now. It’s when we were doing industrial work centuries ago that made sense, where we could pack more in because our tools are getting better, but it’s not at that much more of a cognitive load for us. But as humans, we have a limited capacity in our cognitive load. So to try and overload that, to try and hijack that of course takes a negative toll on us. Our brains just don’t have the capacity to be able to do that.
Dan:
And so I think that’s like if we try to apply that old industrial worker approach to doing knowledge work, it doesn’t fit that way. So even though we invent more efficient tools and better systems and things like that, we can do a different thing with the output of the benefits of that.
Larry:
Nice. Yeah, just… I want to back up a little bit because we kind of jumped right into the middle of this. One of the things, and part of it is just because I’m so enamored of this image you had at the start of the book about ghost towns and graveyards, and you kind of alluded to this a minute ago when you talked about, you know it’s usually designers, engineers kind of build some stuff and then you start codifying it in a system. But talk a little bit about ghost towns and graveyards.
Dan:
Yeah, sure. So a lot of design systems tend to start with a designer or an engineer or a designer engineer pair or some small group that is just dissatisfied with the way that they’re doing work. They realize that there’s efficiencies that can be had or there’s other ways that they could improve their own work at lower cognitive load. So they tend to make things for themselves, and it tends to start in a making space. So “Wow, we don’t want to make this stuff over and over again. We spot the patterns now. So if we made it ahead of time or pre-made it, then actually we can make something easier.” And I think it’s similar to the idea of we could cook a meal from scratch or we could have microwave dinners, which makes sense. It’s a lot faster, but there’s a lot of toll that comes with that too.
Dan:
And so when designers and engineers start from making space, it’s well-intentioned, and it’s generally like, “Well, we made tools for us that actually help us in our work. What if we share these things with other people? Maybe it could help them with their work too. My colleagues, all the people that I work with, I’m going to share this around.”
Dan:
And a lot of times what works really well for a designer-engineer pair, they share it to other teams, they share it to other people, and then it just falls flat. And then they go, “Oh, I wonder why they’re not using it.” And every organization I’ve ever worked with has this story multiple times where they have design systems that are really well-made and well-built and well-crafted that no one is using.
Dan:
So I talk about those as there are design system ghost towns where all these buildings are set up and yet there’s no one there, tumbleweeds rolling across the scene. And then eventually sometimes it’s just like for a long time, no one inhabits that town and it just turns into just a straight-up graveyard. We have buried these things. And so a lot of design systems end up being ghost towns and graveyards because the process and the context of them isn’t considered. And so they end up being artifacts that are old and not used.
Dan:
And I think a lot of people throw the baby out with the bathwater there where they go, “Oh, design systems won’t work here,” or “We’re too big for that,” or “Our organization can’t use those kinds of things.” And it’s because they didn’t manage the process well. They didn’t manage how it exists in culture of their organization.
Dan:
So the book is a lot about how do you avoid design system ghost towns or design system graveyards and spoiler: the idea is that you have to plug it into the culture as soon as you can.
Larry:
Yep. And that’s something… I’ve seen that a lot and I’ve talked to a ton of people about design systems stuff, and that’s the dynamic you described with the ghost towns and graveyards and the dying on the vine and the enthusiastic pair that created this thing just like, “Oh, my God,” walking through this deserted town by themselves. But what is the, and this gets into… One of my real ambitions in this podcast is to advance practice and to find whatever those intellectual or professional development leaps that you need to make to get to that nuanced level that helps that pair, that really nobly motivated people who got good ideas about how we could do things more efficiently. How do you get that? And you just alluded to like it’s got to be ensconced in culture. How do you do that?
Dan:
A lot of it is about changing your mind, both literally and metaphorically is there’s some things that a lot of teams think and people think about design systems that maybe needs a reframing and then literally you need to make your brain different in order to understand this. I love the word that you just used there, which is noble. I think a lot of people approach design system work as a noble enterprise, which it is, but it’s hard to be scrappy when you think about something that’s noble.
Dan:
And I like to use the word humble instead of noble. Gardening is humble. I don’t know if anybody would describe gardening as noble. It is. There is a nobility to it, right? When you grow something and you’re able to maybe eat the vegetables that you’ve planted and harvested, that’s a noble quest that you’ve gone on and you see the fruit of that labor, but it’s more humble than it is noble. You get dirty and you’re in the dirt and you are scraping around and you get soil in your fingernails and there’s all that stuff and you’re kneeling down and you’re getting your clothes all must.
Dan:
And that’s what it takes to have something grow is you’ve got to plant it and you’ve got to water it and you’ve got to do it every day. You can’t just water it once and then you go, “I don’t know. The rain will take care of it.” Because that’s not how some crops work. So that’s the practice part of it is you got to go out every day and water, you got to set your sprinkles on, or to get the hose out. And then sometimes you have to transplant things. You have to move them from this place to this place because hey, it doesn’t get as much sun as you thought it would over here.
Dan:
And so there’s all this humble work that’s associated with it that’s dirty, that’s messy, that’s just not elegant. That’s not something you write the blog post about. And I think that’s a lot of how design system work happens and how design systems grow is it’s a lot of humble work. And so I think that that nobility is such a double-edged sword and it is noble work because you’re doing things that really help people and that’s noble. But to get that work to grow is more humble, I think.
Larry:
No, I think the people I know who have built successful design systems would totally agree with that and would buy that image of you’re kneeling in the dirt all day and then you maybe get a little nobility when you come in at dinnertime and tell your family what a great job you did in the garden that day.
Dan:
Yes.
Larry:
You’ve mentioned practice a couple of times, and I want to go, one of the things, one of the follow-ons right after the ghost towns and graveyards, you talk about that sort of evolution and I think this is the pair of people who come up with the idea that’s kind of a project based thing and you talk about product and then a lot of people talk about productizing a design system and treating it that way, but then you talk about the evolution into a full-blown practice. Can you talk about that pathway?
Dan:
Yeah, totally. I think there’s a big tie between design system graveyards and design system practices in that practices prevent it from becoming a graveyard or a ghost town. And I think where a lot of people who are well-meaning and doing the noble work, they think that if you just create the best components, well then people will use them, right? You don’t have to do anything over and over again. It’s like, so they lean on the objectivity of the system. They lean on if our code is crafted well enough or our Figma files or our copy or our accessibility, or if only that is… it meets some threshold or exceeds some threshold of goodness, of amazingness, of excellence, then people will be drawn to it. And I’m like, “I actually don’t know many products in our world that actually do that. It’s usually something else that catches someone.”
Dan:
It’s either they’re looking to solve some pain or they see some benefit that is greatly outweighs things. And oftentimes those are irrational. It’s the same… The people who are going to use the design system is kind of the same thing as some people buying a $3,000 pair of shoes or a handbag or something like… It’s irrational, but there’s something in it that you’re like, “Ooh, that makes me feel good,” or “That makes me feel like I’m going to get something out of having that or doing that or using that.” And I think a lot of that stuff comes from practice. It comes from, I know for leadership and for leaders, there’s a lot of these mantras of once you get tired of saying something over and over again, that’s when people are starting to hear it.
Dan:
So I think it’s the same thing as people set up a design system and they go, “Well, it’s really good, so people should use it.” And they don’t repeat it at all. They don’t repeat their message, they don’t keep saying it to people. They don’t keep evangelizing it. They don’t send a weekly newsletter to the rest of the team. They don’t do any of that stuff. They go, “Well, we made it. I wonder why people aren’t using it.” It’s very much this, if we build it, they will come. I think that’s where the practice comes in is a lot of the stuff that I talk about in the book, and when I work with teams on their design systems, I go, “We got to do stuff over and over again. We make a component, we got to sing about it every week. We got to put it up on the website, we got to send the newsletter out, we got to send the Slack messages.”
Dan:
And those things don’t happen by accident and those things don’t happen organically either. They happen on purpose, they happen when you make a practice out of it. And so a lot of teams that I work with, I go, “Okay, Friday’s our design system day. On Friday, we’re going to do these six rituals. We’re going to write the blog posts, we’re going to send the messages, we’re going to schedule the tweets or whatever it is that we’re doing public, private, internal, whatever that is.”
Dan:
It’s got to be a practice, and it’s a new habit. And I think that’s the stuff that’s hard for teams is developing a new habit’s hard. You ever try running when you haven’t run in years? That sucks. And so there’s got to be something that makes you go, instead of sitting on the couch, I will get up and run today. There’s got to be something at the end of the tunnel or something motivating or a lot of people have a health scare and that’s what motivates them to run. So there’s got to be some pain or some benefit that come from that in order to get that practice going. And then once it becomes a practice, at some point it flips to it’s actually harder to stop doing this thing than it is to continue doing it. But a lot of design systems teams never reach that point.
Larry:
That’s the definition of a good habit, replacing the bad, old one. That’s good.
Dan:
Yeah.
Larry:
Hey Dan, I got to point out that we’re almost halfway through our time, and this is a Content Strategy podcast and you exhibited your word nerdery a few minutes ago when you made the distinction between nobility and humility. But I got to do my word people justice and make sure we talk about the content that’s all over the place in design systems.
Larry:
We talked about this a little bit before we went on the air, but just as my crackpot way of looking at it, I kind of see three kinds of content, the content that’s in a design system, the documentation of it, like how you use these components and what our foundational principles are and the descriptions of the tokens and all that stuff. Then the content that goes into a design, like the UI strings and the instance data of a database-driven site or something.
Larry:
And then I also think about content about governance stuff and release notes and just kind of maybe boring but necessary stuff. How important to you is content in the context of a design system?
Dan:
Crucial. There’s two things that I teach when I teach design systems, usually. The first thing is called piloting. I think there’s a specific way that you get components into a design system, and that is not by making them and then having teams use them and then having teams contribute to it. So I teach piloting, and we can get into that.
Dan:
But the second thing that I teach, I can’t not teach this because I think I’m doing a disservice by not teaching this part when I talk about design systems is I teach process and workflow and I talk about how can you make things when you do have a design system, what does that process look like? What does the promised land look like? If we have this amazing design system, we’ve got all the components, we’ve got… where do you start? And designers and engineers who generally are the audience that I speak to, they tend to start with design and engineering naturally.
Dan:
And so they go, “Okay, the first place that we should start is we’ll look at our design system and we’ll look at what components we have, and then we’ll figure out what components to use.” I’m like, “Against what?” And that usually leads them to go like, “Oh, we probably need some content, right?” And I’m like, “Yes. That’s where we start with, when you have a full fruition of a design system, what does that allow you to do? Start with content in software, and those things are generally decoupled.”
Dan:
So normally when we start with content on, let’s say we’re making a website, a lot of times that’s in a wireframe or a copy deck or some form of documentation, some form of written, something that is abstracted or separate from the final form that it’s going to take. And a lot of teams that work with design systems generally subscribe to some sort of agile methodology or practice or something like that. And if you look at the tenets of agile, they tend to say, my favorite one of the bunch as it relates to design systems is, “Working software over comprehensive documentation.” So, that’s not to say that comprehensive documentation is not important. It is, we need to have it, but when we can choose working software over comprehensive documentation, let’s choose that thing.
Dan:
And so what does that look like with design? I think design systems bring content to its full fruition in digital work in that when we have the content to start with, whether that’s a content that solves a user need or something that actually has some value to the end user that all of the components in content serve, what can we do with that? Well, we can literally start writing our content in code and then populate and display that content through some sort of UI mechanism or component or something like that that we have in there.
Dan:
So when I talk about process, when I teach process, I go, “What’s the first thing we should do? We should open up an HTML editor and we should just write the content, not even in HTML, in plain text. And then we should save it and open it in a browser and we should look at it like that.” And then as we go along with the process, we can start applying art direction, components, logic, flow, functional, all of that to the content in a software environment. And without a design system, it’s very hard to do that because we always have to stop to go, “Okay, well, we have this content, we have these headlines,” or “We have some content models,” or “We have something like that. And now, okay, give me two days and then I’m going to go design something in Figma that represents that well,” or “I’m going to build a prototype that does that.”
Dan:
And so we have this start and stop thing when we try to start with content. With design systems, we don’t have to do the start and stop thing. With design system. We can go, “Okay, I have this headline,” or “We have this…” And that could be for static or static content, but it could be something like, we have this calculator functionality and there’s content that’s coming, so how can we display that to a user? Can we use some cards to display that or should we put this in a table or should we put this in some sort of interactive presentation or slides or a carousel or this or that? We can cycle through those in seconds if we have a great design system.
Dan:
And to me, that brings content to its full fruition. It’s like, “I have this content, how do we display it to the user? Well, let’s try five things over the next five minutes.” That was not possible, at least in a digital context before the advent of design systems. And yet people don’t do that when they do design systems because they just think about the components and it’s like, no, no, no. If we can flow the content through the components, that’s really where we get the power of design systems.
Larry:
As you say that, I can picture that because the temptation for anybody to just jump into Figma because that’s where the components are and start doing stuff. It’s like, no. And I got to say, I love everything you just said about that, but also you’re reminding me, I had… A couple of years ago, I had on the show Dan Strahl, who runs a company called Knapsack. I don’t know if you know them. They’re one of the design systems software.
Dan:
Sure do.
Larry:
Yeah, and Chris is an old Drupal guy. He comes out of the CMS world and he sees this, and I haven’t talked to him since then. And he saw this convergence looming of design systems and content management systems. Do you see… The way you’re talking, I’m thinking you might be on board with that.
Dan:
Oh, one hundred percent. Chris and I are good friends, and I talk to the Knapsack team a lot. I’m very aligned on those things. And I imagine with the audience listening to this as well, now is such a great time for design systems. It’s almost like we couldn’t have had design systems 10 years ago because we just didn’t have the things that we needed in order to bring them to the full fruition. Content management systems going headless, that’s a really important concept when it comes to design systems. The idea of microservices and micro front ends. Without that idea, we don’t have the full fruition of content. And so I think now is the right time for design systems to be in the zeitgeist because we have all these things that have converged there and that really all of those things converge around content.
Dan:
So one of the exercises that I do with teams a lot is I go, “Let’s map out the ecosystem of not just the design system when we’re doing design system work, but we have to map out the ecosystem of everything else. What APIs do we have? How does this work with our CMS, our content management system or our CRM even, our Customer Relationship Manager or our DAM, our Digital Asset Manager.” All of those things play a role in how and where design systems fit.
Dan:
A design system on its own is an empty tool in the same way that a CMS on its own without templates or without front end rendering, without a design system, it’s not great. You have to build all that stuff from scratch. So it’s really when all these things come together and converge, that’s where we get some real power out of this stuff.
Dan:
So I think it’s a really good time for design systems because they really help content and prop up content in ways that are complimentary to CRMs and digital asset managers and content manager systems and things like that.
Larry:
Yeah, and as you’re talking, I help organize a conference called Decoupled Days, which is all about this new need for orchestration of all of this stuff. I think about it mostly as, actually, let me run this by you too, because the thing that’s come up in a couple of things I’ve worked on is like I’m coming up with this concept of content orchestration. But sometimes it looks like experience orchestration, depending on when and how the content teams and the design teams are working together.
Larry:
Have you come across this kind of spectrum of you’re obviously got content in everything from the get-go, but I know in some places there’s the flow, the rivers converge at different places. And I think of that, and the way I put just kind of bookmark it in my head is like content orchestration or experience orchestration. Does that make sense?
Dan:
I love it. Yes. That’s part of the way I teach it is when some people… This is the irony is that a lot of this stuff works really well when you do agile, and everybody says that they’re agile, but most teams are not. Most teams, what they mean by agile is we follow a pretty much waterfall process when it comes to content and information architecture and design. And then once we get to engineering, then we’re agile. Sorry, once we get to engineering, then we break our things up into two week sprints. That’s what they mean by agile.
Dan:
To really truly be agile means the rivers can converge at any point and it would be fine, you just flow it in. You let them flow into, you know, you let the little tributaries flow into the larger streams, and that’s what, eventually they all lead to the ocean. But where they end up or where they flow in is not really consequential. You just accept it. You go, “Cool, that’s where it comes in. That’s where we’ll use it.”
Dan:
So there are some times where at the beginning of a project you have content and there’s sometimes where the end of a project you have content. That’s just the reality of how some work goes. There’s sometimes where you have an insight at the very beginning of work and there’s sometimes that eight weeks in from doing usability testing, you get a new insight. So what do you do with that? Start a new project or start over again? No, you don’t start over again. You flow it in. You go, “Hey, we learned this new thing about the user,” or “We learned this new thing about our interface,” or “We learn this new thing about…” What’s the word I’m… “performance by testing this and by putting it on a different ecosystem or a different platform.” And then you adapt to those things.
Dan:
That’s really what’s in the spirit of agile is you kind of flow them in, right, the customer collaboration in all of those kinds of things. So I’m very aligned with that idea of content orchestration, experience orchestration, is that when you have a piece of data, content, design, engineering, whatever it is that you have, when you have it, you should have a process that supports you going, “Well, this is the point where we’re integrated. We have a river, it’s flowing to the ocean. We have streams that flow into that? That’s great. We’ll accept them.”
Larry:
Yep. Hey, as you talk about that, I’m reminded we were talking before we went on the air, we’re like, “Well, I guess we’ve got to talk about AI. It’s 2023.” But it is a totally legit thing, and I think this is a great place to talk about it because of all these new little tributaries flowing into this thing. That’s a big one. Tell me, how is AI manifesting in the design system world?
Dan:
So a couple of different ways, and in my mind, I can put them together, but I think I see them appear very separate. There’s one stream that’s like at some point, this is what we’ve been working for, right, in design systems, is we’ve been wanting to automate the smaller pieces, the boring pieces, the more reused pieces, the most common pieces. We’ve been wanting to automate that stuff and put them so that we can pull them off the shelf so we don’t have to do it from scratch every time. So I’m like, “AI accelerates that very much.” And so that’s one thing is like, “Yeah, this is exactly what we’ve been wanting design systems to be.” All of a sudden it just got dropped on us in the last year, so we might be a little bit unprepared for that. I think we were kind of moving toward there slowly and then all of a sudden it accelerated. So we’re a little bit surprised. So that’s one train of thought.
Dan:
Another train of thought is that, “Oh, no, no, this is going to put me out of a job, so I reject it.” And there’s some truth to that as well. There’s like, it’s now all of a sudden so easy to generate an illustration or a piece of text or a paragraph or an idea or a component or code that it’s like, well, this is something that people worked really hard on spending weeks and weeks on a component, and then overnight I can get that in seconds through a bot, through a robot. And so that’s a really scary proposition too.
Dan:
And so those things seem like they’re at opposite ends of the spectrum from each other. I think there’s a version where they work together, but I think we’re finding it together, together as an industry, we’re finding how those two things work together, is we do want to automate some stuff, but we don’t want to automate ourselves away.
Dan:
And I think a lot of the designers and the engineers and the content folks that I interact with are like, “I’m cool with AI to a point.” And I think that in its idealest form, which I realize that it’s not, in its idealest form, we get to train AI to be what we want it to be. In its scariest form, it turns into whatever it wants to be, and it puts us out of work against our wishes and things like that.
Dan:
So, I think there are a lot of opportunities there. I think it’s very much an emerging space that’s changing very frequently, I think for a lot of people that’s very scary. And for other people, that’s very liberating. And we’ll probably net out, hopefully we’ll net out somewhere in the middle of that.
Larry:
Yeah, I hope so too. I’ve had conversations on both sides of that spectrum in the last 24 hours.
Larry:
Hey, Dan, I can’t believe that we’re coming up close to time already. But before we wrap up, is there anything last, anything that’s come up in the conversation that you want to revisit or there’s just you want to make sure we share before we wrap up?
Dan:
I think one of the things that, and thank you for asking that. I think one of the things that I want to give people hope about is that design systems don’t have to be the thing that you think that they are. They don’t have to be as difficult as you think they are. They don’t have to be, you know, they can be all the good things that you want them to be, but that be flexible and open-minded about how you get there.
Dan:
Having a design system in an organization is a vision. And when you march toward a vision, I think about vision as a destination. And so when you take a journey toward a destination, you might have to take detours. And I think a lot of people consider that with in design system work as a failure. No, no, no. We have a noble goal and we must take this journey to get there and this path. And if we don’t take that path, we’re doing it in a compromised way and we refuse to do it. And I’m like, yeah, okay. But sometimes it is actually better if the highway is blocked and you got to take a detour through the scenic route. It wasn’t your plan, but you get a beautiful drive and it might be a little bit longer, but there’s other benefits along the way too.
Dan:
And I think I see teams that are very tightly held to that vision because of how beneficial it is. They see what the world could be with a design system and they have an idea of how to get there. And then when they don’t get there that way, they sort of write it all off. And I wish that more teams didn’t write it all off and kind of said, “Okay, we got to be a little bit scrappier about how we do this. Let’s take the detour. Let’s take the scenic route. Let’s stop for a pit stop here. I know we were going to stop for food in an hour. We don’t know if in an hour there’s going to be a rest stop or a rest area, so let’s get out here. We’ll get hot dogs. We don’t think… I don’t want to eat hot dogs, but that’s what they’ve got at this gas station.”
Dan:
And I think that there’s some serendipity and there’s some beauty to be had there as well. And so I like encouraging teams and people who are working on design systems that the path is almost always going to be unexpected. And so expect that a bit. And I think that you’ll get to your design system destination a bit sooner or a bit happier along the way.
Larry:
I love that. Expect the unexpected. Just stay on your toes and yeah. One very last thing, Dan, if folks want to follow you or connect online, what’s the best way to follow you?
Dan:
Yeah, please don’t email me because I’ll never reply to you. So any of the social media places, LinkedIn, please connect with me on LinkedIn or Twitter. I’m always open to DMs on any of those platforms. Instagram, same thing too. And so those are really easy ways for me to interact with people as they have questions or things like that.
Dan:
If you have a quick question about design systems, shoot it to me. I’ll shoot you back an answer. If you have a very tough question about design systems, it might take me a couple of days or weeks to get back to you, but those are generally easier platforms for me to connect with people.
Larry:
Great. I’ll put that in the show notes as well. Well, thank you so much, Dan. Really enjoyed the conversation.
Dan:
Yeah, thank you, Larry. Thank you for having me on the show.
Leave a Reply