Typography Style Sync

01 El problema

Figma permite definir la tipografía como variables atómicas: familia, tamaño, peso, interlineado y tracking. Es la forma correcta de tener una escala gobernada por tokens. Pero no hay manera nativa de convertir esas variables en text styles a escala. Crear un estilo y vincular a mano sus cinco propiedades, una por una, es repetitivo, se equivoca uno con facilidad, y deja de tener sentido en cuanto el sistema pasa de veinte estilos.

Me pasó con el design system de text+: 107 variables tipográficas, veinte estilos, cien vinculaciones. Quien invierte en una arquitectura de tokens acaba aplicando la tipografía propiedad a propiedad, que es justo lo que el sistema pretendía evitar. Ese hueco es el plugin.

02 Las decisiones

Genérico, no un script para mi archivo

La primera versión estaba pensada para mi estructura de variables. La rehíce para que funcione con cualquier colección y cualquier convención de nombres: quien lo usa mapea qué variable es cada propiedad desde la interfaz. Más difícil de especificar, mucho más valioso.

Desplegables, no campos de texto

El mapeo se hace eligiendo entre las rutas reales de variables del archivo, con detección automática y una etiqueta que dice si el mapeo lo hizo el plugin o la persona. Sin errores de escritura, sin adivinar nombres.

Previsualizar antes de tocar nada

Antes de generar, el plugin resuelve los valores reales de cada estilo, siguiendo las cadenas de alias, y los muestra: “Zilla Slab · 700 · 36px · 44 leading”. Los grupos incompletos se listan aparte con la propiedad que les falta. Nadie ejecuta a ciegas.

La gestión de conflictos solo aparece cuando hay conflicto

Si ya existen estilos con el mismo nombre, el plugin lo dice y ofrece saltarlos o sobrescribirlos. Si no, esa sección no existe. Menos ruido en el caso normal.

03 Cómo funciona

Cuatro pasos en una ventana de 340 píxeles: elegir la colección, revisar el mapeo, previsualizar y generar. Al final, un informe por estilo: creado, actualizado, omitido o fallido, con el motivo.

Cada estilo generado queda vinculado a sus variables con la API de Figma, no copiado. Si mañana cambia el tamaño de un token, el text style cambia con él. Cinco pantallas de interfaz, cargando, vacío, error, principal y éxito, y accesibilidad WCAG 2.1 AA de serie: contraste, etiquetas explícitas, orden de tabulación y regiones que anuncian los cambios de estado.

04 Cómo lo construí

Lo construí con un agente de IA como par, y el proceso es tan parte de la pieza como el resultado.

• Un brief de contexto, no pseudocódigo. Escribí qué tenía que hacer el plugin, cómo debía comportarse y qué restricciones técnicas eran innegociables. El agente decidió cómo. Para eso creé un asistente propio, un “arquitecto de plugins de Figma”, que genera estos briefs con la estructura que el agente entiende mejor.
• Auditoría de UX antes de la primera línea. Detecté cinco estados que faltaban en la interfaz, arreglé el flujo, sin vuelta atrás, un botón de refrescar ambiguo, un botón desactivado sin explicación, y fijé los requisitos de accesibilidad antes de generar código.
• Revisión de cada plan. Aprobé la implementación paso a paso y corregí un error de API que el agente no vio: las variables de Figma exigen las versiones asíncronas y el acceso dinámico a páginas en el manifiesto. Es el fallo más común del código de plugins generado por IA.
• Varias rondas de alcance. La primera salida tenía un solo botón. La rechacé y pedí control completo: selector de colección, mapeo, previsualización y conflictos.

El código está en github.com/eyfran/typography-style-sync.

Y en la otra dirección. Con el mismo criterio escribí un generador que lleva las variables de Figma al navegador: las cinco colecciones exportadas se convierten en custom properties y clases utilitarias con el vocabulario del sistema, y los tres temas se cambian con un atributo.

05 Aprendizajes

01 La calidad de lo que sale de un agente la fija el contexto que le das. Un brief con el problema, el comportamiento esperado y las restricciones produce mejor código que el pseudocódigo, porque el pseudocódigo traslada tus errores a la implementación.

02 Empezar genérico cuesta más y vale más. Un plugin que sirve para cualquier archivo obliga a diseñar la interfaz de verdad, y es lo que lo convierte en una herramienta y no en un apaño.

03 Un diseñador tiene que saber leer la API que usa. Los errores que cacé en revisión no eran de gusto, eran técnicos, y sin entenderlos el plugin no habría funcionado.

---

Un sistema tipográfico que hay que aplicar propiedad a propiedad no es un sistema. Es una lista.