Design tokens multimarca: 6 pasos desde un solo nivel de primitivas

Al terminar esta guía tendrás una sola fuente de tokens que sirve a varias marcas. Tiene cuatro partes: un nivel de primitivas del que beben todas las marcas, un contrato semántico que cada marca cumple, un archivo pequeño de decisiones por marca y componentes que solo leen nombres semánticos. Añadir una marca pasa a ser un archivo nuevo y un target de build nuevo. La librería de componentes se queda como está.

La arquitectura de tokens multimarca es una forma de organizar los design tokens para que varios productos compartan una sola librería de componentes y cada uno conserve sus colores, su tipografía y sus formas. Es para equipos que llevan productos hermanos, plataformas white-label o un grupo con más de una marca de consumo. Quien se la salta lo nota en los forks. Infinum contó el caso de un grupo de telecomunicaciones con cuatro marcas, cada una con su archivo de assets, su archivo de componentes móviles y su archivo de componentes web: doce archivos, y cada cambio compartido hecho cuatro veces.

El formato ya está resuelto. El Design Tokens Community Group publicó su primera especificación estable, la 2025.10, el 28 de octubre de 2025, y el soporte de temas y multimarca es una de sus novedades principales. Los pasos que siguen usan su formato JSON, así que cualquier herramienta que lo lea (Style Dictionary, Terrazzo, Tokens Studio) puede generar el resultado.

Qué necesitas antes de empezar

• Una librería de componentes que ya lea tokens o custom properties de CSS, no valores hexadecimales escritos a mano. Si no es así, se empieza por ahí: el component drift es donde se atascan los proyectos multimarca.
• La lista de marcas y, para cada una, una persona que pueda decir sí o no a un color.
• Una herramienta de build que lea JSON DTCG y se ejecute una vez por marca y plataforma.
• Una herramienta de diseño con variables. En Figma, el número de modos por colección depende del plan: hasta 10 en Professional, hasta 20 en Organization e ilimitados en Enterprise con las extended collections.

Paso 1. Listar lo que de verdad cambia entre las marcas

Pon todas las marcas una al lado de otra en una hoja de cálculo, una fila por decisión: color principal, tinte de los neutros, tipografía de los títulos, tipografía del texto, radio de las esquinas, forma de los botones, densidad, movimiento. Marca cada fila como compartida o propia de la marca.

Las filas propias suelen ser menos de las que esperan los equipos de marca. Escalas de espaciado, breakpoints, niveles de z-index y duraciones tienden a coincidir en todas partes, y van al núcleo común. Color, familias tipográficas y radios sí suelen cambiar. Escribe la lista antes de nombrar un solo token, porque decide cuánto ocupará cada archivo de marca. Un archivo de marca con 300 entradas significa que el análisis se ha saltado.

Apunta también lo que cambia en la estructura y no en el aspecto. Una marca que necesita otra navegación o un paso más en el checkout tiene un problema de componentes. Los tokens no lo resuelven.

Paso 2. Construir un solo nivel de primitivas para todas las marcas

Las primitivas son valores en bruto, sin significado: rampas de color, familias tipográficas, una escala de radios, una escala de espaciado. Van todas en un único nivel, con las rampas de cada marca incluidas, y cada una se llama por lo que es (color.teal.600), nunca por quién la usa (color.acme.primary).

Así dos marcas con un azul casi idéntico comparten una rampa, y un rediseño que lleva una marca del verde azulado al violeta cambia un alias en lugar de renombrar una rampa. Los componentes nunca leen este nivel. Si lo leen, cambiar de marca obliga a tocar el código de los componentes.

Paso 3. Definir el contrato semántico que toda marca debe cumplir

Los tokens semánticos nombran un rol: color.action.background, color.text.default, radius.control, font.family.heading. Esta lista es la API entre el sistema y las marcas. Los componentes solo leen esto, y cada marca tiene que dar un valor para cada entrada.

El contrato tiene que ser pequeño y estable. Cada token semántico nuevo es una obligación más para todas las marcas, así que se añade uno solo cuando ese rol existe en al menos dos marcas. De los nombres hablamos en un sistema de nombres de 3 niveles.

Paso 4. Escribir un archivo por marca, solo con alias

Un archivo de marca enlaza los tokens semánticos con las primitivas y no contiene valores en bruto. En JSON DTCG una entrada se escribe así:

{
  "color": {
    "action": {
      "background": { "$type": "color", "$value": "{color.teal.600}" }
    }
  }
}

Con los alias cada marca se queda dentro del nivel de primitivas, el único donde se comprueba el contraste. Si un diseñador quiere un tono nuevo, lo añade a una rampa, donde lo ven todas las marcas.

El módulo Resolver de la especificación describe cómo combinar estos archivos. Se declaran los sets (los archivos del núcleo) y los modificadores (marca, tema), cada uno con sus contextos, y un orden de resolución. El módulo avisa de la trampa en la que cae todo sistema multimarca: cuando un modificador de marca y uno de tema fijan el mismo token, el valor lo decide el orden del array. Elige el orden a propósito. Si el tema se resuelve antes que la marca, un archivo de marca puede corregir un valor del modo oscuro con el que no está de acuerdo. Elijas el orden que elijas, déjalo escrito en el readme.

Paso 5. Un build por marca y por plataforma

El ejemplo multimarca y multiplataforma de Style Dictionary enseña la forma: tokens repartidos en carpetas de marca, de plataforma y globales, y un script de build que recorre cada par de marca y plataforma y escribe en build/web/brand-1/, y así con el resto.

En la web hay dos formas de servir el resultado:

• Un archivo por marca. Cada producto carga solo su CSS. Es la opción cuando las marcas son apps separadas.
• Un solo archivo, separado por atributo. Las custom properties de cada marca van bajo un selector como [data-brand="b"], y la app cambia de marca cambiando un atributo. Es la opción para productos white-label, donde un solo despliegue sirve a muchos clientes.

Cuenta los builds antes de añadir un modificador. Cuatro marcas, dos temas y tres plataformas ya suman 24. El módulo Resolver lo llama explosión combinatoria, y cada eje nuevo (densidad, alto contraste, movimiento reducido) lo vuelve a multiplicar.

Paso 6. Llevarlo a Figma y vigilarlo en CI

En Figma, las primitivas van en una colección y los tokens semánticos en otra, con un modo por marca. En el plan Enterprise las extended collections lo resuelven de forma más limpia: cada marca extiende una colección madre, sobrescribe solo lo que cambia y hereda cada cambio posterior en las variables que no ha tocado. Una extended collection no puede añadir variables ni modos propios: es el mismo contrato del paso 3, impuesto por la herramienta.

En CI, tres comprobaciones paran casi todas las regresiones:

1. Cada token semántico se resuelve para cada marca. Un valor que falta rompe el build.
2. Ningún archivo de componente hace referencia a una primitiva o a un token con nombre de marca.
3. Cada par de texto y fondo cumple el contraste mínimo de 4,5:1 para texto normal, por marca y por tema.

Cómo comprobar que funciona

Añade una marca falsa con valores llamativos a propósito: un verde saturado, esquinas rectas, una tipografía con serifa en los títulos. Muestra toda la galería de componentes con esa marca. Cada componente tiene que cambiar. El que conserve el aspecto anterior está leyendo una primitiva o un valor escrito a mano, y lo has encontrado antes que una marca real.

Fallos habituales y cómo corregirlos

• Nombres de marca dentro de los componentes. Un botón que lee color.acme.primary sirve para una sola marca. Cámbialo por el token semántico y lleva el valor de la marca a su archivo.
• Tokens de componente copiados por marca. Escribir button.background aparte para cada marca multiplica los archivos sin dar más control. Enlaza los tokens de componente a los semánticos y deja que una marca sobrescriba uno solo cuando de verdad es distinto.
• Valores hexadecimales en bruto en un archivo de marca. Se saltan las comprobaciones de contraste del nivel de primitivas. Añade el tono a una rampa y enlázalo con un alias.
• Estructura disfrazada de aspecto. Cuando una marca necesita otro layout u otro flujo, ningún token se lo va a dar. Conviértelo en una variante de componente y déjalo fuera de los archivos de tokens.

Para ir más allá

Las marcas rara vez cambian solo en el color. La tipografía, el movimiento y la densidad también llevan identidad, y en design tokens más allá del color contamos cómo modelarlos. Cuando varios productos usan el mismo núcleo, el proceso de publicación pesa tanto como la arquitectura: en cómo gobernar un design system en 10 proyectos describimos el versionado y las reglas de revisión que usamos.