Noel: Hello, and welcome to PodRocket. I'm Noel, and joining me today is Brad Frost. Brad is a design system consultant, web designer, speaker, writer, and I have musician here in my notes as well. Welcome to the podcast, Brad. How's it going? Brad Frost: Hey, good, how are you doing? Thanks so much for having me. Noel: Of course, of course. I guess, yeah, let's address the musician thing first. What do you play? What's your instrument? Brad Frost: Oh, yeah, I'm really a musician first, web designer, second, I think. That's how I see it at least, but been a bass player for about 20 odd years, but over time have spread into the drums, but have like a whole setup. So if there's an instrument, I'll play it. But I'll say that bass as well as drums are my instruments of choice. Noel: Right. Do you play live anywhere or just record or what's your...? Brad Frost: Yeah, once one's upon a time, college bands and stuff like that. I actually just played my first gig in 15 years for my sister's 40th birthday party. Noel: Nice Brad Frost: [inaudible 00:01:25] We preformed for that. So it's really fun. Noel: Nice, nice. That's awesome. Well, I could talk about music all day, but let's talk about web stuff though. Brad Frost: Let's just do that. Noel: Yeah, no, it can be... It's a different kind of fun, right? It's all in there somewhere. Brad Frost: You know what, it's very related. Noel: Yeah, yeah, totally. Totally. But no, let's talk about design stuff. Tell us a little bit about yourself. What's your background? How'd you get into design and design systems? Brad Frost: From music!- Noel: Excellent. Brad Frost: [inaudible 00:01:54] Carry that trend. Yeah. I went to university as a music major and my love of music led me to realize that going into that as a profession would totally ruin my love for music. So I shifted into a program at my college called Media Arts and Design, and we had a Dreamweaver class and a Flash class, and that sort of set the stage for... But then all the while playing in a band in college and had our website that somebody had to update the website and that somebody was me. I've talked to a bunch of people in this field and that's been their gateway into web design and development is, "Oh yeah, I had to update my band's website, so." Noel: No, I get it. What do you think kept drawing you to it? How did it evolve into more of a profession? Brad Frost: Yeah, it's a really good question, and I actually find a lot of similarities and commonalities with music. In that, music is a discipline, and that was like, I did that music theory, parallel fifths. There's rules around it. And there's people, there's this discipline, you think of an orchestral setting, these people know how to read music very, very well. There's a lot of logic to it. And then at the same time, it's this art form. It is this free flowing, this experiential thing, this kind of something that can't be quantified really. And it's both of those things. And in the field of web design and development, there's ones and zeros, there's FL statements, there's hard rules. But at the same time, it is this total art form in that you're creating things that have a vibe, have a feel, have an experience that you can't capture perfectly in the same way that you can't capture or describe what music is. You just have to experience it. So I love that. I love that kind of duality of art and science. And my dad's an accountant, my mom's an art teacher, so I've kind of always lived in this kind of realm in between arts and sciences and web design just happens to be a really great vehicle for that. Noel: Yeah, I think there's kind of analogies on both sides, in that they are both pseudo artistic endeavors, kind of emergent from really strong technical rule sets and foundations. And also there are strictly and wrong ways to do things a lot of the time. And there are rules that are hard and fast, except for in these certain cases, you can bend them and break them in certain cases. Yeah, I think that it's a common story because there is so much commonality there. Brad Frost: Yeah, it's lovely. It's always fun to dig into that stuff for those reasons. There's a lot of parallels. But from my actual background, I graduated college, got a job making real estate websites whenever the 2008 bubble burst. Moved to New York City, worked at digital agencies for about five years, and then moved back to Pittsburgh and started my own thing doing a sort of freelance web development, but has turned into a consultancy where we focus on creating and building design systems. And along the way, I created a thing called Atomic Design, which is a methodology for creating sound user interfaces. So yeah, it's been a wild ride. Noel: Gotcha. So yeah, tell me more about Atomic Design. What is it? Is it a book that's been published and is a point in time thing? Is it evolving over time? What is it? Brad Frost: At this stage in the game, Atomic Design as a concept is pretty well matured and thankfully hasn't changed all that much. It's very much a part of the present day design system conversation versus this kind of stepping stone. People ask me if Atomic Design is relevant. A lot of people see it as a buzzword, but I'll give the broad strokes of what it is. It is a mental model for breaking down any user interface. What we're talking through right now, Figma, Sketch, Microsoft Word, literally any website, any app. You can basically take the entirety of that interface and explode it into its atomic bits. It's elemental building blocks effectively. And how you go about assembling these small little bits, these atoms into increasingly complex components, what I call molecules or relatively simple components, and then through organisms, which are more complex components. And ultimately you sort arrive at the finished interface. And by doing things in that way, you are able to separate out and create more considered hierarchical, reusable interfaces that all sort of flow together. Back to a music analogy. It's like, you could look at a note or play a note and hear it in isolation, and it would be interesting, but kind of minimally interesting. It's only through the context of the entire composition that you understand what that note is doing and its place in the world. So the same thing holds true with our interfaces. Design systems have blown up as a concept, everybody's doing them. But still to this day, most of the organizations that I help work with and consult with, a lot of times there's still this attitude, or from an execution standpoint as, "Oh, we're going to build a button component. Oh, we're going to build tabs." This is very crude way of thinking about our interfaces. And I feel like a lot of developers especially fall prey to that. This stuff is easy. You just are making a component library, and any junior developer or designer can do that. When we're talking about how these components play into an organization's product ecosystem, the actual things, the fully composed pieces that we're all putting together here, that's where things get interesting. And so what Atomic Design is a way to connect a design system to the products that that design system serves. And that there becomes this kind of virtuous cycle where the ingredients that are contained within a design system inform and influence the type of products that you can build out of them. And in turn, those products inform and influence what goes in the system and what's there. So I find it all these years later to be an important way for people to create effective design systems. So I see it as that, unfortunately, sometimes it's like a buzzword, it's like, "Is Brad being clever and making funny names?" But it's like, "No, this is actually really how you make really well considered thoughtful designs." Noel: No, yeah, I mean, think that there's a lot to figure out on the relationship between elements in a UI. Announcer: Enjoying the podcast? Consider hitting that follow button for even more great episodes. Noel: Say you're, I don't know, addressing an audience, and they're all of that kind of developer you stood up before, where it's like, "What is a design system other than styles on some component libraries? It's not that hard." How do you bring people into the fold and get them to empathize with this kind of mentality that the design, the way that your components interact with each other, inform what your UI is capable of doing? Brad Frost: Yeah, it is really, I think helping them understand that this is a lot more than just a bunch of puzzle pieces that you're just then cobbling together. That there is a lot of art in the cracks in between these components. But ultimately the eye on the prize is really about creating great experiences for people and to really see it as a toolkit and you're setting the stage for great work to happen. And there's kind of an intentionality to it. Which runs counter a lot of times through a lot of developers, especially thinking about startup culture and stuff like that. Where you're just going to do it or you're just going to build it. And there's something kind of beautiful in that process as well. But really, especially whenever you get multiple people working together and you have that attitude, it kind of runs haywire. And so what a design system does provide is a common language. A kind of an agreement of we're going to do things in a certain way and we're going to have our talented brains also contributing to this sort of thing that's bigger than any one of our individual features or things like that. So I see it as a real encapsulation of a lot of smart people's brains that you could then plug in elsewhere, which is really cool when it works. When you got one working well, you're like, "Ah, there it is." You know how hard it is to make something and make it well. Wouldn't be great to be able to bake a bunch of best practices, brand best practices, UX best practices, front-end best practices, accessibility best practices, performance best practices, whatever best practices you're talking about. To be able to bake those in to, and hold it up to the rest of whoever you're working with or your organization or the world and say, "Use this and you'll get these things for free." It is a really powerful tool and concept around distilling and encoding best practices into a vehicle that can then be used a bunch of times. It's pretty cool. It's pretty cool. Noel: Yeah, I mean, I think that is an exciting notion. If nothing else is the potential of having that there. Where do you feel like that concern, or maybe that purview of the design system lives within the typical web dev organization, like a SaaS company? Is it designers? Is it the front-end devs? How does the design system come to being in a large organization with multiple stakeholders? Brad Frost: Yeah, and that's a lot of where I operate. A lot of the work that I do, as an organization grows, you have designers, you have developers, you have- Noel: Have marketing people, so many people care- Brad Frost: Product teams and all of this. And so keep multiplying that for infinity, and that's what you got. And so the kind of three leg... So from an assets perspective, what a design system should be composed of is a design library that lives in a tool like Figma or Sketch or XD or whatever. And then there's a code corollary to that in whatever sort of framework of choice, whether that's React or Angular, Web components view. We build them all. And those things should be in parity with one another so that you're speaking a common language between designers and developers and helping build things true to form. And then the third leg of the stool is a reference website for the design system. So this is your material.io or polaris.shopify.com or carbondesignsystem.com. And that's really the sort of what I call the storefront where you're putting all the ingredients out on the shelves and contextualizing what these things are, being able to provide that sort of high-level philosophy, high level guidelines, code standards, things like that. And then all of the reference for individual components. And you're able to say, "Use this in these use cases, don't use it in these other use cases" and things like that. So there's kind of a three-legged stool around what goes into a design system. So designers are using them obviously to construct, use pictures of interfaces and work through products that way. Developers are using them as a directly consumable, hopefully directly consumable kind of component that they're able to pull into their application and add a bunch of business logic to it and click handlers and all that stuff to the interface buttons. And then all the while the teams are referring back to the reference site to get a better understanding on how to use these tools. So that's how it plays out in an organization. But the big question of, where does it live and who owns it is a really good question and gets into, in our work as consultants, it doesn't matter. We've seen them live in an engineering organization. We've seen them live in a design organization. We've seen them live in all of these different places. But the fact remains is that it is this interdisciplinary meeting place, this watering hole, this gathering place where all these different disciplines and perspectives come together around this common thing. So that's why it gets challenging to be like, "Where do we situate this thing?" Because if you put it in the design organization, then all of a sudden the engineers go, "Oh, this is just a designer thing". Where vice versa, it's like, "Oh, this is just a tech owned component library and it's far away from..." So the spirit is put it in a place organizationally where it's accessible to people and people can have this sense of shared ownership of it. Noel: Yeah, that makes sense to me. I feel even if we can get to a place where an organization is, everyone's spiritually together, aligned, everyone wants to buy it and make it work. I'm curious, have you seen through your work, is it often difficult when, say the design, the designers, the teams that are doing their work in a tool like Figma. They have it all, this is the button, this is how it fits into these higher order components. We have all those scoped out. Is it tricky then to hand that off to developers to get them to go implement that in a component library in a reusable way where an immense amount of work will not have to be done in the future to get those pieces kind of reconfigured and put together. Or are the tools, Vue, React and Angular, have those made it so it's a lot easier to take those designs that are in Figma and broken out and build them into more modular pieces? Brad Frost: Yes, the more fully featured and parity with the design tools that a coded component library is, the easier that whole process goes that you just described. Oftentimes, and this happens a lot. And this is where design systems is just such an unfortunate name for this whole kit because it really should be interface systems and that sort plays out in a number of ways or whatever. But that's a conversation for another day. But in a tool like Figma, you can have a reusable component library that you're stitching things together and making pictures of user interfaces a lot more efficiently, which is great. But as you're alluding to, if there's not a code corollary to that, the same amount of effort, a developer will look at a comp and pick it up and build it. And it could look exactly like the comp, but it's not following any standards. It's a total one off. And so the answer, the solution for that is to again, see things through the lens of, there is a code piece of this that is in parity with whatever's in design and in order to create a composite component, or again, what I call an organism that's contained. That contains a handful of sub-components, you have a front end ownership of that at the design system level that can make that stuff possible. Think about it in the right way, architecturally. How do you make this stuff flexible and responsive and extensible and kind of things like that. It's doing that sort of hard architectural stuff to go, "Okay, we're going to create this thing, we're going to create it in a way that's built for reuse, that's built for flexibility, and then we're going to publish this thing and then the downstream teams can take it and just use that stuff." So it's a very, I think, interesting thing. And one of the things that I've been most excited about as a front end developer by trade, kind of turned design system person. What I see design systems is doing, is really help put a finer point on something that I think is really interesting in our industry. Which is when we talk about engineers or programmers or developers, they are not really thought of with a great deal of nuance. And it's like, "Oh, Brad, you do code." And this happened to me at a previous job. It was, "Oh, Brad, you do code, go over and sit with our Ruby developers and whip us up some gems." I'm like, "No, that's not how this works. I've never had a computer science class in my life", all of that stuff. So what I see design systems as being very important doing is, it's separating out what I call front of the front end web development as a discreet and unique and important skill set that's very difficult to get right. And what that does in the form of a design system that's kind of operated as a product, it has its own repo, it's its own kind of world. What it does is it sets up this relationship between people that I call kind of back of the front end developers, the people who are actually building application code and crud stuff and cash invalidation and all that jazz. It sort of sets up this really healthy, I think relationship, and a workflow, and a process and just a good one, two punch. Whereas before it's everything was just in the soup of your... A designer would pass off a comp to a developer to build. And oftentimes they're sort building the interface for that thing as well as the functionality and writing the tests and doing all that stuff. And there's a couple different kinds of code work in order to make this thing real. And it's important to actually stratify the types of that code work so that you have good people specializing in certain areas. And I kind of love it. I've found it to be a very welcome and very important and necessary distinction across the board. Doing UI code work is hard work. And even a lot of people say they're full stack are often it's like, "Well, we do this interface work because it's quote easy and we have to." I don't doubt for a second that a lot of people can, but it is also important to realize just in the same way that doing any sort of backend work, that's its own thing. I have a great deal of respect for it and I don't know how to do that stuff very well. I can get in there and do some damage, but that's what tends to happen on the front end. So increasingly, I'm just finding this really important, pulling apart of how websites and apps and things like that get coded into these discrete buckets and skill sets. Noel: Yeah, that makes a lot of sense. I guess one... I don't know if it's really a pushback, but more of a question is say you're trying to advise, maybe even just more broadly, not as a consultant, but just say there's people, they're working at some small little company or a small tech portion of a larger company. They've got one or two devs that kind of have to do everything, but they've got to do some front end work as well. How would you recommend that they avoid pitfalls in terms of front end design and maybe lean into some of the benefits that design systems might provide them, but if they don't have the resources to have a front of the front end designer to use your word, then that kind of middle layer person and then a backend person and a designer to do it well, what advice would you give? Brad Frost: Yeah, I get asked a lot around "What are your thoughts about just using Bootstrap or Material Design and stuff like that?" And it's that situation, that picture you just painted is exactly the sort of target for that kind of stuff where it's just like, okay, you don't have the time, energy, resources to roll a bunch of your custom stuff and to do it well while also trying to get a thing off the ground. And you got to do it by the way, really, really super quick because the money's drying up or whatever. That's a hundred percent in my view, the use case of when to reach for a prefab, a Chakra, a Material, a Bootstrap or whatever. That's great. The challenge becomes once you're established and once you have say a part of the company that has brand standards, you know what I mean? Once you reach a certain size, but I've also sort played things out and validated your quick startup, scrappy idea. Once that pans out and you actually are taking control over evolving your product. I'm actually working with the startup right now, I say startup, they're now... Six years ago, product didn't exist. Fast forward six years, and they have 500 employees. And they're at this inflection point of, we got this big ball of wax, this big code based as just built by hustle, hustle, startup culture, building things, add new features, listen to the customers, build that stuff for them. Just do that quick scrappy stuff. You can't do that with 500 people. So there becomes a time where the solutions and the tools you reach for to accomplish something in the first year of coding or whatever, is going to be different than whenever that stuff matures. And whenever you find yourself in that position where you're like, okay, yeah, we have in-house designers, we have people who give a crap about what this interface is beyond just "Does it do the thing? Does it submit the form?" Once you get to that level, that's where those of prefab solutions, as good as they are, you start of bumping up against the limitations. They're not built for a specific industry or they bring with it a certain look and feel or experience that might be different than what your customers need and stuff like that. Now all of a sudden you're finding yourself painted into a corner. And we see that a lot in our work, and again, it's not nothing against the Bootstraps and Materials of the world and stuff. They are really, really valuable tools, but at the same time, they're built for specific purposes and like any technology or tool or implementation, sometimes you find yourself going, "I think I'm kind of outgrowing this", or "I need something a bit different", which is natural, but also important to listen to. Noel: Yeah, totally. I guess, so in these cases, say small company and they're hoping to grow bigger, they're on that path, do you think it's easier once you hit the point where you are outgrowing whatever off the shelf component, library of choice or whatever you've been using. Is it a better place to be in? To at least have a component library that you've been using, you can start ripping pieces out and making it fit your thing, that if you try to have built something on your own, you end up with something a little more hodgepodge as you go? Or is there an advantage to building it, trying to do it yourself as you build, so it can be more bespoke as you evolve? Brad Frost: Yeah, I think that's a hundred percent a viable choice as well. And like anything, you weigh the pros and cons of it. We are going into this eyes wide open, we're going to incur these costs, but we feel it gives us the ability to solve the problems in front of us and in the best way. And so yeah, I think it really has a lot to do with just the culture, the individual people that are around. But in general, as time goes on, and I've been consulting with companies for a decade on design systems, and it overwhelmingly is clear that at some point whenever you have enough smart people that you employ, you ought to have a perspective on how you go about designing and building products. And it's helpful to be able to own that perspective rather than infuse yourself with this kind of a, "Oh yeah, but we're just kind of following Google's lead here." No, no, no, you really should say, "Here's how we build software here". And that that's actually how I define a design system as the official story of how an organization designs and builds digital interfaces. What is that story? And of course, there's ingredients to that story, tangible, and ingredients like button components and tabs and whatever. But there's also that philosophy and high end guidelines and what are the principles and values that we are trying to instill and scale across our products? Noel: Gotcha. Nice. I guess, have you seen firsthand any cases where companies have tried to go that route or they spent some energy, spent some time trying to build up a design system around their product and it goes awry, just doesn't land. Brad Frost: All the time. That's one of the first things that happens whenever we start working with a new company, is they take us on a tour through their graveyard of fast design system efforts and stuff. They're like, "Oh yeah, here's 2013, whatever. Stacy was still here, and then she left, and then we dusted it off in 2017, and we did it whenever we were moving to Angular. And then here it is in 2019, whenever we moved away from Angular towards React." And then you end up with just this... There's often a lot of past efforts. And it really just goes to show it's not, again, very sort myopic or one dimensional view of what a design system is. It's just like, oh, it's just reusable components. What's so hard about that? And you're like, no, no, no. This is the orchestration of design and technology and people and process and culture and all of that stuff. And you need to align a lot of very human brains in order for something like this to be successful. And that's why I love the work that I do, because I'm around code, I'm touching that stuff. I'm still paying attention to the technical implementation of it, but 95% of why a design system fails is human. It is not, "Oh, whoops, you should have gone with React instead of Vue." It's never that. If it is even around that, it's still a human problem because it's like, oh, you all were misaligned or weren't talking to each other or whatever. So it all boils down to it's about the people and the processes and the organization of people, processes and tools and technologies. Noel: Yeah, I think as developers, people often the inclination is, "Oh, we could just use a tool or use this process and it'll fix the problem and everything will work." I have in my notes here what tools can be used to ensure things succeed. But I don't think that's a great question. I think the better question might be, what advice would you give maybe designers or engineers who are in organizations who are feeling this need, this pain, but they don't know how to go and get buy-in throughout the org and instill that focus on the design system? Brad Frost: Yeah, yeah, it's great. It's a really great question, and one of the best things that I love about this is that it really isn't this big extra effort. So much of this stuff is just a mental shift. When you talk about, whenever you build a feature or something like that, a developer sitting at their desk, they're building a feature in order to get it out the door, a lot of times that's the tunnel vision. It's just like, "I'm building this thing for this reason", and by taking off the horse blinders a little bit and just going, "I'm going to build this thing through the lens of this feature, but I'm also going to just give a little extra thought about how this might be used elsewhere or in the future." Or something like that. So from an actual production effort, there's no real change that needs to happen. Designers, developers, everyone can just start building, creating things in this way, and it doesn't really cost you anything by way of effort or you're not going to be late. It's not like, "Oh, creating this design system, that would be a dream if we had it, but there's just not enough time in the day." The trick is to just make you doing your normal work, also be building a design system. And so that's easy to do at an individual level, broadening the net a little bit to a team. The cool thing is that you can convince the people that you work with directly to commit to this. So this is a very grassroots way of doing it. There's a top down way of doing it, which is "We've allocated this much budget for 2023 budget and Q1 we have this much money", and that's great, and if you can get that kind of muscle behind it, that's great. That means that there's top down commitment to it. But there absolutely is the ground up way, which is you and your team said, "Hey, you know what we're going to do? We're going to try to be thoughtful about how we're reusing things across all the screens that we're building together, and we're going to try to do it in a way that we can reuse this stuff." And that's just a very pragmatic and sensible thing to do. And from there, once you have a couple successes under your belt where it's like, "Oh yeah, we launch this stuff on time and on budget", you're able to be like, "Oh, and by the way, we've been working on this thing" pulling back the curtain a little bit and just being like, "Ta-da". Just to be clear though, in order for a thing to be successful, a design system to be successful in the long run, it's got to eventually get that sort of top down. It needs to become an officially sanctioned things. It's great in the early days, you can just grassroots it and just do it amongst your team, get something off the ground, grow it, build it. But really in order for it to turn a corner and actually be successful in the long run, it needs to not be a side project or a hack-a-thon thing. Noel: Right. So I guess, yeah, I'll ask one more question just to keep pushing here a little bit. I feel that engineers, and probably designers too, the tendency is always to over future-proof and engineer things a lot of the time in their craft. It's like engineers will, they'll write methods like, "Oh it can do this and this and this", and it's like, yeah, but it's never going to do that for any of the reasons we need. So I feel like that happens on the coding front already. And so I think that that inclination is there towards the front end as well. That's why you step into these organizations and there's the six failed attempts. So I feel like there is that general, everyone knows that we should be working on making this future-proofable and scalable. Why does it fail so often? Brad Frost: Yeah, and you sort of alluded to it where it's like sometimes there is a paralysis that's around, "Oh my God, we have to contemplate every future use of a button that will ever happen at this company." And they totally paralyze themselves and never get anything done, because you can always play a bunch of hypotheticals out in your head, and we could do that until we die. It's like, And so that's kind of one end of it. And then I think the flip side of that is sometimes these things get built that are overly tuned for a specific experience that actually loses that scale. So there's this kind of sweet spot and an art to making something that is useful now and gets something out the door and is connected into advancing a real product. And this is coming back to Atomic Design, why that's so helpful. What we do are what we call pilot projects, which are, we need to build the design system, we need to build products using those design systems. What's a good page or what's a good flow, or what's a good sort of slice of an application that we can build while also setting aside these reusable pieces. So it's like, "Oh, the login flow is pretty lightweight. It'll get us some [inaudible 00:41:06] peels, it'll get us some button groups, it'll get us this stuff." That's a good way to go about building a design system. But the trick is, again, there's this art of what I call think globally, act locally. It's like you're building something through the lens of a specific screen, but what you're trying to do is think globally. You're trying to think about that, "Okay, how might this be reused? How could I?" Just even naming things, just don't call it login form, call it form. You don't call it first name field or you call it just a text field or just... Simple stuff like that goes that extra distance to make that stuff a little bit more reusable. So there's kind of this sweet spot of, you don't want it to be totally rigid or so locked into one use case for this one specific app or use case, but you also don't want to go, "Okay, we need to create the perfect button that will serve everyone equally well", that's just not going to happen. So somewhere in between. Noel: Nice, nice. So yeah, I feel like we've talked a lot about how this is a people problem more than a tooling problem, but is there anything in the tooling space that has emerged recently or you've been excited about that you found has been working well in leading to success? Brad Frost: Yeah, it's great. And I think that the tooling landscape in the design system world has been really great. For one, tools like Figma I think have come a long way. They actually have what they call variance in it. So you could create a component, and it used to be in the olden days, you would have a primary button component and a secondary button component and stuff like that. What we now have in these design tools is how we actually build things in code, which is you have a component that surfaces an API and you're able to say variant equals primary or a secondary or tertiary or whatever, and you now have this in the design tool landscape. That's been a huge win to getting that sort of one to one, that parity between what's in code and what's in design and how we talk about that stuff. So that's cool. I'll say that tools Storybook have been incredibly valuable for lots and lots of reasons. Again, just kind of creating this place where you're able to visualize and reference and document and test your components in isolation. I call it a front-end workshop environment. And I built them myself in a tool called Pattern Lab. That was back in 2013. This place that's away from any given application that we're able to really focus on just creating the best UI code, because in the past it used to be like, "Oh, you want to make this button orange? Well, first you got to spin up the Drupal environment, you got to pull the database, get your local environment sort." And you're like, "I'm trying to make orange buttons here. I don't need any of that stuff." So I think that tools Storybook have been super, super-critical and giving design system and UI specialist like a place to focus on. But yeah, so I think that those are that, and that's pretty common fare. There's new stuff that's out there. I think that there's a lot of really interesting tools about trying to create more visual design tools, but are using code under the hood. And so there's a lot of, I think, really interesting things there. There's tools like Style Dictionary for managing design tokens, which are the low level design primitives of a design system. But that's probably a really big area for improvement, I think, to really mature how going, "Oh, here are all available border radius values", or "Here's our brand color palette and our neutral color palette and utility color palette" and things like that. Just kind of making that stuff a little bit more seamless, especially across disciplines and stuff. I think that there's some opportunity there. So good stuff that's out there, but certainly some room for improvement. Last thing I'll say is from an actual meat and potatoes, how we are actually making this stuff go. Over the last three and a half, four years, we've been building increasingly design systems and web components, which has been really fascinating and fun and getting excited about that as that technology matures. And we've been enjoying that. We built things in React, build things in Angular, build things in View, build things in Mustache and Handlebar and everything else. But to have these web native components that we're able to create once and plug into all of these other frameworks and to plug into all these applications and environments and to have that be part of the web is tremendously exciting. And so that's a tool from a actual technology choice that I think that we have really been leaning into or getting jazzed about. Noel: Nice. My last question then I'll be asking you a prediction, do you think that kind of ubiquity of web components will lead to them being the norm and how development is done in the future? Brad Frost: Yeah, I hope so. And I'm thinking about this. Right now, the narrative as this is being recorded it's pitted against other sort of solutions. So it was like React versus web components or React versus Angular, and it's like- Noel: It gets the clicks on the blog titles, yeah. Brad Frost: It sure does, it sure does. And there is some truth to it, but truthfully, in the same way that I've been talking about how a healthy handshake between kind of front of the front end developers and back of the front end developers is a useful distinction. And there actually is this really nice, clean relationship there that I think is healthy. I see kind of web components and the rest of the modern web ecosystem and beyond, as a really sort complimentary affair. And so I'm excited because for these kind of just dumb presentational components where we were just trying to write some markup, trying to write some styles, trying to write some JavaScript, the accordion opens and closes. Do you really need that to be Reactified? Do you need that to be Angular convention? That's kind of silly. We need the accordion to open and close, and sure, you could then take it into React and Angular and do whatever smart things that those environments do really well. And that's what I see as the potential for this super healthy handshake between, okay, we're going to have these web native components, we're going to have this kind of source of truth for this kind of just dumb front of the front end code. And then we still have all of our other landscapes to really breathe life into them and make them real. And I think that that's really exciting. Noel: Nice. Nice. Yeah, I think so too. I think there's stuff going on. I think this realm... I think some people kind of mis-assume that it's kind of done and settled, but I think there's a lot going on still. So yeah, I'm excited. Brad Frost: There is. And there's a lot of, I feel like stinkiness for it. I don't know if the PR and stuff around web components and a lot of the narrative kind of matches the potential or the reality of it. And increasingly I'm finding it. It's like, man, as people who care about the web, we should really all probably care more about web component success. And if there's, of course, rough edges and stuff like that, "Oh, let's smooth them out. That's what we always do." Noel: Yeah, it'll get better. Awesome. Cool. Was there anything else you'd like to promote or point listeners towards? Brad Frost: No. I have a blog where I blog about web stuff and design system stuff, it's just at my website, bradfrost.com. I'm on Twitter, is my drug of choice, Brad_Frost. So yeah, I'm there. I enjoy connecting with the web community, so I would love to keep the conversation going with everybody. Noel: Awesome. Awesome. Well, yeah, we'll get links to those in the show notes. But yeah, thanks for so much for coming on and chatting with me. Brad's been a pleasure. Brad Frost: Yeah, thanks so much for having me. It was great. Noel: Of course.