Universal color system

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.