Contexto
Siempre me ha gustado Figma como herramienta de UX/UI. Tiene muchas virtudes; además, no dejan de agregar nuevas funciones, lo que los hace estar a la vanguardia (por no decir que tiene prácticamente el monopolio del mercado). Otra de las cosas que encuentro entretenidas es diseñar componentes: construirlos con una estructura inteligente, escalable y bien pensada, para luego ver cómo funcionan.
Sin embargo, eso conlleva un proceso que, sinceramente, me da tedio: La documentación.
Teniendo esto en cuenta, me di cuenta de la necesidad de automatizar este proceso. Y justo a tiempo, porque el Design System dejó de funcionar bajo un modelo centralizado para pasar a uno federado, un giro que traía consigo nuevos desafíos.
Este nuevo modelo significaba dar más independencia a las demás células para diseñar sus propios componentes, siempre bajo la supervisión de nuestro equipo y respetando los lineamientos establecidos en nuestras librerías.
Documentar un componente correctamente (sus variantes, propiedades, estados, usos) es una tarea que toma tiempo, y en un esquema federado, donde más personas estarían creando componentes y además considerar los tareas que puedar tener cada diseñador con sus respectivos equipos, ese tiempo se multiplicaba. Automatizar este punto se volvió vital.
Así nació la idea: un plugin de Figma capaz de generar la documentación de un componente automáticamente. La idea de uso era simple — el diseñador termina de construir su componente, lo escanea con el plugin, y con un solo clic obtiene la documentación completa, lista para integrarse a la librería.
Desafío técnico
Acá es donde el proyecto se puso interesante para mí. Tengo nociones básicas de programación, pero no soy desarrollador. Y para construir un plugin de Figma, necesitaba escribir código.
Una opción era delegarlo a alguien del equipo. Pero en ese momento estábamos con un nivel de exigencia bastante alto, sosteniendo roadmaps y tareas propias, además de dar soporte constante a los distintos equipos que consumen el Design System. Sumar este proyecto a la carga de alguien más no era realista.
Así que tomé la iniciativa, empezando por el diseño y la lógica de como debería funcionar el plugin, cómo debía verse, qué pasos seguiría el usuario, qué información debía extraer de un componente, cómo se vería esa documentación generada, etc. El siguiente flujo muestra esa primera aproximación.
Flujo de funcionamiento del plugin
Como no soy programador, el paso obvio fue desarrollarlo con IA. Vibecodear es un termino muy de moda ultimamente, así que, ¿por qué no?.
Prompt & play
Comencé con el más popular, Claude. Solo me bastó con un prompt para llegar a una opción funcional del plugin. Fue plantearle el problema: Qué necesitaba solucionar, para qué lo quería usar y cómolo debía funcionar.
Algo que también me interesaba entender es cómo funciona esto por dentro. Esto funciona mediante API de Figma. Y tiene una estructura simple:
Arquitectura del plugin
Testearlo fue súper sencillo también. En Figma vas a Plugins > Development > Import from manifest. Esto te permite testar el plugin en un entorno local antes de publicarlo. Acá es donde me doy cuenta que la UI que el plugin que me entregó era muy simple. Así que decidí hacer el diseño en Figma y lo traspasé al desarrollo mediante un plugin FigmaToJson.
Teniendo cubierto el diseño, solo quedó el foco de pulir el funcionamiento del plugin. Definir como será la estructura de la documentación, poder encender y apagar secciones de las propiedades, reorganizarlas y añadir anotaciones.
Llegado a este punto decidí hacer un cambio importante en mi flujo de trabajo. Migrar todo el proyecto a Antigravity. Y es que cuando dije que estaba usando Claude, me refería a Claude chat, no Claude Code. Esto hacía que tuviese un flujo de iteración no tan óptimo como me gustaría.
Migrar el proyecto fue la decisión correcta. Para quienes no están familiarizados, Antigravity es un entorno de desarrollo integrado (IDE) impulsado por IA que incorpora agentes (incluido Claude) capaces de comprender el contexto del proyecto, generar código, realizar modificaciones y ejecutar tareas de desarrollo.
In progress...