Los tokens de Material Design: qué son y qué deciden

Un design token es un nombre para un valor de estilo, y diseño y código leen ese nombre en el mismo lugar. La guía de Material Design llama a los design tokens los bloques de construcción de todos los elementos de interfaz (en inglés), usados en diseños, herramientas y código. Define el token como un nombre parecido a código más un valor asociado (en inglés), como un nombre y un color.

Qué reemplaza un token

Un valor fijo en el código no explica nada. Escribes un código de color, y quien venga después tiene que adivinar para qué sirve. El token ya dice el motivo. La guía nombra cada token por cómo o dónde se usa (en inglés), y su ejemplo define el color de contenedor de un botón flotante.

El valor puede cambiar mientras el nombre sigue igual. La guía afirma que aunque cambie el valor final de un token, su nombre y su uso siguen iguales (en inglés). Actualizas un valor guardado, y toda pantalla que lee el nombre recibe el cambio de una vez.

La guía también plantea el beneficio práctico. Usar tokens en lugar de valores fijos puede simplificar el trabajo de construir, mantener y escalar (en inglés) un producto con design system. Lee eso como la postura de la propia guía, no como un resultado medido.

Las tres clases que define la guía

Material divide los tokens en tres clases, y cada una responde a una pregunta distinta. Los tokens de referencia guardan todos los tokens disponibles con sus valores asociados (en inglés). Suelen apuntar a un valor estático y no cambian según el contexto (en inglés). Los tokens de sistema guardan las decisiones y los roles que dan carácter al design system (en inglés), y ahí es donde se aplica el tema. Los tokens de componente guardan las propiedades de diseño asignadas a elementos de un componente (en inglés), como el color del icono de un botón.

Las clases forman una cadena. La guía dice que un token de sistema puede apuntar a tokens de referencia distintos según el contexto (en inglés). Lo mismo vale para el token de componente, que debe apuntar a un token de sistema o de referencia en vez de contener valores fijos (en inglés). Un botón que recibe su color de contenedor así apunta a un valor que puede cambiar sin tocar el nombre del token.

Qué informa el nombre

Un nombre de token se lee de izquierda a derecha, de lo general a lo específico. La guía separa las partes con puntos y va de la información más general a la más específica (en inglés). La primera parte nombra el sistema, “md” en el ejemplo de la guía. La segunda nombra la clase: ref para referencia, sys para sistema y comp para componente (en inglés). El resto comunica el propósito del token (en inglés).

O sea, el nombre funciona como una frase corta que dice la intención. Sabes dónde se usa un valor sin abrir ninguna hoja de estilo.

Dónde un rol de color se vuelve valor

El color es el caso más claro, porque el token es lo que une un rol con un número. La guía reparte el color en 26 roles estándar (en inglés), agrupados en seis familias que van de primario a contorno. Cada rol se vuelve un token con nombre estable, y el tema cambia solo el valor detrás de él. Lo que significa cada rol en el diseño está en el post sobre roles de color.

Los pares son regla, no sugerencia. La guía afirma que el sistema de color se construye sobre pares accesibles con contraste mínimo de 3:1 (en inglés). Advierte que combinar colores fuera de los pares previstos puede romper el contraste (en inglés) necesario para la accesibilidad visual.

Cómo el sistema produce esos valores

Con color dinámico, un único color de origen maneja todo el esquema. La guía describe el camino. Un color de origen genera cinco colores clave (en inglés) y el sistema los convierte en paletas tonales. Después, los tonos se asignan a los 26 roles de color (en inglés) en los temas claro y oscuro.

La asignación sigue el tono, porque el tono decide el contraste. La guía afirma que el tono determina el contraste (en inglés), y por eso sostiene las relaciones accesibles. Su espacio de color mantiene el tono estable mientras el matiz y el croma cambian. Eso es lo que permite al algoritmo emparejar tonos contrastantes (en inglés) sin que una persona revise cada par.

El esquema también lleva niveles de contraste. La guía lista estándar, medio y alto (en inglés), donde el medio mantiene al menos 3:1 y el alto llega a 7:1. Dice que un componente propio admite esos niveles usando los roles adecuados (en inglés), como contenedor primario con on primario.

Cómo obtener los valores

No hace falta copiar a mano el conjunto inicial. Viene listo para descargar. La guía entrega un tema base con tokens y valores por defecto como Design System Package (en inglés). Lo acompaña un plugin de Figma que genera el mismo conjunto de tokens como estilos para aplicar en un layout.

Cuándo el token no compensa

El token compensa cuando un valor se repite y el sistema tiene dueño. La guía nombra las condiciones en que ayuda menos. El token importa menos cuando una aplicación que ya existe usa valores fijos y difícilmente va a cambiar (en inglés) en uno o dos años. También importa menos cuando el producto no tiene design system (en inglés). Las dos describen la misma situación: poca reutilización, y nadie para mantener el mapa al día.

El error común

Un token que solo guarda un valor, sin decir qué decisión representa, es apenas una constante con un nombre largo. La guía apunta al otro lado. Un token de componente debe apuntar a un token de sistema o de referencia y no contener valores fijos (en inglés). Un token de sistema, a su vez, debe apuntar a tokens de referencia en vez de valores estáticos (en inglés) siempre que sea posible. Cuando la cadena se reduce a valores crudos, el tema deja de funcionar, porque no queda nada para cambiar.

Dónde la guía lo deja abierto

La guía define las clases y el formato del nombre. No dice cuándo un equipo debe dejar de usar un valor directo dentro de un componente. No define cómo versionar una ruptura de contrato entre diseño y código. Esas decisiones quedan con el equipo, y un conjunto de tokens no las toma por ti.

Un segundo límite queda fuera de la guía. El Design Systems 101 (en inglés) de Nielsen Norman Group describe un design system como estándares que necesitan un equipo dedicado, y trata el sistema como algo que sigue evolucionando. Un archivo de tokens es la mitad registrada de eso, y se mantiene solo mientras alguien mantiene el mapa correcto.

Es también por eso que la consistencia es una propiedad que un equipo mantiene (en inglés) en vez de un estado que los archivos alcanzan. La misma razón explica por qué la madurez de un design system no es lineal (en inglés), con sistemas que retroceden después del lanzamiento. Ninguno de esos puntos trata de tokens en particular, pero cada uno decide si un conjunto de tokens se mantiene en pie. Los tokens son solo una pieza de un sistema que necesita gente que lo cuide.

Adopta tokens cuando un valor se repite y alguien es dueño de los nombres. Déjalos de lado cuando la interfaz no va a cambiar y nadie va a mantener el mapa. Es la misma prueba de tener un design system, que es la decisión tratada en el texto sobre construir o adoptar uno.

Los tokens sirven a un sistema explicado en el texto sobre Material Design. Ese texto cubre de dónde vino el sistema y cómo difieren sus versiones. Lo que mantiene vivo un sistema después del lanzamiento, token incluido, está en el texto sobre design systems después del lanzamiento.