Abstraction is the real value of design tokens
Design tokens value lies in their simplification power.
Abstraction is a key principle in software engineering.
It’s a way to make complex systems easier, like breaking a big project into smaller tasks.
Focusing on the big picture allows you to ignore minor details. This approach simplifies the development process and accelerates the work pace. Developers can interact with parts of the system generally, without the need to understand every intricate detail of its operation.
In user interface (UI) design, abstraction can be achieved through design tokens.
Tokens are named entities that store visual design attributes, acting as a bridge between the design and development processes. They make complex systems easier to manage, leading to faster and more efficient work.
This simplified design process makes creating a consistent look on different devices and platforms easy. It's flexible and can grow with the product while keeping its main visual style.
Just the Right Abstraction
Using meaningful names is very important to get the right level of simplicity when using design tokens.
Semantic naming means picking names that explain the use or sense of a design token, not its look or content.
For example, a semantic name like color-error
is more appropriate than a token named color-red
.
This way, if the color representing errors changes from red to orange, the token's name remains valid. The name is tied to its purpose – representing errors – not its value – the color red.
However, color-error
doesn't specify the element to which it can be applied. We should enhance the semantic detail in our abstraction.
This brings us to a dilemma:
Should I assign a unique token to each element:
color-text-error
,color-surface-error
,color-icon-error
?Or create a single token for all elements that share the "error" status, like
color-ui-error
?
In the first case, we allow repeated information to keep control over different parts. Even if the error symbol changes later, the text and area won't change.
In the second method, we just need to remember one code for all error parts. It's easier to use but gives less control. It's tough to find one word that fits many situations. For instance, ui
is a term designers know, but developers may not.
If you opt for the latter, you should create a naming convention and taxonomy, and then share them with all design token users.
A trade-off decision
In the end, the choice is between control and simplicity. Deciding how detailed to make the abstraction is a balance between these two.
If you opt for more control, you might end up with repeated information but maintain a firm grip over different parts of the system.
On the other hand, opting for simplicity may make the system easier to use but gives you less control.