On Theme: Design Systems in Depth

Efficiency, respect, and the origins of design systems with Brad Frost — #01

• Elyse Holladay • Season 1 • Episode 1

Share episode

📲 Text the show your thoughts!

Brad Frost takes us back in time to the early days of design systems, and walks us through some of the significant moments of evolution from style guides to modern design systems. We dig in to the multiple proto-Storybook-esque projects, the original problem of sharing UI patterns, what React did, and Brad's personal moment of "oh, it's called design systems now." Plus, a bonus podcast throwback from the Style Guides Podcast feat. Dave Rupert and some early proto-Storybook madness.

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

Links & References

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

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

Brad Frost:

It really comes down to respect. And when we talk about respect and we talk about the finitude of life, and that we have a finite amount of life energy, and time on this earth, do we really want to be doing X, right? What are the worthwhile tasks, that make our jobs fulfilling, that are worth doing, that are not bullshit, that are not just like, yeah, I need to copy and paste this thing across 80 pages,

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. We can't look forward without knowing where we've been, though, so we're kicking off season one with a journey back in time to how design systems as we know them today came into being. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intedesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show.

Elyse:

Today's guest is Brad Frost, who you probably know from Atomic Design infamy, and who is probably tired of being introduced with Atomic Design as the lede. Brad is a design system consultant, front end developer, speaker, writer, musician, and artist from Pittsburgh, Pennsylvania. He's half of agency Big Medium, where he focuses on design at scale, everything from design systems to AI to product and organizational design. They've worked with well known names like United, Target, Marriott, UPS, and PetSmart. Brad is a prolific blogger and speaker and on the side, a musician who knows how to have a ton of fun. The reason that I'm really excited to have Brad on the show is not because of his work on some of those really well known design systems, but because Brad is one of a handful of people I consider true OGs in the design system niche. Brad was there when the industry started talking about style guides for the first time. He was co-hosting a style guides podcast, and was involved in creating several tools and resources like Pattern Lab and Style Guides IO, like pre storybook stuff. He's just seen a ton of changes in this space. So today I want to go, back to the beginning, Brad, welcome.

Brad Frost:

Hey, thank you so much for having me. I'm excited to be here and chat with you.

Elyse:

I'm excited too, we're going to take a tour of, memory lane, a little like nostalgia fest today. It'll be really fun.

Brad Frost:

I love it. I'm here for it.

Elyse:

So one of the reasons I wanted to do this podcast is that I believe design systems are due for a reinvention moment. We've both seen design systems go from a twinkle of an idea to an established niche, that like new grads are actively trying to break into, right? And you have people who are relatively new in their career being like, I want to work on design systems.

Brad Frost:

Yeah.

Elyse:

Which I just think it's so interesting like it was just not a thing when we were starting our career, I'm gonna sound really like old and curmudgeonly today, but that's okay. If you started working on design systems within the last five years, like not even if you're new in your career, but if you've moved into the design system space, you really get the idea that a design system is all about, foundations and tokens and collections of like Figma plugins, tools, and libraries, and arguing on the Internet about the broken promises of design systems. And I just feel like there's a lot of history and context to how design systems got to what they are today, that I think is really important, and like, frankly, just interesting, because I'm seeing us come back into a full circle moment. So let's go back to the beginning, like 2012, 2013, tell me a little bit about what we're doing, like how are we building websites and web apps in this era?

Brad Frost:

Yeah, so, we'll maybe go back a little further to 2010 ish. We have web 2. 0, the app store came out Android, native stuff 2010, the iPad gets released, and that's like kind of where we could pick off because, so at the time, I'm working at an agency called RGA. I got hired as a mobile web developer, and I'm like, what's that in like late 2009. So the iPhone came out 2007, right? App stores to follow, but like at that time, the web industry was not focused on these new devices. It was still very much like the desktop only world. And then here comes this new smartphone that, can actually render the web, like not a poor man's version of the web. And that's what I got into, was like a lot of like making BlackBerry optimized websites. It was wild. But then like, you know, I got a chance to work on, like, ipad. nike. com. At the time, it was like, Apple's coming out with a thing, you don't know what that thing is, but here are some, like, technical specifications that you need to build to.

Elyse:

I forgot that it used to just be like, m. website. com, mobile or app that was like, iPad dot whatever, man. We were building these websites, like the desktop version of the website, in literally like in Photoshop, like this is like pre Sketch, definitely pre Figma, we were building literal pictures in Photoshop, and doing these like, sliced up pixel perfect, position absolute, you know, responsive design was not a thing. Like Ethan had to write a book about it because nobody knew what it was. And now it's just how we make the web.

Brad Frost:

Yeah. So it's like we're, working on ipad. nike. com building these experiences, we're doing the desktop version of it, and then here's this brand new iPad thing, we don't even know that it's called an iPad yet. And Nike actually had two, mobile websites. They had an an iPhone dot nike. com, and then they had an m dot nike. com for everybody else that wasn't on the newfangled iPhone. So you're talking about four web environments for the

Elyse:

separate, entirely separate.

Brad Frost:

right. And so, and that, and that's kind of what I'm wrestling with, in my day job as a front end developer. How are we going to, do this in a way that just isn't, like, totally ridiculous? And I gave like, an internal presentation at our company called Adaptive Web Design, cause we, like, figured out, here's, the way you can make this stuff scale and squish and whatever. And then I think it was like, the next month, or, uh, it was like very very close, that Ethan's A List Apart article came out, and we were like ah yeah it's, it's that. So it was through that process of being like, how do we create a saner way of supporting these different devices and these new device classes, how do we do that effectively? And that's where, for me, as I went through this process, it was like well, it's not that the home page is hard to build, or the product detail page is hard to build, it's the freaking header! It's the navigation, it's this complex data table, it's the individual components that are challenging to make responsive and fluid and and you know, adapt themselves. right so it's like, oh okay. Most of this stuff can just squish, right? Like with text, squish the browser window, and it's just going to reflow, which is, which is magic when you think of the tech that actually underpins that but we just get that stuff for free. But then these other components like require a little bit more thought and consideration, right. So create a project called This Is Responsive, which was a pattern library of sorts, where I was capturing and rounding up all of the vanilla versions of these responsive patterns. So it's

Elyse:

like.

Brad Frost:

here's

Elyse:

how are we doing responsive navigation? How are we doing responsive cards?

Brad Frost:

Here's different ways to slice responsive navigation. Here's how you could handle data tables. Here's how you could handle a gallery.

Elyse:

It's such a straight line from there to components because, you mentioned like the home page, the product details page, and we don't even think about websites or web apps in this way anymore, but we used to build individual pages. You built the header on that page, and then you built the header again on a different page. And then you built the header again on the other page. It's almost incomprehensible now that that is the way that we used to do things, but if you have something like a product details card, and it lives on 5 different pages, you have 5 different implementations. There was no sense of reusability, and I'm talking very specifically about the front end, like the HTML, CSS, this was pre React. Reusability and composability, like this has been a thing in engineering for a long time, but on the front end of the web at this time, was not a thing that you even could do. I remember when we had like Mustache and Handlebars as a templating language. Like, do we even know what Handlebars is these days? Like, this was so Millennial. Mustache?

Brad Frost:

I love Handlebars and I mean, that's what Pattern Lab ended up being built in. But ultimately, yeah, if you have an index dot HTML, you have about dot HTML, and you want make a header and share that across both of those pages, it like, up until then you're like, oh, this is easy. This is very approachable. It was plain language, declarative syntax, HTML, CSS, and then it's like, cool, well, I don't want to have to copy and paste my header, can I just make that thing once, and then it's like, ooh, Nope! And even all these years later, when you look at this giant iceberg of just ridiculously complex software configuration and, and all of these different tech stacks that exist today and these ecosystems that exist today, that's almost like the original sin, or the original like problem that's been around for as long as the web's been around. Where it's just like, share my header and my footer across my websites.

Elyse:

It's like a whole can of worms because it's like, oh, I want to share it, but I want it to be slightly different, or I want to share, but on this page, I want it to work in this other way.

Brad Frost:

That was just a really difficult problem. And the technology has emerged and evolved and we have, created solutions for that. But again, is it perfect? Is it easy? Is it just like as easy as making index dot html and about dot html?

Elyse:

It's insanely abstracted. It's super abstracted now. Okay, so back in our timeline, we were really going, wowww, we need to think about how these components can flex. We need to think about them as components, like we weren't even using that word at the time, but we were going, Hey, like, how do we share the nav? How do we share the card? How do we share these patterns across different things? Instead of like making a Photoshop picture, sending it to an engineer, and I mean, that's like the simple case, right? Like the more realistic case is, we have a hundred pages on our website and we need to update the product card on 80 of them. And it needs to be the same. It needs to look the same. This was a massive problem, because even one engineer, it would take you weeks sometimes to go and do that and copy it around and make sure everything was right, and then test and QA. There was no concept of it being in a single place, and so, we're starting to think about, hmm, these components, these patterns need to like, function by themselves, maybe, they need to be shareable in some way. What happens next?

Brad Frost:

So at that time you have people sweating those problems. People like Nicole Sullivan creating OOCSS. You have people like Natalie Downe over in the UK talking about pattern portfolios. You have people like Jonathan Snook, talking about SMACSS and introducing these CSS methodologies, and BEM of course is born around that time as well. That is just like, here is this way of structuring CSS so it's just not a freaking mess. And here's how we could think about stuff in a more structured and modular way. That was a big piece of the puzzle, and then around that same time, tools like Bootstrap came out By and large, it's here's a a CSS file that you plunk in there. You match the classes and then get that product card to look the same across the board. And that was just like really, really welcome, that was really needed. But again there wasn't this of a directly consumable component. It was still decoupled.

Elyse:

We were really starting to like separate our concerns at this point, by which we meant, HTML, CSS, JavaScript, in their separate files. We were trying to keep them separate, but also, conceptualize things that went together, with these complicated CSS naming conventions and chunks of HTML we were starting to kind of, like, define them in these little ways or, like, copy this or reuse this. Is this the kind of beginning of the style guides era, do you think?

Brad Frost:

Yeah, I really do, I think it was people like Natalie Downe, she was at Clearleft at the time. It's like, here's this idea of a pattern portfolio. You could just have effectively like an index page, of these different patterns and see the different components. It's ultimately the first thing that's giving a hint of the Storybooks to come, which are like a lot more sophisticated, this is just literally like loop through this stuff and splat it all out on the page, so we can see what's going on.

Elyse:

You ran styleguides dot io and did a style guides podcast with Anna Debenham for a while. How did that come about?

Brad Frost:

Yeah, so, there was Anna's site, she started it. In 2013, I left RGA and, and went freelance and, and work with my, still to this day, my partner, Josh Clark, and it was through the lens of these first couple of freelance projects, one was a redesign of TechCrunch, and the other one was a redesign of Entertainment Weekly. I was like, I have this idea that can help us deliver this responsive website to our client a little bit better. Here's this kind of idea of atomic design. I'm not a tremendously great back end developer or anything like that, but I'm like, okay with PHP, I could do that include header dot php, and so you could create, you know, your product card dot php or whatever dot php, and then passing in some parameters, but then being able to loop over that, display that stuff in a chrome that was on a separate layer outside of an iframe

Elyse:

We're really like proto storybook here.

Brad Frost:

Yeah, it really was. Cause again, the stuff to date was like, you could loop through, you could see this stuff, but it's not tremendously actionable, or navigable. So yeah, that was a really big deal. I roped my friend Dave Olson into it, and then he kind of like legitimized it, turned it into something powered by Mustache and Twig instead of just raw PHP. But anyway, I went all in on this and created the tooling to implement those ideas. And then kind of around that same time, I'm big on rounding up resources and sites and stuff like that. And Anna had already started this website, this style guides website, and she's an amazing person, I love her so much, and she was like, hey, want to plug in here together.

Elyse:

I remember those days, I remember there was a lot of, um, it was just really in the air, right? Like when you would go to events, when you go to conferences, these were the kinds of things that everybody was talking about, because we were all really, like you said earlier, these are the problems we were trying to solve in our day to day jobs, right? Like if we're designers, making these beautiful things, and then we're like, struggling with engineers to update them on 80 pages. We're, you know, front end developers and like, we're the ones that have to go update it on 80 pages. And we're like, this sucks, we can do something better here. I think this is the origin of the idea of efficiency, right? Now in this year of our Lord 2024, we say efficiency, and mean, do more with less, like AI, capitalism, like efficiency has this bad taste, that typically means, we still want you to deliver a great product, but we're not going to give you the resources to do it.

Brad Frost:

Yeah.

Elyse:

I mean, like at the time, in 2013, like that was when we were talking about efficiency, we were like, I literally don't want to have to update this 80 times.

Brad Frost:

100%. It's a matter of pragmatism, and a word that I use all the time when we work with clients It really comes down to respect. And when we talk about respect and we talk about the finitude of life, and that we have a finite amount of life energy, and time on this earth, do we really want to be doing X, right? What are the worthwhile tasks? That make our jobs fulfilling, that are worth doing, that are not bullshit, that are not just like, yeah, I need to copy and paste this thing across 80 pages, or I need to rewrite the header for each and every web page. I think you hit the nail on the head, that shift from efficiency as a matter of just like good pragmatic sense, it's been weaponized. It's become a real kind of gross thing that we're all subject to, unfortunately.

Elyse:

Yeah. It's because the problem isn't there anymore. I mean, well, maybe I'm being a dramatic. There's almost no world in which you have to update it 80 times. Maybe in some legacy code base or somewhere really like crappy, but in general, the concept, of the original seed of that problem, is just has been abstracted away from us.

Brad Frost:

Yeah. It's tough to say that it's a truly solved problem, but it's like

Elyse:

No

Brad Frost:

it's like, that has been the last, you know, so it's like, I came out with atomic design 2013 and it was like two weeks later that React launched.

Elyse:

I remember that React talk. You remember the slide, the anti CSS slide and like, this was the beginning of a real anti CSS era, but I digress.

Brad Frost:

Yeah, no, that's true. But those tools came out then. Things like ES Modules that actually allowed us to deliver these things as consumable components. That was like 2016 or something like that. There's these CSS people who are kind of putting this stuff together, there's like JavaScript is still kind of gross and like lacking some core things, but, but great tools like jQuery and jQuery UI came, like, there was a lot of the the whiffs of what was to come in that era. And then, yeah, the tooling caught up and things got created that allowed for the waters we swim in now to, to be possible, where you're able to be like, cool,import button from our design system, and it, just kind of shows up.

Elyse:

I'm dying to revisit this with you. I've been looking forward to this story since I had the idea for this podcast, because when I was doing research for my ClarityConf talk, I dug up this old episode of the Style Guides podcast with you and Anna, with Dave Rupert. And I was working at RetailMeNot at the time, and we had Dave and the Paravel guys consulting with RetailMeNot. So what we did at RetailMeNot, we created a proto design system we called Roux, and we were using this to ship a sitewide redesign. We created a set of what we called ingredients that was Handlebars and Mustache templates, so literally this looks like HTML with like little squiggly brackets where you like insert variables. And then we hand rolled an Express app to deliver these sets, which are called pantries of these templated components, and, we had to build, I mean, we wrote thousands of lines of code. And so in this podcast episode, this is you and Dave talking about this project.

Dave Rupert:

Can I tell you a tale?

Brad Frost:

Okay, yeah, please do. Do you have a sound effect that sort of, you know, leads into a good tale?

Dave Rupert:

Yeah, here we go. You're

Anna Debenham:

like, like a spook.

Dave Rupert:

So, So we, we built the pattern lab out and that was great. And, but it was very clear, like, it would be hard to integrate this into the existing production system. Uh, just because things were different, this uses mustache that's not on the server, blah, blah, blah. So we were like, Okay. So this is kind of where the quest for the Holy grail begins, you know, the, and I call the Holy grail, the like thing where your production and your pattern lab and your dev, everything's in sync and beautiful and not everything works and everything's perfect and nothing breaks. Everything's always up to date. But, um, so we made a move to put this into the production environment that went good. Um, until like people started committing code to it and that sounds terrible, but, um, it, it, it was kind of like immature and then all this stuff started flooding into it, uh, which kind of, polluted the whole pattern lab because, because like, if your pattern lab is inconsistent, you have not made a pattern lab. Does that make sense? Like if inconsistency,

Anna Debenham:

If it's different to what's on the site.

Dave Rupert:

Yeah. So it was kind of a lot of effort to maintain. So, uh, Mike Cravey at RetailMeNot has, uh, and he's hired Elyse Holladay, who's super good at Sass, um, has hired Elyse and they've kind of broken this out into a separate project called they're calling, can I, can I, can I leak the title name? I don't know. I'm going to not leak it, but they're working on a project, uh, to, to abstract this stuff but then it'll be as simple as like an NPM module include to, to get it back into the system.

Brad Frost:

Um, so, okay, so you sort of went, you went from having your pattern library sort of exist outside the production environment, and that was like, uh, oh okay, this is sort of a duplication of efforts because we need to get it into production, and then you put it into production, It got polluted just because a bunch of people are touching it, a bunch of people are contributing and things got really inconsistent slash hard to manage, I guess. Is that? Yeah,

Dave Rupert:

well, and it wasn't ready for prime time at that point, but then things started coming in. And so, so we were like, Hey, now let's come up with the dream scenario. Yeah.

Brad Frost:

Right, so what is that dream scenario? How does it work with the team and stuff like that? Do you have any thoughts on?

Dave Rupert:

I, I really don't know. Um, I, I think what Elyse and Mike and the team are working on is, is really smart, um, because if your style guide, if your bootstrap or whatever is inside an NPM module. Um, and then maybe you can run it like a Jekyll or something, you know, but you, you can run that style guide and visualize it in a, like a standalone kind of app. I think that that's going to make a big difference. I, cause then you're pulling in, you're pulling in a pristine architecture um, I think that's a good thing

Brad Frost:

So, so, so what you're saying is you're basically creating this language, creating your, your sort of front end architecture as sort of a standalone thing and then sort Implementing it and making use of it and sort of sucking it in a smart way.

Dave Rupert:

Yeah. Making it consumable. And that's the big thing, you know, it takes work on, on the production environment and it takes work on your, your standalone environment, uh, to make them kind of, uh, be the same, I don't know, just have the same, but if it's just Sass files, it should work. Um, when it gets into templates, that's different because what if somebody wrote something in Python and one type of something's in PHP, what if something's in Ruby, those all kind of use different templating languages. Uh, if that's the case, maybe you need something like handlebars. So now you have to use handlebars or mustache and then make sure that those systems are using that system and then make sure all your data models are like the same. So that's. Difficult to

Elyse:

This whole thing is hilarious to me now because this whole podcast, y'all are going like, oh, my God, you guys, do you, can you believe this? Yeah.

Brad Frost:

That's what we were doing with Pattern Lab. So we were contracted to deliver the front end templates for Techcrunch.com. There was another partner, the WordPress developers who were doing the backend work. So our handoff, our deliverable, to that agency was these production ready front end templates. And in order to do that, we need this more nimble environment, that allows us to work on the UI code in isolation. And it worked damn good. Like, it worked. We were able to deliver the stuff. The stuff was, dry, right? We were not repeating ourselves from template to template. It was consistent across the board. But, but, but, here is the thing, like, we're handing this stuff off, and we're like, and here's this like whole tool and they're like, that's nice, and then trash can. It was just not what they needed. So there's, there's this disconnect So, that's what, the next, three to five years, and that conversation with Dave Rupert is what we're kind of getting at. It's like, yeah, there's the spirit of this stuff is here now, people are like getting those ideas, but there needs to be a delivery vehicle to connect this stuff.

Elyse:

I love that you call it a delivery vehicle. I think that that really encapsulates what we were trying to do at the time. We were trying to say, how do we take these things and have them isolated from our actual applications so that we can think about them and build them and design them by themselves. It hadn't quite settled into the industry at large yet. And what was happening at that time was, you were building Pattern Lab, all across the industry, everybody was hand rolling this, everybody was making their own little proto storybooks because these ideas were starting to circulate. I think, especially on the design side, we were starting to go, hmm, you know, style guides were also a design led thing in a lot of ways. It was like, we're going to make what we'll call it a sticker sheet, right?

Brad Frost:

Photoshop UI kits were totally a thing.

Elyse:

We weren't really able to do much with that on the engineering side. The key, is that at this time, those patterns or components, like we might start building them in this standalone place with this like proto Storybook, but then they would just get put into the app.

Brad Frost:

You include a CSS file, copy and paste the HTML snippets and hack it apart. But that's obviously not DRY, you got a bunch of loose markup kind of floating around.

Elyse:

Yeah, it took a couple years after that, for, we'll say React. There were other things like Angular, Ember, there were other languages, other frameworks that were thinking about this componentization pattern, but it took a couple of years to move into the industry at large. And I would say that was probably two thousand sixteen when companies started to be like, oh, we're going to rebuild this thing in React. At Indeed we were trying to build a design system to get our engineers to stop writing the front end in Java and start using React. So companies were starting to, put React into their ecosystem. And for obvious reasons, the idea of components took off at the same time, because we had these concepts that you have suddenly the ability to actually implement that.

Brad Frost:

I'll add one more thing to the equation: ES modules, the actual technology, that is like baked into JavaScript. That's around 2016, the actual technology to be able to deliver modules like this. So this idea of the roads got built to deliver the things. So with, JavaScript and ES modules we are able to import this thing that's coming from somewhere else into my JavaScript file. And then do something with it, right? So you're able to actually stitch all this stuff together in meaningful ways. What React did was like, yeah, everything here is a component. And that concept, coupled with atomic design, those things were fellow travelers, and then the technology kind of became available to actually start doing it, to actually start connecting these dots, right? That, uh, in the talks I give, on this history, it's like before, it's just like a bunch of dotted lines, that are between

Elyse:

Conceptual relationships,

Brad Frost:

yeah. And then it's like with, React and ES modules you're actually getting these solid lines of like, oh, this is like an actual dependency, this is an actual relationship versus like a theoretical one. Yep,

Elyse:

Yes. Yeah,

Brad Frost:

Yeah.

Elyse:

You have this great quote on another old podcast where you say, everyone is stumbling their way into this sort of thing. The idea of modularity and patterns has been around for a while, but it's only in the past couple of years that it has become essential for organizations to really adopt this mentality. And I think that really sums up the spirit of this era. But it became so obvious in those years that this is a good way to build UI. I remember at the beginning of React, it was like, Oh, we're not gonna, we don't, we like the way we're doing it now. Like, I mean, I was a CSS person, that was my job, writing CSS. I don't want to do this. My job is going away. My ability to do CSS architecture is really critical. React was very anti CSS at the beginning. A huge part of their manifesto at the beginning was like, the cascade and CSS is terrible and we want to avoid it. And I think we're coming full circle on that too, but that's a different podcast episode.

Brad Frost:

Yeah, no, let me just say for the record, again, I think that their stroke of genius was this mental model of, everything's a component, and that set the stage for a lot of really great things to happen. They also did a lot of damage that we are still recovering from today. So it's like that kind of anti CSS attitude is a big thing. That whole just ship an empty body tag, progressive enhancement is dead, sent us all on a wild goose chase for a decade and then kind of came back around, and reinvented progressive enhancement and server side rendering and, you know, gave it a different name, and suddenly it's the cool thing to do. Uh, anyways, I'm not bitter or anything like that, but it's fascinating. We take the good with the bad, but obviously it's, it's had a real impact on how this stuff continues to get made today.

Elyse:

Thinking about all of this change, everything that's happened, when do you think, or what do you think was kind of the critical moment that patterns or components, these kind of like concepts turned into what we think of as modern design systems, like, looking back now, what do you think was like, the moment?

Brad Frost:

Well, I could tell you my context, so I created Atomic Design in 2013, ran it, put it through its paces through our client work. Gave a presentation about it in Germany at Beyond Tellerrand in late 2013. Wrote a blog post about it. In 2015, I wrote a book on the topic, and it was at the very tail end of, I'm like, great, I am almost done writing this book I Remember sitting in a coffee shop, I used to go there every morning at opening time, that was like the only time I was able to like actually get writing done. And I remember doing a pass of the book, and I went through, and I updated the word"pattern library" and"style guide" to this word,"design system".

Elyse:

Oh, wow. That's the moment.

Brad Frost:

So like somewhere in the year 2015, this term design system kind of popped up. And that'd be really fascinating to dig into like where, where did that actually originate or how did it become the thing? How did it supersede pattern library? Or, style guide, which were these terms that we were using. But at some point in the year 2015, design system was kind of born, and I'm like, oh shit, I got to update my book, to, to like reflect this word that seems to be talking about the stuff that I'm talking about in my book. And like if it were maybe a couple months later, like the book would have already gone to print. So, yeah, 20, 20 15, 2016, 2017. Somewhere in there.

Elyse:

Anything else in this history that stuck out to you then or is, like, you have a real memory of now that we didn't cover?

Brad Frost:

Yeah, I think that that recognizing the fact that around that time, coming back to what you were saying earlier about efficiency, starting to be more like org wide or enterprise wide there is this real kind of beginnings of maturity. Like this infrastructure is in place now, and so an organization can create not just one website or two websites, but like lots of websites. So you all of a sudden have this just like exponential growth of how many pieces of software live under one roof, and all of those things need a user interface. So, so there's like, there's the technology side of things and the tooling side, and the assets side, they feed and inform and influence one another, right? Like the people, then the need influences what technology gets built. The technology influences what people do with that technology. It's around that same era, you see language, like digital transformation, even non digital companies, it's now everybody, all have software, and a lot of it, and it is now like a critical part of just like how things work, gone are the days where it's like, oh yeah, we have a website and here's our like quaint little brochure and it's now like, okay, yeah. HR department has their stuff, the payroll department has their stuff, like all of like the internal stuff. Then there's the marketing stuff. Then there's software as a service. Then there's like of these things. Holy smokes. And again, you see this massive explosion in the amount of stuff, which means you need to manage that stuff in a reasonable way.

Elyse:

That's how we have design systems.

Brad Frost:

Yeah. And that's how we have design systems, but also like, design ops and dev ops and all of this infrastructure, these shared systems, these layers that transcend any one business unit or anything like that. you know, I like to talk about how a design system, as I define it, is like the official story, of how an organization designs and builds digital interfaces. And that story involves the orchestration of assets, like we've been talking about, like a component library in code its corollary in the design world, documentation, things like that, but also the people and the process. That allows this whole machinery to run. I'm fascinated by it all in that, like we are able to define what that is, as a concept and as a technology. That's really cool. But at the same time, it's also like, well, what does that do for how human beings work? And I'm sure you've been around it for long enough to hear the designers who are threatened by the design system, the developers who are threatened by the design system, because they're like, well, wait a minute, that's my job, right? Like, I, I draw the rectangles. I write this code. But again, coming back to that idea of respect, is having to draw that rectangle or rewrite that button— Is this the pinnacle of the work you can be doing in your, in your life and your career? Yep. I see this the most in the conversation, the design system is ruining innovation. You know, the way that we work today with design systems, like, it's not perfect, it's not a fully solved problem, but it's so interesting to have gone back through all of this discussion with you and think about the problems that we were trying to solve 15, 10, 5 years ago and reflect on those as a way of thinking about the problems that we have to solve today. Because we have really different problems today, but, you know, knowing your history means you don't repeat your old mistakes. And so I really, really interested. I think design systems is at a moment where we need to really reconsider, what is it that we are doing? Are we stifling innovation? What is the scope of a design system? And what is the value of this thing that we're building? And I think we are, we need to come back to some of these original goals we had for style guides and pattern libraries like, there's just the space is so different now that I think we're really due for, a reinvention moment thinking about what is the value of a design system So thank you so much for going down that little memory lane trip, that was really fun, and I hope that, for anybody who's listening to this, who's only been in design systems for a handful of years, that this was enlightening in some way to kind of think about like, how did this stuff come up? How did we even get here? So Brad, thank you so much. Thank you so much for having me, this really was just kind of wild that we've been on this journey for a while, huh?

Elyse:

We really, really have. So, I have one last question for everybody who comes on the show, it can be given the conversation we just had, historical or current, but give us a Brad Frost spicy take on design systems.

Brad Frost:

Oh, I, I mean, how many, how much time you got? I got a bunch of them. We'll go with a one that's on the top of my mind you're saying design systems are at this moment of, of we need this reflection. I think that one of the other things that I love about design systems is this, opportunity for real cross disciplinary collaboration, designer, developers, to work more closely with one another. And my hot take is that the way that the tools and processes have evolved, we are worse now than when our tools were shittier. When we had to design in Photoshop, there were real limits to what that tool can do. So out of necessity, that designer had to get out of their comfort zone and have to talk to their developer in order to make this stuff responsive and work and whatever and figure it out. There was a need, it was necessary. And the tools have evolved to a point, Figma specifically, you know, auto layout, variables, variants, all welcome additions, like those are all very good things. But what that's done, is gotten these tools to a good enough state that designers can hang out in that world, and collaboration with developers is relegated to a dev mode switch, which is a

Elyse:

damned shame. Oh, spicy.

Brad Frost:

That's the reality. We need to overcome that. And I have thoughts, feelings, and ideas around it.

Elyse:

Amazing. Thank you so much for the spicy take. Thank you so much for the backstory, the origin story of design systems. This is an amazing episode. Really appreciate having you on the show, and of course, everything that you've done in this industry for a really, really long time. It was a real pleasure,

Brad Frost:

Thanks so much for having me, Elyse, this was great.

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