Tokens Studio: design tokens desde Figma, paso a paso
Tokens Studio es un plugin de Figma para crear design tokens y sincronizarlos con GitHub o GitLab. Qué hace, cómo se configura y qué planes existen.
¿Qué es un design token y por qué importa aquí?
Un design token es un valor con nombre: color.fondo.primario en lugar de #1A73E8. Si el color cambia, cambias el token y no cada pantalla. Para entender cómo se estructuran estos nombres en capas, lee arquitectura de tokens.
Tokens Studio resuelve el paso intermedio: que los tokens nazcan en Figma, donde trabaja el diseñador, y lleguen al código sin copiar valores a mano.
¿Cómo funciona por dentro?
El plugin organiza los tokens en tres piezas:
- Tokens: cada valor individual, con nombre y tipo.
- Token sets: contenedores de tokens, por ejemplo
base,marcaomodo-oscuro. La documentación los describe como la versión sin código de un archivo JSON. Cada set necesita un nombre único, y una barra en el nombre (marcas/berry) crea una carpeta en el árbol. - Sincronización: un proveedor, como GitHub o GitLab, donde se guardan los archivos JSON.
Cada set puede estar activado, desactivado o marcado como fuente. Un set activado deja sus tokens disponibles para aplicarlos, referenciarlos y exportarlos; uno desactivado se ignora; uno fuente solo aporta valores a las referencias. Si dos sets activados tienen un token con el mismo nombre, gana el que está más abajo en la lista. Esa regla, parecida a una cascada de valores por defecto y sobrescrituras, es la base de los temas. Los temas (combinaciones de sets que se aplican juntas, como claro y oscuro) son una función de pago.
Los nombres usan puntos para crear jerarquía (color.texto.secundario), y los grupos forman un árbol dentro del plugin y en los archivos de código. Cada nombre debe ser único dentro de su set. Los nombres de token no pueden contener los caracteres {, } ni $. Además, la documentación advierte que los nombres suelen transformarse al llevarlos al código (cambios de mayúsculas, aplanado de grupos) y pueden chocar entre sí, así que conviene pensar cómo quedarán al final.
Un token semántico (por ejemplo color.accion.primaria) puede apuntar a un token de paleta. Esa referencia es lo que permite cambiar un tema editando una capa, no todos los valores de la interfaz.
¿Cómo se configura GitHub?
La documentación oficial describe estos pasos (Tokens Studio: GitHub sync):
- Crea un repositorio y marca «Add a README file». El plugin no puede sincronizar con un repositorio vacío. Puede ser público o privado.
- Genera un token de acceso personal. Con token clásico necesitas el scope
repo; con token de grano fino, el permiso Contents en lectura y escritura. Con solo lectura puedes ver los tokens, pero no crearlos ni editarlos. - En Figma, abre la configuración del plugin, elige «Add new» en proveedores de sincronización y selecciona GitHub.
- Completa nombre, token, repositorio (
usuario/repo), rama y la ruta donde se guardarán los archivos. La URL base solo hace falta con un servidor de GitHub empresarial. - Guarda y sincroniza con push o pull.
La ruta define el formato del resultado. Con una carpeta (por ejemplo tokens), cada set se guarda como un archivo JSON propio. Con un archivo (por ejemplo tokens.json), todos los sets se combinan en uno, y la documentación advierte que eso limita el trabajo de los desarrolladores con la información de temas. Guardar en una carpeta (sincronización en varios archivos) es una función de pago; si un colaborador no tiene el plan Team, verá esos tokens en solo lectura. GitLab sigue el mismo esquema, con el scope api en el token.
¿Qué formato de tokens conviene elegir?
El plugin soporta dos: el formato legacy de Tokens Studio, que es el predeterminado, y el formato W3C DTCG, que prefija las propiedades con $ ($value, $type, $description). La documentación señala algunas condiciones: DTCG define tipos de token que el plugin aún no soporta, y su salida exige configurar Style Dictionary con SD-Transforms y convertToDTCG. En repositorios con Git, cada rama puede usar un formato distinto. Referencia: Tokens Studio: formato de tokens.
¿Qué planes existen?
Los precios cambian, así que verifica siempre la página oficial (Tokens Studio: precios). La página mostraba el 7 de noviembre de 2026:
| Plan | Precio indicado | Qué incluye, según la página |
|---|---|---|
| Free | 0 € | Un editor, visores ilimitados, un proyecto con una rama activa. Acceso a la plataforma Studio, sin las funciones de pago del plugin de Figma. |
| Team | 39 € por mes, facturado anualmente | Un editor incluido (cada editor adicional cuesta 39 € al mes), visores ilimitados, 5 proyectos con 5 ramas activas cada uno, 1 GB de recursos, soporte por chat o Slack, y todas las funciones de pago del plugin. |
| Organization | 499 € por mes, facturado anualmente | 5 editores incluidos (adicionales a 49 € al mes), proyectos y ramas ilimitados, 10 GB de recursos, soporte prioritario. SSO, sincronización de directorio y exportación de auditoría son complementos de pago. |
| Enterprise | A medida | Configuraciones de seguridad y escala; se contacta con ventas. |
La página indica que los planes antiguos (Starter Plus, Pro y Essential) se integraron en Team. El precio base incluye un editor en Team y cinco en Organization, y los editores extra se cobran aparte. Studio ofrece una prueba de 14 días sin datos de pago.
¿Cuándo NO conviene usarlo?
- Si tu equipo no tiene un flujo de código donde los tokens lleguen. Sin destino, el plugin es solo una paleta bien organizada.
- Si vas a sincronizar en un solo archivo y ya tienes un pipeline propio con Style Dictionary, puede bastar con exportar JSON desde otra herramienta.
- Si el equipo aún no decidió quién es dueño de los tokens. Sin reglas de cambio, los sets se llenan de valores duplicados. Eso se resuelve antes que con cualquier plugin; mira gobernanza de un design system.
Ejemplo ilustrativo
Ejemplo ilustrativo: una diseñadora crea un set base con colores y espaciados, y un set modo-oscuro que sobrescribe solo los colores de superficie; como el set de abajo gana, basta activar los dos en ese orden. Sincroniza con un repositorio cuya carpeta tokens tiene un archivo por set (función de pago). El desarrollador lee esos JSON con su herramienta de build y genera variables CSS. Cuando la diseñadora cambia el color de superficie en Figma y sincroniza, el cambio llega al repositorio en una confirmación (commit) que se puede revisar, igual que cualquier otro cambio de código.
Si ya usas IA para generar código desde estos valores, lee design tokens para agentes. Para la parte de paridad entre diseño y código, mira paridad de tokens.
Errores comunes
- Crear tokens con nombres de valor (
azul-2) en lugar de nombres de función (color.accion.primaria). - Usar un repositorio vacío y luego no entender por qué falla la conexión.
- Cambiar al formato DTCG sin configurar Style Dictionary para la salida.
- Editar el JSON a mano en el repositorio y luego sobrescribirlo desde Figma.
- Dar por hecho que la sincronización en carpeta es gratis y descubrir que un colaborador sin plan de pago solo puede leer los tokens.
- Pensar que la herramienta reemplaza la decisión de diseño: un token mal nombrado sigue siendo un token mal nombrado.
Qué puedes hacer mañana
- Abre el plugin con un archivo de prueba y crea un set
basecon cinco colores y cinco espaciados. - Revisa en la documentación oficial si tu proyecto de código ya consume JSON de tokens o necesita otro paso.
- Escribe una regla de nombres en una página de una línea antes de crear más tokens.