Universal color system
Color naming in interface design systems
Sep 11, 2023
Universal color system
Color naming in interface design systems
Sep 11, 2023
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.
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.
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.
This blog rarely updates. Subscribe to receive updates.
This blog rarely updates. Subscribe to receive updates.
This blog rarely updates. Subscribe to receive updates.
Scalable interface design
Eight key concepts
Dec 18, 2021
Scalable interface design
Eight key concepts
Dec 18, 2021
Scalable interface design
Eight key concepts
Dec 18, 2021
Essential tools
A collection of useful software
Nov 17, 2020
Essential tools
A collection of useful software
Nov 17, 2020
Essential tools
A collection of useful software
Nov 17, 2020
Playbook
Concepts for design and development processes
Jan 2, 2019
Playbook
Concepts for design and development processes
Jan 2, 2019
Playbook
Concepts for design and development processes
Jan 2, 2019
How to value a logo
Design comprehension
Mar 31, 2015
How to value a logo
Design comprehension
Mar 31, 2015
How to value a logo
Design comprehension
Mar 31, 2015
Working with friends
Freelance life
Aug 14, 2014
Working with friends
Freelance life
Aug 14, 2014
Working with friends
Freelance life
Aug 14, 2014