Los design tokens son el contrato entre diseño y código
Las custom properties estaban definidas en el 28,6 % de las páginas móviles del Web Almanac de 2021, pero casi ninguna referencia a otro valor. Esa capa de alias ausente separa variables de design tokens.
Contenido
- Puntos clave
- Qué es exactamente un design token
- Tres capas, de primitiva a componente
- El naming es donde fallan los sistemas de tokens
- Qué está estandarizando el grupo del W3C
- Las decisiones de accesibilidad viven en la capa semántica
- Qué se rompe cuando se salta la capa de tokens
- Preguntas frecuentes
- Define las capas antes del primer componente
Un design token es un valor con nombre, legible por máquina, que guarda una decisión de diseño: un color, un espaciado, un tamaño tipográfico. Diseño y código leen así la misma fuente. Los tokens funcionan en tres capas: valores primitivos, roles semánticos que los referencian y nombres de componente sobre los roles.
Puntos clave
- El Web Almanac de 2021 encontró custom properties en el 28,6 % de las páginas móviles y el 28,3 % de las de escritorio: el mecanismo ya está desplegado.
- Casi ninguno de esos valores es un alias. Cerca de un tercio referencia otra un nivel, y con dos niveles son casi inexistentes.
- Tras una entrada del core de WordPress, los nombres más frecuentes son colores literales:
--red,--bluey--green, con un 7,2 %. Es una capa primitiva usada como semántica. - El Design Tokens Community Group del W3C publicó su primer editor's draft el 23 de septiembre de 2021, hacia un formato compartido entre herramientas.
Qué es exactamente un design token
CSS tiene el mecanismo desde el 3 de diciembre de 2015, cuando el W3C publicó Custom Properties for Cascading Variables Level 1. Son propiedades del autor que cascadean, heredan y se sustituyen con var().
Un token no es una variable, aunque acabe compilando en una. Una variable es un valor con nombre. Un token es una decisión con nombre, guardada fuera de cualquier plataforma. La misma decisión sale como CSS, como constante de iOS, como recurso de Android o dentro de una herramienta de diseño.
El Design Tokens Community Group del W3C declara un objetivo: aportar la tecnología con la que productos y herramientas de diseño compartan las piezas estilísticas de un design system a escala. Su primer editor's draft público salió el 23 de septiembre de 2021 (W3C).
Tres capas, de primitiva a componente
La capa primitiva guarda valores en bruto con nombres descriptivos: color-orange-500, space-4, font-size-3. No opina sobre el uso.
La capa semántica nombra roles y referencia primitivos: color-action-primary apunta a color-orange-500. Aquí viven las decisiones de marca.
La capa de componente cubre los pocos sitios donde un componente necesita su propio anclaje, como button-primary-background. Casi todos los sistemas necesitan menos de los que el equipo espera, y cada uno es otra línea.
El beneficio es aritmético. Cambia un primitivo y cambian todas las pantallas que lo heredan. Un rebrand toca un archivo y no cuatrocientos. Es la misma lógica de tratar un logo como portador comprimido de significado y no como un dibujo.
El naming es donde fallan los sistemas de tokens
La web ya muestra qué pasa sin capa semántica.
En el Web Almanac de 2021, las custom properties estaban definidas en el 28,6 % de las páginas móviles. Entre esas páginas, tras una propiedad del core de WordPress, los nombres más frecuentes son colores literales:--red,--bluey--green, con un 7,2 % cada uno (HTTP Archive, 1 de diciembre de 2021).
Una propiedad llamada --red es un primitivo disfrazado de rol. La primera vez que la marca cambie el rojo por un terracota, cada --red será una mentira o un renombrado en todo el repositorio.
Tres reglas de naming resisten el contacto con proyectos reales. Nombrar por rol y no por apariencia. Poner la categoría delante y el modificador al final, para que los nombres se agrupen. Y no codificar un valor en el nombre: un --blue-600 de aviso es peor que un hex sin nombre.
Qué está estandarizando el grupo del W3C
El grupo trabaja sobre la interoperabilidad. Un archivo de tokens escrito para una herramienta de build suele necesitar traducción antes de que otra lo lea, y ahí se desvían los sistemas.
Un formato compartido no decide tu naming ni tus capas. Decide si el archivo sobrevive a un cambio de herramienta, por la misma razón por la que la transformación digital es un problema de operaciones: el artefacto dura más que la herramienta.
Las decisiones de accesibilidad viven en la capa semántica
Las relaciones de contraste son propiedades de pares, no de colores sueltos. Si el sistema solo nombra colores, cada diseñador y cada desarrollador comprueba el contraste a mano. Si nombra pares — un fondo y el texto aprobado contra él — se comprueba una vez.
WCAG 2.1 fija una relación de contraste mínima de 4,5:1 para texto normal y 3:1 para texto grande. Los componentes de interfaz y los objetos gráficos necesarios para entender el contenido también exigen 3:1 (W3C, 5 de junio de 2018).
Qué se rompe cuando se salta la capa de tokens
Sin tokens, el archivo de diseño y el código son dos copias independientes de las mismas decisiones, y divergen. Los síntomas se repiten: seis grises donde debía haber tres, un modo oscuro dos trimestres tarde y un rebrand cotizado como reescritura del front end. Nadie sabe dónde se usa el color antiguo.
Nada de eso aparece en el primer build, y por eso surge en el handover. Define la capa de tokens mientras aún se dibuja la identidad, en el tramo que va de la auditoría al handover. Se paga entonces una sola vez, sea cual sea la arquitectura del sitio.
Preguntas frecuentes
¿En qué se diferencia un design token de una variable CSS?
Una variable CSS es un valor con nombre dentro de una plataforma. Un design token es una decisión guardada en un archivo neutral, desde el que se generan la variable CSS, la constante de iOS y el recurso de Android. El token es la fuente; la variable, una salida.
¿Cuántas capas necesita un sistema de tokens?
Tres bastan para casi cualquier producto: primitiva, semántica y de componente. Dos funcionan en un sitio pequeño con un tema. Cuatro o más suele indicar que la capa semántica se nombró mal.
¿Los tokens sustituyen a un design system?
No. Los tokens son la capa de valores bajo los componentes, la documentación y las reglas de uso. Un archivo sin componentes documentados produce colores consistentes sobre interfaces inconsistentes. Es un problema menor, no resuelto.
¿Quién debe responder del archivo de tokens?
Una persona con nombre, y los cambios revisados como cualquier código. La propiedad compartida reproduce la deriva que los tokens venían a evitar: la forma más barata de publicar una pantalla siempre es añadir un valor más.
Define las capas antes del primer componente
Escribe la paleta primitiva, después los roles semánticos con sus pares de contraste y luego los tokens de componente que hagan falta. Pon el archivo bajo revisión y nombra a un responsable. A los seis meses la respuesta medible es si un cambio de color tocó un archivo o muchos.
