¿Qué es un «design token»?

De qué hablamos cuando hablamos de “Design Tokens”

Si estás aquí, leyendo esto, probablemente sea porque te interesa saber algo más sobre este término que acuñó Jina Anne y el equipo de Salesforce durante el proceso de diseño y desarrollo del “Lightning Design System». 

En la web de Salesforce, la definición de un «design token» es la siguiente:

“Los tokens de diseño son los átomos de diseño visual del sistema de diseño – específicamente, son entidades con nombre que almacenan atributos de diseño visual. Los utilizamos en lugar de valores codificados (como valores hexadecimales para el color o valores de píxel para el espaciado) para mantener un sistema visual escalable y coherente para el desarrollo de la interfaz de usuario.”

Salesforce

Un design token puede ser un color, un estilo de texto, una cantidad de píxeles de espaciado o de radio en un borde…

Con qué nos quedamos de la definición de Salesforce

Profundizando en la definición de Salesforce podemos observar algunos aspectos que nos ayudarán a entender mejor qué es un design token. 

Atomic Design

Por un lado, la referencia al diseño atómico de Brad Frost. Los design tokens son los elementos más básicos del sistema de diseño, lo que para nosotros los diseñadores serían los cimientos o “foundations”. Los tokens no pueden descomponerse en elementos más pequeños y, por lo general, no funcionan de forma aislada.

El nombre es la clave

Los tokens son entidades “con nombre”. Lo ideal sería construir estos tokens junto al equipo de desarrollo y consensuar la forma en la que vamos a nombrar cada token, encontrar un sistema que defina el token y contribuya a construir un sistema flexible y escalable. Por ejemplo…

Hay varias maneras de nombrar los tokens. Lo importante es que encontréis vuestra metodología ideal junto con vuestros desarrolladores de confianza y que esté todo bien documentado.

¿Por qué no llamarlo directamente “lila”?

Una de las ventajas de definir tokens es poder aplicar cambios de manera rápida y consistente. ¿Y si mañana hay un rediseño de la marca y se decide cambiar su color principal? Si definimos el color como primario o secundario solo cambiaríamos el hexadecimal asociado a ese token pero la nomenclatura usada en todo el sistema seguirá siendo válida.

Representan valores codificados

Como hemos visto, parece que se trata de declarar variables. Seleccionamos, por ejemplo, un color en formato hexadecimal y le asignamos un nombre que nos ayude a darle sentido. Entonces… ¿Qué tienen de especial los design tokens?

  • Forman parte de una metodología agnóstica, es decir independiente de cualquier plataforma o lenguaje.
  • Están alojados en una única fuente de verdad (source of truth). Tener el color de la marca definido en un único sitio es la opción más segura para evitar duplicidades y posibles errores (por ejemplo, cambiar el hexadecimal en un botón y olvidarte de otro). Esto es especialmente importante cuando hay varios equipos involucrados en el mismo producto (web, app, tv…) que deben funcionar de manera coordinada. 
  • Ayudan a mantener la consistencia a través de todo un producto o conjunto de productos, ya que cualquier cambio se propagará a todos los productos y plataformas.
  • Finalmente, podríamos decir que generan un lenguaje compartido, nos acercan al equipo de desarrollo mejorando la comunicación y fomentando la colaboración.

Tipos de design token

Para acabar de darle una vuelta más al asunto os diré que existen diversos tipos de tokens que encontraréis mencionados de forma distinta aunque el concepto suele ser similar.

Global tokens

Los tokens globales son aquellos que se refieren a los aspectos más básicos del diseño. Normalmente son valores estáticos, como un código hexadecimal para el color o una cantidad de píxeles para el espaciado. 

Si cambiamos el hexadecimal del token global, y le damos otro valor, por ejemplo #028F4E, todos los elementos que usen ese color primario (botones, textos, iconos…) cambiarán con esta modificación. Se recomienda usar solo tokens globales cuando no haya alias para su caso de uso.

Alias tokens

Los alias token se relacionan con un contexto específico de uso. Los alias ayudan a comunicar el propósito previsto de un token y permiten controlar el alcance de los cambios. Los alias token son los más recomendables, ya que ayudan a asociar el significado, el contexto y/o la intención de los tokens que se están aplicando. Es una buena manera de asegurar la escalabilidad del producto. 

Imaginemos que necesitamos cambiar un color en un contexto muy concreto. Si cambiamos el hexadecimal del token global, ese color se cambiará en todos los elementos que lo usen (iconos, tipografía, colores de fondo…). Para evitar esto podemos crear alias para referirnos a estos contextos concretos. Por ejemplo…

En este caso, si queremos cambiar el rojo del color del borde, podríamos cambiar la referencia al token global de esta forma -> ds.color.border.error = color.error.800.

Component-specific tokens

Este es el tipo de token es probablemente el que cuesta más de entender. Adobe los define como representaciones exhaustivas de cada valor asociado a un componente. Generalmente se heredan de los alias tokens pero están nombrados de forma que permite a los equipos de desarrollo ser lo más específicos posible al aplicar los tokens en el desarrollo de componentes. No recomiendan usar component-specific tokens de manera intercambiable con otros componentes, a menos que uno sea derivado del otro.

De esta forma, añadimos un nivel más de especificación. El borde del color rojo 500 puede aplicar a varios tipos de componente como por ejemplo alerts, inputs, popovers… El component-specific token nos permite concretar y especificar el color del borde para el componente concreto, en este caso, el input field.

Conclusiones

Los sistemas de diseño han llegado para quedarse y para conseguir unos productos digitales más escalables, más consistentes y más flexibles. Desde mi punto de vista, los design tokens y en general los sistemas de diseño traen algo muy bonito, la comunicación y el trabajo conjunto con el equipo de desarrollo. Por qué en estos contextos, más que nunca, trata de consensuar, entenderse y trabajar como un solo equipo.

Referencias

Atomic Design

https://atomicdesign.bradfrost.com/table-of-contents/

Design Tokens

https://www.invisionapp.com/inside-design/design-tokens/

https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421

https://specifyapp.com/blog/introduction-to-design-tokens

https://m3.material.io/foundations/design-tokens/overview

https://www.uifrommars.com/design-tokens-que-son-ventajas/

https://www.lightningdesignsystem.com/design-tokens/

https://docs.tokens.studio/getting-started

https://spectrum.adobe.com/page/design-tokens/

Jina Anne

https://www.youtube.com/watch?v=q5qIowMyVt8&ab_channel=DesignSystemsAdvocate%2CJinaAnne

https://www.youtube.com/watch?v=ylDed18OVdY&ab_channel=Figma

Comentarios (0)

No hay comentarios. Sé el primero en comentar.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.