Design Tokens en tu Design System

Si estás comenzando a trabajar en un Design System, considera hacer una pausa y define primero tus Design Tokens.

Read the English version of this article here

¿Qué son Design Tokens?

Si buscas Design Tokens (DT) en Google, seguramente llegarás a la genial Jina Anne, quien acuñó el término con su equipo, mientras trabajaban en el Lighting Design System de Salesforce.

Si gustas, puedes darte una vuelta por un artículo (en inglés) como este de Louis Chenais, y este episodio del podcast de Smashing Magazine en donde profundizan en el tema.

En simple, diremos que el término hace referencia a las unidades más pequeñas (decisiones) que te da un Design System (DS) para construir tus elementos UI, como componentes/átomos abstrayendo su valor. Si conoces sobre Atomic Design, entonces haz cuenta que DT son los eones (ions) antes de siquiera formar átomos.

Extending atomic design.

¿Antes de siquiera formar átomos?

Según Brad Frost:

“Atoms are the smallest functional units of matter, despite being composed of smaller particles such as protons, neutrons, and electrons.”

Incluso en esa definición el bueno de Brad habla de smaller particles. No me mires a mí, pregúntale a Brad.

“In the world of UI, design tokens are subatomic particles. The design token color-brand-blue is a critical ingredient of a UI, but it’s not exactly functional on its own. It needs to be applied to an “atom” (such as the background color of a button) in order to come to life.”

Entonces, en la práctica DT serán elementos que sirven para construir átomos. Partiremos con:

• colour (background, text, border, etc.)
• typography (Family, line-height, font-size, etc.)
• drop-shadow
• gradient

Ahora, piensa en las decisiones de diseño que no siempre se representan visualmente como un ente aparte e independiente.

• spacing/layout
• border-radius
• border-width
• z-index (depth)
• opacity
• time

Al crear y organizar DT estamos documentando y exponiendo todas las decisiones que más tarde se convierten en opciones para el resto del equipo de diseño y desarrollo, y que pueden ser compartidas, mantenidas y reutilizadas de manera sencilla. La idea es reducir las decisiones sólo al abanico que provee tu design system, y así manter escalabilidad y consistencia, y dar alternativas en caso que sea necesario romper los patrones.

Si documentas y expones DT en tu design system reduces confusiones, ya que estableces un lenguaje común entre diseño y desarollo, con nombres acordados y sugerencias al usar las opciones. Muchos de estos DT pueden ser reproducidos y documentados en tu software de diseño UI favorito, Figma, Sketch o Adobe XD. Aplausos 👏🏻 para Adobe por empujar la idea del Design System package (dsp) format.

Plugins como Puzzle Tokens permiten controlar tokens en sketch usando Sass, automatizando el proceso.

¿Cómo implementamos Design Tokens?

Al implementar DT debemos tener en cuenta lo que hacemos en diseño y en desarrollo, simultánemante. La librería o UI kit de Sketch o Figma de tu DS debería estar sincronizada con el código que provees a los developers (componentes, patrones, templates, etc) o al menos medianamente al día.

A continuación, te mostraré un ejemplo de DT usando variables Sass.

Ejemplo de design tokens usando Sass

Esto es un ejemplo básico de naming en variables Sass, elementos clave: valor que pueden ser fácilmente documentados. Las variables (tokens) en Sass son la forma de guardar valores y distribuirlos de manera simple al equipo de desarrollo, a través de tu DS. Más tarde, los componentes/átomos usarán estos tokens para ser rápidamente configurables, themeables, etc.

Un elemento clave en Design Tokens es cómo los nombras. Te aconsejo definir tus propias reglas, pero ten en cuenta la abstracción del valor. Prefiere usar el rol en lugar del valor en el nombre.

En el segundo caso, el nombre de la variable nos dice de dónde viene (ds), tipo de token (color), su uso (text) y rol (primary).

El verdadero poder de Design Tokens

Design tokens pueden ser abstraídos un nivel más y así cubrir las necesidades de consistencia en todas las plataformas. El caso más común para esto, es una compañía que debe mantener distintos productos alineados y funcionando medianamente igual, aunque usen tecnología distinta, como en el caso de Salesforce con Lightning Design System. Aunque también está el caso de compañías que deben mantener el mismo producto en varias plataformas, como Netflix y Spotify.

En ambos casos, debes publicar y mantener estas decisiones paralelamente en distintas tecnologías, ¿por qué? Porque tus variables Sass pueden cubrir tus proyectos web, pero imagina que tienes además un proyecto usando Less y otro en React injectando variables javascript en style-components, súmale a esto iOS (SWIFT), Android (XML), etc.

A través de un archivo JSON o YAML puedes configurar una herramienta como Theo (Salesforce) o Style Dictionary (Amazon) para distribuir tus Design Tokens en varios formatos, manteniendo sólo un archivo de configuración que escribirá Sass, Less, XML, SWIFT, etc. Es aquí donde radica el poder de usar DT.

Básicamente, documentas y mantienes todos tus tokens en un archivo JSON:

Mientras, Style Dictionary transforma estos valores a Sass para web:

XML para android:

SWIFT para iOS:

Te recomiendo el artículo de Cristiano Rastelli “How to manage your Design Tokens with Style Dictionary” donde explica con mucha más profundidad el uso y configuración de Design tokens en Style Dictionary.

Style Dictionary Demo

Para terminar, ten en cuenta que documentar y diseñar tus DT tempranamente, te permitirá detectar problemas de inconsistencia en interoperabilidad entre plataformas, podrás establecer las relaciones entre elementos de manera metódica y anticipar cambios que se puedan implementar rápidamente en distintas plataformas.

“A stitch in time saves nine.”

Si bien el concepto de Design Tokens parece ser un poco técnico, lo cierto es que está más relacionado con el diseño y la arquitectura de un design system que con código. DT está directamente ligado a la organización y planificación para escalar y mantener un sistema que pueda abrirse a ser alimentado por distintos equipos, y que al mismo tiempo, pueda entregar valor de manera agnóstica y simultánea a todos los productos y equipos por igual, sin importar la tecnología o código que haya detrás.

Referencias y enlaces de interés:

• Lightning Design System, design tokens https://lightningdesignsystem.com/design-tokens/
• Design tokens for dummies, Louis Chenais https://uxdesign.cc/design-tokens-for-dummies-8acebf010d71
• Smashing Podcast Episode 3 With Jina Anne: What Are Design Tokens? https://www.smashingmagazine.com/2019/11/smashing-podcast-episode-3/
• Extending atomic design, Brad Frost https://bradfrost.com/blog/post/extending-atomic-design/
• Theo, Salesforce https://github.com/salesforce-ux/theo
• Style Dictionary, Amazon https://amzn.github.io/style-dictionary/#/
• How to manage your Design Tokens with Style Dictionary https://didoo.medium.com/how-to-manage-your-design-tokens-with-style-dictionary-98c795b938aa