Design System – Colors, Variables and Tokens!
This week, we realized that there are a few things we need to do to button-down our use of colors in a way that makes sense, not just for designers but also for developers.
As we find inspiration on what others are doing, we will make a couple of changes in the design system when it comes to colors.
- Select UI colors using HCT color methodology.
- Adopt a similar variable/token naming strategy as Material Design
HCT (hue, chroma, tone) Method
As suggested by team members, the HCT color selection methodology has a few advantages:
- Accessibility
- Standard calculation method for color selection rather than by doing manual contrast calculations. This allows for all selected colors to be separated and distinct-enough from each other that users can see color differences in their applications.
- Perceptual accuracy
- HCT allows for seeing colors more accurately at a perceptual level.
- Consistent lightness and colorfulness
- Consistent lightness and colorfulness across hues.
- Precise color and tonal accuracy
- More precise color and tonal accuracy, especially in dark shadows and richly-saturated colors.
- Higher dynamic range and wider color gamut
- Provides a wider color gamut and higher dynamic range than typical camera targets.
In our team, we have 3 people currently working on this. Not only are we selecting colors, but also creating a color-use system that all users can understand.
Building logic use into the colors allows for less dependence on people but something we can document and anyone looking at it would be able to understand regardless of their specialty.
Tokens
A few of the questions we had as a team while producing the design system were, how can we make it so that developers and designers understand all the pieces used in the design system, but at a development level?
One of the things that applications such as Figma and PenPot allow is for designers to define the names of each of the elements used in a design. We create variables names for stuff like fonts and colors. However, while that’s helpful, we also have to have logic behind the naming so that our developer friends are not confused by the use of variable names in the design system.
For this purpose, design system creators often use a token system that ensures naming between the design system and development is consistent, predictable, and useful.
Material design has a robust naming idea around tokens. It works a little like this:
The types of tokens are:
- Reference tokens
All available tokens with associated values - System tokens
Decisions and roles that give the design system its character, from color and typography, to elevation and shape - Component tokens
The design attributes assigned to elements in a component, such as the color of a button icon
We consulted with the team members and it seems like a good strategy. Right now, we don’t have any of the reference or system tokens but we use component tokens in some capacities. The idea is to create and organize the naming conventions around the token ideas from Material. We may still decide to change some of the naming conventions but keep the general idea.
Note that we don’t have the intention of replacing current tokens. The process would be to add new ones that developers would begin using over time while keeping the ones we already have.
What this means for us in the design system, is that we will change our design variables to reflect this organization and when communicating the changes to the dev team, we will provide tables showing all the variables/tokens used. It will also contain which elements of the design system are included in a reference, system, or component token.
If you would like to participate of this effort, you’re welcome to join us here:
Our channel is dedicated to working on the design system. For general Visual Design questions, you can access our team here:
https://matrix.to/#/#visualdesigngroup:kde.org