Design Systems, Design Tokens and the eternal battle between efficiency and flexibility

From an old article: https://medium.com/@silversonicaxel/design-systems-design-tokens-and-the-eternal-battle-between-efficiency-and-flexibility-1feaaaf987c7

It’s 2021.

It’s been seven years since the concept of Design System was concretely defined by Google with its Material Design in 2014.

And it’s five years since Design Tokens made their first official appearance due to a great idea that became implementation from Salesforce people within their Lightning in 2016.

If you would like to know more about Design System, here is an interesting link on the internet https://www.invisionapp.com/inside-design/guide-to-design-systems/.

You are very familiar with the Design System concept but you feel a newbie regarding Design Tokens, take a tour here https://www.invisionapp.com/inside-design/design-tokens/ and if you have 40 minutes more, watch this awesome presentation https://www.youtube.com/watch?v=wDBEc3dJJV8.

You might be aware of the main reasons why Design Systems and Design Tokens are important nowadays, such as Unique source of truth, Scalability, Maintainability or Theming.

As well, you might be also aware that the internet is already full of great examples, tutorials, opinions, suggestions to highlight the best approaches to implement a great Design System with a great Design Tokens setup.

Within this evolution and exposure, the trend is becoming more and more popular across big companies that are implementing their own systems and share them to the world. Why so? It’s a signature, it’s the identity and personality and it helps in efficiency and flexibility.

But the question is, which is the best approach if we are searching for efficiency and flexibility?

It’s a constant challenge indeed between design and development, between web and mobile, between reusability and exception, between flexibility and efficiency. It is a to-be or not-to-be matter.

The common goal is to share as much as possible in terms of reusability. Specially if the Design System we are working on is supposed to serve multiple themes. The less Design Tokens you define, the more your Design System is maintainable and we achieve efficiency.

The more Design Tokens you need, the more your Design System is customisable and we achieve flexibility.

The balance between identical multi themes and different multi themes resides in this, the ability of creating a proper design tokens structure, that let you be different and faster.

How to work on a multi theme Design System?

From a theoretical point of view it is very simple. It is just necessary to define a list of all the Design Tokens necessary to implement from a development point of view all the design decisions and reuse them across all the layouts of the Design System, for all the provided themes. Easy right?

When we leave the theory and face the practice, things might become more complicated. How come?

• We have design and development for desktop applications and native applications.
• We have one unique Design System that is used for multiple themes and some differences are strictly necessary.
• We have to take into account the default implementation mode but we have to manage also the dark mode.
• We have to consider that Design Tokens might require different types of output accordingly to the amount of tools that the consumers are using.
• We have the requirement of creating a new theme in a day.
  And the list can grow.

Let’s try to focus on some questions we are going to ask ourselves along the way.

Do I need some specific decision, tokenisable in the same way for all themes, that can’t be applied with a current design token?

Create a new token, but that will have a cost in terms of maintainability because it takes more time to maintain more Design Tokens during the creation or the update of a theme.

Do I need some specific decision, diverging from the default behaviour but just for one or few specific themes?

Create a new exception token, but that will have cost in terms of reusability, because you might end up to have more Design Tokens not shared across all themes of your Design System.

OR

Avoid diverging and make a compromise following an already defined design decision, that has a cost in terms of flexibility, because a design decision should be tuned to be aligned with the different default layout of your Design System.

So what is the best answer?

Taking these types of decisions it makes you feel like in an attempt of moving a “node of a web”. It becomes pretty visible under your eyes that with any little movement, everything moves.
So what is the best answer? There is no best answer. Every Design System has its own answer.
Or we can assert that the challenge to achieve the best answer can’t be too far from a good balance. Otherwise the “web” is going to break somewhere.

Designers and developers should become best friends and cooperate strictly with each others taking into account the deep meaning of every Design Token of the Design System, thinking of all the good and bad consequences that every decision has, understanding the impact of any new token creation or of an existing token update, measuring efforts in this balanced challenge.

An example can help

Let’s analyse few lines of code to understand what is the good balance between.

❌ a too efficient oriented approach — super easy to maintain but difficult to customise

$color-text: 'black';

❌ a too flexible oriented approach — super easy to customise but difficult to maintain

$color-text: 'black';
$color-text-label-small: 'midnightblue';
$color-text-label-medium: 'indigo';
$color-text-label-large: 'navy';
$color-text-error-input: 'red';
$color-text-error-textarea: 'darkred';
$color-text-error-fileuploader: 'firebrick';
$color-text-error-checkbox: 'maroon';
$color-text-error-radio: 'tomato';
$color-text-error-image: 'orangered';

✅ a balanced approach — compromised and easy to maintain and customise

$color-text: 'black';
$color-text-label: 'navy';
$color-text-error: 'maroon';

The only way is to try it out.
So enjoy the challenge and have a good balance!