Naming colors

I believe the developer is talking about Material Design’s color systems. This involves not only creating generic color names (blue-40, blue-50, …), but going an extra step to assign colors to where and how they will be used.

Here’s the page: Color system – Material Design 3
Here, you’ll notice that the colors have “roles” that go beyond just primary or accent. Each color concept has “groups” which are basically combinations of colors that will always appear together. For example, text on top of the primary color will always be the on-primary color.

This system can be taken another level deeper, where the colors are defined on the component level. I found this article to be super helpful to grasp the different levels of color naming: The Practical Guide to Naming Design Tokens | UX Collective

So it depends—is the developer expecting you to just change the colors on the global color like blue-50 level? Because in that case, you’re right—it will be a total mess. Or is he talking about the component level like button-primary-background?

I would suggest that you ask the developer to provide you with the list of colors he is referring to, so you can see at which level he wants you to name these colors.

Hi @Jenny_Seong
Thank you so much for taking the time for such a great answer.
Yeah, the developer is probably referring to naming the colors exactly as they are named in the Material Design system. He’s using Flutter, and from my understanding, there’s a plugin or builder that basically assigns all the colors in the right place, based on the color names.

The problem is, I didn’t assign the colors in the same way Material Design did, I assigned them based on the app I am designing, so even if I was to name some colors in the same way, if they don’t get hard coded per component and instead assigned automatically, that’ll be a total mess.

I’m trying to find out if this ever happened to someone else, or am I the first one meeting this problem 😛

Going through it rn 😂

I think this Material Design’s approach to color definition is a great thing. It is not about forcing you to use the same color for some components. It is more about naming conventions and dependencies between colors, which makes it much easier to maintain themes inside of the application easly.

Example:

Primary - color for the background, onPrimary - color on the background (for example text color), PrimaryContainer - not sure, probably card / some other box color, onPrimaryContainer - color on the background (text color) of PrimaryContainer

It is a set of colors which work together very well. Developer doesn’t care what value Primary, OnPrimary is. He just needs to know that this particular component has to use Primary and OnPrimary. Designer can change the definition of Primary and OnPrimary - the application will change the colors in every place where this definition was used. It is the main advantage. The other advantage is you have to create color sets instead of using different colors on all components. For developers it is a management chaos if every screen has different sets of colors.

Material Design also is not limiting your number of color sets. You can create new ones, beside using the standard ones. It is just “forcing” you to declare the colors exactly the same as developers are recommended to declare them. It makes the definitions well structured and you can then easly change the colors used accross the app much easier, as developers will not have to go to edit values on screens, but will instead edit the theme of the application. Believe me, it will be a real time saver if you need to change the colors in the application.

The same goes for typography - you delcare textStyles and users can use that in their setup too.

Example: component in the app can have color MaterialTheme.colorScheme.background with text color MaterialTheme.colorScheme.onBackground, but also MaterialTheme.colorScheme.someNewColor with MaterialTheme.colorScheme.OnSomeNewColor

You should also declare all common UI parts, like buttons, popups and other things the same in Figma, although it is not about Material Design. It is just a good practice. Think of it as playing with legos. You give lego parts to developers and they build screens using those lego parts. You can then easly change how the defined lego parts look like and the whole application will be changed accordingly.

Found a great example on Figma: https://www.figma.com/community/file/1036262363837856233

More resources on the topic: