¿Qué son los design tokens?

Los design tokens son decisiones de diseño almacenadas como datos con nombre. Cada token vincula un nombre con un valor —brand-600 contiene un azul exacto, space-4 una separación exacta— y los tokens viven en un archivo neutral respecto a la herramienta, del cual se genera cada formato consumidor: CSS para la web, variables para Figma, recursos para código nativo.

Esa definición comprime tres ideas, y cada una carga parte del peso: un token es una decisión con nombre, los tokens se componen mediante referencias, y el sistema compuesto se exporta a cada consumidor. Este artículo —la pieza inicial de nuestra guía de design tokens— construye la definición paso a paso.

¿Qué significa “una decisión de diseño con nombre”?

Todo producto acumula decisiones de diseño: el azul de marca es este hex, el texto de cuerpo mide 16px, las tarjetas llevan este relleno. Lo que varía es dónde viven esas decisiones. En muchos equipos viven en la memoria de alguien, en una presentación de diapositivas o en una guía de estilo en PDF: lugares que una persona puede leer pero que nada puede ejecutar. Un token traslada la decisión a datos:

"brand-600": { "$value": "#2563eb", "$type": "color" }

El nombre es el asa de la decisión; el valor es su respuesta actual. Una vez que una decisión es dato, las herramientas pueden hacer lo que hacen: validarla, comparar dos versiones de ella, generar código a partir de ella, encontrar cada lugar donde se usa. Un PDF que dice “azul primario, úsalo para botones” necesita un intérprete humano; un archivo de tokens expresa la misma decisión en una forma sobre la que un paso de compilación puede actuar.

¿Cómo se convierten los tokens en un sistema?

Mediante referencias. El valor de un token puede ser el nombre de otro token, y ese único mecanismo convierte una lista plana de constantes en decisiones compuestas. La convención común es por capas: los tokens semánticos nombran funciones y apuntan a tokens primitivos que nombran valores —

"background": { "$value": "{neutral.50}",  "$type": "color" },
"accent":     { "$value": "{brand.600}",   "$type": "color" }

background → neutral-50 y accent → brand-600 son decisiones por derecho propio, independientes de lo que neutral-50 y brand-600 almacenen. “El acento es el color de marca” y “el color de marca es este azul” ahora pueden cambiar de forma independiente: un rediseño de marca edita la segunda afirmación, un tema reapunta la primera, y ninguno toca los componentes que consumen accent.

¿Cómo llegan los tokens al código y a las herramientas de diseño?

Mediante exportación. El propio archivo de tokens es deliberadamente neutral —JSON que no pertenece a ninguna herramienta en particular— y cada consumidor recibe una vista generada de él: propiedades personalizadas para las hojas de estilo, un bloque de tema para Tailwind, Figma Variables para el archivo de diseño, recursos clave-valor para plataformas nativas. Un solo origen, varias representaciones, los mismos nombres en todas partes.

Scale Composer funciona así de principio a fin: deriva la escala tipográfica, el espaciado y las rampas de color, además de los roles semánticos para tema claro y oscuro, a partir de una única escala compartida, y todo lo que deriva sale como un solo archivo de tokens DTCG junto con propiedades personalizadas CSS, un bloque @theme de Tailwind v4 y Figma Variables, con el hex acompañando a los valores OKLCH. Abre un sistema de tokens generado en Scale Composer: las secciones del archivo en un lado, y los mismos nombres representados como exportaciones de CSS, Tailwind y Figma junto a ellas.

¿Cómo se ve el mismo botón con y sin tokens?

Primero en lenguaje de guía de estilo, tal como lo pondría un PDF:

Los botones primarios usan el azul de marca (#2563EB) como fondo, con texto blanco.

Segundo en lenguaje de tokens:

{
  "color":    { "brand": { "600": { "$value": "#2563eb", "$type": "color" } } },
  "semantic": { "accent": { "$value": "{color.brand.600}", "$type": "color" } },
  "button":   { "background": { "$value": "{semantic.accent}", "$type": "color" } }
}

El contenido es el mismo, pero la versión con tokens lleva un rastro. Pregunta cuál es el fondo del botón y el archivo responde en saltos: button.background → semantic.accent → brand-600 → #2563eb, que es oklch(0.546 0.215 262.9). Cada salto es una decisión que puede cambiar sin perturbar a las demás: reapunta accent para un tema, cambia lo que almacena brand-600 para un rediseño de marca, desvincula button.background de accent el día en que el botón realmente necesite dejar de seguirlo. La frase del PDF contiene una única decisión fusionada; el rastro contiene tres separables.

¿De dónde viene el término?

Dos frases de historia: Salesforce acuñó “design tokens” alrededor de 2014, cuando su sistema de diseño tenía que servir a plataformas web y nativas desde un único conjunto de decisiones, y construyó herramientas que traducían un solo archivo de tokens al formato de cada plataforma. El término superó su origen: hoy el Design Tokens Community Group (designtokens.org) mantiene un formato de intercambio compartido sobre el que las herramientas de diseño y los pipelines de compilación han convergido en gran medida.

¿Por qué la industria convergió en los design tokens?

Por la deriva: los archivos de diseño y el código entregado discrepan sobre valores que se supone que son idénticos. La deriva no tiene solución de proceso: pedir a diseñadores y desarrolladores que mantengan dos listas sincronizadas trata un problema estructural como un problema de disciplina, y las listas vuelven a divergir en la siguiente fecha límite. La versión intuitiva es casi aritmética: dos copias de cualquier cosa, mantenidas por manos distintas, se separan; cuantas más copias, más rápido se separan. Los tokens cambian la forma del problema para que no quede nada que sincronizar: una copia es el origen, y las otras N−1 son vistas generadas de ella. El archivo de diseño y la hoja de estilo coinciden porque ninguno se mantiene a mano; ambos se leen de las mismas decisiones.

¿Qué no son los design tokens?

No son solo variables. Las variables son el mecanismo de almacenamiento; los tokens son variables más la disciplina —nombres basados en funciones, capas, referencias— que hace que las decisiones almacenadas sean navegables. Un --blue puede contener cualquier cosa que su autor haya escrito; un sistema de tokens está estructurado para que quien lo lea pueda saber para qué sirve un valor y qué depende de él.

No son solo para equipos grandes. Las organizaciones multiplataforma nombraron el problema primero, pero un único diseñador que rediseña la marca de un sitio pequeño se enfrenta a la misma deriva a menor escala: los mismos valores duplicados entre un archivo de diseño y una hoja de estilo, divergiendo en silencio.

No son una función de Figma. Figma Variables es un consumidor de los tokens —un lugar donde aterriza una vista generada— no el lugar donde los tokens se definen. Tratar a cualquier consumidor concreto como el origen vuelve a meter las decisiones dentro de una sola herramienta, que es precisamente la situación que los tokens existen para terminar.

Rastrea una decisión de principio a fin

Una definición se asienta una vez que tú mismo has seguido una cadena real de saltos. Abre los roles semánticos en Scale Composer y rastrea un token — elige accent, síguelo hasta el paso primitivo al que hace referencia y el valor almacenado allí, luego cambia la semilla y observa cómo la decisión superior se mantiene firme mientras la respuesta que hay debajo cambia.