Design Systems with Brad Frost

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax, the podcast with the tastiest web development trees out there. Today, we have a special guest on the podcast, mister Brad Ross, 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. Syntex is presented by Sentry.

If you're shipping software And users are using it, you wanna make sure that you have a handle on your bugs before your users hit them. Not only does Sentry give you access to finding and fixing all of those bugs, but they also give you incredibly useful tools like session replay, test coverage, performance metrics, And tons more. So head on over to century.i0.

Use the coupon code tasty treat, all lowercase, all one word, and you'll get 2 months for free. 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 are, where you're from, what you do, all that good stuff. My my website being a

sort of a calling card is a is a point of pride. The one time I was at The the dog park. 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, yes. I am. I am the guy with the orange website. So Is it orange? I always I I was gonna say, 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 sort of, like I I have, like, a Long standing brand palette that has worked quite well for me over the years.

But, anyways yeah. How did you develop that that brand palette? Is that, like,

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

Oh, yeah. I can see it now. Yeah. Oh, yeah. It's totally worth it. 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 brown? Yeah. So so I do like like you said, I do a lot around, design systems, and, I've been Writing, blogging, about the web, making websites for since 2007, and so I've been sort of On a few different rodeos, it kinda started, kinda maybe coming into prominence a little bit through the whole responsive era. I I happen to be working at an agency right whenever the sort of smartphone bomb went off, and it was like, okay. What do we do with this? And so that so I kinda started piecing that together.

And sorta 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 no. No. No. How do we convert this navigation Mhmm. 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 sorta cast of characters. And what we do As we sort of jump into a bunch of big organizations working with design and development teams to actually help So to implement and evolve design systems and stuff. So that gets into all the technical architecture side of things, which is what I tend to sorta hang out Du and my team sorta helps, you know, build component libraries and integrate component libraries into products and sorta 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 listening to this. That's That's not the hard part about the site system. So so, yeah, so that's what I've spent the last decade doing and and sort of, Through that work, sort 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 Kinda 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 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 are 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. And I'm based in Pittsburgh. Yeah. I'm 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, 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 a 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 blind 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 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, wheeled 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 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 that Don't pertain to user interfaces. So so I kind of sort of narrow the focus to that.

There's kinda 3 Main assets, 3 legs of the stool from, from, what a design system, sort of constituent parts are. 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 organization. Not one product necessarily. Right? A lot of times we're we're working with organizations that have Dozens, hundreds, thousands 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 Yeah. Org.

So design library, one leg of the stool.

A code library that is a corollary to the design library, and then kind of a reference website, documentation that sort of brings it all together. Right? So something like material.ioorpolaris.shopify.comorcarbondesignsystem.com.

Right? This 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 CMSs, many different blah.

Yeah. 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 I kinda call that the the front of the front end code. Right? HTML, CSS, Presentational JavaScript.

No logic, no nothing. Mhmm. Just just strictly that. And that concept alone, Whenever we introduce that to our clients organizations are 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, one is 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. 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, one for mobile, one for desktop, top 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 And closer to representing the box model, 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 gets get thrown over the fence to development. So what's interesting in the world of design systems is that There's an opportunity to kind of reframe it, and this is what we help our clients do is 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 home 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. Mhmm. I'm I'm curious about, 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 apps built in React, and they've got a marketing site in WordPress and a store running on Shopify.

How do you get, like, Let's say you have a card 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 is, 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 was in it? Button and some text.

Yeah. All right. Card, avatar, button, text.

What we tend to call that is a recipe that might not live in this sort of basement level design system. It's composed of all of those basement level design system things. Right? Yeah. But 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 One button, or we need a subheading in addition to that, and that's where those kinda 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. Okay. 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 Yeah. And 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 is 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 that? Is that CSS built baked into that web component so it's it's scope 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 dist folder

is, like, The CSS that is like effectively just a handful of of, CSS custom properties. Right? That That is what's sort of flowing through the web components to give it the specific look and feel. Yeah. 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? Yeah. But that's the stuff that That penetrates through the shadow Dom.

So what it looks like in practice, if you just have like index dot HTML, you're linking up The design system CSS file and 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, d s dash. Alright. Design system dash button Yep. Variant equals primary, and then, pah. Right? That gets you the the desired, like, look and feel.

So So that's like it at its, like, most basic 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 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 you kinda 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 web 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. It kinda be be sort of hitting up against those kind of rougher edges, but things have definitely, like, stabilized a lot. Mhmm.

But ultimately, like, these things are their own little islands.

They operate in a lot of ways similar to how 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 kinda reach into The shadow dom and just kinda hacked the crap out of things.

Yeah.

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 com 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.

Yeah. So, like, the ergonomics are there for people used to working in certain frameworks.

It also helps Still sorta like normalize API stuff. Like, one of the main things that we tend to encounter when we work with clients is From component to component, right, the button component was created first and uses specific language, and then People get lazy or junior developer kinda 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, Angular layer, whatever layer, is that you're able to sort of, like, Have it be this pass through, but also kinda 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. Yeah. 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, is 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's 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 sanely.

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. Oh, god. Yeah.

I I feel I wish I had, like, literally all of my clients with me. Like, Just let 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.min.

CSS and the heavier document match these classes. You're good to go. Right? A lot of these things then require, A certain 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 there's that just introduces so much room for error And especially whenever you're talking about, let's just say you've got a bunch of react apps, you got a bunch of angular apps, and you got a bunch of view 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 you're 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 Yeah. Nugget, as a little bundle that you just sort of get for free. And if changes happen, well, you bump the version, you pull in the latest version, These those people maintaining those Vue and Angular and React libraries don't need to do any work aside from just bumping a version, and they get Whatever accessibility updates I was gonna say Oh, whoops. We changed these things in the DOM. Like, it's just way more direct of a delivery Kind of vehicle forefront of the front end code. That's beautiful.

That's very well put. I was going to say, not to mention, like, Trusting 3 teams to accessibly implement the same thing exactly the same way or sometimes like

No. It's Oh. It's awful.

Wes, I've told you about this before. When I worked at Ford, we we We're 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 was a tremendous nightmare, and most of it never ended up shipping because of that.

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 start up web app need to worry about having a system like this?

My answer There 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 just 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 dot HTML and about dot HTML.

And, oh, we need that Header, we need that footer. We're gonna have, like, the same kind of stuff on here. So, you know, historically, whether that's what PHP He 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 Wise organizations because in order to build the homepage, well, I need the hero. I need those 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 and 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 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, sort of workflows.

You could call that a design system again, like You don't need to make something that's as, 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 in in in, 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 is, 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 kinda 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 gotta sort of start Simple. And then sort of grow and introduce that complexity only when it it 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.

Thank you. How do design tokens come into play here? 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, 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 the flavor. But they're effectively these, like, really low level brand Attributes.

Right? Their their brand definitions. You know? Here's a brand orange. Here's a brand cream. Here's a brand brown. Right? For my own Yeah. For my own personal website. There we go. So that's my brand palette. Right? But 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, for instance. Right? So, like, iOS apps, Android apps, these things aren't using web components, but they can consume the design tokens and get Starbucks green. If, you know, Starbucks green needs to be Starbucks green, whether you're on their Android app, their Ios 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 are like, here's the single place you define where Starbucks green, what it is.

And then there there can be a a second 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 kinda dumb definition, this this interface agnostic definition of what this Starbucks screen is, And then we can start mapping this as, like, a little sort of mix and match kind of exercise, where it's like, oh, okay.

Brand background, we're going to map Starbucks green to that.

Error, or or 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, draw an arrow from that sort of Tier one definition.

So it's just, like, basically, like, mixing and matching these these, these variables together and sort 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 scale Then our, you know, dashboard back end systems that don't need big jumbo 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 we 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 independent tracks. They could be independently versioned, 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 work. Right? Like, these are these are kinda 2 separate concerns.

They're 2 separate layers.

But yeah. So That was a little meandering of of of a of an answer, but, 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, an 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 the bad way to do it. And people are are probably listening to us being like, I want to implement this at our company.

Like, 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 is 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, wait.

You're gonna be delivering.

You're gonna you're touching my code? You're touching my code base? Like, you know, like, I'm not no. No. No. Like, we need to we 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, trust 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 one 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 sorta get this into your world. You're able to kick the tires. You're able to sort of, like, validate or, you know, kinda, You know, put it through the ringer. You know? Like, we're not we're not precious here. We're not, like, here to you know? 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 own it literally.

Back to what you were saying earlier. Like, oh, yeah.

I you published a CSS file. Yeah. I matched that. Like, that 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.

So that's the that's definitely on the tech side that tends to be one of the the common things that we encounter.

And then, of course, just like, you know, your garden variety, just Designers wanting to be creative and like, design systems are ultimately constraints. 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. But that that was the question I have. It's like, what do you do? Like, we're we're working on the syntax website right now, And I wanted to style something Mhmm. That wasn't one of the blessed purples.

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

I didn't hit this the 1st time here, buddy. This.

Look over your table.

Oh, man. I even gave you copy and paste buttons for all the colors, man. Sometimes it just doesn't look good. You know? Like, what do you do when it just doesn't look Good. The the short answer is

have a conversation.

Oh, sorry, Scott. You bailed.

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 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? 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 sort 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? Yeah. 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 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 We're capable of making the right decisions versus you have a bunch of teams that can't be trusted with a butter knife Yeah, that's true. Like,

even if you come back to 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 was. 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 purple. 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. Yeah. And and that that's what that's what I'd recommend is, like, having gradients be part of your token set.

Just just the same as your 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 stability standpoint. They work From just, like, a vibe,

standpoint, and then you ship those. Yeah. This is a this is a perfect timing because Les and I were just supposed to have a a conversation after this about, finish 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 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. Is, 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. Oh, yeah. It absolutely critical.

Incredibly hard.

Yes. I do love it.

Most people don't love it, and it's it it really kind of I think this is the the kind of systems mentality is that you need to kinda 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, s 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 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, 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 as because it's, like, my my brother who who is 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 kinda Figma land, What's interesting is that these tools are relatively new into the game the game API naming and stuff like that. Designers Designers are used to, like, layer 73, copy 42.

Totally. And, like, all of a sudden, we're, like, asking them to sort of be, like, incredibly detailed and nuanced in the Incredibly detailed and nuanced in the architecture of these components, and that's what back to that kind of broken designer to developer hand off 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 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 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 It weighed your mind to document that that language, not, like, necessarily, like, the established well, not necessarily, like, the component language, but, like, Those decisions that you've made, 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 kinda 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, like, actually embed storybook inside of your reference website tools.

That that tends to work out pretty well, 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 quick. It is fun stuff.

Man, we I don't even think we got, like, 30% of the way through my notes here. And Scott and 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 because I I just can't help myself.

I I wanted to ask about how you blog so much, but I don't think we have time. We'll have to have you back on at some point, but we'll move into 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.

Guy And just the Mac MacBook Air.

MacBook Air. Beautiful.

Yeah. I 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, In my opinion and let me just, like, make sure that I'm, like, getting yeah. Thinking in systems a primer.

Cool. Got it. That's the yeah. Donella Meadows, and that is That is 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 like this is this, like, interconnected kind of hierarchy. This is it 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 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.

Cool.

Another question I have, this is not Regular supper club questions, but I'm curious what CSS features that are, like, either new or 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 in glove than Yeah. Right? Yeah. 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 one 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 happening. That was, like, that was so big.

But also just, man, like, so many yeah. The the nesting stuff, really all, like, the stuff that you would want Sass to do that anytime that that sort of native CSS chipping away at Sass's feature set, It it makes me feel good. Like because we are we're, like, getting to a point, and, obviously, I'm, like, enthusiastic about, like, web components and stuff. Or we're, like, getting to a point where, like, Just native web technology.

Oh, yeah. I'm from, like, the school of Zeldman. You know what I mean? Like, so the more that, Like, we're able to, like, just build things, do standards.

It's like, that's a bet on the future because all of 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, it makes me feel good to be this. It's I think It is now a matter of pragmatism.

I think of it as, 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. Yeah. Solar panels are a good idea. Yeah. Right. Yeah. Seriously. Standards are good ideas.

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.

I'll I'll say an artist that we we really like.

I've been, we've been listening to a lot of Rubble Bucket.

If you're familiar with Rubble The bucket.

The dog. Like that. It has, like, a a little, thing on his back. Yeah. Yeah. He runs around saving the world.

Rubble? The no. You talking about was done? Oh, pop, not pop, not pop, not pop.

Not.

Oh, pop. Rubble bucket. Okay.

No. Rubble rubble bucket. Check out rubble bucket. They're great. A great band. It's like Barry Sachs, So they're, like, front woman, 2 trumpets, but, like, it it's, like, good art rock. It's it's, like, as close to, like, talking heads As modern music can get. So they're 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 web people, people we all know, Chris Coir Oh, so David 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, like, a big charity show, and we have, like, a whole year to plan this single show. -Wow. -And I'm like, I'll in on it. 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, a concert to end all concerts. So Frost a palooza? Frost a palooza.

Nice. I'm gonna make sure that's linked out to the menu. 17th 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. An outlook on life. I'm going with Take outlook on life as as you should.

You're you're selling yourself short, and you can you could do more.

Do do whatever you want with your life. There is nobody telling 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. Yeah. We need to we need to add that question to everybody. Give us your Yeah. I felt like I felt like that. And Shameless Plug, what would you like to plug to everybody? I I think I just said that.

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 big medium. It's a big medium .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. Super super Yeah. This is a lot of fun. I I love talking with you guys, and and, yeah, I love talking. Hey. Well, thanks so much for coming on. We'll catch you later. Peace.

Head on over to syntax.fm for a full archive of all of our shows.

And don't forget to subscribe in your podcast player or drop a review if you like this show.