Design Systems With Brad Frost (Rereleased)

Hey. What's up? This is Scott from Syntax.

Now that we're on YouTube and approaching 800 episodes, we wanted to release some of the very best interviews that we've done on Syntax.

So please enjoy one of our favorite episodes.

Welcome to Syntax, the podcast with the tastiest web development trees out there. Today, we have a special guest on the podcast, mister Brad Frost.

Brad is author of Atomic Design, design system consultant, web developer, CSS thought leader.

I'm sure he doesn't like that last one. All kinds of stuff around building design systems and building stuff for the web. Welcome, Brad. Thanks for coming on. Yeah. Thank you so much for having me. This is awesome. And if you want to see all of the errors in your application,

you'll want to check out Sentry at century.i0forward/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to reduce entry.ioforward/ syntax. Again, we've been using this tool for a long time, and it totally rules. Alright.

Wes. Let's let's Scott, like just tell I'm sure that literally everybody has probably stumbled upon your website at some point. If you just go to Brad's website, you probably go, oh, yeah. I remember this website. But if people don't know who you are, give us a rundown of who you're who you are, where you're from, what you do, all that good stuff. Yeah.

My my my website being a Scott of a calling card is a is a point of pride. That one time I was at the the dog park and was talking I was talking with somebody.

I was talking with somebody and and so, you know, it got into, oh, what do you do? And, oh, I'm a web designer and started talking about what they what they got into. And then they said, well, what do you do? And I said, oh, I'm a web designer too and started explaining a little bit more. And they because you're the guy with the orange website.

And I was like, Wes. I am. I am the guy with the orange website. So Is it orange? I always I was gonna say, I I almost introduced you as the guy with the brown website. It's it's like it's like cream, brown, and orange. Those are, like, my Scott of, like I I have, like, a long standing brand palette that has worked quite well for me over the years.

How did you develop that that brand palette? Is that, like,

just like your favorite colors, or was it Like, I my vibe is whole, like, 19 seventies. Like, I I was, like, born in the wrong era. Like, I yeah.

Hi. I can see it now. Yeah. Well, besides having a Brown website, what what what else do you do? What what do you put on this Brown website? What do I put on this problem? Yeah. So so I do

like you said, I do a lot around, design systems.

And, I've been writing, blogging about the Wes, making websites for since 2007. And so I've been sort of on a few different rodeos. I kinda started, kinda maybe coming into prominence a little bit through the whole responsive era. I happen to be working at an agency, right, whenever the sort of smartphone bomb went off and where it was, like, okay. What do we do with this? And so that so I kinda started piecing that together.

And sort of through that responsive design work is what sort of ultimately kind of, evolved into working with design systems.

Because in a lot of cases, what we learned is, oh, yeah. It's not that making a whole page responsive is the hard part. It's Node, no, no. How do we convert this navigation thing to, you know, something that's more conducive for small screens, large screens, and everything in between. But anyway so kinda came up through the agency world, but, for the last decade, I've I've been on my own, but also partnered.

And I am a a principal and design system consultant with an agency called Big Medium, with my partner Josh Clark, my brother Ian, and a whole other sort of cast of characters. And what we do JS we sort of jump into a bunch of big organizations working with design and development teams to actually help sort of implement and evolve design systems and stuff. So that gets into all the technical architecture side of things, which is what I tend to sort of hang out and do. And my team sort of helps, you know, build component libraries and integrate component libraries into products and sort of make it all go.

But then it also, of course, gets into all of the the the people, and the process, and the culture, and the organizational kind of stuff. And that's the that's the real fun and the real challenge of of doing design system stuff. Like, anybody can make a button. Right? Anybody listen to this. That's that's not the hard part about the site.

So so yeah. So that's what I've spent the last decade doing and and sort of through that work Scott of helping organizations build these things, sort of came up with this this methodology called atomic design, that sort of helps connects connect the the design systems that we're creating to the real products that those design systems are serving and sort of kind of setting up this kind of virtuous cycle between, you know yeah. If your marketing website has big old heroes and chunky cards and newsletter sign up things. Well, guess what? Your design system needs to account for. Right? It needs to account for exactly those things. So yeah. So it's been, it's been a fun journey. And the, the fun part about doing consulting and plugging, you know, ducking my head into all of these different organizations is that we get to see many, many, many different flavors of the same thing. Right? Sort of different patterns or different sort of weird left turns or different frustrations that all ultimately sort of feeds what I talk about and write about and think about.

Beautiful. Yeah. I'm bay I'm based in Pittsburgh, but, you know, Internet.

Oh, yeah.

Right on. Let let's take it that direction, about design systems. So we'll talk about both, like, holistically.

Like, because I know that, like, a design system takes both a lot of work, both in terms of planning and figuring out how to approach something, but also from, like, a technical implementation as well. Like, how do you how do you do that? How do you make a button look the same across a 20,000 developer organization? So, you wanna give us, like, a rundown of, like first of all, people listening might not even know what is the design system, and then we'll go into maybe some of the tech behind it.

Yeah. No. That's it. That's a great place to start because that's kind of the $1,000,000 question. And, you know, if you were to ask a bunch of people who work in our world to define what a design system is, you're gonna get a lot of different answers.

It's a bit of, like, the the parable of the blind men and the elephant, right, where ESLint men approach the elephant and somebody's touching the trunk, and they're like, oh, it's like a snake. And somebody's touching the leg. It's like, oh, it's like a tree trunk. And it's like so there's all these different sort of facets and assets to a design system.

But sort of the the umbrella that I tend to put things under is that a design system is the official story of how an organization designs and builds user interfaces.

And that's kind of intentionally vague, right? There's a lot of ingredients that go into that story, but at the same time, like that's, that's kind of ultimately what you're trying to do is is is is, you know, say, here is how we, you know, wield accordions or form fields. Here's the things that we care about. Here's how we sort of, you know, construct an architect and build and implement user interfaces.

And it's sort of specifically user interfaces, not necessarily digital products, because there's all these other things that go into making a digital product work, as you know, that don't pertain to user interfaces. So, so I kind of Scott of narrow the focus to that.

There's kind of 3 main assets, 3 legs of the stool from, from, what a design system, the sort of constituent parts Yarn. It's a design library and something increasingly Figma, right? Figma library containing your common components. And this is this is important here.

Common components that are meant to work across an entire of of different websites and apps that are that are in there. So the design system is really the foundational level, which is like, here's where truly shared things go.

And that's an important sort of qualifying characteristic of this because there's lots of other things that can exist in, like, a layer cake, format that we could talk about in a bit that that aren't truly sort of scalable to the whole work.

So design library, Node leg of the school, a code library that is a corollary to the design library.

And then kind of a reference website, some documentation that sort of brings it all together. Right? So something like material.

Ioorpolaris.shopify.comorcarbon design system.com.

Right? There's just kinda brings it all together, puts a bow on it, helps sort of frame it, contextualize it, and sort of teach people how to use it properly.

So those are the kind of like 3 assets, 3 core assets of a design system and on the code end specifically increasingly for the last like 4 going on 5 years now, we have been, increasingly reaching for web components to help author and deliver design systems to the, again, dozens, hundreds or thousands of applications, many, many, many different tech stacks, many different implementations, many different frameworks, many different CSS, many different blah.

But at the end of the day, when you talk about what a design system is, it's like delivering the kind of like dumb presentation, basic functionality of these sort of reusable components, right? The button you pull in the button web component, boom, there you go. There's your branded buttons, Pull in the, the design systems, accordion component. You click on it. Guess what happens? It opens. Right? You click on it again. Guess what happens? It closes. So it's like, it's that level that we're talking about with design systems. We're not talking about wiring this up to sort of, you know, back end services or APIs or anything like that. It's it's kinda strictly the sort of presentation, the thing that the the users see, we kind of call that the, the front of the front end Node, right? HTML, CSS, presentational JavaScript, no logic, no nothing.

Just, just strictly that and that concept alone.

It, whenever we introduce to our clients' organizations warp like, it will help help them sort of unpack that it's it's it's not something that a lot of people outside of our little circles, I think, really understand.

Nice.

You mentioned, like, it is a part of the different layers, you know, being a design component and a a code component to these layers. But I think one of the the things that people hit is keeping some of that stuff in sync.

Do you think that there like, Node JS is there a more unified way to connect the design in the code aspects, and is that even, like, a good idea to have those, like, deeply connected?

It's a damn good question. And, yeah, like, we've we've seen, you know, generations now of trying to solve this problem going all the way back to, you know, Dreamweaver days. Yeah. Right? And, you know, WYSIWYG days and stuff like this, and, you know, PSD to HTML just, like, hit the yeah.

Probably like giving shivers to some some people listening. But it's like yeah. These tools are getting closer together.

At the end of the day, they are different worlds. Right? Like, Figma, here's this blank canvas. You could just drag things around arbitrarily. You could have these different artboards, 1 for mobile, 1 for desktop, and whatever. And you could just go, oh, yeah. I'm just feel like moving that from here to here in free space, which is obviously not how things work in the browser.

So it's challenging because especially in, like, the Figma world, it's, like, gotten good. It's gotten a lot better at sort of in closer to representing the box Node.

Basic things like, you know, the auto layout and sort of stretching things, like, to to better behave like the browser, but at the same time, like, it isn't.

It's it's this kind of like very narrow band of of what goes into UI as you all know. Right? There's there's many, many, many different capabilities that these browsers can do that that do not get reflected in these static design tools. And, yeah, you can there are prototyping tools and there's stuff like that, but those are all approximations.

Right? So you don't get performance, page layout, and jankiness.

Right? Loading of of like these big hero images. Like all of that stuff interact true interactivity and stuff like that. That's the user experience. Right? Like that is the UI.

And so, yeah, it's long been a a, you know, soapbox of mine of, like, the whole sort of designer developer workflow and how broken it tends to be, especially whenever sort of things originate in design, and then Wes they get thrown over the fence to development. So what's interesting in the world of design systems is that there's an opportunity to kinda reframe it. And this is what we help our clients do JS that what's in a design system Figma library isn't so much like a spec for developers to, like, build it out. What what this Figma library is is kind of a promise of what's in code. Right? It it is a representation of what exists in the coded design system, which means that downstream product designers are able to sort of reach for these things, drag their form controls onto a page, drag their button group onto a page, drag their different cards onto a page, and know with a with a greater degree of of of certainty that that, oh, yeah. This can be built. Right? So it's it's a little bit different than the normal design process where it's like, I'm gonna blue sky, you know, create this new funky Node page and then sort of give it to my developers to build out. It's a little bit the the the coded design system library truly is the source of truth, and then the Figma library is this kind of abstraction of that that allows designers to do their thing.

I'm I'm curious about, like like, what does it actually look like when you put it in a developer's hand? So you said, like, web components, but, like, I'm imagining a big company.

Their main app's built in React, and they've got a marketing site in WordPress and a store running on Shopify.

How do how do you get, like, let's say you have a a Yarn, and that card has an avatar inside of it and a button and some text. How do you get that to look the same across

all of the different websites? Yeah. So we actually just published I just published 55 100 words, I think, is is what it ended up being. But it's it's it's kind of in the answer to that question, which JS, like, here literally is the entire ecosystem of, like, the different layers of this layer cake and how you get these sort of web components that live at the sort of basement layer in the design system ultimately into products. Right? And a lot of these, the answer to your question is really like, of course, like most things, web design and development is like, it depends.

But some of the ways that we accomplish this, if you have a card with an avatar, what else Wes in it?

Button and some text. Yeah. Alright. Card,

avatar, button, text. Mhmm. What we tend to call that is a recipe that might not live in the sort of basement level design system. It's composed of all of those basement level design system things. Right? Yeah. This is this is where things get tricky. Because, like, whenever you deliver something that that that's that composed in your design system, product 1 might be able to use that thing as is.

Product 2 comes along and they say, oh, we actually need 2 avatars or we need a button group instead of just this 1 button or we need a subheading in addition to that. And that's where those kind of more composable components like cards and headers and stuff like that tend to fall down. So what we do to solve that is we'll kind of like move that into its own layer called a recipe layer that allows people to go, okay.

Avatar card is is its own product specific thing, and that thing might be React component. Right? Like, if it is for, like, the flagship React Yeah. App like you're saying. So it's like it would import what it would look like. It would be like import card, avatar, heading, text passage, or whatever you wanna call that thing, and Yep. Button from the design systems web component library. But then a a sort of React recipe gets born out of that, and then it gets ingested, you know, by the actual application, however it sees fit.

Alternatively, you could make those as its own sort of recipe layer, which is often like a sibling repo in, like, a mono repo or something like that. Right? And make that in web components.

And then you could deliver that to your React application, but also your WordPress site. And also, I don't know about Shopify JS in what their ability to digest

or ingest packages and stuff like that is. I'm curious. And, like, like, what about all the CSS that comes with it? Is that CSS built it baked into that web component, so it's it's Scott to it? Or do you give them a CSS file or they have to import it? Yeah. Yeah. So so when you publish the design systems package, what you'll get in, like, a disk folder

is like the CSS that is like effectively just a handful of CSS custom properties. Right? That that is what's sort of flowing through the web components to give it this specific look and feel. And what that does is that that unlocks all the stuff with like, you know, themeable design systems and supporting multiple brands and white labeling and dark mode and the whole 9 yards. Right? But that's the stuff that penetrates through the shadow Dom. So what it looks like in practice, if you just have like index Scott HTML, you're linking up the design system CSS file in the head of your document.

You're linking up via CDN or some package manager, the actual web component library.

And then whenever in your body, then you're able to be like, you know, DS dash, right. Design system dash button.

Yeah. Variant equals primary and then pnpm.

Right. That gets you the, the desired, like, look and feel.

So that's like it at its, like, most basic Yeah. In, like, an index dot HTML thing, but then, of course, every product, every app is architected differently, but ultimately, you know, we're like leaning on NPM or yarn or whatever to, you know, pull these things in as dependencies and then you're able to import them.

And then all of these web components are rendering out to standard HTML elements. So, like, there's there's no sweat if a React developer wants to put custom attributes or props or classes or anything

on each of those? Yeah. So so this is this is what gets interesting. So there's like a couple concepts that are important. Right? So one is the shadow Dom, right? So it's like, you can kind of have this, this kind of protected boundary around each one of these things. They're they're designed to be their own islands, which there's kind of pros and cons to all of that.

There's some challenges around there, especially around like it's like, if you have like a label web component and then a text input component, Wes component, and you need those things to talk to each other. That's all been kind of like either in progress or it has been sorted out at the, like the sort of browser level. So it's getting better, but the last number of years has been fun.

Yeah. Yeah. The Scott of hitting up against those kind of rougher edges, but things have definitely like stabilized a Scott, But ultimately, like these things are their own little islands.

They operate in a lot of ways, similar to how a react developer would be used to sort of interacting with any other react component, but different in other ways, especially this kind of like this literally has like a boundary drawn around it and you can't just go around and like extend it and, and just kind of reach into the shadow dom and just kind of hack the crap out of things.

Yeah.

So so there's a number of interesting things that we tend to do. A lot of organizations that we work with have existing React applications and React component libraries to power those applications or, and, or they have a bunch of angular apps and an angular component library that is sort of powering that. And a lot of times, like what we'll do is we'll actually kind of come in almost like hollow out the guts of those things and establish this web sort of more basement level web component layer, but still preserve those like react libraries and those angular libraries.

But all it is is effectively like a pass through layer. So react developers are still able to engage and interact with these react components, but under the hood, they're ultimately, you know, being powered by web components, same deal with the angular world. Right.

Angular developers can continue using that stuff.

So like the ergonomics are there for people used to working in certain frameworks. It also helps to sort of like normalize API stuff.

Like Wes from component to component, right? The button component was created 1st and uses specific language and then people get lazy or junior developer kind of came in and create a new component. And it's like totally a mess from a language perspective. So a lot of the times what we do is help establish clear API definitions and a whole language around your component library.

But then the cool thing with this kind of like intermediary layer with like a react layer or angular layer, whatever layer is that you're able to sort of like, have it be this pass through, but also kind of support the old API while also introducing the new API and sort of like smoothing that out under the hood.

So there's like a lot, there's like a lot of weird nuance here, but at the end of the day, it's like, what's going on at the end of the day? If you zoom, like, way out JS this, like, basement level web components getting delivered somehow some way to real websites and apps that people use.

Yeah. There might be a couple train stops along the way, or they might get sort of wrapped in sort of various levels of smarts or or framework specific technologies or this recipe layer, like we're talking about.

All of that is optional. All of that, like, helps make it all go more Sanity.

But at the end of the day, we're talking about

web components powering products now. I think people listening right now might be saying, like, what's the benefit of going all in on web components for everything instead of just delivering some classes and telling people, hey.

Put this class on your button, and it'll look like x, y, and z. God. Yeah.

I, I feel I wish I had like literally all of my clients with me. Like, just let me get Neil in here to tell you why that's ultimately, here's the problem.

The problem with that is that that's you can create and this goes all the way back to just, like, bootstrap. Right like put bootstrap Scott Node dot CSS and the heavier document match these classes you're good to go right a lot of these things then require the Dom to be a certain way, right, in order for them to to work. Right? Like, obviously, we try to make classes as modular as possible and stuff like that. But a lot of times, it's like this stuff just falls down as, that just introduces so much room for error.

And especially whenever you're talking about let's just say you Scott a bunch of React apps, you got a bunch of Angular apps, and you got a bunch of Vue apps. You're then requiring 3 different teams to rebuild the same accordion logic. Right? Again, you click on the thing, it opens. You click on the thing, it closes.

You're relying on 3 different teams to do that. Get the Dom exactly right. If something changes that became that creates a bunch of downstream work for all of these sort of framework specific layers. And what we've learned, unfortunately, is that front of the front end code is still kind of relegated to a 2nd class citizen. Not a lot of people know how to do it properly.

So by actually the beauty of web components is that it literally bundles up the HTML, the CSS, and the JavaScript as a little nugget, as a little bundle that you just sort of get for free. And if changes happen, while you bump the version, you pull in the latest version, These those people maintaining those view and Angular and React libraries don't need to do any work aside from just bumping the version, and they get whatever accessibility updates for free. Say that. Oh, whoops. We changed these things in the DOM. Like, it's just way more direct of a delivery

kind of vehicle for front end. That's beautiful. That I'm that's very well put. And I was gonna say, not to mention, like, trusting 3 teams to accessibly implement the same thing exactly the same way or sometimes, like No. It's it's awful.

Yeah. Imagine that. Wes, I've told you about this before. When I worked at Ford, we we were given the task of building these experimental components, and and we were expected to deliver them as a style guide.

And our style guide was just being presented as here's our Angular and CSS code, and Ford, with their 90 different markets, all used a different back end, a different CMS, whatever they had.

Their front end engineers were tasked with reimplementing those same components on every single one of those 90 CMSs.

Mhmm. You could just see exactly where the problem is going to be there, and it it was a tremendous nightmare. Most of it never ended up shipping because of that. Yeah. Do you think that these kind of problems are only the types of problems that people hit at a larger scale? Like, does Joe Schmo with a a Scott up web app need to worry about having a system like this?

My answer is yes. Like, obviously, the benefits become greater. I think the the bigger the the breadth and depth of the organization, like, which is why all of these, you know, fortune 500 companies and stuff are it's like, obviously, we need a design system because we've got dozens, if not hundreds or thousands of apps around, but let's just take index Scott HTML and about Scott HTML and Node, we need that header. We need that footer. We're going to have like the same kind of stuff on here. So, you know, historically, whether that's what PHP includes or whatever sort of templating language or whatever. It's like that problem.

Like the problem of components, right, is needed as soon as you create 2 web pages.

So the example I I like to use is that, like, even so, my wife ran a jewelry company.

I of course being the good husband I am created a website for her and even with what's effectively a 5 pager, right? I still applied this whole that this exact same methodology that we do for these jumbo size organizations because in order to build the homepage, well, I need the hero. I need these cards. I need the header in the footer. And then I go into the interior page, and it's like, oh, okay. Well, I got my header in my footer, so that's already, like, 70% of the way done. Right? And then I might be able to reuse that card there. And then by the time I get to the 3rd template, it's, like, oh, okay. So now I'm like, now I'm I'm really 70 way percent of the way done. The 4th template, I'm, like, 85% of the way done. By the 5th template I might not have to do any new component work. Right? It's just a matter of composition.

So so just simply a matter of pragmatism, like literally any organization of any size or any website or app or whatever can benefit from component driven workflows.

You could call that a design system. Again, like, you don't need to make something that's JS, like, full blown as material design. I don't think that any every organization needs something that sort of formal or grandiose or comprehensive.

But even for, like, a design system to power a 5 page website, yeah, that's a design system powering the product as much as it needs to. And that's like a big asterisk that I wrote in that, in this big ecosystem article that we just published JS, like, these are all potential things. Right? Everything that we've just been talking about this, like, framework specific layer or this notion of recipes or this notion of, like, even kind of taking our dumb form fields and wrapping them in in, you know, whatever React hook forms, whatever, in order to make it go. Like, all of those are optional. Right? Like, not every organization needs that. We've never encountered any organization that has, like, literally all of these layers in place.

It's like a design system ought to be as complex as it needs to be and no more. Right? Like, don't introduce complexity without a real need for it. And like most things, you got to sort of start simple and then sort of grow and introduce that complexity only when it's warranted.

I had a question about design tokens given that they're in this post. We'll we'll make sure that this post is is linked up, by the way, because it's really substantial and great. Right. How do design tokens come into play here? Mhmm. And I think a common, like, understanding of them is that their design token is a CSS variable. Is in your opinion, is that accurate at all? And, like, what are design tokens here? Yeah.

So so it's it's basically there's truth to it. Just to again, just with the the term design system, it it means different things to different people.

Mhmm.

What we've been talking about is like a web component powered design system.

And through that lens, your your design tokens are ultimately coming out the other end as CSS custom properties to power those web components, right. To, to sort of give the flavor, but they're effectively these like really low level brand attributes. Right? Their their brand definitions, you Node, here's a brand orange. Here's a brand cream. Here's our brand brown. Right? For my own for my own personal website. There we go. So that's my brand palette. Right? But so what these things do in design land is obviously you're able to sort of like pump those into your, your Figma library and stuff like that. In code, you're applying them as CSS custom properties, but also other environments, especially like native environments, tokens and get Starbucks green. If, you know, Starbucks green needs to be Starbucks green whether you're on their Android app, their Bos app, their their, you know, starbucks.com, or even freaking like PowerPoint templates and stuff like that, which is pretty interesting. You could, like, you could basically export these things, like, at its at its core design tokens Yarn like, here's the single place you define where Starbucks green, What it is. And then there, there can be a 2nd layer to this, what we kind of call like a semantic layer, like this kind of like tier 2 thing that we sort of take this kind of dumb definition, this, this interface agnostic definition of what this Starbucks screen JS. And then we can start mapping this JS like a little sort of mix and match kind of exercise where it's like, oh, okay.

Brand background. We're going to match Starbucks green to that error success border. Right? If we wanted to have branded Starbucks branded, valid, you know, form controls for instance. Right? We could sort of mix and match. Right? Draw an arrow from that sort of tier one definition.

So it's just like, basically like mixing and matching these variables together and Scott of creating this, this kind of tiered system.

And what doing that accomplishes is you could have, and literally all of our work over the last probably 5 years has involved some form of supporting multiple brands, supporting multiple product families, things like our marketing website has a different type Scott.

Then our, you know, dashboard back end systems that don't need big combo things, right? So so there's that use case. There's dark, dark mode, light mode, and all of that stuff, which is its own thing. There's white labeling, which is Wes need to take our thing. And then we have a bunch of people buying our software and then they need to be able to sort of skin it as mega bank corpse, you know, sort of brand colors and stuff like that. So all to say by sort of having this design token layer, that's kind of managed as its own thing.

You're able to sort of like keep those definitions kind of like nice and tidy without necessarily touching the components at all Right? They they, like, move it independent tracks. They could be independently Vercel, so you get it. And and what we do is we we train our clients, like, here's the brand people. Here's the marketing department. We, like, say, here's the mix and match exercise. You all do this and create your theme.

We'll be over here working on making the accordion. Yeah. Right? Like, these are these are kind of 2 separate concerns.

They're 2 separate layers.

But yeah. So that was a little meandering of of of a No. That was good. Pnpm, like, it's design tokens are these sort of brand definitions.

Right? They define the border radius, the colors, the font families, the the the type scale, all of that stuff. Everything that goes into, like, Wes aesthetic, like, look and feel. And then we pump the result of that into our web components and our Figma libraries in order to give them the specific,

static. What kind of pushback do you get from people when you're trying to implement this? I'm sure that you've come across all kinds of folks being like, this is garbage. This is a bad way to do it. Yeah. And, people are are probably listening to us being like, I want to implement this at our company.

Like, what what's the most common type of pushback you get from people?

Oh, man. I mean, there's so many. I mean, I think I think that there's we'll say, the biggest real challenge, I think, at this stage in the game JS design systems as a concept is I don't wanna say universally understood as a good thing.

It's this one of these things that is like, oh, that's a good idea in theory.

And I think that, like, where a lot of this sort of hesitation comes from is from people going especially on the code side, which is where I live, where it's just like, what? You're gonna be delivering you're gonna you're touching my code. You're touching my code base. Like, you know, like, my we need to Wes need to own literally all of this. So a lot of times, like, we we deal with a lot of IT organizations that are super protective or have, like, very specific ideas around, like, how they wanna sort of build their things. They're using very specific frameworks or very specific tech stacks, and they are often very hesitant, skeptical, if not downright hostile to the idea of, like, some jokers coming in and saying, hey. Yeah. We're gonna create this thing, and you all you need to do is plug this in.

So so there there tends to be a lot of, like, mistrust around that. And that's one of the things that we really tend to do is really kinda come in, try to build that trust, and and also just kinda be, like, way early on in the in in the engagement. We're, like, we don't know what the design system is going to, like, look like just yet if if Node doesn't exist. But, like, here's a bright pink button. Let's just pretend that that is our design system. Let's at least get that pipeline set up so that we can, like, at least sort of get this into your world. You're able to kick the tires. You're able to sort of, like, validate or, you know, put it through the ringer. You Node? Like, we're not we're not precious here. We're not, like, here to, you Node, this isn't our egos. We we just think that these are like good ideas.

And so a lot of it is just kind of like getting this kind of division of labor introduced to organizations who are historically used to owning literally back to what you were saying earlier, like, oh, yeah, I you published a CSS file I match that I get that's what a lot of teams are like comfortable with But now we're, like, wait a minute. Like, you're actually delivering more than that, and I don't know how I feel about that. Yeah. Yeah. So that's that's definitely on the tech Node. That tends to be one of the the common things that we encounter. And then, of course, just like, you know, your garden Sanity, just designers wanting to be creative and that that that that that like, design systems are ultimately concerns. Right? You're basically saying we do it like this, which means that we don't do it like these other ways. Right? And if you really like purple and the brand's color is blue, like, don't know what to tell you, boss.

Yeah. Yeah. What that that's the question I have is, like, what do you do? Like, we're we're working on the syntax website right now, and I wanted to style something that wasn't one of the blessed purples.

I just went out of it. You know? Yeah. And and, like, in a bigger yeah. I'm sorry, Scott.

I didn't hear this is the 1st time hearing about this.

Here. Flipped over at people. But Oh, man. I even gave you Scott and paste buttons for all the trailers, man. Sometimes it just doesn't look good. You know? Like, what do you do when it just doesn't look good? Yeah.

So so the the short answer is have a conversation.

I and I could I could share this I could share this article with I could share I could share this article with you, but we talk a lot about the governance process. We help organizations establish and evolve their governance processes for all of this. But like when push comes to shove, right? Like that the happy path is designers and developers come to the design system to help them build new work, Right? They reach for the component.

They they go to the design system component library and say, I need an accordion.

There's the accordion.

Does it do what I need that accordion to do? Does it open and close? Yeah. Okay. There we go. Good. Happy path. That's that's like the the success story. But if they come to the design system library and they don't see the component they need or they don't see the variant or or they have a specific use case for it or they just straight up, like, yeah, don't like what they see.

What happens? And coming back to the short answer is a conversation is warranted between the team or the person needing or wanting or having a need for something or has a question about something.

And the design system team who is ultimately the ones Scott of governing this. If it's just broken, if that purple isn't the right purple, then you all need to collectively make a decision. It's like, should the purple be updated? Right? If it's a bad idea here, if it's not working in this context, well, maybe it's not working in these other contexts, too.

Or do we need to support multiple things? Or do we just kind of, like does the design system totally relinquish control of that layer? And this all really kinda depends on, like, the makeup, the smarts, the autonomy of the organization. Like, do you have a bunch of really smart product teams who are capable of making the right decisions Vercel you have a bunch of teams that can't be trusted with a butter knife in their hands?

Yeah. That's true. Like, even if you come back to the the example I have is it's not it wasn't the purple straight up, but it was I was using the purple in a gradient and fading it between purple and whatever I Wes. It didn't look good, so I had to to to adjust it. And the answer there is not that we need to add a new Vercel. It's that we need to figure out maybe we need a set of gradients that are reasonable and and and look a little bit better. Yeah. Yeah. And and that that's what that's what I'd recommend is, like, having gradients be part of your token set. That's actually a good idea, I am. Unless you really are just going for, like, a total, yeah, mix and match, like, almost, like, user generated, like, gradient thing. Like, what you what we tend to do with our clients is it's, like,

here's this sanction set that all work. They work from a Sanity standpoint. They work from just like a vibe, standpoint, and then you Yeah. Ship those.

Yeah. This is a this is perfect timing because Wes and I were just supposed to have a a conversation after this about finishing up everything. So if we can establish our our system gradients now as part of this, it'd be great for me. I I had a question about naming things. You'll often hear that, like, naming is is a huge problem. And and and so far in this episode, I've I've heard you reference, like, a ton of different, like, token names for different things. JS, like, naming a massive part of this job, and is it hard? Is it something that you really love, or is it something that you have a system for?

There's there's a lot there. It's hard.

It absolutely critical.

Critical.

Incredibly hard.

Yes. I do love it.

Most people don't love it.

Yeah.

And it's it it really kind of I think this is the kind of systems mentality is that you need to kind of be this, like, weird, pedantic nerd about really small things and having people that sweat that level of detail, you know, like, is really important because that means that everyone else just gets to sort of reap the rewards of that, and they don't have to think about it. Right? That's that's I think design systems and design system teams are like the great place for those kinds of people that just, like, sweat those really minute details over something, right? Like, do you call something small Wes m a l l? Are you writing that in all lowercase? Are you doing s m as, like, an abbreviated thing? Do you do you do s m m d l g x l? Right? Like, do you do that versus spelling it all out? Do you do camel case? Do you do, you know, like all of that stuff? Like, that's the place for those kinds of conversations to happen.

And ultimately, what we've found is that, again, people want just a good experience. Right? When we talk about a good developer experience, it's like, oh, yeah. We've internalized this API language that's used across the entire component library.

So I know to use the term variant consistently, whether I'm reaching for a badge, whether I'm reaching for an alert, whether I'm reaching for a button, they all use this word the same way. And it's it that's the hard work, and that's, like, dare I say like one of my like the biggest one of our team's like biggest pieces of intellectual property is like the specific language that we tend to recommend for our clients because it's like people my my brother, who JS normally sitting next to me, we will have hours long arguments. Yeah.

Over the specific names of a prop effectively. Yeah. But but in doing that, we are we are sort of ultimately creating a better user experience for, like, everyone that's, like, downstream from it. One of the kinda coming back to kind of Figma land.

What's interesting is that these tools are relatively new into the game. The game. Yeah. API naming and stuff like that. Designers designers are used to like layer 73. Yeah. P42 Totally. And like all of a sudden we're like asking them to sort of be like incredibly detailed and nuanced in the architecture of these components.

And that's what back to that kind of broken designer to developer handoff thing.

This isn't just about here's what this component looks like. You're now sort of creating this architecture. You're creating this naming. So our biggest pieces of advice is to really, like, kinda have the designers and developers kinda co located, really just working through the details of that API language together and sweating the small stuff, documenting the hell out of it, getting it out there and making that like a part of your ongoing, like, governance and PR process to make sure that, like, any contributions or evolutions or new components or or new props or variants they come in they're all using language in the same way so incredibly incredibly incredibly difficult work And it kinda comes down to, like, the choosing the right language, but it's also just, like, the governance and the managing the people part of it.

Yeah. And I know we're short on time here, but I do wanna just a quick follow-up there.

What is the best way, in your mind, to document that that language? Not, like, necessarily, like, the established well, not necessarily, like, the component language, but, like Yeah. Those decisions that you've Node. How do you present that to the team and and keep it into a source of truth? Yeah. It's a good that's a good question.

I talked about that, like, 3rd leg of the stool being the reference website. That's like a good place for that kind of language. But also what we tend to do is have kind of a handful of of markdown documents living in our code base that then gets sort of surfaced in storybook, And then you can kind of actually embed storybook inside of your reference website tools.

That that tends to work out pretty Wes. And we're actually now doing some cool stuff where we're we're training AI on our sort of specific code guidelines and structure for design system architecture. And we're able to sort of like have AI sort of blast out new components that use the exact language that we're using and stuff like that. It's really cool.

Wow.

Yeah. Yeah. There's That's good. Fine stuff.

Man, we I don't even think we got, like, 30% of the way through my notes here. And Scott and I don't even have a lot of notes before people come on, so that's that's saying something. And I said I wasn't gonna ask anything, and then I ended up asking a lot. So I just couldn't help myself. I wanted to ask about how you blogged so much, but I I don't think we have time. We'll have to have you back on at some point. But we'll move into the the last section of the show here, which is our supper club questions.

Curious which, computer, mouse and keyboard you're using?

Your standard issue Mac keyboard, Logitech MX Master 3 Beautiful. And just the Mac MacBook Air.

MacBook Air. Nice. Beautiful. I have some special questions for you. I do you do, like, any systems, like, reading about systems design? I'm sure you do. But if you do, like, what what are some resources that you, would recommend for that type of thinking?

Thinking in systems is right there right there in your question, by Danella Meadows.

That's that's like it's beautiful because it just, like, gets into just systems in kind of in the abstract, but with, like, a lot of real world examples, but getting into things like economies and and stuff like that. But it's it's so beautifully articulated that it, like, applies to really, like, low level stuff. Like, we're talking about, like, a design token system. It's like the same sort of concepts apply to these, like, massive things. So it's like the the word design system, right? Like that that word is important.

It's not just like hot air. It's Yeah. This is this, like, interconnected kind of hierarchy. This is it all sort of influences one another. There's, like, feedback loops. There's all this good stuff. So yeah, that's a, it's a great book. I would recommend that book to, to literally anyone, whether or not you're doing, this stuff. It it really helped me better understand how the world works.

Yeah. Cool. Yeah. Another question I have is is not on our regular supper club questions, but I'm curious, what CSS features that are, like, either new or upcoming. There's a lot going on in CSS world right now. Which ones are you specifically excited about?

Pertaining to design systems, I think that container queries, it's it's you don't get much more, like, hand glove than that. Right? The the idea of, like, being able to create a bunch of components in the abstract that just kind of, like, are their own little worlds, and then you're able to plug them into any arbitrary page layout or grid system or whatever, and they'll just work. It's like, that's massive. I mean, like, that's that's absolutely huge. And, you know, Miriam, Suzanne, and and, like, just hearing Wes of her talks and stuff at a at a conference where you're speaking at. It's like it's still, like, style queries and, like, oh, there's just, like, so much. But I'd say that that that was, like, that was the huge one. That whenever that sort of went over the theoretical line into, like, oh, this is actually happening. And I was, like, that was so big. But also just, man, like, so Sanity yeah. The the ESLint stuff. Really all, like, the stuff that you would want Sass to do. The anytime that that sort of native CSS chipping away at Sass's features.

It makes me feel good. Like because we Yarn. We're, like, getting to a point. And, obviously, I'm, like, enthusiastic about, like, web components and stuff. Wes we're, like, getting to a point where, like, just native web technology.

Oh, yeah. I'm from, like, the school of Zelman. You know what I mean? Like, so the more that, like, we're able to, like, just build things to standards, it's like, that's bet on the future because all these frameworks come and go. Every, you know, tech stack, CMS comes and goes.

So it's like, what is going to stand the test of time? That's the stuff that I get really excited about. It's like it's it's really it's less about, like like, theoretical or, like, you know, makes me feel good to be this. It's I think a lot it is now a matter of pragmatism.

I think if it JS, like, the same way as, like, solar panels used to be. It's like, oh, yeah. Like, you're an environmentalist, and now it's just, like, literally just crunch the numbers.

Yeah. Solar panels are a good idea.

Yeah. Right. Yeah. Seriously. Standards Yarn good ideas.

Nice.

I know you're a big music guy. What's, what's one of your favorite albums right now?

Oh my gosh.

Give me a few if you want. Doesn't matter.

How much time? Yeah. Yeah.

I'll I'll say an artist that we we really like, we've been listening to a lot of Rubble Bucket. If you're familiar with Rubble Bucket.

The dog that has, like, a a little, thing on his back. Yeah. Yeah. Dog? Round saving the world.

Rubble rubble bucket check out rubble bucket they're great a great band it's like barry sax sort of like front woman 2 trumpets but like it's like good art rock. It's like as close to like talking heads as like modern music can get. So, yeah, they're really great. The other big thing, though, if if you don't mind me plugging, I'm putting together, like, this, like, really big show next year. I'm coming up on my 40th birthday, and I'm, like, 1 I'm, like, swinging for the fences. So in Pittsburgh, I'm getting, like, a bunch of musicians.

A lot of them Wes people, people we all Node. Chris Coir,

Dan Rupert,

Dan Mull, other people, we're all gonna play music, and we're gonna fill up this venue in in Pittsburgh, this this old converted church, which is really, really cool.

And, we're doing a big charity show, and we have a whole year to plan this single show.

And I'm like, oh, wow. So so from a music perspective, we're like lay lay on your song requests and stuff like that, but it's like it's gonna be like a a party to end all parties. It's a concert to end all concerts. So Frostapalooza? Frostapalooza.

No. It's probably the nature that's linked up. That's amazing.

2024.

Oh my god. But, yeah, if you wanna hear what what my musical tastes are Yeah. That's the best way to do that. Oh, cool.

Awesome. So last thing we have here is a sick pick and a shameless plug. A sick pick is a you pick something that is sick. Literally can be anything. Could be a charcoal Yarn. Can be a little gadget that you've been using. Could be a

outlook on life.

An outlook on life.

I'm going with outlook.

Outlook on life JS as you should.

You're you're selling yourself short and you can, you could do Node, Do do whatever you want with your life. There's no real constraints to your life besides your own imagination.

That is that is my sick pick. That's deep. I love it. Man, we need to add that question to everybody. Give us your Yeah. Life. I like that.

And shameless plug, what would you like to plug to everybody?

I I think I just did.

Russell Russell. No. I No. I mean, shameless that you should come to that, and that's gonna be awesome, but if I I could do another one, like, if we obviously talked about, like, the gory details of all this, like, design system stuff, it's hard, it's complicated and stuff. So shameless plug, like, if you your organization needs help with that, the technical architecture, the design architecture, but also the people, process, all that stuff, you could hire us at at bigmedium.

It's a bigmedium.com.

And you could also get to it from my site, bradfrost.com, where I'm, like, writing about all this stuff. So it's

amazing.

Brad, we'll have to have you on again, man. This has been incredible. Yeah. Yeah. It's super super amazing. I love talking with you guys, and and, yeah, I love talking. Yeah. Sweet. Well, thanks so much for coming on. We'll catch you later.