
Paletas y tokens de color: cómo organizar el color de un sistema
Una paleta es el conjunto de tonos de una marca; los tokens le dan nombre y función. Cómo estructurar colores primitivos, semánticos y de tema con control.
¿Qué es un token de color?
Un token es una decisión con nombre. En lugar de escribir #B42318 en veinte componentes, escribes color.error y dejas que el valor viva en un solo lugar. Cuando el equipo decide que el rojo de error debe ser más oscuro para cumplir contraste, cambias un valor y el cambio llega a todo el producto.
La especificación del Design Tokens Community Group lo expresa de forma simple: un token es un objeto con una propiedad $value. Esa propiedad puede ser un valor literal o una referencia a otro token, lo que la especificación llama alias. Según sus definiciones, el mismo valor puede tener varios nombres.
¿Qué diferencia hay entre paleta y token?
La paleta es el inventario: los azules del 50 al 900, los grises neutros, los rojos de alerta. El token es el uso: qué color va en el fondo de un botón, en el borde de un campo con error, en el texto secundario.
Esta diferencia importa porque la paleta cambia con la marca y el token cambia con la función. Si el equipo rediseña la marca, cambia la paleta y los tokens siguen apuntando a los mismos usos.
¿Cómo se estructuran en capas?
Una convención muy usada en equipos de diseño tiene tres capas:
- Primitivos. Valores crudos de la paleta, con nombres descriptivos como
blue.600. No dicen para qué sirven. - Semánticos. Asignan una función:
color.text.primary,color.feedback.error,color.surface.default. Apuntan a un primitivo. - De componente. Aplican el semántico a una pieza concreta:
button.primary.background. Apuntan a un semántico.
Esta separación permite cambiar un primitivo sin revisar los componentes, y cambiar un tema sin duplicar archivos. Es una práctica, no una regla de estándar: otros equipos usan dos capas o nombran las capas de otra forma. Lo importante es que la relación entre capas sea explícita y documentada.
Los tokens de color también necesitan ser accesibles. Antes de asignar un semántico a un fondo y a un texto, verifica el contraste de la combinación. Para eso sirven las matemáticas del contraste de color y los criterios de WCAG explicado, en la parte de contraste.
¿Cómo se manejan los temas y el modo oscuro?
Los temas son la aplicación más clara de tokens semánticos. Un modo oscuro no necesita un segundo conjunto de componentes: necesita que color.surface.default apunte a un gris oscuro en el tema oscuro y a blanco en el claro. Los componentes no cambian; cambia la referencia.
El formato DTCG 2025.10 contempla esto: según su anuncio, permite gestionar modos claro y oscuro, variantes de accesibilidad y temas de marca sin duplicar archivos. Si tu sistema tiene dos temas, define la estructura desde el inicio y no como parche después.
Un detalle que se olvida: la paleta del tema oscuro no es la inversa de la clara. Los colores de acento suelen necesitar ajustes para mantener contraste sobre fondos oscuros, así que conviene revisar cada combinación.
¿Qué formato usar?
El Design Tokens Community Group publicó la versión estable de su especificación, 2025.10, en octubre de 2025. Es un formato en JSON que define tokens, grupos, alias y tipos. Su FAQ aclara que define el formato de intercambio y deja la estrategia organizativa a los equipos de sistema, y que la especificación no está en el Standards Track del W3C: la publica un grupo de la comunidad.
En la versión 2025.10 el valor de un color es un objeto con colorSpace (por ejemplo srgb, oklch o display-p3) y components; hex es un respaldo opcional. Un token puede heredar su $type de un grupo, y un alias toma el tipo del token al que apunta. Un ejemplo con alias:
{
"$type": "color",
"blue": {
"600": {
"$value": {
"colorSpace": "srgb",
"components": [0.114, 0.306, 0.847],
"hex": "#1d4ed8"
}
}
},
"color": {
"action": { "$value": "{blue.600}" }
}
}
Herramientas como Style Dictionary toman los tokens y los transforman para distintas plataformas y lenguajes, y también permiten referencias entre tokens con llaves, como {blue.600}. Para el flujo de tokens desde Figma, revisa Tokens Studio, y para la forma general del sistema, la arquitectura de tokens.
Ejemplo
Ejemplo ilustrativo: un equipo tiene 40 pantallas con el azul de marca escrito como valor fijo en cada componente. Quieren añadir un modo oscuro y, al revisar, descubren tres azules casi iguales. Migran a tres capas: primitivos con la escala de azules, semánticos como color.action.default y color.surface.default, y los componentes apuntan a semánticos. El modo oscuro se implementa cambiando las referencias de superficie y texto. Al terminar, el equipo tiene un solo lugar donde cambiar el azul de acción y una prueba de contraste por cada par de tokens.
Para tu próximo proyecto: revisa los colores de una pantalla, anota los que se repiten, y agrupa cada uno por función. Si dos colores tienen la misma función, probablemente comparten token.
Errores comunes
- Nombrar tokens por color en lugar de función:
blue-buttonse vuelve incorrecto cuando el botón cambia de color. - Saltarse la capa semántica y apuntar componentes directamente a primitivos.
- Crear demasiados tonos sin criterio, que vuelven la paleta imposible de mantener.
- Hacer el tema oscuro invirtiendo colores sin revisar contraste.
- Asignar tokens sin probar pares de fondo y texto.
- Usar valores fijos en componentes nuevos, lo que rompe el sistema desde el principio.
Fuentes
- Design Tokens specification reaches first stable version, W3C Design Tokens Community Group (28 de octubre de 2025)
- Design Tokens Format Module 2025.10, Design Tokens Community Group
- Design Tokens Color Module 2025.10, Design Tokens Community Group
- Design Tokens FAQ, designtokens.org
- Design Tokens, Style Dictionary