Design Tokens: Qué son y cómo usarlos

Imagina que tienes que cambiar el color principal de un producto digital: un azul que se usa en cientos de botones, enlaces, iconos, bordes y fondos. Sin un sistema, tendrías que abrir decenas de archivos, buscar cada valor hexadecimal a mano y cruzar los dedos para no olvidarte de ninguno. Con los design tokens, solo tienes que cambiar un valor en un único sitio y la actualización se propaga a todas partes, desde el diseño hasta el código.

Los design tokens son una de las competencias que distinguen a quien "hace pantallas bonitas" de quien construye productos escalables. Son el lenguaje compartido que permite a diseñadores y desarrolladores hablar de las mismas decisiones visuales sin malentendidos, y son el motor invisible detrás de todo design system serio.

En esta guía te explico qué son los design tokens, por qué existen, cómo se organizan en niveles (primitivos, semánticos y de componente) y cómo gestionarlos en la práctica en Figma con las variables. Es un tema técnico, pero lo abordaremos paso a paso: al final tendrás un modelo mental claro, incluso si todavía estás aprendiendo.

Qué aprenderás en esta guía:

• Qué son los design tokens y qué problema resuelven
• La diferencia entre tokens primitivos, semánticos y de componente
• Ejemplos prácticos para color, espaciado y tipografía
• Cómo los tokens conectan el trabajo de diseño con el de desarrollo
• Cómo crear y gestionar tokens en Figma con las variables
• Cómo definir una naming convention que no se convierta en un caos

Qué son los design tokens

Un design token es la unidad más pequeña de una decisión de diseño, guardada en un formato reutilizable e independiente de la plataforma. En la práctica, es un par nombre → valor: en lugar de escribir "este botón es #2563EB", le das un nombre a ese valor —por ejemplo, color-primary— y lo usas siempre que necesites ese azul.

El punto clave es la separación entre el nombre y el valor. El nombre expresa la intención ("color primario", "espaciado pequeño", "texto grande"); el valor es el detalle técnico ("#2563EB", "8px", "24px"). Esta distinción, aparentemente trivial, es lo que hace que los tokens sean tan potentes: puedes cambiar el valor sin tocar el nombre, y todo lo que usa ese nombre se actualiza automáticamente.

Los tokens pueden describir prácticamente cualquier propiedad visual: colores, tamaños de texto, espaciados, radios de esquina, sombras, duraciones de animaciones. Son el vocabulario base de un design system, y su propósito es garantizar la coherencia (el mismo valor usado en todas partes de la misma manera) y la mantenibilidad (un cambio en un solo punto).

Por qué existen: el problema que resuelven

Para entender el valor de los tokens, piensa en cómo funciona un producto sin ellos. Cada pantalla se diseña con valores "escritos a mano": un gris ligeramente diferente aquí, un espaciado de 14px allá, otro gris casi-pero-no-exactamente-igual en la pantalla de al lado. Multiplica esto por decenas de pantallas, dos o tres diseñadores y un equipo de desarrollo que lo reinterpreta a su manera: el resultado es un producto incoherente e imposible de mantener.

Los design tokens resuelven tres problemas concretos:

1. Coherencia — existe una única "fuente de la verdad" para cada valor. Si el gris de los textos secundarios es text-secondary, es siempre ese, en cada pantalla y en cada plataforma.
2. Escalabilidad — añadir una nueva pantalla o un nuevo componente significa reutilizar tokens existentes, no inventar nuevos valores cada vez.
3. Velocidad de actualización — un rebrand, el cambio a una nueva paleta o la introducción de un modo oscuro se convierten en operaciones controladas, no en maratones de copiar y pegar.

Y hay una cuarta ventaja, quizás la más importante: los tokens son agnósticos a la plataforma. El mismo token color-primary puede exportarse a CSS, a código de iOS o a código de Android. Una sola decisión de diseño, múltiples destinos. Esto es lo que los convierte en el puente natural entre diseño y desarrollo.

Los tres niveles: primitivos, semánticos y de componente

El error más común al empezar es crear una única y enorme lista de tokens. Funciona mientras el producto es pequeño, pero luego se vuelve inmanejable. La solución que adoptan los design systems maduros es organizar los tokens en niveles (tiers), donde cada nivel hace referencia al inferior.

Tokens primitivos (o globales)

Los tokens primitivos son los valores en bruto, la "paleta" completa disponible para el producto. No tienen un significado de uso: solo describen el valor.

blue-500   = #2563EB
blue-600   = #1D4ED8
gray-100   = #F3F4F6
gray-900   = #111827
space-2    = 8px
space-4    = 16px

Un token primitivo como blue-500 no dice dónde se debe usar ese azul: solo dice que existe y cuál es su valor. Es el nivel más estable y rara vez cambia.

Tokens semánticos (o de alias)

Los tokens semánticos dan un significado a los primitivos. No describen qué es el valor, sino para qué sirve. Son alias que apuntan a un primitivo:

color-action-primary   → blue-500
color-text-default      → gray-900
color-text-muted        → gray-500
spacing-inline-sm       → space-2

Este es el nivel que usas en el 90% de los casos cuando diseñas. La ventaja es enorme: si mañana el color primario pasa a ser verde, solo tienes que hacer que color-action-primary apunte a green-500 en lugar de a blue-500. Todo lo que usa el token semántico cambia, mientras que la paleta de primitivos permanece intacta. También es el nivel que permite crear temas: un modo oscuro es simplemente el mismo conjunto de tokens semánticos que apuntan a primitivos diferentes.

Tokens de componente

Los tokens de componente son el nivel más específico: describen las propiedades de un único componente y, por lo general, hacen referencia a un token semántico.

button-primary-background  → color-action-primary
button-primary-text         → color-text-on-action
input-border-focus          → color-action-primary

No siempre son necesarios: introdúcelos solo cuando un componente necesite un control detallado e independiente. En productos pequeños, puedes quedarte tranquilamente en los dos primeros niveles y añadir los tokens de componente más adelante.

La regla de oro es la dirección de la referencia: componente → semántico → primitivo. Un componente nunca debería apuntar directamente a un primitivo, porque perderías el significado y la flexibilidad que te ofrecen los niveles.

Ejemplos prácticos: color, espaciado y tipografía

Veamos cómo los tres tipos de tokens más comunes toman forma en la práctica.

Color. Empieza con una escala de primitivos (por ejemplo, de gray-50 a gray-900, más los tonos de la marca). Luego, crea los semánticos que expresan el uso: color-background-page, color-surface-card, color-text-default, color-border-subtle, color-action-primary. Cuando diseñas una tarjeta, no eliges "el gris claro": aplicas color-surface-card. El nombre ya te dice lo que estás haciendo.

Espaciado. Define una escala basada en una unidad base, normalmente 4px u 8px: space-1 (4px), space-2 (8px), space-3 (12px), space-4 (16px), y así sucesivamente. Luego, los semánticos describen el contexto: spacing-stack-md para el espacio vertical entre elementos apilados, spacing-inset-lg para el padding interno de un contenedor. Una escala de espaciado coherente es lo que da ritmo a una interfaz, y los tokens hacen que sea imposible "equivocarse a ojo".

Tipografía. Aquí los tokens a menudo se agrupan en estilos compuestos. Los primitivos son font-size-sm (14px), font-size-md (16px), font-weight-regular (400), line-height-normal (1.5). Los semánticos los combinan en roles: text-body, text-heading-1, text-caption. Al aplicar text-heading-1 a un título, aplicas de una sola vez el tamaño, el peso y el interlineado ya decididos y coherentes.

Si estos conceptos te suenan, es porque el pensamiento basado en tokens encaja de forma natural con el atomic design: los tokens son, en cierto modo, los "átomos" de las decisiones visuales, incluso más pequeños que los componentes.

El puente entre diseño y desarrollo

Aquí reside el verdadero superpoder de los design tokens. Tradicionalmente, el paso del diseño al código es un punto de fricción: el diseñador entrega un archivo, el desarrollador "traduce" los valores a ojo o copiándolos a mano, e inevitablemente algo se pierde por el camino.

Con los tokens, diseño y código comparten la misma fuente de la verdad. Los tokens se guardan en un formato estructurado —normalmente JSON— y luego se transforman en el código específico de cada plataforma mediante herramientas de "build" (la más conocida es Style Dictionary). El mismo archivo de origen se convierte en variables CSS para la web, constantes para iOS y recursos para Android.

{
  "color": {
    "action": {
      "primary": { "value": "#2563EB" }
    }
  }
}

A partir de este JSON, una herramienta de build genera automáticamente --color-action-primary: #2563EB; para CSS y los equivalentes para otras plataformas. Cuando el diseñador cambia el valor, el código se regenera: se acabaron los valores que divergen con el tiempo. Este es exactamente el enfoque que sistemas maduros como Material Design 3 han convertido en un estándar del sector. Es la base sobre la que operan empresas como Glovo, Cabify o Rappi para mantener la coherencia en sus múltiples plataformas, desde la web hasta las apps de iOS y Android.

El resultado práctico: diseñadores y desarrolladores dejan de discutir sobre "qué gris es el correcto" y empiezan a hablar el mismo idioma, compuesto por nombres compartidos.

Cómo gestionar design tokens en Figma con variables

Durante años, en Figma los tokens se simulaban con los "estilos" (de color, de texto), que eran útiles pero limitados. Hoy, la herramienta adecuada son las variables de Figma, que reproducen fielmente la lógica de los tokens, incluyendo las referencias entre niveles y los temas.

Así es como puedes configurarlas, paso a paso:

1. Crea las colecciones. Una buena estructura incluye una colección para los primitivos (tu paleta completa) y otra para los semánticos. Mantenerlas separadas refleja los niveles de los que hemos hablado.
2. Define los primitivos. Introduce todos los valores en bruto: los colores de la escala, los números del espaciado, los tamaños de fuente. Son variables "hoja", que contienen valores reales.
3. Crea los semánticos como alias. Esta es la parte crucial: una variable semántica como color/action/primary no debe contener un valor hexadecimal, sino apuntar a la variable primitiva blue/500. En Figma, esto se hace asignando otra variable como valor. Es la misma lógica de la referencia semántico → primitivo.
4. Usa los modos (modes) para los temas. Los modos te permiten tener, en la misma colección semántica, una columna "Light" y una "Dark": el token color/surface/page apunta a gray/50 en Light y a gray/900 en Dark. Al cambiar de modo, todo el archivo se adapta.
5. Aplica solo los semánticos en tus diseños. Cuando colorees un rectángulo o un texto, elige siempre el token semántico, nunca el primitivo directamente. Así mantienes intacta la cadena de referencias.

Trabajar de esta manera transforma Figma de una simple herramienta de dibujo a la verdadera fuente de los tokens, alineada con el código. Es una habilidad muy demandada, y profundizamos en la práctica en nuestro tutorial completo de Figma, donde las variables son uno de los pilares.

Naming convention: la regla que lo sostiene todo

Un sistema de tokens es tan bueno como su naming convention. Nombres incoherentes o ambiguos anulan todas las ventajas: si nadie entiende qué token usar, cada uno inventa uno nuevo y se vuelve al caos.

La convención más extendida sigue una estructura jerárquica, de lo general a lo específico:

[categoría]-[propiedad]-[variante]-[estado]

color-text-primary
color-text-primary-hover
spacing-inset-sm
color-border-error

Algunos principios prácticos que puedes adoptar:

• Describe la intención, no la apariencia. Usa color-action-primary, no color-blue. Si mañana el color primario se vuelve verde, el nombre color-blue se convertiría en una mentira.
• Ve de lo general a lo específico. La categoría primero, el detalle después: color-text-muted es más legible y fácil de ordenar que muted-text-color.
• Sé coherente en los niveles. Los primitivos pueden usar escalas numéricas (gray-100, gray-200); los semánticos usan nombres de uso (text-default, surface-card).
• Evita abreviaturas opacas. spacing-sm es claro; sp-s no lo es.

Una convención sólida es lo que permite que un nuevo diseñador en el equipo entienda al instante qué token necesita, y que un desarrollador pueda predecir su nombre sin tener que preguntar. Es una inversión que se amortiza con cada pantalla.

En resumen

Los design tokens son pares nombre → valor que capturan las decisiones de diseño en un formato reutilizable e independiente de la plataforma. Se organizan en tres niveles —primitivos (los valores en bruto), semánticos (la intención de uso) y de componente (las propiedades específicas)—, conectados por una cadena de referencias que va del componente al semántico y al primitivo.

Su valor es triple: garantizan la coherencia, permiten la escalabilidad y aceleran las actualizaciones, desde un rebrand hasta el modo oscuro. Sobre todo, son el puente entre diseño y desarrollo: una única fuente de la verdad, exportable a CSS, iOS y Android, que hace que diseñadores y programadores hablen el mismo idioma. En Figma, se gestionan con las variables, aprovechando los alias y los modos para reproducir fielmente los niveles y los temas.

Entender los design tokens significa dar un salto: de diseñar pantallas a diseñar sistemas. Es exactamente el tipo de competencia estructural que enseñamos en nuestro curso de Diseño Visual, donde aprenderás a construir design systems coherentes y listos para el desarrollo, no solo archivos bonitos.

Preguntas frecuentes

¿Cuál es la diferencia entre design tokens y estilos en Figma?
Los estilos de Figma agrupan propiedades visuales (un color, un estilo de texto), pero no permiten crear referencias entre valores ni múltiples temas. Las variables de Figma, en cambio, reproducen la verdadera lógica de los tokens: una variable semántica puede apuntar a una primitiva, y los modos gestionan el modo oscuro y diferentes marcas. Para trabajar con tokens, hoy se usan las variables.

¿Siempre se necesitan los tres niveles de tokens?
No. Los niveles primitivo y semántico son el corazón del sistema y casi siempre necesarios. Los tokens de componente deben introducirse solo cuando un componente requiere un control independiente y detallado: en productos pequeños, puedes prescindir de ellos al principio y añadirlos a medida que el sistema crezca.

¿Los design tokens solo son para los desarrolladores o también para el diseñador?
Son útiles sobre todo para el diseñador. Son la forma en que tomas decisiones visuales coherentes y las haces reutilizables, mucho antes de que lleguen al desarrollo. Pensar en tokens mejora la calidad del trabajo de diseño en sí; el hecho de que luego se conviertan en código de forma automática es una ventaja adicional, no su único propósito.