El reto no era la coherencia visual, sino la complejidad organizativa: marcas, productos, equipos y prioridades cambiantes resolvían problemas parecidos por separado.

Eso ralentizaba decisiones, duplicaba esfuerzo y elevaba el coste de mantenimiento.

Diseñar era solo el principio: el sistema aportaba valor cuando los equipos lo incorporaban a su trabajo.

El éxito dejó de medirse por los componentes publicados y pasó a verse en cómo los equipos resolvían juntos.

El éxito ya no se medía por el número de componentes. Se medía por si equipos distintos empezaban, de forma natural, a resolver problemas con el mismo lenguaje.

Al sostener trabajo real, el Design System reveló nuevos límites. Cada respuesta amplió lo que permitía hacer y preparó el siguiente paso.

Con una instrucción, la IA generaba una card o una pantalla en minutos, pero desconocía los componentes, sus variables y cómo cambiaban entre marcas. Ante cada vacío, inventaba una respuesta.

Cada resultado añadía decisiones duplicadas sobre espaciados, estructuras o nombres, y debilitaba el Design System como fuente de verdad. La rapidez inicial reaparecía después como revisión, reconstrucción y deuda de diseño. Para evitarlo, la IA debía trabajar desde los componentes y las reglas reales.

Una imitación visual no bastaba: el código debía conservar la estructura, la composición y las variables de cada pieza para que la IA pudiera trabajar con el sistema.

Los componentes complejos se construyen combinando piezas pequeñas y sus propiedades visuales usan variables del sistema. Cada variable mantiene el mismo nombre en Figma y código, sin traducciones ni equivalencias.

La card de hotel mantiene una misma estructura con cuatro zonas y doce piezas; ocho pueden mostrarse u ocultarse sin crear otro componente. Así se pueden montar pantallas y probar variantes dentro de las reglas definidas.

Necesitábamos una versión propia de los componentes en código, independiente de la de producción, para enseñar a negocio, maquetación y desarrollo el comportamiento, la animación y la interacción que buscábamos antes de que se construyeran. No como aproximaciones: con la estructura, las variantes y las variables de las librerías de Figma.

Cuando esa representación empezó a ser fiable, ya no servía solo para enseñar: también podíamos modificar una pieza, probar el estado que faltaba, ajustar su comportamiento responsive o crear una variante nueva dentro de las reglas del sistema.

Ahí apareció algo que no formaba parte del encargo inicial: el código podía ser también un espacio de diseño. La IA ya no partía de una pantalla vacía; trabajaba con el vocabulario y los límites que habíamos definido.

Hay round trip cuando un diseño puede continuar en código bajo las mismas reglas y volver a Figma editable.

Puede regresar como layout, variante o propuesta de componente, conservando capas y relaciones para seguir trabajando en Figma.

En Figma revisamos si la propuesta reutiliza piezas existentes o necesita una variante o un componente. Después decidimos su destino: el layout puede quedarse en el archivo de producto; una variante o un componente pueden avanzar a la librería; cualquier propuesta puede corregirse o descartarse. La automatización devuelve material editable; la revisión decide qué se publica.

Un sistema que se actualiza solo es un sistema que se estropea solo.

Cada pieza muestra su estado: en curso, en revisión o ready for dev. Como Lead del Design System, reviso el cambio en Figma y solo después de aprobarlo cambio su estado a ready for dev. La publicación en la librería no es automática.

Las variables siguen su propio camino. El equipo puede proponerlas; yo reviso la nomenclatura y el uso antes de incorporarlas a la colección correspondiente. Un nombre mal resuelto propaga su coste a todo lo que lo consume, así que ese control es deliberado.

La IA ejecuta contra esas reglas: identifica, compara y transporta cambios. No decide la nomenclatura, el alcance ni qué se publica. Con cada pieza viaja el detalle de qué cambia, a quién afecta y qué debe revisar quien ya la usa.

Cada fuente respondía una parte: qué se había diseñado, cómo funcionaba o qué estaba construido. Para saber si una necesidad concreta ya estaba cubierta todavía había que reconstruir la respuesta.

Así, una duda sobre lo existente podía empezar como una petición nueva: otro análisis y otra conversación antes de descubrir que parte del problema ya estaba resuelta.

En lugar de añadir otra capa de documentación, construí el catálogo alrededor de los componentes que ya teníamos en código, fieles a los de producción. Usaba los mismos tokens que producción y respetaba lo que ya estaba decidido y construido. Cada marca guardaba su configuración en un JSON (qué layouts y qué componentes usa), así que dos marcas del grupo podían enseñar pantallas distintas con las mismas piezas.

Cada componente podía cambiar de marca, variante, página y contexto. La pantalla podía componerse y abrirse en el navegador: la respuesta dejaba de ser una especificación y se convertía en algo navegable.

Negocio podía comprobar si la composición cubría la necesidad; mi equipo y yo, evaluar si respetaba el sistema; desarrollo, señalar límites mientras corregir seguía siendo barato.

El comportamiento responsive también entraba en esa conversación: no si la pieza simplemente encogía, sino qué debía permanecer visible y qué podía resumirse.