Si el color de Figma no es el de producción, no tienes sistema. Tienes un archivo bonito y un CSS que alguien ha ido parcheando. Los tokens son de las pocas cosas que sí están cambiando de verdad en el diseño web, frente a las que solo se anuncian: lo separamos en qué tendencias de 2026 son descriptivas y cuáles aspiracionales. El desajuste empieza en un hex y acaba en un botón que en móvil no es el mismo que aprobó dirección.
Los design tokens no son un capricho de designops. Son el contrato: el mismo valor de color, tipo, espacio y radio en el archivo de diseño y en el código. Sin ese contrato, cada sprint reabre la discusión de “este verde no es el verde”.
Este artículo explica cómo se trabajan los design tokens Figma de verdad —naming, capas, puente a código— y qué hacemos en Truman cuando un proyecto de diseño UX/UI tiene que sobrevivir al handoff.
Qué son (y qué no) los design tokens Figma
Un token es un valor con nombre: color, tipografía, espacio, radio, sombra, z-index, duración. No es el componente. No es la librería de botones. Es el átomo que el botón consume. Si cambias color.brand.600, cambian CTA, links y estados sin reabrir 80 frames.
Figma Variables cubre una parte —color, número, string, boolean— y Modes (claro/oscuro, marca, densidad). No cubre solo el archivo: el token tiene que salir del archivo. JSON, CSS custom properties, tokens de Style Dictionary, tema de una app. Si se queda en Figma, es una variable de diseño, no un token de producto.
Esto encaja con lo que ya escribimos sobre qué es un sistema de diseño: el sistema no es la UI kit. Es la gobernanza de decisiones visuales. Los tokens son esa gobernanza hecha dato. El resto —componentes, documentación, proceso— se apoya encima o se pudre encima.
Naming: el contrato que sí se puede cumplir
El naming malo es la causa número uno de que Figma y código se divorcien. Diseño nombra por aspecto (blue-2, green-button). Desarrollo nombra por uso (--btn-bg). Nadie traduce. Cada uno “ajusta un poco”.
En Truman usamos dos capas, y solo dos, hasta que el producto las pide: primitivos y semánticos. Los primitivos son la paleta cruda (color.green.700). Los semánticos son la intención (color.text.primary, color.action.bg). El código consume semánticos. Los primitivos se pueden cambiar de marca sin reescribir componentes.
| Capa | Ejemplo | Quién la toca |
|---|---|---|
| Primitiva | color.green.700 | Diseño + marca |
| Semántica | color.action.primary | Diseño + front |
| De componente | button.primary.bg | Solo si hay excepciones |
| Hex suelto en CSS | #1a4a3a | Nadie debería |
| Nombre por aspecto | blue-button-hover | Se rompe al rebrand |
La tercera capa (tokens de componente) solo la abrimos cuando un patrón no cabe en semánticos: un checkout con un verde distinto al CTA de marketing, un estado de error en un mapa. Si todo es “de componente”, no tienes tokens: tienes una lista de excepciones.
¿Puedes cambiar el color de marca en un solo sitio y que Figma y producción se actualicen sin un buscador de hex? Si no, el naming aún no es un contrato.
El puente real entre diseño y desarrollo
El puente no es “exportar CSS” desde un plugin y pegarlo. Eso dura un sprint. El puente es una fuente de verdad versionada: variables en Figma, un export (Tokens Studio, variables nativas, script propio) y un build que genera CSS, iOS o el tema de la app.
Las herramientas de 2026 ayudan —Variables, MCP, plugins de handoff— pero no sustituyen el acuerdo. Lo detallo en Figma to code: herramientas en 2026: el plugin no gobierna. Gobierna el naming y el repo. Sin eso, automatizas el desorden.
Tip técnico: una sola familia de custom properties
En web, el destino más estable es :root con custom properties semánticas (--color-action-primary), no una mezcla de Sass maps, hex en Tailwind config y variables de Figma sin publicar. Tailwind puede mapear a esas properties. Lo que no puede es ser la fuente de verdad si diseño no las ve. Fuente: Figma + JSON. Consumo: CSS. Tailwind, si acaso, es un adaptador.
Dónde se nota: Klapper y Pulso Studio
En Klapper el producto es propio: marca, web y app de compra de entradas. Si el verde del CTA de iOS no es el de la web, el usuario no piensa “design tokens”: piensa que la app es de otro. Tokens de color, tipo y espacio tienen que viajar a dos frontales. El naming semántico es lo que evita un hex por plataforma.
En Pulso Studio el problema era otro: una web de agencia de entretenimiento en vivo que tiene que parecer del sector —rápida, clara, con pulso— sin que cada sección invente su escala tipográfica. Tokens de tipo y espacio evitan que “la home vaya a 72px y el caso a 28px porque el frame era otro”. Coherencia no es aburrir: es que el ritmo se sienta el mismo.
Cómo implantarlo sin montar un design system de 200 componentes
No hace falta Atomic Design en un wiki. Hace falta que el siguiente color no se decida en un comentario de Figma. En un proyecto a medida de 8–12 semanas, el mínimo viable es este: paleta primitiva cerrada, 15–25 semánticos, escala de tipo y de espacio, y un export al repo en la semana 2 —no en la 11, cuando el CSS ya tiene 40 hex.
El error clásico es esperar a “tener el sistema”. El sistema empieza el día que el primer botón usa una variable. En Truman lo atamos en el kickoff de UX/UI: quién nombra, quién exporta, quién rechaza un PR con hex suelto. Sin dueño, el token es folklore.
Un design system que no llega a código es una presentación. Los tokens son la primera prueba de que diseño y desarrollo están construyendo el mismo producto.
Si el producto va a tener app y web —como Klapper— el token se define una vez y se traduce dos veces. Si solo hay web, CSS custom properties bastan. No adelantes iOS tokens “por si acaso”. Adelanta el naming, que es lo que no se refactoriza barato.
Antes de dar por cerrado el handoff, verifica esto
- ¿Los componentes de Figma usan variables, no hex pintados a mano?
- ¿Existe capa primitiva y capa semántica, con nombres que desarrollo puede copiar?
- ¿El export vive en el repositorio y se revisa en pull request?
- ¿El CSS o el tema de la app consume tokens semánticos, no una paleta paralela?
- ¿Hay una regla de equipo: cero hex nuevos sin token?
- ¿El modo oscuro o la marca blanca, si existen, son Modes —no un filtro?
- ¿Alguien (diseño o front) es dueño del naming y puede rechazar un alias sucio?
Preguntas frecuentes sobre design tokens y Figma
¿Hace falta Tokens Studio o bastan las Variables nativas de Figma?
Para un producto web con un tema, Variables nativas y un export a JSON suelen bastar. Tokens Studio (o un script) entra cuando hay varios temas, plataformas o un pipeline Style Dictionary que ya usa el equipo. La herramienta no arregla un naming roto.
¿Cuándo hay que crear tokens de componente?
Cuando un patrón no se puede expresar con semánticos sin mentir. Un botón primario debería usar color.action.primary, no un token propio. Si cada componente tiene su token, has copiado el CSS con otro nombre.
¿Los tokens sustituyen a un design system?
No. Los tokens son la capa de valores. El sistema incluye componentes, documentación y reglas de uso. Pero sin tokens, el sistema se desvía en el primer sprint de producción. Empieza por tokens; no empieces por un wiki de 80 páginas.
¿Cuánto tarda implantar tokens en un proyecto a medida?
El núcleo (color, tipo, espacio) se cierra en días, no en meses, si se decide en el kickoff. Lo que alarga es el inventario de hex ya existentes. En un rediseño, hazlo en la semana 1. En un legado, mapea y sustituye por oleadas: acción, texto, fondos. No un big bang.
