Design Systems with Storybook, v2

Color Naming Convention

Steve Kinney

Steve Kinney

Design Systems with Storybook, v2

Check out a free preview of the full Design Systems with Storybook, v2 course

The "Color Naming Convention" Lesson is part of the full, Design Systems with Storybook, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses several considerations for deciding on a naming conversion for colors within them. The variables2CSS Figma plugin, which generates color variables for different formats, is demonstrated.


Transcript from the "Color Naming Convention" Lesson

>> The initial version of our app was one. I was the first front-end engineer and the only front-end engineer in working with that designer. And I think out of the box, any kind of really flexible general purpose styling tool, Tailwind, whatever, doesn't really matter. It has stuff like red and blue, and stuff along those lines.

And so early me and then now as the leader of the team, everyone else followed my fault is what I'm trying to say, use colors like red and blue throughout the UI, right? And so I work on the thing has workflows, some of them are canceled, some of them are terminated, those had color meanings.

Design team comes in and now all of a sudden you wanna change what certain colors mean throughout the UI, which means going through, because not all red, red was the bad stuff. It was also like the little required button. It was also lots of other things. Don't get me started on blue, right?

[LAUGH] And so at one point, it makes sense to no longer refer to colors, but to refer to the semantic meaning, right? Especially once you have theming, because you might have a color called light blue turns out in dark mode, that's not light blue, right? And so then you need to go ahead and have a new philosophy on how you go about this, right?

And there's different extremes to which you can take it, right? One is you can start even just with the various shades of, no longer calling it green or whatever. So by default, we start out with primary warning, danger, you can call it error, call it whatever you want.

And then informations, which are primary, secondary warning, information, danger, success, that was the one I was missing. [LAUGH] You can tell I'm a pessimist. So starting out with those colors, because then like theoretically, if you wanna change all the success messages, you can just actually find that class and just tweak that color versus green, which could be used for things that are not success.

And you don't wanna change that per se, or blue is, again, like even more insidious than green and red, which kind of tend to map very closely. So we don't, we purged all of the references through a color in our code base, right? Because it made refactoring hard.

Now, under the hood, obviously colors are things that exist, but one of the things you can do is whether or not you're doing with your own utility classes, your own CSS variables we have you or with Tailwind, is sometimes, like, replacing the color set with something themed devalues.

And so I'll show a few different because we use multiple strategies for this. I'll kind of show you all of them. One of them is if I kind of pull out the derived color palette from our fun little design system. You've got these colors, they have their semantic meanings or primary secondary accent, which is yet just a little like the required button and stuff like that, and then this information success, warning, danger, and state.

Here's the issue, if people on your team, or you on a bad day have access to colors, you're gonna use them, right? So part of it becomes how do we basically limit the access that goes, which is somehow hiding them in your code base? And so let's say we didn't wanna say any kind of background, and I've slayed, those are just my various surface colors as well.

So Tailwind, we can go ahead and just kind of you can extend it, things of a Tailwind theme, and then you can replace them. And I feel this way a lot of any kind of UI kit and Tailwind in particular is there are a lot of colors. Let's not be too hyperbolic.

There's a lot of colors. There's also like, I think eight or nine different border radii settings, like eight or nine different box shadows. And if you have eight or nine box shadows, your team will use eight or nine box shadows, right? They will use eight or nine border radii.

And then you'll try to reuse something in a different part of the codebase and realize that everything looks like trash, right? And so kind of beginning to part of like implementing a design system being to maintain your codebase is taking the surface area of choice and constraining it as much as possible.

So let's look at how to do that in Tailwind, but like it could. We'll see CSS variables in a little bit. I'll show you a strategy that we literally shipped this past Friday, right? So I'll show you that as well and kind of just some of our thinking around it.

So over in here, I've got those colors that you saw earlier. One of the things I would say as a workflow thing, and for whatever set of tools that you have, is if you can automate this in some way, this is great. So we happen to use Figma, but there's always a version of this that'll work for you.

There are plugins. So, for instance, there's variables to CSS. This tool is great, because I can grab this case colors, and then I can either generate a Tailwind theme or honestly CSS variables, right? And from the design system in Figma generate all of the CSS for variables that I might need, right?

And so this involves two things, though this involves how you structure your code, and also how you collaborate with the design team. Because if they're just using hex codes willy-nilly, then it doesn't really matter, like you're kind of stuck with that. So it involves a little bit of like, kind of like that collaboration working together.

But if you can kind of Come up with this system, you can first of all come up with a set of colors that you use and generate that, so at least you have a more defined set of colors. The other thing that you can do to take it one step further is we actually don't use those colors in our code base at all, right?

They're aliased to from, if you could see these component colors. And Ash and I worked on this for honestly two months because figuring out a naming convention that didn't drive us insane was really, really hard, and it will be different in your application. There's no silver bullet for solving this, but we then have, and this is just a smaller subset of, okay, we've got button primary default, button primary hover, button primary active, right?

I've got that for disabled buttons, ghost buttons, secondary buttons, input fields while they're disabled, and so there's a bunch of name colors that do alias to those colors, right? These are the only colors you're allowed to reference in our code base, right? Because we just literally hide the rest of the color.

You can't get the rest of them. And so then you just say, okay, this button should have reference to CSS variable that, we use CSS variables. It could be anything you want, that is this color. So now we need to change all the primary buttons. We just tweak that one variable.

And so we have all of that kinda put in place and instead of even those dark colon stuff, we actually just have a set of CSS variables that relate to everything we use in the code base. And then when you switch them to dark mode, we switch the values of those CSS variables.

So if we wanted to add seven more themes, what's involved in that? Going into Figma, once Ash finishes that up, going to variables2css, going to Component Colors, hitting Ignore aliases, and getting these new CSS variables. And having whatever the selector is that puts into high contrast mode, like summer mode, whatever, right?

And we can swap these out, and this is where that kind of both designers and how they structure the design system. And then for you and the way that you structure your code base and the implementation of that design system, take things that, like it took us six weeks to refactor our code base to do this.

It will take about six hours, not even that right just honestly just running through the tests and like, our tests are good, but a little clicking around is usually helpful as well. And you know beta stuff like that and like adding another theme will then not take any work whatsoever, right?

And just swapping out another mode with another set of variables, adding maybe the stories and stuff like that that kind of updating the automation around it, will work. Because if we go to three or four themes, having again, a set of automation around this really helps and this is kinda what we have set up in storybook and when you can too, in our time together.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now