Build a design system with CSS

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of Learn with Jason. Today on the show, we are gonna be learning about something super-practical. I -- in working at bigger companies, I've always found that one of the things that I trip up on is my ability to quickly build out new prototypes because I always find myself just having a little bit too much fun with the CSS. If you watch the show before, you know that's my favorite rabbit hole to fall down is writing a bunch of CSS. And while I do enjoy it, it's also not the most productive use of my time in a lot of cases. We are going to be talking today about how we can solve that problem and make it so we can be really productive without having to get deep into the technical weeds of making it look right. And to help us with that, is our resident expert, Mike Aparicio, Mike, how are doing?

MIKE: I'm great. Thanks for having me, Jason.

JASON: Thank you for being here. I'm very excited to be learning from you. Because you are somewhat of I think kind of a unicorn out there in that you are a principal engineer in HTML and CSS.

MIKE: Yes. Yeah. Unicorn in that I only have one skill. [ Laughter ] You don't want me writing production JavaScript. That's for sure, but yeah.

JASON: But you're in a role that I think a lot of people would love to have, which is --

MIKE: Yes.

JASON: A lot of people really enjoy writing HTML and CSS, and dabble a little bit in JavaScript. But ultimately the joy of putting together a great-looking UI is -- that's a desirable job.

MIKE: Yep.

JASON: But it feels like those are becoming fewer and further between. So, do you -- like how many other people do you know who have your job title?

MIKE: Literally none. And if there are, I would love to meet them. But I've seen a lot of friends recently lament that, you know, they love writing CSS, but they have to write React and other stuff they don't enjoy. And why can't I just write CSS? I'm now at my third role at a big company doing this. And I've gotten my last two jobs from people who knew me from Groupon who I was with there for eight years. And Mike, come work here. I haven't applied for a job in like 12 jobs. That's not true, I've applied to a couple jobs. But they don't really get what I do, right? Like unless you've worked with me and you know -- you know what it's like to not ever have to write CSS, then you don't -- why am I gonna hire a guy for that much money that only writes CSS, right?

JASON: You know, this is not what we're talking about today. So, I'm going to try not to get too far off on this tangent. But you just said something that is so important. You have a skill-set that would be very hard to get hired for in a traditional way.

MIKE: That's true.

JASON: Through an application process. And I think I do as well. I don't think I could go to a company and say you need to pay me as much as I get paid to make videos for your company. But through the I would say application of network and working in public, both of us have been able to leverage our way into non-traditional careers at a rate that is, you know, that sustains us. That's -- just a little take home for everybody at home. Like if you want a weird job, you got -- you can't go in through the front door. You got to find another way in.

MIKE: That's true.

JASON: It's gonna be through that working in public, it's gonna be through the network. What other things have you done that you think have helped you kind of get this career for yourself?

MIKE: Second City. I did the improv conservatory and writing program at Second City. That's really helped my career quite a bit. Because, you know, there's a lot of engineers that do -- any idiot can do what I do. I went to school for sports journalism. I don't have a computer science degree. There's not rocket science what we're doing. But being able to communicate ideas between design, engineering, and product has been summer-valuable.

JASON: Yeah. I -- and so, Second City being like an improv comedy troupe, it's not necessarily the comedy, it's the communication skills.

MIKE: Yes. And collaboration skills, right? Like the spirit of yes, and. Rather than like, no, but -- right? And just being to take what people are giving you and grow it, you know?

JASON: I love this so much.

MIKE: No matter what it is.

JASON: This lines up -- I talk about this all the time on the stream. Usually when I'm on my solo streams and just ranting about whatever is on my mind. So, this idea that when you learn a skill, the surface value of the skill might not seem that high. Like learning improv comedy if you look at it in the technical professional context, you might go, well, that has zero application. But the other skills that you learn as part of learning that skill have full overlap into --

MIKE: Yeah.

JASON: -- this seemingly unrelated career.

MIKE: Yep.

JASON: And that is absolutely fascinating.

MIKE: I would also say, once you've failed on the main stage at Second City everything else is easy. When you bomb on the same stage that Chris Farley was on, being on your show is super-easy.

JASON: Right. When I was in a touring band, you know, we would do so much where we would play to an empty room and like one person would maybe be watching. But most of the people were like, man, we wanted to come to the bar. We don't know you were going to be here making noise. When are you done? Are you done?

MIKE: I have been in those shows, but for improv.

JASON: Yeah, yeah, exactly, right?

MIKE: Whoa, what is this? I just to want drink my beer.

JASON: You have given us a little bit of background, but for folks meeting you for the first time, you want to give us a bit more of your kind of context, back story?

MIKE: Yeah. I started out my career as kind of just a webmaster, right? Like back in the day. I really started making websites before CSS was even a thing. And so, I spent many years kind of toiling away as a webmaster, right? I don't even know if those exist anymore. But in 2011 I started at Groupon. And I was hired by design as a UI engineer to work on this redesign project. And it went for like a year. And just never saw the light of day. And so, I was really frustrated and I was getting ready to quit and an opportunity came up on the internal tools team to be their, you know, kind of frontend person. They had two designers supporting a half a dozen engineering teams. How do we take the work of these two designers and scale it across these, you know, six teams and make it look similar? So, that was right around the time that Twitter Bootstrap came out. Should we use Twitter Bootstrap? We thought about it, well, we would have to make a lot of customizations, writing a lot of styles on top of Bootstrap. And I was like, why don't we just make our own Bootstrap? Kind of inspired by Dave Rupert who had written a blog post who said, essentially, tiny bootstraps for every client. Why can't we just do this? That's what I did and that kind of transitioned into systems, supporting iOS and Android teams. The CSS doesn't help with that. But I doubled down on my CSS skills and as I built these frameworks, I built three of them at Groupon for different verticals. I found people had to write less and less CSS and then so from there, I worked at a startup called Provi, like an alcohol B2B under one of my former managers. Hey, Mike, we need a design system. This is right when the pandemic started, Groupon's business model relied on people leaving the house.

JASON: Yeah.

MIKE: Turns out the pandemic did not stop people from drinking. That was a pretty good move. And then had another colleague reach out to me, hey, Mike, do you know anybody who does what you? Yeah, me. I started at Turquoise Health about a year and a half ago. And Turquoise is a startup focused on price transparency in healthcare. And so, I developed our design system there which is called Pit Viper, this is the logo.

JASON: Nice, nice.

MIKE: And yeah. It's kind of where I'm at. And so, kind of our motto with Pit Viper, we write CSS so you don't have to. The Devs come in and they're not used to not having to write CSS. And we talked before about the value of what I do. The way I kind of pitch people on it. Not that I have to pitch people on it once they work with me. But let's say how much time, Jason, would you say you spent working on CSS back when you were in an actual developer role? Maybe 10%?

JASON: Back when you had a real job?

MIKE: Well, when you have to write code, right? Probably now, like you know --

JASON: I think I spend... I would spend a decent amount of time in the CSS. Yeah, maybe 10, 15%. I mean, if I had my way, it would be like 75%. But that probably wasn't productive.

MIKE: The average engineer spends 10% of their time writing CSS. And let's say conservatively they're making 100,000 a year. That's like 10 grand for every developer that's not writing CSS. So, the bigger your company gets, the more valuable it becomes, right? And it's funny that my last two roles have been at startups where we started out. We had like one designer and maybe ten engineers? But it's even more valuable there because -- it's even more valuable there because, you know, as you bring people on board, you're kind of, you know, showing them this way of doing things that makes everything so much easier. And we'll get into that once we start. Like what make this is so powerful. It's not just the CSS. It's like what we can do with it. And how we can get developers from translating pictures of websites into just like wiring up frontend code.

JASON: Got it, got it. Yeah. I mean, I think there's... yes. I think I have spent -- and I think what makes it valuable to me is when I take it outside of myself. Right? Because when I start thinking about like -- if I think about CSS, I'm like, but I want to write CSS. It's fun for me. But then if I start thinking about working on it on a team, it's not fun anymore because now you have the problem where everybody does it a little bit differently.

MIKE: Yes.

JASON: You don't have the consistency of like, well, I write it like this.

MIKE: Right.

JASON: You start going in for conventions because there's not the equivalent of a TypeScript for CSS yet. And you end up with now you're enforcing BEM or you're enforcing some kind of strict rule for CSS. And a lot of the people don't enjoy it. So, they're just kind of slamming whatever they need to at the end of the file to like append something to solve the problem they have so they can get back to the thing they're interested in. And all of a sudden, now you're not like doing fun CSS. You're doing like defensive CSS.

MIKE: Yes.

JASON: You're doing like palliative CSS.

MIKE: Yes. exactly.

JASON: And that's where I think these really start to shine is that you're not just solving like Devs don't want to write CSS. Because some of us do. What you're solving is --

MIKE: Yep.

JASON: -- every Dev will probably approach CSS a little bit differently. And you can solve that problem through convention, which takes a lot of enforcement, training, revisiting, code reviews, et cetera, et cetera, or you can train it through -- or you can solve it through removing it as a bottleneck.

MIKE: Yep.

JASON: And so, I think that on balance, if you have any stable product, it's not really a question. You want -- you want to remove the bottleneck. You want it to be something where like the Devs just get it done the right way without having to think about it or care about it.

MIKE: Yep.

JASON: So, yeah, I think that's a very, very like -- there is a clear use case here. So, I guess what -- I'm trying to think how to like segue and I don't have a good -- I don't have a good strategy so I'm just gonna slam us into it.

MIKE: So, let's say you hired me, right?

JASON: All right.

MIKE: It's my first week at LWJ industries. Why don't we take a look at what that would look like, right?

JASON: Okay. I can do it in the most, like, true way possible because we're literally in the middle of this right now. Let me take us over here. And I'm gonna put -- I'm gonna do a couple things before I start talking about this. Put this banner up. This episode, like every episode, is being live captioned. We have got Amanda with us here from White Coat Captioning. You can find those captions at the link at the bottom of the chat. Let me actually put that up because it's kind of hard to -- there it is -- it can be a little challenging to type that from memory. So, y'all can go check this out. Go there. And that is being made possible through the support of our sponsor. We've got Netlify, Nx is -- still talking to them. Hopefully they come back. But Netlify is currently the active sponsor. So, thank you very much for making this show more accessible to more people with that. All right. So, Mike, you started. Here's what happens on your first day.

MIKE: Yep.

JASON: Is I'm gonna show you this Figma file.

MIKE: Great.

JASON: So, the next iteration of Learn with Jason is that I have more than just this show now. I have multiple series and I need a better way of showing those series because right now if you ask me about my Four Web Devs challenge which I have actually renamed and there will be news on that soon. Or my Web Lunch series or any of these other things, I can only point you to a YouTube playlist. I don't have a home for it anywhere. That's what I want to correct. We are pivoting towards this sort of Netflix, Hulu, like general streaming TV-style layout that has the series and then the episodes of the series here and it's broken up into seasons so that you can, you know, switch between like years and stuff like that. And, you know, more details like who is in the series and credits, supporters, things like that. So, all of that, then, points to -- we got to make it a thing, right?

MIKE: Yep.

JASON: I have been working on this. I have been trying to get the database to work. I have been trying to get the kind of core functionality running. And I'm pretty happy with how that's coming together. But I've definitely just been like YOLOing the styles. Because it's fun for me. But I also can't ask anybody for help because it's all done the way that I do it.

MIKE: Yeah.

JASON: So, my first task for you if you join the company would be, make this scale.

MIKE: Yep. Great. Let's do it. So, the first thing I would say is that, you know, the way a lot of people approach design systems is they come in and they're like, okay. We need buttons. We need this, we need that, right? And then they tell the engineering team, you know, hey, we need to get this design system work on the roadmap. And they've already got the roadmap, you know, six months to a year out. And it's full. You're not getting anything on the roadmap. So, my approach has been to take the first thing that's coming up on the roadmap, which in this case is let's say this page, and then make that the system, right? So, everything that I need to make this page is what goes in the system. And only what I need to make this page goes in the system, right? And so, we've got, you know, we've got some type styles, some avatars, we've got some NAV elements and buttons, right? So, we build all that stuff. And then we get to feature two, which might be another, you know, another show, another, you know, section, like maybe a video details page or something like that, maybe that has some new elements that we don't have in the system. But we've got enough in the system from what's here to get us like 90%, you know, set, 60 --

JASON: Right.

MIKE: -- 70% of the way there. Each successive feature is easier to build because you have less stuff that's supporting it. And almost being at Turquoise for a year and a half, I'm rarely writing things, it's mostly supporting engineers in implementing it. And so, you know, I probably spend less than an hour a week writing CSS. Maybe less.

JASON: Nice.

MIKE: So, yeah, the first thing I would do is kind of come in and do like a visual-style audit, right? That means looking at your Figma. Looking at the website. And looking at all of the values that we're using, right? All of the type sizes, font families, font weights, colors, you know, icons, space and values. And just kind of writing all that stuff down and then trying to whittle it down into a like narrower set of values so that those are the values in our system, right? That we're using. And then from there, we can start like working on stuff.

JASON: Got it, okay. We're gonna do a little bit of movie magic here or, you know, have the first step here and then we're gonna just pull the pre-made turkey out of the oven because you asked me for this file about a week ago. And then you sent me -- well, first, hold on. Let me send people to some of your stuff here. So, this is Mike's website. You should go and check that out. Right? So, there's -- there's that. And then I've got some comments from the chat. Yes, absolutely. And also if you want to follow Mike on Mastodon, that's where the action is. So, get on there. And let's get that shown... And then you sent me this. Okay. So, talk to me about what this is. So, you've done your visual audit, you've kind of moved on to the next step.

MIKE: Yep. This is the documentation site for our design system. So, this is using Eleventy and we're basically just like documenting all of the stuff we're building as we go. So, that developers know, like, A, what's in the system, and B, like how do I use this, right? And kind of the benefit of having CSS being the cornerstone of your design system is that it doesn't matter what frontend language you use, right? So, at Turquoise, we have people using, you know, Django, they're using Vue, they're -- we've got some people that want to use React. And like for me, like it doesn't even matter. It's like, okay. Great. Use all those things. I don't care. Because we're not writing styles in any of those languages. They're just using class names from our CSS framework.

JASON: Oh, that didn't do what I wanted. I thought there was a way to show... we're just using class names and premade components and stuff.

MIKE: Yeah, you can maybe zoom in a little bit. The site is responsive. So, it will switch around to, you know, there grow.

JASON: How about that? That's -- everybody can see?

MIKE: So, if you look at the visual styles section, those are all the kind of the things that I'm looking at when I'm coming up with a plan, right? So, this is kind of what I derived from the -- from the Figmas and from the existing website and just kind of pulling values. The big thing with colors is making sure that they're accessible and you did a great job of already doing that for the most part. There was only the purple for the links on the dark backgrounds. You had to use a different purple for that. But aside from that, all the stuff was accessible. And so, that's kind of the big thing. One of the great things about using CSS too for design systems is you can kind of bake in a lot of those accessibility concerns into the system so that the developers don't have to think about it.

JASON: Awesome. Okay. So, and this is great too because then this means that I've got my colors and notes about where to use it.

MIKE: Right. That's the big thing. I see a lot of people that just, you know, have some automated process that takes all their tokens and turns it into utility classes. And it's like, slow down. Like we're not using yellow for text. We're not using, you know, we're not using all these colors in every context. We're using specific colors and specific contexts. And we want to limit how developers are using the colors. Even though these are all available in the design system.

JASON: Nice. Okay. Cool. And then let's see... so, we get into spacing.

MIKE: Yep. So, spacing, like -- I noticed for the most part you're using like, you know, multiples of five. I tend to go with multiples of four. But one of the things they learned in all of my many years of design systemming is there's so many hills you can die on. Right? It's best to just -- rather than try to, you know, impose my beliefs about how things should be, I'm just curating the way things are done already and distilling it into a more repeatable thing, right? So, if we want to use, you know, five pixel increments, great. We can do that. As long as that's what we're doing and we're not doing like, you know, eyeballing it and doing nine pixels every now and then. Let's just pick a set of values and be consistent with it. That's the big thing.

JASON: Got it, got it, got it. Yeah. And so, did you pull these out of my file here?

MIKE: Yep. There were a few instances where like stuff was a little bit bigger, a little bit smaller. But I kind of rounded it off.

JASON: I mean, I was definitely vibing in that Figma file. I was gonna say, I'm gonna be blown away...

MIKE: No, that happens. And certainly -- I wasn't Tweeted that if you give a developer a Figma file that says 15 pixels instead of 16 pixels, they'll put 15 pixels because that's the design, you know? And a bunch of other people were like, they look at the thing and a bunch of other people were like, no, I do the 15 pixels. I think Figma is one of the best and worst things that's ever happened to web development. Best in the sense that it's as close as you can come to a website without actually making a website. But that's also the worst thing, right? And the developer tools, especially, like it's great that you have all of -- that you can click on a layer. And it gives you all of those styles. But the bad thing is a lot of times developers will just copy those in and --

JASON: Right.

MIKE: And maybe you're inheriting styles from somewhere else already, you don't need to declare what the font color is, you don't need to declare the font family. In Turquoise, there's 1200 instances in CSS that they're using the font color to control the font wave. Rather than just the font wave. That's one of the things we have to address.

JASON: Gotcha.

MIKE: The big thing I see, a lot of people, the way they approach CSS is that they're looking at the feature that they're working on and they're scoping everything to that feature. Right? There's -- okay. This is the, you know, the show -- the show section, right? We have show title, show image, show this, show that. It's all encapsulated, right? There's what I call the fetishization of encapsulation. Everything has got to be encapsulated, right? But if you just like use CSS the way it was designed. Like the first C is cascading, right? Use that to your advantage and let things inherit. Then you're only changing things where they need to be changed. You can get away with writing a lot less CSS. And then whether you're not scoping everything to this particular feature, it becomes a lot more flexible.

JASON: Gotcha. So, we got a couple questions coming in.

MIKE: Yeah.

JASON: One of them feels relevant because I think we just talked about it. Is there an argument for like a microscopic design system? A design system for just this thing versus a giant design system for all the things?

MIKE: That's a great question. At Groupon, there was a big question of like, can we just have a system that supports all of our verticals, right? Internal tools, consumer, merchant, whatever else. And at the time I was like, no way! Because like internal tools has all these tables and, you know, it's very data-driven. Whereas the consumer side is very eCommerce-driven. And the merchant side was data-driven, but in a different way than our internal tools. There was a lot of different components. But over time, I have started making things a lot more atomic. Right? We're just taking the bare bones HTML elements and providing utility classes to compose them -- those things in different ways. Right? So, it's not utility-first. It's utility-also, right? Like we have these component styles, like a button is one class. But then if you want to arrange two buttons, like there's a utility for that. You don't have to have, you know, buy button module or something, you know? It doesn't have to be that specific. We're just putting a flex on it. That's it.

JASON: Got it so, it's kind of leaning toward -- what was it called? the OCSS, the Nicole Sullivan, you know, kind of utility-first, what eventually became Tailwind and so on and so forth?

MIKE: Yeah, but I think Tailwind is kind of overboard. You don't want a utility for everything.

JASON: Right.

MIKE: I don't want to write 30 classes to make a button. People are gonna yell at me, there's ways to do that in Tailwind. But whatever. Look at documentation page. Look how easy it is to write Tailwind, but inspect it under-the-hood, there's way more Tailwind to make that happen than what is shown in the example.

JASON: Yeah.

MIKE: You're dealing with media queries and it doesn't really handle all that stuff very well. But if you can just write CSS, you don't need to use, you know, other frameworks. You can just make your own.

JASON: Gotcha. Another question that came in, in reference to sort of what we're looking at the on the screen here. What's the difference between a design system and an old fashioned style guide?

MIKE: Yeah, and I think they're kind of used interchangeably, you know, the style guide was here's how we do things. And the design system, here's all the tools that we use. And I think this kind of skews more towards like the engineers. Like the designers don't use the documentation very much except to just kind of make sure that, you know, the engineers have what they're designing with. That's a huge thing too is like you can have a design system in code, but if your designers don't have the equivalent UI kit in Figma that they're working from, you don't have a design system.

JASON: Okay.

MIKE: They're just gonna be making one-offs that you're going to have to be constantly supporting in the system. And so, it's very important to like, you know, I talked to the designers twice a week. And I see what they're working on. What -- to see kind of like what's not in the system that I might need to add to the system. Or any concerns that they have with like the engineers are implementing the system. Like where I have to like work with them individually on those things. So, you know, the style guide I think is -- was a lot -- it was a lot more static, right? Where I think the design some kind of evolves over time. And it includes more than just like kind of like what's in the system. But like how we do it and when to do is certain things. Maybe the same thing in a style guide. But I don't know. It's kind of a semantic difference to me, I think.

JASON: Okay. Okay. Well, let's pull this one down here. And then the last one that I have is the primary/secondary color division based on what?

MIKE: It's completely arbitrary. I think primary is just like these are the most-used colors associated with like our brand and just kind of black and white. And then secondary is more like accent colors. Like there's other pages in Jason's Figma that used those. It's not really used in the one that we'll be working on. But I just kind of pulled those in there just for, you know, just to have them as an example. And then the neutral colors are just grays and stuff you would use for borders and text and things.

JASON: Got it. You said earlier when we were talking about spacing, you said there was a lot of hills that you could die on. But one question is worth talking about a little bit, how do you choose a multiple when you're setting up a spacing?

MIKE: I kind of go by multiples of four. Generally screen sizes are multiples of four. And if you're doing -- if your spacing is horizontal and your type is vertical and your type is using multiples of four, it just kind of like visually just kind of feels good. You can do it however you want, though. Like I'm not here to tell you like how to, you know, to be prescriptive in how to do it. But this is more about like taking the way you do it and documenting it and making it repeatable.

JASON: And so, in this case, you used the multiples of five because that's where I was in my Figma.

MIKE: Yep.

JASON: And it was closest to the design that I did.

MIKE: Yep.

JASON: Were I being a responsible designer, I plight have actually looked at what those spaces were.

MIKE: Right. Once we document all this stuff and make the design tokens of the values, it makes it easier. We can change this to multiples of four and all of our stuff would just update automatically.

JASON: Got it. Got it, got it, got it. Multiples of four meaning spacing as font size. Yeah. Right? Like you kind of -- because that's the scale that I'm used to is that, you know, you've got your 12-point font and then your 16-point font and then it goes to 24, 36, 48, et cetera. So, multiples of four, but also like increments of 12.

MIKE: Yeah. So, the spacing page that we're on, if you scroll down a little bit, a lot of the kind of vocabulary that I use around spacing comes from this article by Nathan Curtis that I linked to there under terminology. And he talks a lot about like creating a scale, right? And you want it to be -- you want the values to be far enough apart to create a hierarchy without, you know, because if you're just doing like -- if your font sizes are like, you know, 12-pixels, 14, 16, 18, 20 -- like you're not really -- there's not much of a visual hierarchy there. But if you're doing like 12, 16, 20, you know, 24, 32 and then it just gets bigger and bigger, then it becomes more clear. But Nathan also has an interesting way of describing space. So, inset, referring to like padding. Like the inside of an element. And then -- I'm drawing a blank now. But it's all -- it's all in the documentation. But it just makes it really easy to distinguish like margins from padding. There we go. Inset. And there's different types of inset. And then stack. We're essentially just adding margin to -- mostly to the bottom and to the right of things. Instead of just like whatever, right?

JASON: Got it. Got it, got it. Okay. So, then we get into typography and -- I actually pulled all these in. That's great.

MIKE: Yeah. So, here's a place where I would probably say like, you know, maybe we would want our type scale to be -- to have a little bit more space between the values. Because we basically have like 12, 14, 18, I think? Or 16. And 18 and then it goes all the way up to like 36. We would maybe want to like remove some of those middle values and space it out a little bit more. But I mean, it's a design decision, right? Like I said, it's not a hill I'm gonna die on.

JASON: And it actually is really interesting here when we get into this. Because what I was struggling with this is I tend to make everything too big. My default is to make all the text huge.

MIKE: Yeah.

JASON: And so, in this case, I was trying to mimic off of the way that, you know, this is Crunchyroll, Netflix, Paramount+, I think, there's Hulu, AppleTV. I was kind of looking at the way they all did it. They all did a good job of staying small.

MIKE: Sure.

JASON: And then I was over here on mine trying to make sure that it made sense. And I think I kept bumping font sizes you were and down a little bit to try to create some kind of hierarchy. But I think you're right. That it feel -- it's not like -- I think a designer would look at this and go, you're 80% there.

MIKE: Yeah. And again, that's fine. Like we can adjust it, right? In our design tokens. And we can -- once we have this prototype built, we can see those changes in real-time and it's like we're designing in the browser, right? And we can see it responsively, okay, maybe we made it too big when we go to a small screen, it's like, uh. Maybe we look at some like fluid type styles, right? Where the size of the font is based on the viewport width, right?

JASON: Got it, okay.

MIKE: But here like week one, we're just documenting what exists and narrowing it down, right? So, there might have been some other font sizes that you used that I just kind of -- it was like a one-off, right? I chalked it up as a one-off.

JASON: Sure.

MIKE: And this is like the scale that we're sticking with.

JASON: Got it. Got it, got it. Yeah, people are talking about -- yeah, even in the chat, saying smaller, Linda is saying bigger.

MIKE: I'm getting old. So, I also skew for bigger. Bigger, bigger, bigger.

JASON: I just zoom in on every website these days.

MIKE: But a lot of them are designed not to deal with that. Designed in a particular way...

JASON: That's a fact.

MIKE: That's if you can get through all the popovers and the cookie disclaimers to even see a website these days.

JASON: On my phone, I put most things into reader employed. It just doesn't work otherwise.

MIKE: Yeah, icons. There aren't really any -- there aren't really a lot for now to change. We've got like a hundred on Turquoise and Pit Viper. And so, it certainly adds up. But kind of the way we're approaching this is to use an SVG sprite that we pull into every page that we can then call instances of icons and then apply CSS to them to change the size, the color, and everything. And then if we need to, you know, change an icon or add or remove an icon, we do that in the sprite file. It updates everywhere on the site. We don't have individual SVGs that we have embedded in the page that we have to do a find and replace on or anything like that.

JASON: Oh, good question about clamp. So, clamp I think is one of the those things that when I first saw it, I'm like, I'm gonna use this everywhere. And then I really struggled because the syntax of it doesn't fit inside my brain. Something about like the minimum/maximum. Okay, I'm in. And then the middle one, I'm like, why doesn't this work? Why is this always wrong?

MIKE: It's frustrating. There's generators. I think utopia.fyi is one. I think it's great for headlines. I don't know about like for body text as much. I think maybe you could just use a media query that bumps down the stuff a notch. But yeah, I think -- I think -- I think it's great. I wouldn't write it by hand. It doesn't make sense to me either and I do this for a living. But, you know, there's so much stuff I don't know about CSS. I mean, you know it's funny that we're doing this today because CSS Day is going on in Amsterdam. All the heavy hitters are there, Una is there, Adam is there, Stephanie is there, Kevin is there -- everybody you have heard of who does CSS is in Amsterdam. I would rather be here with you, Jason, than enjoying Amsterdam.

JASON: It means a lot to me.

MIKE: It's hard to get away when you have two kids.

JASON: And I didn't even get invited. Okay. So, then we get into our design tokens. And so, design tokens I assume are the pieces that they're built out of these, is that right?

MIKE: That's right, yeah. We're documenting all the values we see in the system. The way I approach it, I have it in three layers that give us varying degrees of control over how those values are used in our system, right? The global tokens are all the values in the system. Raw, hex values and font sizes. And the contextual values are how we use those values. Maybe we have a particular brand color. Maybe, you know, for subdued texts, we use a certain color, right? And then so, if we want to change let's say our brand color, we can do that in these contextual tokens and it only affects where the brand color is used. It's not gonna change other parts that we didn't intend.

JASON: Right. I'm happy to see the way this is constructed. Because I think over the years, I've picked up tips from, you know, I think the first time I heard somebody speak on how to organize CSS was Jonathan when he was teaching SMACSS.

MIKE: Yep.

JASON: Watch people like Nicole Sullivan, Rachel --

MIKE: Rachel Andrew? She's great.

JASON: Chris Coyier, so on and so on talking about different strategies for organizing CSS. I think now I instinctively write sort of good CSS like this. Like I tend to do the absolute values and then these contextual values because I have been bitten by this so much.

MIKE: Sure.

JASON: Why I have a gray that I like for text. But then you start using it for borders.

MIKE: Right.

JASON: And you find, I can't find and replace anymore. I have to go line-by-line on this.

MIKE: Yeah, I see a lot of systems that only have that top layer of tokens. And then when they have to change something, it become this is big find and replace job. So, whereas this, you know, if we -- if the page you're working on doesn't have any borders, really, we don't have a token for borders, but if we did, we would have a second -- you know, we would have another thing that's for borders. And maybe we have different borders. So, we have the context of -- maybe we have a brand border versus a regular border. We have a success and an error border. We can define all that in our tokens. And finally, the component tokens, we can get down to the nitty gritty and have all of our individual component styles defined in tokens, right? If we want to change just what a button looks like, we can do that in those styles without touching any CSS or markup, we can control the visual styles just in that. And we'll talk later about like theming. Let's say we want to support different brands or different verticals that have different global values. We can do that.

JASON: Right.

MIKE: Really easily with the tokens.

JASON: So, yeah. This is -- this is one: Local color. I struggle with this too. Because I overabstract this all the time. And then I -- what I find is that I -- maybe like the same problem that I have when I try to look at Tailwind. I create for myself by having these like many lay-layered, contextual and component and then subcomponent and so on and so forth where my tokens become their own little -- like I've made my own framework for CSS, basically.

MIKE: Yeah.

JASON: And managing that can get really out of control. How you draw the line for yourself like between -- I guess when is it time to do component tokens versus having, you know, we know that buttons use, you know, colored -- color text button, for example, versus like having a straight up button-suite of custom properties.

MIKE: Sure. I think with component tokens, I only use them when I need them, right? An example would be at Turquoise we wanted to make kind of like -- what's the word I'm looking for? Like the white label, you know, versions --

JASON: Oh, yeah, like the generics.

MIKE: Yeah, where companies could provide their own global tokens.

JASON: Right.

MIKE: Those would filter down to the contextual tokens and the component tokens, if I need the button to be different or a different border radius on the button, then they can have the component tokens. I'm not sweating every system needs to have these unless it needs to be changed.

JASON: Yeah. You're choosing some particularly high-volume components.

MIKE: Yep.

JASON: Like if it's gonna get hit hard, if it's gonna have a ton of variations, then it makes sense to do this component-specific theming. But if it's something that isn't, you know, it's not gonna change a ton. Like the header for the website probably isn't gonna be like ultra-customized unless you're white labeling the design system.

MIKE: Yeah, the header probably more -- one of the hardest things I think about design systems is where does the system end and the product begin? You don't want to be in charge of -- you don't want to be -- you don't want the system to be responsible for product decisions, right? So, what is the header composed of? What components are in it? What does it do whether you click on stuff? You don't want any of that in the system. You want the header to be composable from all the parts of the system. But if you want the NAV to have, you know, three items instead of five items or whatever, that's up to you. We'll support that. But like that's a product decision, right?

JASON: Right.

MIKE: So, I think that's the thing that a lot of people get hung up on. They want to put all of the stuff in the system, and maybe in the UI kit you want that stuff, right? Like just like I look at a UI kit as like a component library for developers, right? There's really like -- there's the UI kit. There's what we're doing here, right? The CSS. And maybe the engineers take what we're doing here and build components from that. And maybe they build them in Angular or they build them in Vue, they build them in React, whatever. But I'm just like providing the tools that they need to make that easier. Right? Taking one thing out of the equation so that they can just focus on like how it works, rather than what it looks like.

JASON: I gotcha, I gotcha. Yeah. So, I think that's a good -- that's a good point. Because it's -- there's a difference between a design system, which is intended to be, you know, reused and applied across multiple parts of the product. And like the design of the product itself. Like the header is not a reusable component. It's just the thing at the top of the website for the product.

MIKE: It could be a reusable component. Like it could be a component that livers in our, you know, in our frontend, you know, language of choice. But it's composed of, you know, these CSS classes. Right? That maybe that gets shifted around.

JASON: Right.

MIKE: But we're not documenting that in the system. That's just more of an implementation of it.

JASON: Yeah and so, I guess the thing that is important is that as you're deciding what goes into the design system and so on and so forth, you have to take the context of what you're building into account and like is this really something that like lots of developers are going to need to be able to implement quickly. Or once this is implemented, it doesn't really change without a huge cross-functional decision that goes up to every VP in the company about what goes into the top NAV, what goes into the -- you know what I mean?

MIKE: Yeah, I'm not in those.

JASON: Exactly, right? And I think that's the thing to note. You don't really -- whether you're doing the design system, you're not making those like business critical product decisions about what the information architecture of the product is.

MIKE: Right.

JASON: Or, you know, those sorts of things. Don't try to build them into the design system or you're going to yourself at odds with people in the company.

MIKE: Yep.

JASON: Choose your scope of control and be okay with that.

MIKE: My approach is I'm essentially making a third-party framework, but I work at the company, right? So, in system is a dependency in the product, but I'm not -- I don't even -- I have been there a year and a half, I don't have the app loaded on my computer. Like I don't commit to the app. I commit to a separate repo that they're using as a dependency, right?

JASON: Right and remembering which, you know, which parts you're expected to control versus which parts they're expected to control.

MIKE: Yeah.

JASON: I think that's the other thing that I've noticed is that teams that have design systems or security teams or -- like anybody who is sort of like an adjacent team that controls a piece of the product for compliance or consistency or any other sort of cross-cutting concern, if there is a clear understanding of like who controls what and for what reason, and everybody agrees on the value of those things, it goes so well. If there is a struggle for control where the security team is trying to like control things that are outside of the realm of security, because they have opinions, or whatever it may be, or the, you know, the product team is resisting things that the security team needs to control because they don't want to, those sorts of things then now you've got these internal power struggling and it gets very political, it gets very draining. And the teams can really struggle to get anything done. Despite having all the outward appearances of a highly agile team because they've broken down these functions. So, again, you know, the communication of things, the trust on the team. All that stuff is so much more important because honestly, we could be really bad at design systems and really good at trusting each other and we could probably outperform a team that didn't trust each other and had great design systems. That's another little tangent. We're if you feel tangents today, Mike.

MIKE: I could talk about this all day.

JASON: We have a couple other sections to explore here. We have got components. These, I'm happy to see we've got the kind of general setup here of how these things work. I love that it's just straight HTML. And I'm assuming this is just copy-pastable for me. I could pull this out, swap in whatever person's photo.

MIKE: Yep.

JASON: And we're good to go.

MIKE: Yep. Like the Turquoise one, we have an avatar. But if there's no image, you can put the person's initials in there.

JASON: Oh, yeah.

MIKE: You could, you know, there's a thing where we have like stacked avatars where they're kind of overlapping. There's all these different things. Yeah, the docs are crucial because we want to show developers not just what's in the system, but how to use it, right?

JASON: So, we've got buttons, we've got NAV bars. Oh, you built out my NAV bar. I was literally -- this has been on my to do list. So, excellent. My life just got so much easier. But so we end up with these nice little pieces here. This is wonderful.

MIKE: Yeah.

JASON: We've got different typography. Oh, yeah. Look at it go. Amazing! So, this is -- yeah, this is excellent.

MIKE: Yeah, this is essentially everything we need to build that page, right? These are all like kind of the raw components and then the utility classes allow us to like arrange those components in the way that we need to as well as the layout. So, this is very similar to Andy Bell's CUBE CSS, right? Where we kind of divide things up into like components, utilities and layouts. I call it COOL CSS. But for me, that's all you really need. And I don't find myself writing CSS ever. And the Devs certainly don't have to. If they are writing CSS, we have a problem. They need to come see me. I'm basically the code owner. I'm the CSS file in the app, and so, if people are adding to is that, I get like added as a reviewer on the pull request. So, that kind of helps us keep that stuff in check.

JASON: Awesome. Okay. And yeah, and so, I like some of the naming that's happening in here too. Where we've got, you know, text is text. That's fine. But like surface. This is something I've always struggled with because I call it background. But it's not background, it's like a different -- it's something else. It's the color of the container. Which isn't always the background. And so, I like -- yeah, Surface is very good. And then we've got some layout stuff which I'm very happy to see.

MIKE: And you'll notice all this stuff is a the lot more verbose than Tailwind. So, developers like this because they can actually tell at a glance like what's happening without -- oh, what is MX8, you know? You know? If you use Tailwind a lot, you probably know what that is. Even our designers know what's going on here. So, here's something I want to point out is like how we're using custom properties here. So, like you could just go nuts and make a bunch of CSS classes that handle every single combination of flex properties. But for the most part, you're just flexing, right? You're applying display flex. You're centering the items. You're adding a certain amount of gap. And maybe you're justifying it, but maybe not. And then maybe it should wrap or maybe it shouldn't. So, we have these kind of sensible defaults that work in most -- 80% of cases. And then we allow you to -- we provide certain custom properties that you can override in a style attribute, right? So, you could write the actual CSS in there. But these are the ones you're allowed to change rather than just writing a bunch of in-line CSS. Here you can, you know, change the justification, right? So, that it's to the right in this particular context. But in most cases, like the defaults will get you there.

JASON: Yeah. Yeah, yeah. This is -- this is great. So then we've got a grid, right?

MIKE: Yep.

JASON: And that will be very useful. Got our default spacing so that things are, you know, split the right way.

MIKE: Yeah, flow is another Andy Bell original that I stole. Basically, it just -- it's a container and all the children of that container get the same amount of bottom margin instead of applying that margin to every individual child. But then you can also add margin, you know, with one or the other utilities to a child element if it needs to be different.

JASON: Got it. Cool. And then we've got, let's see, our padding, our insets. So, that gives us our -- like so it's not crammed against the side. Okay. Individual stuff. So, we can center...

MIKE: The best thing in CSS is centering stuff, right? The hardest thing.

JASON: I have been blown away, honestly, at like how far we've come on that. Like I think it's a one-liner these days. You can just place -- what is it? Place content center?

MIKE: There's a bunch of ways you can do it. This is not being prescriptive about how to write CSS. It's more about like what to include and, you know, how to organize it, you know? The goal is like developers don't have to write CSS and so, whatever helps us get there. Like you can write the CSS however you want. So, you know, my way of centering this thing might be different from somebody else's. Like this is just putting margin auto on the thing. We could also use Grid. There's any number of ways that we could achieve that. We're just like, here's how we're doing that in our system and we're documenting that.

JASON: Nice. Then we got layouts. Oh, nice.

MIKE: Yeah. So, this is like, you know, all of our stuff lives in containers, right? Like HTML is just boxes, essentially. And so, the layouts help us, you know, particularly with CSS Grid, help us arrange all of these boxes. And then those boxes, depending on the sizes, like kind of inform how all of this stuff sits in those boxes, right? And we can like further use like Flexbox and Grid to -- we can nest these layouts, right? If we get more complex layouts. We can potentially nest these layouts. So, I use like a data attribute called data grid area to like define what those are separate from the semantics of it. Maybe the grid area is called NAV. But in a certain context, maybe it doesn't need to be a NAV element.

JASON: A NAV element, right.

MIKE: Particularly if you're nesting things. Maybe the main section isn't a main element. But in the context of this layout, it's kind of the main area.

JASON: That's -- yeah, that's super-slick. And then we got some -- oh! All right, then. So, we get some theming. Right out of the gate, that's great.

MIKE: This is a fun thing. So, if you scroll down a bit, these are the values we're using in the theme. If you take a -- if you take a style element and you put a style attribute on it and put display block, it will show you the contents of that and further, if you add the attribute content editable, you can click in that box and edit those values live and it will update.

JASON: Okay. Very cool. So, let's... hey, hey, look at that. So, now we can start theming right away.

MIKE: Yeah, yeah.

JASON: That's very cool.

MIKE: That's literally the only context in which you would ever do that.

JASON: Right.

MIKE: Is demonstrating theming. I couldn't think of another one. But we can like scope that to the root to affect the whole page. Or we can scope it to a class to affect like a subset of things. So, that becomes super-valuable. So we're not really using that in this first project. But it was just something I wanted to demonstrate that you could do with these tokens.

JASON: Right. This is very cool.

MIKE: If you go back to that page and just blow it out, just like erase the whole thing, it will default to the regular styles.

JASON: Oh, nice. Okay.

MIKE: Yeah. If you scroll up to the top, you'll see like kind of how we're doing that. So, we're using like the -- the fallback in the var, right? To define like here's what the name of the property is and if that doesn't exist, we'll fall back to our -- I'm using SaaS for our tokens. Because the developers don't -- we don't need everything to be a custom property to let the developers use. We want to kind of bake that into the system so that like we have like a, you know, surface brand, right? We don't want people just saying, like, you know, oh, background color, since they're not writing CSS, they don't have to write color yellow, that's not in the system. Please don't do that. We only want certain colors used for surfaces.

JASON: Right. That makes sense.

MIKE: This lets us define which of those tokens are themable.

JASON: Got it. Okay. And over here, I saw a prototype button which I clicked to.

MIKE: Yeah. And that's the whole page built using the system.

JASON: Ah! Just... I could hug you.

MIKE: And so, like -- I did this in less than a week. So, here's how the week would go, right? Day one, I'm meeting with stakeholders. Meeting all the, you know, product people, all of the developers, all the designers that I'm gonna be working closely with and getting a sense of what's your experience with design systems? What are your expectations for this? How can I help you? I look at my role as developers, designers, and product people are my customers. Like the company's customers are not my customers. That's your problem. I'm here to help you and make your job easier. However I can do that with the design system kind of informs, you know, how I build the system and maybe that's different from company-to-company. So, certainly a lot of the stuff I've built into Pit Viper is in this system for LWJ. But this is specific to what LWJ needs, right?

JASON: Right.

MIKE: Like I'm not copying Turquoise's font spacing values or font values or anything like to. This is like bespoke for LWJ, but it uses all the same concepts. So, day one is like meeting with stakeholders. Day two is the visual style audit. Right? Where we're finding out what those values are. And putting that into design tokens. We're like looking at the roadmap, what's the next feature we're working on? And what are the things we need to build use those tokens? And what are the components, the utilities, and the layouts that we need to use to support that stuff?

JASON: Yeah.

MIKE: And then we're prototyping. This is kind of how I'll work. Is I'll -- there's actually on the home page of the -- this design system doc that we built, there's a link to CodePen that actually has a template that's using LWJ.CSS. You can start using all the stuff in the documentation in CodePen. So, we could essentially replicate that page here in CodePen. And so, the way I work is I will use this template for like the next feature, right? And maybe either CSS that I need to write to support that new feature. I'll start building that out and then I will -- I'll write whatever CSS I need in the CSS tab. And then I will show that to stakeholders. Like, hey, how does this work? Is this what you intended, you know, for the designers? And then once we do that, I will take the CSS, put that in the system, release a new version, and then from there, the template is using the latest version of the framework. So, I can delete all the CSS and it should still work, right? And then from there, we're taking that, handing that off to the developers and then they have all of the markup and everything they need to build this entire page and they can just say, okay. I just need this one episode thing, markup for one episode. I can write all the JavaScript I need to pull that from the API and show, you know, all of the different things for each episode in whatever data we're getting back. And they can get this stuff built out way quicker than if they had to like style this on their own.

JASON: Right. And so, I can do something like -- I kind of want to try this now that we've --

MIKE: Yeah.

JASON: -- got a playground. For me to put this together. We've got each of these pieces. And we can see the triple dots showing up wherever we want them to go.

MIKE: Yeah. I actually did this. But for whatever reason the image that I passed in wasn't working. So, I'll probably have to think of something to get around that. But I'll send you the link.

JASON: I just to want see how well this works. So, we go into the NAV. Drop in this NAV. And then, yeah. So, my --

MIKE: We're just missing some image references.

JASON: This image is broken and that's fine.

MIKE: Yeah.

JASON: But like starts coming together real fast. Which is -- which is pretty impressive considering I'm just kind of hopping through the docs and grabbing the things that I need. So, let's see if we can quickly I want to lay out the... we would want a grid. And so, I would grab a grid like this... don't want to get all of those. Just that bit there. And then... close that up. And then if I want to get one of these for the videos themselves, it's probably somewhere in -- no. Okay. It's probably not in here, right? Because --

MIKE: You have to compose it. It's not a -- there's not like a card. I will put a card in if like the card itself needs like a hover state or, you know, styles like that. But each of those things is just composed of like an image with some, you know, some inside of one of those grid elements. So, like in this case, you'd probably want like a figure. Okay. Each card is a figure and then you've got the image and then the fig caption is kind of the text below it. That's kind of how I wrote it in my prototype.

JASON: Okay. So, let's do a figure. And then we've got our figure. And then underneath that, we've got our fig caption. And our fig caption has some stuff in it. And we'll be able to style that with our text stuff so I'm gonna start by saying it's probably like an H2 or something. We'll put a class on that later. And then we need our icon. So, our icon is in here somewhere. So, you can use the -- can and I think if you expand the -- well, that -- go up one. One example. Yeah, right there. You can basically just copy that. But the problem is, in CodePen, we also have to pull in that --

JASON: Right. We need the sprite.

MIKE: Which we can do.

JASON: And we probably... the -- why don't we skip that for now?

MIKE: Sure. Just worry about the title.

JASON: Yeah. Because I want to be mindful of how much of a rabbit hole I get into here. And so, this would be the episode description.

MIKE: Yeah, this is a great approach. Just get the markup right and figure out what classes we need to make it look like the picture.

JASON: okay. So, down here. Is that how this works?

MIKE: Might be below that section.

JASON: Oh, no, PlaceKit is down. Why don't we instead then -- I have somewhere in my -- oh, you know what I have? I have a Cloudinary site-images. I'm working on a thing.

MIKE: If you want, I sent you a link in the Streamyard chat to like the actual CodePen.

JASON: Oh, I got it.

MIKE: Minus the hero image which I couldn't figure out why that wasn't loading.

JASON: Got it.

MIKE: So, there's the sprite, right? That's all the icons. And then yeah, you can just kind of see like how we composed that.

JASON: Cool. Okay so, we've got all this built here. And so, we've -- yeah, we've got our NAV happening. We've got all these pieces. Our image didn't work for whatever reason. That's fine. And then we've got -- here is the promo section. That's this one here. So, we've got this little tag. We've got the heading. Text body here. We've got a button. Great. And then this would be like when you click this, we would fire the JavaScript to start the video player. Or I guess actually in this case it would be a -- it would be a regular link because it's gonna link into the episode standalone page.

MIKE: Yep. And that class would work on an anchor element as well as a button.

JASON: Episode link... oh, it refactored that. That was cool. Good job, CodePen.

MIKE: So, there's an issue where we would see, oh, we don't want that to be purple. So, we would in our button styles, we would update that to inherit the color of the parent as well as remove the text underline.

JASON: Got it. Yeah. So, then we've got our, you know, this -- what was it called? I think it was an eyebrow I think you called it?

MIKE: The all caps text.

JASON: This is not --

MIKE: It's the small text, subdued, meaning the color is not as bright as the regular text.

JASON: Nice.

MIKE: Yourself are interesting because the headers are even brighter than the body text. And then there's subdued text, which is another level. You can create hierarchy with like position, right? Like how far are things apart? By size, by color. By weight, right? Font weight. So, there's lots of different ways that you can create hierarchy besides just like font size.

JASON: Yeah, this is actually something that I was trying to embrace for this design was the idea of using something other than size. Because I always rely on size. And so, I was -- I was trying to point out, you know, like this is the most important thing, right? And so, you've got your title, or your image and your title. And then you've got body text. But then here you've got something that's not as bright --

MIKE: Right.

JASON: It's a little bolder. And here you've got something that's not as bright and also not bold. So, hopefully when you look at this, you see the image and then you see this and read this and kind of come back around to read these in terms of eye flow. That's assuming I know anything about design.

MIKE: In my career, I have been the best designer the engineering team, and the best engineer on the design team, neither of those are saying very much. I'm not a designer or an engineer.

JASON: I'm using Art Browser. It's dope, you should try it. What's up, Fuzzy. How is it going?

MIKE: I forgot to change my hat, Jason.

JASON: Oh, did you have a different hat? I've got that hat.

MIKE: Shoutout Cassie evens.

JASON: Cassie, and Brody.

MIKE: Can't forget Brody.

JASON: That's an excellent hat. I unfortunately can't wear that hat because my head is too big.

MIKE: I can relate.

JASON: I see the benefit here. I see what's happening. Where we sort of get to the point where as we're building out more things in the site, we're kind of just copy-pasting units of UI.

MIKE: Yep.

JASON: And it makes it so that I don't have to stress about the specifics of what's going on here. I just get to work on the thing that I'm supposed to get done and get shipped and it all kind of works.

MIKE: Yeah, in the prototyping process like with the button. It surfaces stuff we didn't consider when we were first making it. And also, as we're using these things in different context when is we build new features, that also surfaces stuff. Maybe we have to adjust our layout. Or maybe we need a whole new layout to support this page instead of trying to -- or maybe we notice with the NAV -- when I was designing the NAV, I was using a bunch of utility classes. That's fine. But if you find yourself doing that a lot, maybe this needs to be a component and so, we just bake that in so you only need one class instead of five classes, right?

JASON: Right. So, there's a question from -- where is he? Fuzzy asked: Any advice for folks starting out to build their own design system? And I think that's probably a good, you know, we've got about 10, 10, 15 minutes left. So, you were able to get so much done here. And, you know, you said it took you about a week. Which first of all, thank you for putting a week into this.

MIKE: A week chronologically, not a week of work.

JASON: Sure, I got you. So, being able to put this together in the short time that you put this together in, it's got a lot going on. And, you know, it feels usable. It feels like the kind of thing that me as an outsider can do. Obviously, you have a ton of experience. This is your full-time job. This is something you think about all day every day. So, for something who is new to this, what are the things that, you know, we should be thinking about or studying or looking into so that we can get toward making these types of design systems?

MIKE: Yeah, I mean, I think just looking -- you know, like we said, looking at the next thing on the roadmap and just start your system from there, right? Whatever you need to build to support that, that's the system. Right? And then it just grows over time. And incorporating it into your workflow. Instead of trying to sell the higher ups and like, oh, we need a design system. Don't even say "Design system," just make it the way you it. They will see the results. You're selling the results, not selling the system. Look how much faster we're moving because we're doing it in this way. We're able to go from, you know, it taking three weeks because the developers are struggling with the CSS to like now they can ship it in a week, right?

JASON: Yeah.

MIKE: And then each successive feature gets faster because you're writing less and less CSS. It sells itself.

JASON: Yeah.

MIKE: In terms of how you learn this stuff? There's a ton of great design systems folks out there. Dan Mall, you have had Dan on the show, I remember. Brad Frost, there's a ton of people that I've certainly, you know, learned from. Nathan Curtis has a lot of great stuff. But yeah, there's just a lot of people that enjoy the work and enjoy doing this stuff and, you know, you can learn all this stuff pretty much for free. People talking about it all the time. Actually, inspired by your show, I was doing a show for a while called Design System Office Hours, CSS Office Hours, something like that.

JASON: Nice.

MIKE: But I was talking about design systems every Friday. And just making design systems out of whatever. You can practice, go on Dribbble. I'm gonna take this thing and build a design system for it. Even on your own personal site. Personal sites are making a comeback.

JASON: Is this the one?

MIKE: No, that's something else. I think after I came up with that, everybody started using the term "Office Hours."

JASON: Well, if you find a link, throw it out there.

MIKE: I don't really -- it was just kind of like a live thing. I didn't really record it or anything.

JASON: And you named one more person, Dan Mall, Jinna, Brad Frost, and --

MIKE: Nathan Curtis. I reference his stuff. There's a lot of great books. Got behind me here... let's see...

JASON: Let's see...

MIKE: Got this. Design Systems book by Alla Kholmatova. And Atomic Design is a good one. Dan came out with another book, Design That Scales. Another good one. What else? The folks at InVision, have this book called Design Systems Handbook.

JASON: Nice, nice.

MIKE: A lot of good books. But you can get it by following people. They talk about it all the time. They won't shut up about it. How do you know a design systems practitioner? They'll tell you.

JASON: I'm also spotting that you have the ultimate coding companion behind you there on the shelf.

JASON: This little buddy. Maybe one of these? We could all -- huh? Yeah?

MIKE: These are available for purchase, everyone. If you want to put the link in the chat.

JASON: I will put the link in the chat. What an excellent idea. Yeah. We've got -- we've got Corgi Ducks, everyone. They are amazing.

MIKE: If you sell a lot of these, you should cover my invoice.

JASON: Yes, please, go and buy them. Because there are so many.

MIKE: They're great, they're fun. You got a whole garage full of these, don't you?

JASON: I definitely still have like 700 left. So, please buy a Corgi Duck.

MIKE: Yeah, they're great. My kids love them.

JASON: They float. They --

MIKE: Yeah.

JASON: They're good to talk to. They're great listeners. They will make you -- they help you with your code if you explain your code to it. Excellent. Excellent companions to have. So, Mike, this has been amazing. Thank you so much for taking the time to teach us today.

MIKE: Of course.

JASON: So, I'm gonna share your website one more time. Is there anywhere else that you would -- a veritable platoon of rainbow corgis. A horde in fact. Super cute, never talks back. This is your website. Anywhere else that we should be sending people to find out either more about you or more about design systems?

MIKE: No. That's pretty much all on my site. If you want to check out Turquoise's design system, it's pitviper.turquoise.health. That will look very familiar to you. It's the same kind of layout as the one that we've built for LWJ. I'm trying to make a GitHub template that will make setting this up a lot easier if folks want to take that for a spin eventually.

JASON: Nice.

MIKE: I'll probably promote that on Mastodon when I get around to it. But yeah. Similar thing. A lot of -- same, you know, structure and layout and everything. We're just using different design tokens, essentially.

JASON: Yeah. I mean, it's very cool stuff. And you can kind of see the flexibility here just in looking at this as a -- like a reusable system. That once you've kind of thought through how these things work, they start to organize into buckets in your mind. And, you know, the -- this is -- this is the value of doing this work is when you start to think about things in certain buckets and you start to understand how these different components interact with each other, how these different elements and tokens interact with each other, you -- you're able to start thinking about your websites as LEGO pieces where you're snapping together things that are already done for you. And it turns things from being -- it's not two jobs anymore. You don't have to like make the layout and also make the components that make the layout. You get to look at something you're supposed to do and say, all right. What's in the box that lets me get there? And suddenly things go many faster. I think that really is a huge selling point for why this stuff is worth it. And even if it can sometimes, you know, make you feel like you're using a coloring book instead of going from scratch, which, you know, the artist in me always bucks at the idea of having to use something that's been pre-designed --

MIKE: Yeah.

JASON: But also, like, the artist in me has been meaning to ship a portfolio redesign for five years now. Now it's time to sit down and shut up and use some pre-designed components.

MIKE: Well, I would say two things. I love Adam Argyle's open props. Those are great. You don't have a designer, those are what I call curated design tokens. Right? Adam's already picked out all the great values for you. And you can incorporate that into however you want to use CSS. If you want a nice type scale, Adam has taken care of it. If you want some nice gradients, they're amazing. He's got those there for you. Yeah, shoutout to Adam. He's awesome. But also like, it's hard to, you know, I would say that these systems don't necessarily have to be a constraint, right? Like this system can support new stuff, right? We just have to build around it. And, you know, we get designers, you know, new designers at Turquoise who, you know, they have got their own ideas about how stuff looks. We look at those things and either we can adjust the existing component to match what they want to do, we can create a variation of a component to support what they want to do, or we can make an entirely new thing, right?

JASON: Yeah.

MIKE: So, it's never like preventing you from doing what you want to do, it's just kind of -- I refer to it as like curating what we're doing, right? How we're doing things. We're not being prescriptive about how you it. We're just kind of like, you know, documenting how we do it here at our particular company. And maybe that's different from company-to-company. But like at the end of the day, we're just applying the same visual styles to the same, you know, few dozen elements over and over again until we die.

JASON: Right. Yeah. Exactly that. That feels like as good a place as any to end it here.

MIKE: One more thing I want to pitch it dogsof.dev. If you make websites and you have a dog, I would love you to send many a picture of your dog so I can put on here.

JASON: This is a very good website. Wow, this is a great website. Why have I not heard of this website before? Everybody go look at this website?

MIKE: There's some big named folks on here that have submitted their dogs. You see Lynn Fisher's dog, Brad Frost --

JASON: I don't know if Lynn is still here, but I love that Lynn named her dog Gravy. What a fantastic name?

MIKE: It's amazing, she's the only person that submitted a dog as a pull request instead of just filling out the firm like a person that doesn't have any time on their hands. Lynn, you're awesome.

JASON: This is fantastic. I mean, these are some good -- that's good --

MIKE: Even if you don't have a dog, if you just like looking at dogs. And some of the names are amazing. There's one like Burt Macklin, FBI agent.

JASON: Wait, Burt Macklin, FBI -- whose dog is that, know? I know that dog.

MIKE: Do you? There's a lot of names you would recognize.

JASON: Dan Mall's dog. That's a cute dog.

MIKE: He's got two.

JASON: How much time we got? I'm gonna hang out here all day. Priscilla, Queen of the Desert. This is wonderful, and cribbing many names. Ben Hur? Good gravy. Yeah, this is fantastic. And I'm gonna look at this for the rest of the day, you should too. Thank you all very much for hanging out. Mike, thank you so much for spending some time today.

MIKE: Yeah, no worries.

JASON: Any parting words for the chat as we are wrapping up.

MIKE: Just, you know, I like to say, whatever way you want to do things, it's your website. If using the way you're doing it works for you, keep doing it. That's fine. If any of this has helped you work that into the way you do things, you know, it's your website.

JASON: Yeah. There are no rules, there are only pro tips. Shared experience, shared pain, shared trauma and we all the try to build something that looks nice. Mike, I appreciate you taking the time. Chat, thank you for hanging out with us. Make sure -- wait, I got one more thing to show. One more thing, one more thing that we got to look at. This episode, like every episode, has been live captioned. We've had Amanda here from White Coat Captioning. And that's made possible through the support of our sponsors. We've got Netlify on board today making this show more accessible to more people. Make sure and go check out the schedule. June is gonna be a wild month for me for travel. I am at all sorts of events, some that I've announced, some that are surprises. And as a result, I won't be doing any more episodes for the remainder of June. And then the first Thursday in July is a US holiday. I will be back on July 11th for the next episode of Learn with Jason. In the meantime, a lot of fun things coming out. There's more stuff that I'm working on, my web Dev series, Dev lunch, and enjoy your summer, and see you soon. Mike, thanks again. We'll see you all next time.

MIKE: Thanks, Jason.