0:00

Hey, what's up? This is Scott from

0:02

syntax. Now that we're on YouTube and

0:04

approaching 800 episodes, we

0:06

wanted to release some of the

0:08

very best interviews that we've done

0:10

on syntax. So please enjoy one

0:12

of our favorite episodes. Welcome

0:20

to syntax. The podcast with

0:22

the tastiest web development trees

0:24

out there. Today we have

0:26

a special guest on the

0:28

podcast. Mr. Brad Frost. Brad

0:30

is author of Atomic Design,

0:33

design system consultant, web developer, CSS

0:35

thought leader. I'm sure he doesn't

0:37

like that last one. All kinds

0:39

of stuff around building design systems

0:41

and building stuff for the web.

0:43

Welcome, Brad. Thanks for coming on.

0:45

Yeah, thank you so much for

0:47

having me. This is awesome. And

0:49

if you want to see all of

0:52

the errors in your application, you'll want

0:54

to check out century at century dot

0:56

IO/syntax. You don't want a production application

0:58

out there that well, you have no

1:00

visibility into in case something is blowing

1:02

up and you might not even know

1:04

it. So head on over to century

1:07

dot IO/syntax. Again, we've been using this

1:09

tool for a long time and it

1:11

totally rules. All right, Wes.

1:13

Let's let's start like just tell

1:15

I'm sure that literally

1:18

everybody has probably stumbled upon

1:20

your website at some point.

1:23

If you just go to Brad's website, you

1:26

probably go, oh yeah, I remember this website.

1:28

But if people don't

1:30

know who you are, give us a rundown

1:32

of who you are, who you are, where

1:34

you're from, what you do, all that good

1:36

stuff. Yeah. My website being a sort

1:39

of a calling card is a

1:41

point of pride that one time I was at the

1:44

dog park and was talking. I

1:46

was talking with somebody that's talking

1:48

with somebody and and so,

1:50

you know, got into, oh, what do you do?

1:52

And I'm a web designer and started

1:54

talking about what they what they got into. And

1:57

then they said, well, what do you do? And

1:59

I said, oh, I'm Web designer too

2:01

and started explaining a little bit more

2:03

and they use because you the guy

2:05

with the orange website and I was

2:07

like Yes, I

2:09

am I am the guy with the

2:11

orange website. So Orange

2:14

I always I was gonna say I almost introduced

2:16

you as the guy with the brown website It's

2:18

like it's like it's like cream brown and orange

2:21

as they're like by sort of like I

2:23

have like a long-standing brand

2:26

palette that is Worked quite

2:28

well for me How

2:31

did you develop that that Brian palette is that

2:33

like a just like your favorite

2:36

colors or like I my vibe is

2:38

whole like 1970s

2:41

like I was like born in the

2:43

wrong era like yeah Yeah,

2:49

well besides having a brown website

2:51

what else What

2:54

do you put on this brown website? What

2:56

do I put on this problem? Yeah, so

2:58

so I do like you said I

3:00

do a lot around design systems

3:03

and I've been writing blogging

3:05

about the web making websites

3:08

for since 2007

3:11

and so been sort of On

3:14

a few different rodeos kind of started

3:17

Kind of maybe coming into prominence a

3:19

little bit through the whole responsive era

3:21

I happen to be working at an

3:24

agency right whenever the sort of smartphone

3:27

Bomb went off and I was like, okay, what do

3:29

we do with this? And so that's so I kind

3:32

of started piecing that

3:34

together and sort of through

3:36

that responsive design work is what sort of

3:39

ultimately kind of Evolved

3:41

into working with design systems

3:43

because in a lot

3:46

of cases what we learned is oh, yeah

3:48

It's not that making a whole page Responsive

3:52

is the hard part. It's no no. No,

3:54

how do we convert this navigation? Thing

3:57

to you know something

3:59

that's more conducive for small screens, large

4:01

screens and everything in between. But anyway, so

4:05

kind of came up through the agency world, but for

4:07

the last decade, I've been on my own,

4:10

but also partnered

4:12

and I am a principal and

4:15

design system consultant with an agency

4:17

called Big Medium, with

4:19

my partner, Josh Clark, my brother

4:21

Ian, and a whole

4:24

other sort of cast of characters. And

4:26

what we do is we sort of

4:28

jump into a bunch of big organizations

4:30

working with design and development teams to

4:33

actually help sort of implement and evolve

4:35

design systems and stuff. So that gets into

4:37

all the technical architecture side of things, which

4:40

is what I tend to sort of hang

4:42

out and do. And my team sort of

4:44

helps build component libraries and

4:46

integrate component libraries into products and sort

4:48

of make it all go. But then

4:51

it also, of course, gets into all of the

4:54

the people and the process and the culture

4:56

and the organizational kind of stuff. And that's

4:59

the real fun and

5:01

the real challenge of doing

5:03

design system stuff. Like anybody can

5:05

make a button, right? Anybody listening

5:07

to this, that's not the hard

5:10

part about design. So yeah, so

5:13

that's what I spent the last decade

5:15

doing and sort of through

5:17

that work, sort of helping organizations

5:20

build these things sort

5:22

of came up with this methodology

5:24

called Atomic Design that

5:26

sort of helps connect the

5:29

design systems that we're creating to the

5:31

real products that those design systems are

5:33

serving and sort of kind of setting

5:36

up this kind of virtuous cycle between,

5:38

you know, yeah, if your marketing website

5:40

has big old heroes and chunky cards

5:42

and newsletter signup things, well, guess what?

5:45

Your design system needs to account for,

5:47

right? It needs to account for exactly

5:49

those things. So yeah, so

5:51

it's been a fun journey and the

5:54

fun part about doing consulting

5:57

and plugging, you know, ducking my head into

5:59

all of these. different organizations is

6:01

that we get to see many,

6:03

many, many different flavors

6:06

of the same thing, right? Sort

6:08

of different patterns or different sort

6:10

of weird left turns or different

6:12

frustrations that all ultimately

6:14

sort of feeds what I

6:17

talk about and write about and think about. Beautiful.

6:20

Yeah, I'm based in Pittsburgh, but you

6:22

know, internet. Oh, yeah.

6:25

Right on. Let's think at

6:27

that direction about design systems. We'll

6:30

talk about both like holistically,

6:32

like, because I know that like

6:34

a design system takes both a

6:37

lot of work, both in terms of planning

6:39

and figuring out how to approach something but

6:41

also from like a technical implementation as well.

6:43

Like how do you how do you do

6:45

that? How do you make a button look the same across a 20,000 developer

6:49

organization? So you want to give us like

6:51

a rundown of first

6:53

of all, people listening might not even know what

6:55

is a design system. And then

6:57

we'll go into maybe some of the tech behind it.

7:00

Yeah, that's a great place to start because

7:02

that's kind of the million dollar question. And,

7:05

you know, if you were to ask a

7:08

bunch of people who work in our world

7:10

to define what a design system is, you're

7:12

going to get a lot of different answers. It's

7:15

a bit of like the parable of

7:17

the blind men and the elephant, right,

7:20

where blind men approach the elephant and

7:22

somebody's touching the trunk and they're like, Oh, it's

7:25

like a snake and somebody's touching the leg. It's

7:27

like, oh, it's like a tree. And it's like,

7:30

so there's all these different sort

7:32

of facets and assets to a

7:34

design system. But sort of

7:37

the umbrella that I tend to put things

7:39

under is that a design system is the

7:41

official story of how an

7:44

organization designs and builds user

7:46

interfaces. And that's

7:48

kind of intentionally vague, right?

7:50

There's a lot of ingredients that go into

7:52

that story. But at the

7:54

same time, like that's that's kind of ultimately what

7:57

you're trying to do is, you

7:59

know, here is how we

8:03

wield accordions or form fields. Here's

8:06

the things that we care about. Here's how

8:08

we construct an architect and

8:12

build and implement user interfaces.

8:15

And sort of specifically user interfaces.

8:17

Not necessarily digital products because there's

8:19

all these other things that go

8:21

into making a digital product work,

8:23

as you know, that don't

8:25

pertain to user interfaces. So I kind

8:27

of sort of narrow the focus to

8:30

that. There's kind

8:32

of three main assets,

8:35

three legs of a stool from

8:37

a, what a

8:39

design system, sort of constituent

8:41

parts are. It's a

8:44

design librarian, something increasingly Figma,

8:46

right, Figma library containing your

8:48

common components. And this is

8:50

important here. Common components

8:52

that are meant to work across

8:55

an entire organization. Not one product

8:57

necessarily, right? A lot of times

9:00

we're working with organizations that have

9:02

dozens, hundreds, thousands of

9:04

different websites and apps that are in there. So

9:08

the design system is really the

9:10

foundational level, which is like, here's

9:12

where truly shared things go. And

9:16

that's an important sort of qualifying characteristic

9:18

of this because there's lots of other

9:21

things that can exist

9:23

in like a layer cake format that

9:25

we could talk about in a bit that

9:28

aren't truly sort of scalable to the

9:30

whole board. So design

9:32

library, one leg of the school, a

9:34

code library that is a corollary

9:37

to the design library. And

9:40

then kind of a reference website, some documentation

9:42

that sort of brings it all together, right,

9:44

so something like material.io

9:47

or Polaris.shopify.com or carbondesignsystem.com, right? That

9:49

just kind of brings it all

9:51

together, puts a bow on it,

9:54

helps sort of frame it, contextualize

9:56

it and sort of teach

9:58

people how to use it. properly. So

10:01

those are the kind of like three assets, three

10:04

core assets of a

10:06

design system. And on

10:08

the code end, specifically, increasingly for

10:10

the last like four, going on

10:13

five years now, we have been

10:15

increasingly reaching for web components to

10:18

help author and deliver

10:21

design systems to the, again,

10:23

dozens, hundreds or thousands of

10:25

applications. Many, many, many different

10:27

tech stacks, many different

10:29

implementations, many different frameworks, many different

10:32

CMSs, many different blah, blah. But

10:35

at the end of the day, when you

10:37

talk about what a design system is, it's

10:39

like delivering the kind of like, dumb presentation,

10:43

basic functionality of

10:46

these sort of reusable components, right?

10:48

The button, you pull in the

10:50

button web component, boom, there you

10:53

go. There's your branded buttons, pull

10:56

in the design systems accordion component, you

10:58

click on it, guess what happens? It

11:00

opens, right? You click on it again,

11:03

guess what happens? It closes. So it's

11:05

like, it's that level that we're

11:07

talking about with design systems. We're

11:09

not talking about wiring this up

11:11

to sort of, you know, back

11:14

end services or API's or anything

11:16

like that. It's kind of strictly

11:18

the sort of presentation, the thing

11:20

that the users see, we kind

11:22

of call that the front of

11:24

the front end code, right? HTML,

11:27

CSS, presentational JavaScript, no

11:29

logic, no nothing, just

11:31

strictly that. And that concept

11:33

alone, whenever we introduce

11:36

that to our clients organizations, or like

11:38

it would help them sort of unpack

11:40

that it's, it's,

11:42

it's not something that a lot

11:44

of people outside of our little

11:47

circles, I think really understand. Nice.

11:50

You mentioned like, it

11:52

is a part of the different layers, you know, being a

11:55

design component and a code

11:57

component to these layers. But I think

12:00

I think one of the things that people hit

12:02

is keeping some of that stuff

12:04

in sync. Do

12:06

you think that there, like

12:08

one is, is there a more unified

12:10

way to connect the design

12:13

in the code aspects and is that even

12:16

like a good idea to have those like

12:18

deeply connected? That's a damn good

12:20

question. And yeah, like we've

12:22

seen generations now of

12:26

trying to solve this problem, going

12:28

all the way back to Dreamweaver

12:30

days, right? And WYSIWYG days and

12:32

stuff like this, and PSD

12:34

to HTML just like hit the,

12:37

yeah, probably like giving shivers

12:39

to some people listening. But

12:42

it's like, yeah, these

12:44

tools are getting closer together at

12:46

the end of the day, they are

12:49

different worlds, right? Like Figma, it's

12:51

a blank canvas. You could just drag

12:53

things around arbitrarily. You could have these

12:56

different art boards, one for mobile,

12:58

one for desktop and whatever. And you could

13:00

just go, oh yeah, I'm just moving that

13:02

from here to here in

13:04

free space, which is obviously not how

13:06

things work in the browser. So

13:09

it's challenging

13:11

because especially in like

13:13

the Figma world, it's like gotten good. It's

13:15

gotten a lot better at sort

13:18

of in closer to

13:20

representing the box model, basic

13:23

things like, auto layout and sort

13:25

of stretching things to better behave

13:27

like the browser. But at the

13:29

same time, like it isn't. It's

13:32

this kind of like very

13:34

narrow band of what

13:37

goes into UI as you all

13:39

know, right? There's many,

13:41

many, many different capabilities

13:44

that these browsers can do that I

13:46

do not get reflected in these static

13:49

design tools. And yeah, you can, there

13:51

are prototyping tools and there's stuff like

13:53

that, but those are all approximations, right?

13:55

So you don't get performance.

14:00

layout and jankiness Right loading of

14:02

like these big hero images like

14:04

all of that stuff interact a

14:06

true interactivity and stuff like that

14:09

That's the user experience right like

14:11

that is the UI and

14:14

so yeah, it's long been

14:16

a a you know

14:18

soapbox of mind of like the

14:20

whole sort of designer developer workflow

14:22

and how Broken it

14:25

tends to be especially whenever sort of

14:27

things originate in

14:30

Design and then gets to get thrown

14:32

over the fence to development. So what's

14:34

interesting in the world of design systems

14:36

is That there's

14:39

an opportunity to kind of reframe it. This is

14:41

what we help our clients do is that What's

14:44

in a design system figma library?

14:48

Isn't so much like a

14:50

spec for developers to like build it out

14:52

what what this? Figma library

14:54

is is kind of a promise What's

14:58

in code right? It is a

15:01

representation of what exists in the

15:03

coded design system Which means that

15:05

downstream product designers are able to

15:07

sort of reach for these things

15:10

Drag their form controls onto a page

15:12

drag their button group onto a page

15:15

drag their different cards onto a page

15:17

and know With

15:19

a with a greater degree of certainty

15:21

that that oh, yeah, this can be

15:24

built, right? So it's

15:26

it's a little bit different than the normal

15:28

design process where it's like I'm gonna

15:31

Blue sky, you know create this new funky

15:33

home page and then sort of give it to

15:35

my developers to build out It's

15:37

a little bit the coded

15:40

design system library Truly

15:42

is the source of truth and then

15:45

the figma library is this kind of

15:47

abstraction of that it allows designers to

15:49

do their thing Hmm I'm

15:52

curious about like like what does it actually

15:54

look like when you put it in a

15:56

developer's hand? So you said like web components,

15:58

but like I'm imagining a big company,

16:01

their main apps built in

16:03

React, and they've got a marketing

16:06

site in WordPress and a store

16:08

running on Shopify. How do

16:10

you get like, let's say you

16:12

have a card, and that

16:14

card has an avatar inside

16:16

of it and a button

16:18

and some text, how do

16:20

you get that to look

16:22

the same across all of

16:24

the different websites? Yeah, so

16:26

we actually just published 5500

16:28

words, I think is what it ended up

16:31

being, but it's kind of in

16:33

answer to that question, which is like, here

16:36

literally is the entire ecosystem of

16:38

like, the different layers of this

16:41

layer cake and how you get

16:43

these sort of web

16:45

components that live at the sort of

16:47

basement layer in the design system, ultimately

16:50

into products, right? And

16:53

a lot of these, the

16:55

answer to your question is really like,

16:57

of course, like most things web design

16:59

and development is like, it depends. Some

17:03

of the ways that we accomplish this

17:06

if you have a card with

17:08

an avatar, what else was in it? A

17:11

button and some text. Yeah. All

17:13

right, card, avatar, button,

17:15

text, what we tend to call that

17:18

is a recipe that

17:20

might not live in the sort

17:23

of basement level design system, it's

17:25

composed of all of those

17:27

basement level design system things, right? Yeah,

17:30

this is where things get tricky,

17:32

because like, whenever you deliver something

17:35

that that's that composed in your

17:37

design system, product one

17:40

might be able to use that thing as

17:42

is product two comes along and they say,

17:44

Oh, we actually need two avatars or we

17:46

need a button group instead of just a

17:48

subheading in addition

17:50

to that. And that's where those kind

17:52

of more composable components like cards and

17:54

headers and stuff like that tend to

17:56

fall down. So what we do to

17:58

solve that is is we'll kind of

18:01

like move that into its own layer called

18:03

a recipe layer that allows people to go,

18:05

okay, avatar card is

18:09

its own product specific thing. And

18:12

that thing might be

18:15

React component, right? Like if

18:17

it is for like the flagship React

18:20

app like you're saying. So it's like

18:22

it would import what it would look

18:24

like. It would be like import card,

18:27

avatar heading, text

18:30

passage or whatever you wanna call that thing. And

18:33

button from the design

18:36

systems web component library. But

18:38

then a sort of

18:40

React recipe gets

18:42

born out of that and then it gets ingested

18:46

by the actual application, however

18:48

it sees fit. Alternatively,

18:51

you could make those

18:53

as its own sort of recipe layer, which

18:55

is often like a sibling

18:57

repo in like a mono repo or

18:59

something like that, right? And

19:02

make that in web components. And

19:04

then you can deliver that to

19:06

your React application but also your

19:08

WordPress site. And also I don't

19:11

know about Shopify is in what their ability

19:14

to digest or

19:17

ingest packages and stuff like that is.

19:19

I'm curious and like what about all the CSS

19:22

that comes with that? CSS built it baked

19:24

into that web component. So it's scoped to

19:26

it or do you give them a CSS

19:28

file or do they

19:30

have to import it? Yeah, yeah. So

19:32

when you publish the design systems package,

19:35

what you'll get in like a dist

19:37

folder is like the CSS that is

19:39

like effectively just a

19:42

handful of CSS custom properties, right?

19:44

That is what's sort of flowing

19:47

through the web components

19:49

to give it the specific look and feel.

19:51

And what that does is that unlocks all

19:53

the stuff with like, you know, theme-able design

19:55

systems and supporting multiple brands and white labeling

19:58

and dark mode and the whole nine. But

20:01

that's the stuff that penetrates through the

20:03

Shadow DOM. So what it looks like

20:05

in practice, if you just have like

20:07

index.html, you're linking

20:09

up the design system CSS

20:11

file in the head of your document.

20:14

You're linking up via CDN

20:16

or some package manager, the actual web

20:18

component library. And then whenever in your

20:21

body, then you're able to be like,

20:23

you know, you can just type in

20:25

the CSS dash, design system dash button,

20:29

variant equals primary. And then,

20:31

right, that gets you the desired look

20:33

and feel. So

20:36

that's like it at its most basic in

20:39

like an index.html thing. But

20:41

then, of course, every

20:43

product, every app is architected differently.

20:45

But ultimately, you know,

20:47

we're like leaning on NPM or Yarn

20:50

or whatever to

20:52

pull these things in as dependencies and then

20:54

you're able to import them. And

20:57

then all of these web components are

20:59

rendering out to standard HTML

21:02

elements. So like there's no

21:04

sweat if a React developer wants to

21:06

put custom attributes or props or classes

21:08

or anything. Yeah,

21:10

each of those? Yeah. So this is

21:12

what gets interesting. So there's

21:14

like a couple concepts that are important,

21:16

right? So one is the Shadow DOM,

21:18

right? So it's like you kind of

21:21

have this kind of protected boundary

21:23

around each one of these things.

21:26

They're designed to be their own

21:28

islands, which there's kind of

21:30

pros and cons to all of that.

21:33

There's some challenges around there, especially around

21:35

like if you have like a label

21:37

web component and then a text input

21:39

component, web component, and you need those

21:41

things to talk to each other. That's

21:43

all been kind of like either

21:46

in progress or it has been sorted out

21:48

at the browser level. So it's getting better,

21:50

but the last number of years has been

21:52

fun. Yeah, yeah. It's

21:55

kind of hitting up against those kind

21:57

of rougher edges, but things have definitely

21:59

stabilized. a lot, but

22:01

ultimately, these things

22:04

are their own little islands.

22:07

They operate in a lot of

22:09

ways similar to how a React

22:11

developer would be used to interacting

22:13

with any other React component, but

22:16

different in other ways, especially this kind

22:18

of like, this literally

22:20

has a boundary drawn around it,

22:22

and you can't just go around

22:24

and extend it and just

22:26

kind of reach into the shadow DOM

22:29

and just kind of hack the crap out of

22:31

things. So there's a number of

22:33

interesting things

22:36

that we tend to do. A lot

22:38

of organizations that we work with have

22:41

existing React applications

22:43

and React component libraries

22:45

to power those applications

22:48

and or they have a

22:50

bunch of Angular apps and an

22:52

Angular component library that is sort

22:54

of powering that. And a lot

22:56

of times, like what we'll do is we'll actually kind

22:58

of come in, almost like hollow

23:00

out the guts of those things and

23:03

establish this web sort of

23:05

more basement level web

23:07

component layer, but

23:09

still preserve those like React libraries

23:11

and those Angular libraries, but

23:14

all it is is effectively like

23:16

a pass-through layer. So React developers

23:18

are still able to engage and

23:20

interact with these React components, but

23:22

under the hood, they're ultimately, you

23:25

know, being powered by web components.

23:27

Same deal with the Angular world, right?

23:30

Angular developers can continue using that

23:33

stuff. So like

23:35

the ergonomics are there for people used

23:37

to working in certain frameworks. It

23:40

also helps to sort of like normalize API

23:42

stuff, like one of the main things that

23:44

we tend to encounter when we

23:46

work with clients is from

23:49

component to component, right? The button

23:51

component was created first and uses

23:53

specific language and then people

23:56

get lazy or junior developer kind of came

23:58

in and created a new component. component and

24:00

it's like totally a mess from a

24:02

language perspective. So a lot of the

24:04

times what we do is

24:07

help establish clear API definitions and

24:09

a whole language around your component

24:11

library. But then the cool

24:13

thing with this kind of like intermediary layer

24:15

with like a react layer, angular layer, whatever

24:17

layer is that you're able to sort of

24:19

like have it be this

24:22

pass-through, but also kind of support the

24:24

old API while also introducing the new

24:26

API and sort of like smoothing that

24:28

out under the hood. So

24:30

there's like a lot, there's like a lot

24:32

of weird nuance here. Yeah, but

24:34

at the end of the day, it's like what's

24:37

going on at the end of the day if you

24:40

zoom like way out is this like basement

24:43

level web components getting

24:45

delivered somehow some way

24:48

to real websites and apps that

24:50

people use. Yeah, there

24:52

might be a couple of train stops along

24:54

the way or they might get sort of

24:56

wrapped in sort of various levels

24:59

of smarts or framework

25:01

specific technologies or this recipe layer

25:04

like we're talking about. All

25:06

of that is optional. Yeah, all

25:08

of that like helps make it all

25:11

go more sanely. But

25:13

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

25:17

components powering products now. I think people listening

25:19

right now might be saying like what's the

25:21

benefit of going all in

25:23

a web components for everything instead of

25:25

just delivering some classes and telling people

25:28

hey put this class on your button

25:30

and it'll look like X, Y, and

25:32

Z. Oh God. Yeah. I

25:36

feel I wish I had like literally

25:38

all of my clients with me like

25:40

let me get

25:43

Neo in here to tell you why that's ultimately

25:49

here's the problem. The problem with

25:51

that is that that's you

25:56

can create and this goes all the way back

25:58

to just like bootstrap right like put bootstrap. So

26:00

the headgear.crap.yam.css and the headgear document

26:02

match these classes, you're good to

26:04

go, right? A lot

26:06

of these things then require

26:09

the DOM to be a certain way, right,

26:11

in order for them to work, right? Like

26:13

obviously we try to make classes as modular

26:15

as possible and stuff like that, but a

26:17

lot of times it's like, this

26:20

stuff just falls down, that

26:22

just introduces so much room for error, and

26:24

especially whenever you're talking about, let's just say

26:26

you've got a bunch of React apps, you've

26:28

got a bunch of Angular apps, and you've

26:30

got a bunch of Vue apps. You're

26:33

then requiring three different

26:35

teams to rebuild the same

26:38

accordion logic, right? Again, you click

26:40

on the thing, it opens, you click on

26:42

the thing, it closes. You're

26:45

relying on three different teams to do

26:47

that, get the DOM

26:49

exactly right. If something changes,

26:51

that creates a bunch of

26:53

downstream work for all of

26:55

these sort of framework-specific layers.

26:58

And what we've learned, unfortunately,

27:00

is that front-of-the-front-end code is

27:03

still kind of relegated to

27:05

a second-class citizen. Not a

27:07

lot of people know how to do it

27:10

properly. So by actually,

27:12

the beauty of Web Components is that

27:14

it literally bundles up the

27:17

HTML, the CSS, and

27:19

the JavaScript, as a

27:21

little nugget, as a little

27:23

bundle that you just sort of get for

27:25

free. And if changes happen, while you bump

27:27

the version, you pull in the latest version,

27:30

those people maintaining those Vue and

27:32

Angular and React libraries don't need

27:35

to do any work, aside from

27:37

just bumping the version, and they

27:39

get whatever accessibility updates for free.

27:42

Oh, whoops, we changed these things in the DOM.

27:45

It's just way more direct of

27:48

a delivery kind of

27:50

vehicle for front-of-the-front-end code. Yeah, that's beautiful.

27:52

That's very well put. I was going

27:54

to say, not to mention trusting

27:56

three teams to accessibility.

28:00

It's the same thing exactly the same

28:02

way or sometimes like it's

28:04

all. Yeah.

28:07

I've told you about this before. When

28:10

I worked at Ford, we were given

28:12

the task of building these experimental components

28:15

and we were expected to deliver them

28:17

as a style guide. Our

28:20

style guide was just being presented as

28:23

here's our Angular and CSS code and

28:25

Ford with their 90 different

28:28

markets all used a different back

28:30

end, a different CMS, whatever they

28:32

had. Their front end

28:34

engineers were tasked with re-implementing

28:36

those same components on every single

28:38

one of those 90 CMSs. You

28:42

could just see exactly where the problem is going to

28:44

be there and it was a tremendous nightmare and most

28:47

of it never ended up shipping because of that. Do

28:50

you think that these kind of problems are only

28:52

the types of problems that people hit at

28:54

a larger scale? Does

28:57

Joe Schmoe with a startup web app

28:59

need to worry about having a system

29:01

like this? My

29:04

answer is yes. Obviously

29:06

the benefits become greater. I think that

29:08

the bigger the breadth and depth of

29:11

the organization which is why

29:13

all of these Fortune 500 companies

29:15

and stuff are like obviously we need

29:18

a design system because we've got dozens

29:21

if not hundreds or thousands of apps

29:23

around. Let's just

29:26

take index.html and

29:28

about.html and

29:31

oh we need that header, we need

29:33

that footer. We're going to have the

29:35

same kind of stuff on here. Historically

29:39

whether that's with PHP includes or

29:41

whatever sort of templating language or

29:43

whatever. The

29:47

problem of components is

29:49

needed as soon as you create two web

29:51

pages. The

29:54

example I like to use is that

29:56

even my wife ran a jewelry company.

30:00

company, I of course being

30:02

the good husband I am created

30:04

a website for her. And

30:06

even with what's

30:08

effectively a five pager,

30:10

right, I still applied

30:13

this whole that this exact same

30:15

methodology that we do for these jumbo

30:17

size organizations. Because in order to build

30:19

the homepage, well, I need the hero,

30:22

I need the cards, I need the

30:24

header and the footer. And then I

30:26

go into the interior page and it's

30:29

like, okay, well, I

30:31

got my header and my footer. So that's already like

30:33

70% of the way

30:35

done, right. And then I might be able

30:37

to reuse that card there. And then by

30:40

the time I get to the third template,

30:42

it's like, okay, so now I'm like, now

30:45

I'm really 70% of the way done. The

30:49

fourth template, I'm like 85% of

30:51

the way done. By the fifth template, I

30:53

might not have to do any new component

30:56

work, right. It's just a matter of

30:58

composition. So just simply

31:01

a matter of pragmatism, like

31:04

literally any organization of any

31:06

size or any website or

31:08

app or whatever, can benefit

31:10

from component driven workflows. You

31:12

could call that a design

31:14

system. Again, like, you

31:16

don't need to make something that's

31:19

as like full blown as material

31:21

design. I don't think that any

31:23

every organization needs something that sort

31:25

of formal or grandiose or comprehensive.

31:29

Even for like a design system to power

31:31

a five page website. Yeah, that's

31:33

a design system, powering

31:35

the product as much as it needs

31:38

to. And that's like a big asterisk

31:40

that I wrote in that in this

31:42

big ecosystem article that we just published

31:45

is like, these are all

31:47

potential things, right? Everything that we've just

31:49

been talking about this like framework specific

31:51

layer, or this notion of recipes or

31:53

this notion of like, even kind of

31:56

taking our dumb form fields and wrapping

31:58

them and, you know, whatever React

32:00

hook forms, whatever, in order to

32:02

make it go. Like all of

32:04

those are optional, right? Like not

32:07

every organization needs that. We've never

32:09

encountered any organization that has like

32:11

literally all of these layers in

32:13

place. It's like a design

32:15

system ought to be as complex as

32:18

it needs to be and no

32:20

more, right? Like don't introduce complexity

32:22

without a real need for

32:25

it. And like most things,

32:27

you got to sort of start simple

32:29

and then sort of grow

32:32

and introduce that complexity only

32:34

when it's warranted. I

32:37

had a question about design tokens given

32:39

that they're in this post. We'll make

32:41

sure that this post is linked up

32:43

by the way because it's really substantial

32:45

and great. How do design tokens come

32:47

into play here? And I

32:49

think a common like understanding of them is

32:51

that their design token is

32:53

a CSS variable. In

32:55

your opinion, is that accurate at all?

32:57

And like what

33:00

are design tokens here? Yeah. So it's

33:02

basically, there's truth to it. Just

33:07

again, just with the term design

33:10

system, it means different things to

33:12

different people. What

33:14

we've been talking about is like

33:16

web component powered design system and

33:18

through that lens, your

33:20

design tokens are ultimately

33:23

coming out the other end as CSS

33:25

custom properties to power those

33:27

web components, right, to sort of

33:29

give the flavor. But they're effectively

33:31

these like really low level brand

33:34

attributes, right? They're brand definitions, you

33:36

know, here's a brand orange, here's

33:38

a brand cream, here's a brand

33:40

of brown, right? For

33:43

my own personal website, there we

33:45

go. So that's my brand palette,

33:47

right? But so what these

33:49

things do in design land is

33:52

obviously you're able to sort of like pump

33:54

those into your Figma library and stuff like

33:57

that. In code, you're applying

33:59

them. CSS custom properties,

34:02

but also other environments, especially like

34:04

native environments for instance, right? So

34:06

like iOS apps, Android

34:09

apps, these things aren't using web components,

34:12

but they can consume

34:14

the design tokens and

34:16

get Starbucks Green. If you

34:18

know Starbucks Green needs to be Starbucks

34:20

Green, whether you're on their Android app,

34:23

their iOS app, their you know starbucks.com,

34:25

or even freaking like PowerPoint templates and

34:27

stuff like that, which is pretty interesting.

34:30

You could like, you could basically

34:32

export these things, like at its

34:34

core design tokens are like, here's

34:36

the single place you define where

34:38

Starbucks Green, what

34:40

it is, and then there can be

34:43

a second layer to

34:45

this, what we kind of call like a

34:47

semantic layer, like this kind of like tier

34:49

two thing, that we sort of take this

34:51

kind of dumb definition, this interface

34:54

agnostic definition of what this Starbucks Green

34:56

is, and then we can start mapping

34:58

this, it's like a little sort of

35:01

mix-and-match kind of exercise, where it's like,

35:03

okay, brand background, we're

35:05

going to map Starbucks

35:07

Green to that. Error success

35:10

border, right? If we wanted

35:12

to have branded, Starbucks branded

35:15

valid, you know, form

35:17

controls for instance, right? We could

35:19

sort of mix and match, draw

35:22

an arrow from that sort of

35:24

tier one definition. So it's just

35:26

like basically like mixing and matching

35:28

these variables together and sort of

35:30

creating this kind of tiered system.

35:33

And what doing that accomplishes is

35:36

you could have, and literally

35:39

all of our work over the

35:41

last probably five years has involved

35:43

some form of supporting

35:45

multiple brands, supporting multiple product

35:48

families, things like our

35:50

marketing website has a different

35:52

type scale than our,

35:55

you know, dashboard back end systems

35:57

that don't need big jumbo things,

35:59

right? So there's that use

36:01

case, there's dark mode, light mode,

36:03

and all of that stuff, which is its own thing.

36:06

There's white labeling, which is we need to take our

36:08

thing and then we have a bunch of people buying

36:10

our software and then they need to be able to

36:12

sort of skin it as Megabank,

36:15

corpse, you know, sort

36:17

of brand colors and stuff like that. So all

36:20

to say by sort

36:22

of having this design token layer that's

36:24

kind of managed as its own thing,

36:27

you're able to sort of like keep

36:30

those definitions kind of like

36:32

nice and tidy without necessarily

36:34

touching the components at

36:37

all, right? They like move independent

36:39

tracks. They could be independently versioned.

36:42

So you get it in and what we

36:44

do is we train our clients like here's

36:46

the brand people, here's the marketing department. We

36:48

like say here's the

36:51

mix-and-match exercise. You all do this

36:53

and create your theme. We'll

36:56

be over here working on making the accordion.

36:58

Yeah, right. Like these are these are kind

37:00

of two separate concerns. There

37:03

are two separate layers. But yeah, so

37:06

that was a little meandering of an

37:08

answer, but like it's design

37:11

tokens are these sort of brand

37:13

definitions, right? They

37:16

define the border radius, the

37:18

colors, the font families, the

37:20

type scale, all of that

37:22

stuff. Everything that goes into

37:24

like an aesthetic like look and feel and

37:27

then we pump the result of that

37:30

into our web components and our Figma

37:32

libraries in order to give them the

37:34

specific setting. What

37:38

kind of pushback do you get

37:40

from people when you're trying to

37:43

implement this? I'm sure that you've come across

37:45

all kinds of folks being like this is

37:47

garbage. This is a bad way to do

37:49

it. People are probably

37:51

listening to us being like I want to

37:53

implement this at our company. What's

37:57

the most common type of pushback you get from people?

38:00

Oh man, I mean, there's so many.

38:02

I mean, I think that there's... We'll

38:06

say the biggest real

38:08

challenge, I think, at

38:10

this stage in the game is design

38:13

systems as a concept is... I

38:17

don't want to say universally understood as a

38:19

good thing. It's just one

38:21

of these things that it's like, oh, that's a

38:23

good idea in theory. And

38:26

I think that where a

38:28

lot of the hesitation comes from

38:31

is from people going, especially

38:34

on the code side, which is where I live, which

38:36

is like, you're

38:39

going to be delivering... You're touching

38:42

my code. You're touching

38:44

my code base? We need to own literally all

38:46

of this. So

38:50

a lot of times we deal with

38:52

a lot of IT organizations that are

38:54

super protective or have very

38:57

specific ideas around how they want

38:59

to build their things. They're using

39:01

very specific frameworks or very specific

39:03

tech stacks. And

39:06

they are often very hesitant,

39:09

skeptical, if not downright hostile to the

39:11

idea of some jokers coming in and

39:13

saying, hey, yeah, we're going to create

39:15

this thing. And all you need to

39:18

do is plug this in. So

39:21

there tends to be a lot of mistrust around that.

39:23

And that's one of the things that we really tend

39:25

to do is really come in, try

39:28

to build that trust, and also

39:30

just be way early on in

39:32

the engagement. We're like, we

39:34

don't know what the design system is going to

39:36

look like just yet if one doesn't exist.

39:39

But here's a bright pink button.

39:41

Let's just pretend that that is

39:43

our design system. Let's at least

39:45

get that pipeline set up so

39:47

that we can at least get

39:49

this into your world. You're able

39:51

to kick the tires. You're able

39:53

to validate or put it through

39:55

the wringer. We're not

39:57

precious here. We're not here to... This

40:00

isn't our egos. We just think that these are

40:02

like good ideas. And so a lot of it

40:04

is just kind of like getting this

40:07

kind of division of labor introduced

40:10

to Organizations who are historically

40:12

used to owning

40:14

literally back to what you were

40:16

saying earlier like oh, yeah I

40:19

you published a CSS file. I match

40:21

that That's what

40:23

a lot of teams are like comfortable with but

40:26

now we're like wait a minute like you're actually

40:29

delivering More than

40:31

that and I don't know how I feel that

40:34

Yeah So that's that's

40:36

definitely on the tech side that tends

40:38

to be one of the common things

40:40

that we encounter and then

40:42

of course just like, you know your garden variety

40:44

just designers wanting

40:46

to be creative and da da da da

40:48

da da like Design

40:51

systems are ultimately consents. Yeah, it's right here

40:53

We're saying you do it like this which

40:55

means that we don't do it like these

40:57

other ways, right? And if you

41:00

really like purple and the brand's color is

41:02

blue like don't know what to tell you

41:04

boss. Yeah What

41:07

do you do like we're working

41:10

on the syntax website right now and

41:12

I wanted to style something That

41:14

wasn't one of the blessed purples. I

41:17

just went out of it, you know, yeah and

41:19

in like in a bigger This

41:24

is the first time hearing about this What's

41:27

over it? Yeah, but oh man, I

41:29

even gave you copy and paste buttons

41:31

for all the colors man Sometimes

41:33

it just doesn't look good. You know, like what do

41:35

you do when it just doesn't look good. Yeah

41:39

so so the short answer

41:41

is have a conversation I And

41:45

I could I could share this this

41:48

article with I

41:51

could share I could share this article with

41:53

you, but we talked a lot about the

41:55

governance process. We help organizations Establish

41:57

and evolve their governance processes for

42:00

all of this, but like when push

42:02

comes to shove, right? Like the

42:04

happy path is designers

42:07

and developers come to the design system

42:09

to help them build new work, right?

42:11

They reach for the component, they

42:13

go to the design system component library and

42:15

say, I need an accordion. Ah, there's the

42:18

accordion. Does it do what I need that

42:20

accordion to do? Does it

42:22

open and close? Okay, there we go.

42:24

Good, happy path. That's like the

42:27

success story. But if

42:29

they come to the design system library and

42:31

they don't see the component they need or

42:34

they don't see the variant or they have

42:36

a specific use case for it, or they

42:38

just straight up like, yeah, don't like what

42:40

they see, what happens?

42:43

And coming back to the

42:46

short answer is a conversation is warranted

42:48

between the team or

42:50

the person needing or wanting

42:52

or having a need for something or has

42:55

a question about something and

42:57

the design system team who is ultimately the

42:59

one sort of governing this. If

43:01

it's just broken, if that purple

43:03

isn't the right purple, then

43:06

you all need to collectively make a

43:08

decision. It's like, should the purple be

43:10

updated? If it's a bad

43:12

idea here, if it's not working in this

43:14

context, well, maybe it's not working in

43:17

these other contexts too. Or

43:19

do we need to support

43:21

multiple things? Or do we just kind

43:24

of like, does the design system totally

43:26

relinquish control of that layer?

43:29

And this all really kind of depends on

43:31

like the makeup, the smarts, the autonomy of

43:33

the organization. Like, do you have a bunch

43:36

of really smart product teams who are capable

43:38

of making the right decisions versus

43:41

you have a bunch of teams that can't be

43:43

trusted with a butter knife in their hands? Yeah,

43:46

that's true. Like, even

43:49

if you come back to the example I have,

43:52

it wasn't the purple straight up, I

43:54

was using the purple in a gradient

43:56

and fading it between purple and whatever

43:58

I was, it didn't look like it. So I

44:00

had to adjust it and the

44:02

answer there is not that we

44:04

need to add a new purple is that we need

44:06

to figure out Maybe we need a set of gradients

44:08

that are reasonable and Yeah,

44:11

yeah, yeah, and that's what that's what

44:13

I'd recommend is like having gradients be

44:15

part of your token set That's actually

44:17

a good idea I am unless you

44:19

really are just going for like a

44:21

total yeah mix and match like almost

44:24

like user-generated like gradient thing like what

44:26

you what we tend to do with

44:28

our clients is it's like Here's

44:30

this Sanction set that all

44:32

yeah, they work from a stability

44:35

standpoint. They work from just like a vibe

44:38

Standpoint and then you yeah ship those Yeah,

44:41

this is a this is perfect timing because less than

44:43

I were just supposed to have a conversation after this

44:45

about Finishing up everything so

44:47

if we can establish our system gradients now

44:49

as part of this yeah great

44:51

for me I had a

44:54

question about naming things You'll often hear that

44:56

like naming is a huge problem and and

44:58

and so far in this episode I've

45:00

heard you reference like a ton of different like token names

45:02

for different things It's like naming a

45:04

massive part of this job and is it hard

45:07

is it something that you really love or is

45:09

it something? They have a system for There's

45:13

a lot there. Oh, yeah hard it

45:16

absolutely critical critical

45:18

incredibly hard Yes,

45:20

I do love it most people don't

45:23

love it Yeah,

45:25

and it's it really kind of I think

45:28

this is the kind of

45:30

systems mentality Is that

45:32

you need to kind of be this like

45:34

weird? pedantic nerd

45:38

about really small

45:40

things and Having

45:43

people that sweat that level

45:45

of detail You

45:47

know like is really important

45:49

because that means that everyone else

45:52

Just gets to sort of reap the rewards of that and

45:54

they don't have to think about it, right? That's it. That's

45:56

I think design systems and

45:59

design system teams are like the

46:01

great place for those kinds of

46:03

people that just like sweat those

46:06

really minute details over

46:08

something right like do you call

46:10

something small? S M A L

46:12

L. Oh, are you writing that

46:15

in all lowercase? Are you doing SM? And

46:18

like an abbreviated thing? Do

46:20

you do SM, MD, LG,

46:22

XL, right? Like do you

46:24

do that versus spelling it

46:26

all out? Do you do

46:28

camel case? Do you do, you know, like all

46:30

of that stuff, like that's

46:32

the place for those kinds

46:34

of conversations to happen. And

46:37

ultimately what we've found is that again,

46:40

people want just

46:42

a good experience, right? When we

46:44

talk about a good developer experience,

46:46

it's like, Oh yeah, we've internalized

46:48

this API language that's used across

46:50

the entire component library. So I

46:52

know to use the term variant

46:55

consistently, whether I'm reaching for a badge,

46:58

whether I'm reaching for an alert, whether

47:00

I'm reaching for a button, they all

47:02

use this word the same way. And

47:05

it's it that's the hard work. And that's

47:07

like, dare I say, like one

47:09

of my like the biggest one of our teams, like

47:12

biggest pieces of intellectual

47:14

property is like the specific language that

47:16

we can direct for our clients

47:19

as because it's like people,

47:23

my brother who is normally sitting next

47:25

to me, we will have

47:28

hours long arguments over

47:30

the specific names of a

47:33

product effectively. But

47:35

in doing that, we are we are sort

47:37

of ultimately creating a better user experience for

47:39

like everyone that's like downstream from it. One

47:42

of the kind of coming back to kind

47:44

of figma land, what's

47:47

interesting is that these tools are relatively

47:49

new into the game,

47:51

the game, API naming and stuff

47:53

like that designers, designers

47:55

are used to like layer 73, copy 42. And

48:00

like all of a sudden we're

48:02

like asking them to sort of

48:04

be like incredibly detailed and nuanced

48:06

in the architecture of these components.

48:08

And that's what back to that

48:10

kind of broken designer to developer

48:12

handoff thing. This

48:14

isn't just about here's what

48:16

this component looks like, you're now sort

48:19

of creating this architecture, you're creating

48:21

this naming. So one of our biggest pieces

48:23

of advice is to really like kind of

48:25

have the designers and developers

48:27

kind of co-located, really

48:30

just working through the details

48:32

of that API language together

48:35

and sweating the small stuff, documenting the

48:37

hell out of it, getting it out

48:39

there and making that like a part

48:41

of your ongoing like governance and PR

48:43

process to make sure that like any

48:46

contributions or evolutions or new

48:48

components or new props or

48:50

variants, they come in, they're

48:52

all using language in the same way.

48:54

So incredibly, incredibly, incredibly difficult work. And

48:56

it kind of comes down to like

48:58

the choosing the

49:00

right language, but it's also just like the

49:03

governance and the managing the people part of

49:05

it. Yeah, and I know we're

49:07

short on time here, but I do want to just quick follow up

49:09

there. What is the

49:11

best way, do you mind to document

49:14

that, that language, not like necessarily like

49:16

the established, well, not necessarily like the

49:18

component language, but like, those

49:21

decisions that you've made, how do you present that to

49:23

the team and keep it into a source of truth?

49:25

Yeah, that's a good, that's a good question. I talked

49:28

about that, like third leg of the stool

49:30

being the reference website, that's like a good

49:32

place for that kind of language. But also,

49:34

what we tend to do is have kind

49:38

of a handful of markdown documents,

49:41

living in our code base that then

49:43

gets sort of surfaced in storybook. And

49:45

then you can kind of like actually

49:47

embed storybook inside of your reference website

49:49

tools that that

49:51

tends to work out pretty well.

49:53

And we're actually now doing some

49:56

cool stuff where we're, we're training

49:58

AI on our specific

50:00

code guidelines and structure for

50:03

design system architecture and we're all

50:05

sort of like have AI sort

50:07

of blast out new components that

50:09

use the exact language that we're

50:12

using and stuff like that it's really cool.

50:14

Wow. Yeah. Yeah

50:17

there's fun stuff.

50:21

I don't even think we got like 30% of

50:23

the way through my notes here and Scott and

50:25

I don't even have a lot of notes before

50:27

people come on so that's saying something. And I

50:29

said I wasn't gonna ask anything and I ended

50:31

up asking a lot. I just couldn't help myself.

50:34

I wanted to ask about how you blog so

50:36

much but I don't think we have time.

50:38

We'll have to have you back on at some

50:40

point. Yeah. But we'll move into the last

50:42

section of the show here which

50:44

is our supper club questions. Curious

50:47

which computer

50:50

mouse and keyboard you're using. Your

50:53

standard issue Mac keyboard

50:57

Logitech MX Master

51:00

3. Beautiful. And

51:03

just the Mac MacBook Air. MacBook

51:05

Air. Nice. I have some special questions

51:08

for you. Do you do like any

51:10

systems like reading about systems design? I'm

51:12

sure you do but if

51:14

you do like what are some resources

51:17

that you would recommend for

51:19

that type of thinking? Thinking

51:23

in systems right there

51:25

right there in your question by

51:27

Danella Meadows. That's

51:30

that's like it's beautiful because it just

51:32

like gets into just systems in kind

51:35

of in the abstract but with like

51:37

a lot of real

51:39

world examples by the getting into

51:41

things like economies and

51:44

stuff like that. It's

51:46

so beautifully articulated that

51:49

it like applies to really like low level

51:51

stuff like we're talking about like a design

51:53

token system. It's like the same sort of

51:55

concepts apply to these like

51:57

massive things. So it's like the the

52:00

word design system, right? Like that,

52:02

that word is important. It's

52:05

not just like hot air. It's like

52:07

this is this like, interconnected kind

52:10

of hierarchy. This is it all sort

52:12

of influences one another. There's like feedback

52:14

loops. There's all this good stuff. So

52:16

that's a, it's a great book. I

52:18

would recommend that book to to literally

52:20

anyone whether or not you're doing this

52:23

stuff. It really helped me

52:25

better understand how the world works. Cool.

52:28

Yeah. Another question I have, this is not

52:30

on our regular supper club questions, but I'm

52:32

curious what CSS

52:34

features that are like either new

52:36

or upcoming. There's a lot going

52:38

on in CSS world right now.

52:40

Which ones are you specifically excited

52:42

about? Pertaining

52:47

the design systems, I think that

52:50

container queries, it's it's you

52:52

don't get much more like handy

52:54

love than that idea of

52:56

like being able to create a bunch of

52:59

components in the abstract that just kind of

53:01

like are their own little

53:03

worlds and then you're able to plug them

53:05

into any arbitrary page layout or grid system

53:08

or whatever. And they'll just work. Like,

53:11

I mean, like that's, that's absolutely huge.

53:13

And, you know, Miriam

53:16

Suzanne and like, just

53:18

hearing one of her talks is stuff at

53:20

a conference we were speaking at it's like,

53:22

it's the like style queries and like, oh,

53:25

there's just like so much. But

53:27

I'd say that that that was like, that

53:30

was the huge one that whenever that sort

53:32

of went over the

53:35

theoretical line into like, Oh, this is

53:37

actually happening. That was that was so

53:39

big. But also just man, like so

53:41

much. Yeah, the nesting stuff,

53:43

really all like the stuff that you

53:46

would want task to do that anytime

53:48

that that sort of native

53:50

CSS chipping away at sass is

53:52

features that makes me feel good,

53:54

like because we are we're like

53:56

getting to a point and obviously

53:58

I'm like enthusiastic. about like web

54:00

components and stuff where we're like getting to

54:03

a point where like just native web technology.

54:05

Oh, yeah, I'm from like the

54:07

school of Zeldman, you know, the more

54:10

that like we're able to like just

54:12

build things do standards. It's

54:15

like that's a bet on the future because

54:17

all these frameworks come and go every you

54:19

know, tech stack CMS comes and

54:21

goes. So it's like, what

54:23

is going to stand the test

54:25

of time? That's the stuff that

54:28

I get really excited about. It's like

54:30

it's really, it's less about like, like

54:32

theoretical or like, you know,

54:35

it makes me feel good to be this is I

54:37

think a lot. It is now a matter of pragmatism.

54:39

I think of it is like the same way as

54:41

like, solar panels used to be

54:43

as like, Oh, yeah, like you're an environmentalist. And

54:45

now it's just like, literally just

54:48

crunch the numbers. Yeah,

54:50

solar panels are good idea.

54:52

Yeah, right. Yeah. Good idea.

54:54

Nice. I

54:58

know you're a big music guy. What's a what's

55:01

one of your favorite albums right now? Oh,

55:05

my gosh. Give me a few if you want.

55:10

How much time? Yeah,

55:12

I'll say an

55:15

artist that we we really like we've been

55:17

listening to a lot of rubble bucket. If

55:20

you're familiar with rubble bucket,

55:22

their dog that has like

55:24

a little thing on

55:27

his back. Yeah, yeah. Round saving the

55:29

world. Rubble the

55:31

now you know, which one? No, that's not.

55:33

Oh, pop.

55:36

Okay. No, rubble,

55:39

rubble bucket. Check out rubble bucket. They're great.

55:41

A great band. It's like, berry

55:43

sacks, sort of like

55:46

front woman to trumpets. But

55:48

like, it's like good art rock. It's

55:50

like as close to like talking heads

55:52

as like quarter music can get. So

55:54

yeah, they're really great. The other big

55:57

thing though, if

55:59

you don't mind me plugging. I'm putting

56:02

together like this like really big show

56:05

next year. I'm coming up on my

56:07

40th birthday and I'm like one I'm

56:09

like swinging for the fences. So Pittsburgh,

56:12

I'm getting like a

56:14

bunch of musicians, a lot of

56:16

them web people

56:18

people we all know Chris

56:20

Koyer, Rupert, Dan Mal, other

56:23

people, we're all going to play music

56:25

and we're going to fill up this

56:27

venue in Pittsburgh, this is this old

56:29

converted church, which is really, really cool.

56:32

And we're doing like a big charity show. And

56:34

we have like a whole year to plan

56:37

this single show. And I'm

56:40

like, Oh, wow. So so from a music

56:42

perspective, we're like, lay lay on your song

56:45

requests and stuff like that. But it's like,

56:47

it's going to be like a party

56:50

to a concert and all

56:52

concerts. So yeah, the Palooza,

56:55

Frosta Palooza. We'll

56:58

make sure that's linked up. August 17 2024. Oh

57:01

my god. But yeah, if

57:04

you want to hear what what

57:06

my musical tastes are. Yeah, that's the

57:08

best way to do that. Oh,

57:10

cool. Awesome. So

57:13

last thing we have here is a

57:15

sick pick and a shameless plug. A

57:17

sick pick is a you

57:19

pick something that is sick literally can be anything

57:22

could be a chocolate bar can be a little

57:24

gadget that you've been using could

57:27

be a outlook on

57:29

life. And outlook on life.

57:34

I'm going with outlook. On

57:38

life is you should you're you're

57:40

selling yourself short and you can you could do

57:42

more do do whatever you

57:45

want with your life. There's no

57:47

real constraints to your life. Besides

57:50

your own imagination. That is that my

57:52

sick pick. I love it. Yeah, I

57:54

said we need to add that question

57:56

to everybody. Give us your And

58:02

shameless plug, what would you like to plug

58:04

to everybody? I think I just said that.

58:08

No, I mean, shameless, you

58:10

should come to that. And that's going to

58:13

be awesome. But if I could do another

58:15

one, like if we obviously talked

58:17

about like the gory details of all this

58:19

like design system stuff, it's

58:21

hard. It's complicated and stuff. So shameless

58:23

plug, like if you your

58:26

organization needs help with that, the

58:28

technical architecture, the design architecture, but

58:30

also the people process all

58:33

that stuff. You could hire us at Big

58:35

Medium. It's a big medium dot com. And

58:37

you could also get to it from my

58:39

site, Brad Frost dot com, where I'm like

58:41

writing about all this stuff. So it's amazing.

58:45

Brad, we'll have to have you on again, man.

58:47

This has been incredible. Yeah, it's a lot of

58:50

fun. Amazing. I love talking with you guys. And

58:52

yeah, I love talking. Well, thanks so

58:54

much for coming on. Catch you later.