Design tokens

Por norma general, todo aquello que nos rodea se considera así mismo como entidades volátiles, donde el todo es un conjunto de organismos que conforman una unidad mayor. Demócrito de Abdera, fundador del atomismo, definía el conjunto del todo como la unión de una serie de elementos llamados átomos que conforman el universo.

Trasladando esta consecución jerárquica al entorno del desarrollo de software, desde hace algunos años dio lugar a metodologías como Atomic Design, que a su vez forma parte de un concepto aún mayor conocido como Design System.

¿Qué es un Design System?

Es un método de trabajo donde se establece un lenguaje común para que el equipo de desarrollo de producto (programación, UX/UI) trabaje de manera colaborativa y resuelva los problemas de la misma forma.

La finalidad de un sistema de diseño es poder crear un producto que sea escalable, consistente e intuitivo. La construcción de nuestro propio sistema de diseño trae consigo una serie de ventajas que se presentan a continuación:

  1. Mantenimiento de la coherencia en el diseño
  2. Mayor eficacia en el diseño y UX
  3. Mayor velocidad en el desarrollo
  4. Mejora de la calidad y del valor añadido
  5. Mejora en la escalabilidad y crecimiento del producto
  6. Mejora en los protocolos y procesos de trabajo
  7. Mejora en la consistencia y colaboración entre los distintos equipos implicados

Hoy en día podemos encontrar muchos ejemplos y muy variados de Design Systems, donde podemos encapsularlos en tres niveles distintos en base a su complejidad. Por otro lado, existe un proyecto open source llamado Adele que recoge gran parte de los Design Systems construidos por las principales compañías a nivel mundial.

Atomic Design

Ahora bien, tras entender que es un Design System y la importancia que tiene, surge la gran pregunta, de qué manera podemos trasladar este enfoque a la práctica. La respuesta reside en Atomic design, una metodología que convive en sincronía con la atomización de los elementos de un diseño para la construcción de elementos más complejos.

La base de esta metodología consiste en la tokenización del diseño, donde partimos de la idea de que existen unas piezas principales, caracterizadas por su inmutabilidad y cuya función reside en la propagación hacia el resto de la aplicación existiendo una única fuente de verdad.

Design Tokens

Al hilo de la descripción de Atomic Design, los Design Tokens van muy de la mano por ser una parte esencial de un Design System, la cual, nos podemos dirigir a ellos como la caracterización del producto en sí mismo.

De la misma forma que cuando hablamos de la combinación entre un color rojo junto a una fuente texto de tipo cursiva nos viene a la mente la marca Coca-Cola, son estos elementos los que reservamos el derecho a llamarse Design Tokens, pues su naturaleza es la propia asignación de la esencia de la marca.

En este punto todo parece bastante claro, haciendo una pequeña retrospectiva de lo que llevamos hasta ahora, entendemos que la construcción ágil y escalable de un producto se basa en la tokenización de los elementos de diseño, para que de esta manera poder abordar futuros problemas con soluciones ya planteadas sin tener que reinventar la rueda en cada nuevo evolutivo, generando una consistencia y escalabilidad en cada caso de uso.

Por lo que, se nos presenta una nueva cuestión, ¿Qué deberíamos tokenizar en nuestro Design System? La respuesta es fácil, Todo aquello que entendamos como la identidad de la marca, como podría ser:

  • Colores, opacidad, sombras
  • Iconos
  • Fuentes de texto (nombre, espaciado, altura, etc.)
  • Bordes (estilo, interlineado, grosor, radio del borde, etc.)
  • Espaciado, puntos de ruptura, transiciones, contextos de apilamientos

Tras lo propuesto se engloban la mayor parte de las decisiones que el equipo de diseño y desarrollo deberían entender como Design Tokens. Sin embargo, debemos entender que para una buena propagación de dichos tokens a nivel de aplicación debemos separarlos por naturaleza, para así definir una correcta jerarquía de responsabilidades.

1. Primer nivel: Tokens principales que conforman el core de la entidad, En este punto los tokens no se han aplicado a ningún elemento de diseño.

  • Grid
  • Iconos
  • Niveles de sombras, opacidad
  • Color principal, secundario, etc (Color composition). Derivaciones del color principal para más adelante utilizarlos en los distintos estados web: hover, focus, link clicked
  • Fuente principal, secundaria, etc, así como los distintos estilos y variaciones
  • Espaciado, puntos de ruptura, transiciones, contextos de apilamiento

2. Segundo nivel: Definición de las entidades de alto nivel relacionadas con los tokens de primer nivel. Decisiones de diseño donde relacionamos la naturaleza visual de los elementos generales de la interfaz.

  • Color principal definido a enlaces de contexto principal
  • Fuente de texto principal de la aplicación

3. Tercer nivel: Token a bajo nivel que define el detalle de la interfaz de usuario de cada componente. Aquí se relacionan los tokens específicos con los tokens de segundo nivel destinados acotar casos concretos de la interfaz

  • Estilos de botón principal, secundario, etc (color, fuente de texto,etc)

Esta orquestación de la naturaleza de los tokens es primordial para generar una tokenización consistente y escalable en el tiempo. Uno de los mayores exponentes se encuentra bajo el contexto de Salesforce con su Lightning Design System

Digital Lover

Figma

En lo que se refiere al diseño y construcción de interfaces UI, durante años no existía otro como el ya tan conocido Sketch, eternamente ligado a las plataformas OS X y que, desde hace ya algún tiempo, ha dejado de ser la principal herramienta de los diseñadores, en favor de un no tan nuevo aspirante.

Figma es una herramienta de prototipado web y editor de gráficos vectoriales, que a diferencia de otras como sketch, se aloja en la web lo que le permite ser multiplataforma. Para un equipo de desarrollo de software, sería una información poco sugerente, de no ser porque además cuenta con un REST API que abre un mundo de posibilidades con respecto a la automatización de arquitecturas.

Dicho de otra forma, tras la construcción de un Design System y una correcta tokenización de la interfaz, los cambios realizados desde el equipo de diseño en Figma podrían propagarse hasta el producto final sin prácticamente la intervención del equipo de desarrollo.

La REST API de Figma nos provee de una serie de utilidades por la que el equipo de desarrollo es capaz de obtener los tokens de diseño en la interfaz que el equipo de UX/UI define en la herramienta. Solamente es necesario obtener el token de autenticación, así como el identificador del archivo definido en la url cuando accedemos a Figma web.

La llamada de la petición da como resultado un árbol de nodos con la siguiente estructura:

La complejidad en este tipo de automatizaciones reside en la imperiosa comunicación que debe existir entre diseño y desarrollo, dado que el árbol de nodos se define en base a la estructura de la construcción de la interfaz de diseño, es decir, el directorio de carpetas y vectores del propio archivo de Figma.

En el siguiente repositorio, podemos encontrar un caso de uso donde podríamos consumir los endpoints del REST API de Figma y conectar una arquitectura web automatizada, obteniendo un listado de iconos del UI Kit y creándolos en formato SVG en nuestro proyecto.

Tras el asombro inicial y trasladarlo a un caso real, probablemente hemos sacado dos conclusiones negativas.

  1. En un caso real donde el fichero Figma podría contener un UI KIT extenso, eso generaría un árbol de nodos bastante complejo donde se debería hacer una inversión inicial de tiempo nada despreciable.
  2. Si en algún momento el equipo de diseño modifica el árbol de directorios del fichero dejaría de funcionar dicha automatización.

Desde luego son riesgos de alto impacto no precisamente alineados con el principio de escalabilidad de un Design System. Para ello Figma cuenta con una segunda API de construcción de plugins que el equipo de diseño puede utilizar. Sin embargo, para este caso y dada la enorme comunidad de desarrolladores que tiene detrás, tenemos un plugin a nuestra disposición para mejorar la escalabilidad que precisamos.

Tokens Studio for Figma

Tokens Studio es un plugin que nos permite por medio de una interfaz exponer los Design Tokens y sincronizarlo directamente en nuestro repositorio del proyecto.

Los tokens se representan por medio de un fichero JSON, donde se establece el nombre, valor y tipo, pudiendo generar distintos temas por si nuestra aplicación pudiese tener distintos look and feel.

Style Dictionary

Ya tenemos nuestro fichero de configuración con los tokens del Design System, por lo que el último paso sería llevarnos esa tokenización a la arquitectura de desarrollo. Es aquí donde entra Style Dictionary, una librería construida por Danny Bunks, diseñador UX de Amazon, que por medio de los Design Tokens permite generar arquitecturas en distintas plataformas.

Con ello cerraríamos un flujo completo de propagación a todos los niveles, partiendo de una conceptualización de los tokens de diseño en Figma hasta la propagación en la arquitectura y generando una consistencia en todos los equipos. En el siguiente repositorio podemos ver una integración con Style Dictionary, donde partiendo de unos tokens generamos dichas variables en tecnologías como Sass, Flutter y Android de forma simultánea.

Una vez más se pone de manifiesto la importancia en la comunicación de equipos como UX/UI y desarrollo, pudiendo generarse un producto de gran escalabilidad y mantenibilidad a largo plazo, ampliando de esta forma la durabilidad en el tiempo.

 

 

Tags

He leído y acepto la política de privacidad
Acepto recibir emails sobre actividades de recruiting NTT DATA