En un principio, yo también era de los que pensaba que los design tokens habían llegado para complicar el proceso de un sistema de diseño y de interfaces de usuario como tal, incluso pensaba que limitaban la creatividad y la libertad para diseñar. Pero cuando entendí su poder, comencé a amarlos y respetarlos a tal nivel de considerarlos la pieza fundamental de un sistema de diseño.

Pero bueno, para poder entender bien esta ecuación, comencemos por el principio.

¿Qué carajos son los design tokens?

Uno de los beneficios que ofrece tener un sistema de diseño y en mi opinión el que más aporta en un diseño de interfaz, es la consistencia de un producto digital.

Hablar de consistencia es hablar de elementos que estén diseñados de manera coherente siguiendo patrones establecidos para que la identidad y el lenguaje del sistema de diseño no se pierda aún cuando el producto sea muy robusto. Pues bien, los design tokens son los responsables de esta consistencia.

Un design token es el valor indivisible de los elementos que conforman un componente. Tanto en diseño como en desarrollo, un componente se compone de varios elementos que forman un grupo.

Composición

Un botón básico se compone de los siguientes elementos:

• Texto
• Background
• Padding
• Border

Cada elemento de este botón tiene unos valores (tokens), en el caso del texto por ejemplo es uno poco polémico ya que este elemento está compuesto de varios tokens (font-family, font-size, vertical-height, weight, etc), es decir, que podríamos definir el texto como un componente según la metodología de Brad Frost y Atomic Design donde una molécula es una composición de dos o más átomos.

¿Interesante debate verdad? Pero hoy no es el caso.

Volvamos a los tokens; tomemos de ejemplo entonces el fondo o background, este tiene un valor (token) que es el color, tanto en el estado default como en el hover, active y demás; los bordes también tienen un valor dependiendo de la forma que queremos darle al botón (2px, 4px, 8px, etc).

Y por último y no menos importante tenemos el espaciado o padding, que proporciona al botón el margen entre el texto y el fondo.

Todos estos valores son indivisibles, pero son dinámicos, es decir, el botón tiene un fondo o background de color “verde” (#1F8A70), este valor es indivisible pero es dinámico porque en un futuro podemos determinar que ese mismo botón ya no tendrá el “verde” (#1F8A70) en el fondo, pero puede ser “orange” (#FC7300) y aquí es donde viene la magia, si tenemos un una buena composición de nuestros tokens, todos los botones y demás componentes que estén referenciados por ese color, cambiarán inmediatamente, a eso es lo que llamamos consistencia.

Composición de tokens y sus niveles

Como toda metodología existe un plan, para llevar a cabo una buena composición de tokens hay seguir un paso a paso y acá es donde se vuelve interesante todo este tema.

En la mayoría de sistemas de diseño se manejan 3 niveles de tokens, pero referenciarlos todos en este post sería un poco complejo, así que tomaré de ejemplo a Google y Material Design.
En la última versión de Material Design La documentación de los tokens, habla de 3 niveles que nombran de la siguiente manera:

• Reference tokens
• System tokens
• Component tokens

En esta pirámide, el token de abajo está referenciado por el token de arriba, creando una simetría para todo el sistema de diseño. Si logramos tener una buena administración de esta pirámide vamos a tener un sistema de diseño y una interfaz de usuario consistente y escalable.

Reference tokens

Los reference tokens o tokens de referencia son los que conocíamos anteriormente como las “opciones” dentro de un sistema de diseño. Es la zona donde agregamos todos las opciones de elementos y valores que podemos llegar a utilizar en nuestro sistema de diseño.

Ejemplo, para colores agregamos generalmente una paleta de colores de más o menos 5 o 6 colores, cada uno con su escala de tonos y un nombre. A este valor indivisible es lo que denominamos token.

Para los bordes generamos una escala de aproximadamente 10 o 15 opciones y le damos un nombre que sea fácil de referenciar.

Y así para el resto de los tokens.

System tokens

Los system tokens o tokens del sistema son los que conocíamos anteriormente como las “decisiones”dentro del sistema de diseño. En mi experiencia puedo decir que este es el nivel más importante dentro de toda la pirámide, aquí es donde definimos todos los tokens que usaremos en todo el producto y será el nivel encargado de darle consistencia y escalabilidad a nuestro sistema.

Lo que hacemos en este nivel es darle un “alias” a cada token, es decir, le damos un nombre genérico que sea fácil de replicar en todo el sistema de diseño y del cual los tokens de componentes se puedan referenciar sin problema.

En los colores ya no usamos hexadecimales o nombres particulares, si no que creamos un “alias” para definir cual será la función de ese color.

Ejemplo: background-primary, color-heading o outline-color y definimos cual será la función de cada uno.

En los bordes ya no usamos px si no que los nombramos por su peso o tamaño, ejemplo: xs, sm, md, xl o por fuerza: weak, moderate, strong, extreme.

Esta tarea puede llegar a ser la más compleja pero sin duda la más trascendental y creativa de la pirámide. De acá depende la escalabilidad y la consistencia del sistema de diseño.

Si tenemos varios componentes que usan los mismos tokens de sistema, con solo cambiar el valor del token de sistema cambiará el aspecto de toda la interface sin necesidad de tocar los componentes, eso se llama escalabilidad y consistencia, es por esto la importancia que debemos darle a esta tarea.

Component tokens

Llegamos a la parte final de la pirámide y de toda esta columna vertebral. Los components tokens o tokens de componentes es simplemente darle una referencia de un token de sistema a nuestro componente y como dije anteriormente, varios componentes pueden usar el mismo token de sistema.

Ejemplo, un botón básico en su estado default utiliza 4 tokens: texto, fondo o background, espaciado o padding y border.

Para realizar esta composición usamos los siguientes tokens:

Elemento	Token (system)
Texto	text-button
Background	background
Padding	top, bottom: sm / left-right: lg
Border radius	xs

Nombrando components tokens

Como en todos los niveles, los tokens de componentes también deben llevar un nombre, existe también una metodología que explica muy bien Nathan Curtis que proporciona una semántica y taxonomía para los nombres de tokens de componentes

También, Dan Mall recomienda, “Nómbralos como quieras” no hay que tener la formula perfecta, eso si, debe de existir una coherencia en todos los niveles de tokens y que todo el equipo logre entender la función de cada uno.

Así que lo explicaré como lo hago yo: generalmente comienzo con el nombre del componente, luego la categoría, propiedad y por último la variante y/o estado.

Para un botón principal default, sería algo así:

Teniendo un buen entendimiento y administración de los tokens, podemos crear sistemas de diseño escalables y productos digitales consistentes.

Mi recomendación es no tocar los tokens de componentes y solo modificar los tokens de sistema o tokens de referencia si es necesario.

Aunque entre menos opciones tengamos, más consistente y práctico será el sistema. Interviniendo solo los tokens de sistema, podremos replicar y escalar nuestro sistema sin perder consistencia en el diseño de los componentes, esto también reducirá el trabajo en el equipo de diseño e impactará en el desarrollo de nuevas vistas y/o componentes.

Esto también reducirá el trabajo en el equipo de diseño e impactará en el desarrollo de nuevas vistas y/o componentes.