Sistemas de marca que escalan: tokens, no capturas de pantalla

TL;DR — Una marca entregada como un PDF de 60 páginas y una carpeta de mockups planos nace muerta. En su lugar, entrega la marca como un sistema de tokens — color, espaciado y tipografía expresados como variables con nombre que mapean 1:1 a código y a Figma. Los tokens son el contrato entre diseño e ingeniería. Todo lo demás es una captura de pantalla que se desvía en el momento en que el software real la toca.

Lo hemos visto pasar demasiadas veces. Un estudio entrega un brand book precioso. Seis meses después, el producto en vivo no se parece en nada. El azul está tres tonos desviado, los títulos usan la escala equivocada, los botones inventaron su propio padding. Nadie actuó de mala fe — simplemente la guía no tenía ninguna conexión exigible con el código. Un PDF no se puede importar. Una captura de pantalla no puede ser fuente de verdad. La marca se pudrió porque nunca se sistematizó en primer lugar.

Por qué las guías de marca estáticas se pudren

Las guías estáticas describen una marca como una fotografía describe a una persona: exactas el día que se tomaron, cada vez más erróneas después. El problema es estructural, no cosmético.

• Son prosa, no datos. “Usa nuestro azul primario con generosidad” es una frase que un desarrollador tiene que interpretar. La interpretación es donde empieza la desviación.
• No se pueden referenciar. Ningún paso de build lee un PDF. Los valores se re-teclean a mano en el CSS, en una librería de componentes, en la memoria de alguien — y cada copia es una oportunidad de divergir.
• No tienen un único dueño. Cuando la marca se actualiza, el PDF, el archivo de Figma y el código cambian de forma independiente. Tres fuentes de verdad significan cero fuentes de verdad.

Una marca que vive solo en documentos es una marca que existe en todas partes excepto en el lugar donde los clientes realmente la ven.

Los design tokens como contrato

Un design token es una decisión con nombre. No #0F766E esparcido por cuarenta archivos, sino color.brand.primary definido una vez y referenciado en todas partes. El nombre carga la intención; el valor es solo un detalle de implementación que puede cambiar sin que nadie tenga que rastrear hojas de estilo.

Un token no es un color. Es la promesa de que este color significa lo mismo en Figma, en el sitio de marketing y en la app de producción — para siempre, hasta que decidas cambiarlo deliberadamente en un solo lugar.

La ventaja es que los tokens son datos. Se pueden exportar, importar, validar, comparar (diff) y versionar. Cuando expresas tus escalas de color, espaciado y tipografía como tokens, la marca deja de ser documentación y se vuelve infraestructura.

:root {
  /* Color — nombres semánticos, no hex crudo */
  --color-brand-primary: #0f766e;
  --color-text-default: #1c1917;
  --color-surface: #faf8f5;

  /* Espacio — una escala basada en ratio, no números mágicos */
  --space-1: 0.25rem;
  --space-2: 0.5rem;
  --space-4: 1rem;
  --space-8: 2rem;

  /* Tipografía — una escala, no un montón de tamaños sueltos */
  --font-size-body: 1rem;
  --font-size-h2: 1.5rem;
  --font-size-h1: 2.25rem;
}

Esa es toda la idea. Un botón echa mano de --space-2 y --color-brand-primary. Un título echa mano de --font-size-h1. Nadie teclea un código hex o un valor en píxeles a mano, así que nadie puede equivocarse en silencio.

El theming y los modos salen gratis

Una vez que la marca es un conjunto de variables, los modos claro/oscuro y el theming white-label dejan de ser proyectos separados. No reconstruyes componentes — cambias los valores detrás de los mismos nombres de token. El modo oscuro es un bloque de overrides:

[data-theme="dark"] {
  --color-text-default: #f5f5f4;
  --color-surface: #1c1917;
}

Cada componente que referenciaba --color-surface se adapta al instante, porque nunca supo ni le importó cuál era el color real. El mismo mecanismo alimenta a un cliente con dos submarcas sobre un solo código, o a un refresh estacional que se entrega en una tarde en vez de en un sprint. La estructura se paga sola la primera vez que la marca necesita estar en dos estados a la vez.

Handoff a código (y a Figma) sin capa de traducción

Aquí está la parte que hace que diseñadores e ingenieros dejen de pelear: las Figma Variables y las CSS custom properties tienen la misma forma. Un token llamado color/brand/primary en Figma se vuelve --color-brand-primary en código. El mapeo es mecánico, lo que significa que se puede automatizar — herramientas como Style Dictionary o Tokens Studio exportan un único archivo canónico de tokens a CSS, a la config de Tailwind, a iOS, a Android, a lo que sea el destino.

El handoff deja de ser una traducción y se vuelve una sincronización. Cuando entregamos una marca así:

• Los diseñadores trabajan en Figma contra las mismas variables que llegan a producción.
• Los ingenieros consumen tokens, no capturas de pantalla — no hay nada que estimar a ojo.
• Actualizar la marca significa editar la fuente de tokens y dejar que se propague. Un cambio, todas las superficies.

Se acabó el “hazlo que coincida con el mockup”. El mockup y el código beben del mismo pozo.

La conclusión

Cuando le entregamos una marca a un cliente, el entregable no es un PDF precioso — es un sistema de tokens versionado, reflejado en Figma y listo para soltar en código. El PDF sigue existiendo, pero es un mapa del sistema, no el sistema en sí. El sistema son las variables.

Si vas a encargar una marca, haz una pregunta antes de aceptar la entrega: “¿Puedo importar esto?” Si la respuesta es “está en la guía”, compraste una captura de pantalla que se va a pudrir. Si la respuesta es “aquí está el archivo de tokens”, compraste una marca que escala.