Naming colors within an interface design system can often pose challenges and consume a significant amount of time. Finding a suitable approach is crucial for maintaining consistency and flexibility. In this blog post, I will share my journey and present a comprehensive approach to naming colors within a design system.
The initial approach: Literal names
At the outset, I believed that the simplest way to name colors would be to use their literal names, accompanied by specifications such as tint or shade, similar to the approach adopted by Tailwind:
gray/500
blue/500
purple/500
green/500
red/500
...
While this method seemed straightforward, I soon discovered its limitations. Changing a blue color to purple would necessitate manually modifying every element that used the blue. This lack of flexibility made me seek an alternative approach.
Exploring abstract names
To address the inflexibility of the literal naming approach, I experimented with more abstract names that could accommodate any color and be easily modified later. This resulted in the following naming convention:
neutral/500
primary/500
secondary/500
positive/500
critical/500
...
Utilizing an abstract naming convention was a step in the right direction. However, it failed to convey how colors were utilized within the design system, making documentation a challenging task.
Assigning functional names
In order to provide clarity on color usage, I decided to name colors based on their specific functions. This approach resulted in names such as:
background/page
foreground/neutral
border/primary
...
While this method enhanced overviewing the system, it also meant that multiple tokens could potentially reference the same color. For instance, the following tokens would represent the same color:
background/primary
foreground/primary
border/primary
Embracing Figma's variables
Fast forward and Figma's variables to the rescue, I could combine the aforementioned approaches and created two variable collections:
Primitive colors
Semantic colors
Tokens within the semantic collection refer to colors from the primitives collection. Consequently, when changes are made to primitive colors, the semantic colors automatically update.
At present, this hybrid approach has proven to be highly robust. It allows for effortless color modifications while offering a clear overview of color usage throughout the system.
If you are interested in the specifics of my token naming or wish to adopt this approach for your own projects, feel free to download the accompanying Figma resource here.
I hope you found this blog post helpful. I encourage you to share your experiences with color systems and provide feedback on any aspects you would modify or improve over at Twitter.
