Qué son los tokens en diseño web: guía práctica
Entiende los tokens de diseño con ejemplos de paleta, roles semánticos, variables de Figma, CSS y temas.
Los tokens de diseño son decisiones reutilizables con nombre, como roles de color, espaciado o tipografía. Separa los valores base de los roles semánticos, relaciona las variables de Figma con los estilos web y revisa cada tema y estado. Los tokens no sincronizan herramientas automáticamente ni garantizan accesibilidad.
¿Qué son los tokens en diseño web? Son decisiones de diseño con nombre y reutilizables —como el rol de un color, un paso de espaciado o un tamaño tipográfico— que permiten referirse a una intención en vez de repetir un valor sin contexto. Un token puede conectar un archivo de diseño con los estilos de una web, pero esa conexión requiere nombres claros y una ruta de implementación: crear una variable no sincroniza automáticamente todas las herramientas.
Entiende el token como una decisión de diseño con nombre
Un valor base expresa una cantidad concreta: un color como #FACC15, un espacio como 16px o un tamaño tipográfico como 14px. Un token añade un nombre legible que explica por qué existe el valor o dónde se usa. El formato del Design Tokens Community Group describe un token como información asociada a un nombre legible, con al menos un nombre y un valor.
Por ejemplo, yellow-500 puede nombrar un paso de la paleta. Un token semántico como surface/notice puede hacer referencia a ese color para el fondo de un aviso. Después, el componente usa el rol semántico en vez de codificar directamente el amarillo. Si cambia el lenguaje visual, el rol puede apuntar a otro valor sin cambiar el significado del componente.
Pasa de los valores de paleta a tokens útiles
Empieza con una escala pequeña de valores base y añade nombres semánticos solo cuando ayuden a tomar decisiones coherentes. Algunos roles habituales son fondo de página, superficie elevada, texto principal, texto secundario, borde, foco, acción principal y estado. Son ejemplos, no un esquema universal; nombra los roles según las decisiones que se repitan en tu producto.
La imagen muestra muestras de una paleta etiquetadas como claras, principales, vivas y oscuras. Ilustra opciones de color base, no un mapa completo de tokens ni una evaluación de accesibilidad. El siguiente paso es decidir qué función cumple cada color en la interfaz y si esa función cambia según el tema.
Una cadena práctica podría ser green-700 → action/primary → fondo del botón principal. El primer nombre describe una posición en la escala; el segundo expresa un rol semántico; el componente consume ese rol. Mantén separados estos niveles si un mismo color cumple varias funciones o si una función requiere valores distintos según el tema.
Usa tokens para dar coherencia sin ocultar el contexto
Los tokens facilitan actualizar y revisar decisiones repetidas. Si varias páginas usan el mismo color de acción, cambiar el token semántico ofrece un lugar común donde revisar el efecto. Si un componente necesita un valor especial, no añadas un token solo para reemplazar un literal: créalo cuando represente una decisión reutilizable o un contexto que el sistema deba manejar.
Sigue un token por la interfaz
Cuando un rol aparece en varios lugares, anota sus usos antes de cambiar el valor. Un mapa breve ayuda a detectar un aviso, un mensaje de validación o un estado vacío que podría conservar un color antiguo o usar un nombre semántico distinto.
Los nombres deberían ayudar a diseñadores y desarrolladores a elegir bien. blue-600 puede servir para nombrar un color base, pero no dice si pertenece a un enlace, un estado seleccionado o un borde. Nombres como text/link o border/strong comunican un rol, siempre que esos roles estén documentados y se usen de forma coherente.
No confundas los tokens con un sistema de diseño completo. Los tokens cubren valores con nombre y sus relaciones. Los componentes definen estructura y comportamiento; las pautas explican cuándo usarlos; las pruebas de accesibilidad comprueban si el resultado funciona para las personas. Una paleta tokenizada, por sí sola, no hace accesible una página ni garantiza un contraste suficiente.
Relaciona las variables de Figma con los estilos web de forma deliberada
Las variables de Figma son valores reutilizables que se aplican a propiedades de diseño. Figma explica que crear alias entre variables permite implementar tokens y que las colecciones y los modos organizan valores para contextos distintos, como temas claros y oscuros. Una estructura útil puede separar las variables de paleta base de los roles semánticos y conectarlas mediante alias.
En CSS, las propiedades personalizadas permiten nombrar valores, reutilizarlos en las hojas de estilo y cambiarlos mediante la cascada. Por ejemplo, una web puede definir --color-action-primary y usarlo en el estilo de un botón. Esa es una decisión de implementación: una variable de Figma no se convierte en una propiedad CSS a menos que el equipo la exporte, la asigne o la vuelva a crear mediante un flujo de herramientas.
El Design Tokens Community Group publicó su módulo de formato 2025.10 como una especificación estable para intercambiar tokens entre herramientas. Es una especificación de un Community Group, no un estándar del W3C. Trátala como un formato de interoperabilidad, no como una garantía de que dos productos interpreten igual todas las extensiones o flujos. Comprueba el soporte y las reglas de mapeo de las herramientas concretas.
Usa modos para representar contextos reales
Un modo es útil cuando una misma decisión semántica necesita valores distintos en un contexto, como un tema claro u oscuro. Mantén estable el nombre semántico —por ejemplo, surface/default— y asigna el valor apropiado a cada modo. El componente puede seguir usando el mismo rol mientras cambia el contexto visual.
Figma también explica cómo usar modos para contextos de idioma y tamaño de dispositivo. Pueden ayudar a explorar cambios en el diseño, pero no sustituyen las reglas adaptables de la web ni la revisión de las traducciones. Para los temas de color, comprueba las combinaciones reales de texto y fondo en cada modo, incluidos los estados hover, desactivado y foco. El nombre del token o la muestra de paleta no demuestran que haya accesibilidad.
Evita crear un modo para cada situación posible. Añade un contexto cuando el producto lo necesite y el equipo pueda explicar qué marco, página o componente lo selecciona. Si un valor no debería cambiar con el tema, déjalo fijo en vez de añadir un modo por simetría.
Mantén el conjunto de tokens acotado y fácil de cuidar
Empieza por enumerar las decisiones repetidas que aparecen en varias pantallas representativas. Agrupa los valores relacionados, documenta el significado de cada rol semántico y señala los componentes que lo usan. Pide a un desarrollador que confirme que los nombres se pueden mapear al código y que el equipo entiende cómo mantener ese vínculo antes de ampliar el conjunto.
Revisa si un token propuesto se reutiliza, si el nombre expresa su función y si el efecto de cambiarlo sería predecible. Elimina alias obsoletos y valores sin uso mediante una migración deliberada: renombra, actualiza los consumidores y luego retira el nombre anterior. Sustituir valores a ciegas puede provocar regresiones sutiles en un tema o estado.
El kit de Figma de EmviUI incluye variables y componentes reutilizables, por lo que ofrece ejemplos concretos que un equipo puede inspeccionar o adaptar. No decide los nombres ni la relación con el código de un producto concreto. Para el uso de tokens en Figma, consulta nuestra flujo de diseño web adaptable con Figma. Para llevarlos al código, lee nuestro flujo de Figma a Tailwind; para estructurar una pantalla antes de aplicar estilos, consulta nuestra guía de Figma y wireframes.
Define una ruta de tokens que pueda conservar la implementación
Separa los valores originales del papel que necesita cada componente. Un modelo pequeño puede usar palette.yellow.500 para el color de origen, color.notice.surface para el uso semántico y un token de componente solo cuando una pieza necesite una decisión propia. Así, el equipo puede cambiar la superficie de un aviso sin renombrar la paleta ni buscar cada lugar donde copió el valor hexadecimal.
Sigue el nombre del token hasta CSS
Una entrega útil registra el valor primitivo, la propiedad semántica que lo referencia y un componente que la utiliza. Así es más fácil revisar el recorrido desde una variable de Figma hasta la interfaz renderizada, sin dar por hecho que las herramientas se sincronizan solas.
La misma separación sirve en CSS. Una propiedad personalizada semántica puede apuntar a un valor primitivo, mientras que la interfaz utiliza el nombre semántico:
:root { --palette-yellow-500: #facc15; --color-notice-surface: var(--palette-yellow-500); }
.notice { background: var(--color-notice-surface); }En Figma, crea una variable para el valor y organiza colecciones y modos cuando el producto tenga contextos distintos. Después documenta cómo se relacionan esos nombres con el código. Las variables de Figma, un formato de intercambio de tokens y las propiedades personalizadas de CSS forman partes relacionadas de un flujo, pero no son el mismo sistema de almacenamiento ni se sincronizan por sí solas. Hace falta que alguien mantenga y revise la exportación, la transformación o la correspondencia manual.
Antes de multiplicar los tokens, acuerda una gramática de nombres breve. Decide si el orden será plataforma, función, componente y estado; mantenlo estable y explica cuándo se justifica una excepción específica de componente. Una ruta predecible ayuda al equipo de diseño a encontrar la variable adecuada y permite rastrear una propiedad de la interfaz hasta su origen.
Decide qué valores merecen un token
Un valor suele ser buen candidato cuando expresa un significado compartido, aparece en varios lugares o se espera que cambie como una sola decisión. Los colores de marca, la escala de espaciado, los roles tipográficos, los niveles de superficie y los indicadores de foco suelen cumplir alguno de esos criterios. Un desplazamiento único de una ilustración o una medida que aparece una vez puede funcionar mejor como estilo local que como parte permanente del vocabulario común.
Antes de crear el token, piensa qué debería entender un compañero al leer su nombre y quién lo mantendrá. Si la respuesta es solo «este valor aparece en esta pantalla», quizá añada trabajo sin ofrecer reutilización. Si significa «esta es la superficie de aviso en formularios y ajustes», es más fácil compartirla y revisarla. Conserva los valores primitivos para composiciones controladas, pero evita usarlos directamente por todos los componentes cuando el producto necesita una capa semántica estable.
Los tokens de componente sirven cuando existe una necesidad real que el rol semántico general no expresa, por ejemplo, un botón cuyo texto cambia de estado de una forma concreta. No crees por defecto un espacio de nombres para cada propiedad: cada alias añade otra relación que el equipo debe comprender. Empieza con pocos roles semánticos, detecta excepciones repetidas y convierte en tokens solo las que necesiten un nombre estable.
Revisa los cambios de tokens en la interfaz
Los tokens centralizan decisiones, pero no demuestran que la interfaz resultante sea usable. Antes de publicar un cambio de paleta o de modo, revisa las combinaciones reales de texto y fondo en contenido, controles, bordes, errores, foco y estados desactivados. Las pautas de contraste de WCAG se aplican a las combinaciones renderizadas; un nombre como text/subtle no garantiza contraste. Prueba cada combinación que aparece en el producto y todos los temas admitidos.
Organiza una revisión concreta: enumera los roles semánticos modificados, localiza los componentes que los usan, compara los modos de Figma con el CSS generado y revisa pantallas representativas en anchos estrechos y amplios. Un token de color puede cambiar estados hover, foco, selección y error que no aparecen en la muestra inicial de paleta. Es más útil detectarlo en contexto que aprobar solo una muestra de color.
EmviUI puede ayudar a revisar cómo se repiten los valores compartidos en un UI kit de Figma y en ejemplos de componentes. Usa esos patrones para localizar roles comunes y luego asigna la variable elegida al código del producto de forma deliberada. El kit aporta una referencia de diseño; el equipo sigue siendo responsable de los nombres, las exportaciones, los temas y las comprobaciones de accesibilidad.
Fuentes y lecturas recomendadas
Pablo Mayoral
Diseñador UX/UI y Web con más de 10 años de experiencia. Creador de EmviUI (sistema de diseño en Figma con más de 10k componentes), UImand y Vitamin Bootstrap. Diseñando actualmente productos digitales en CQMRewards.
