En el proyecto Hoteles B2B se usaron los componentes del sistema desde el principio. Lo que costó fue que una organización acostumbrada a resolverlo todo con una plantilla estática viera qué ganaba con trabajar de otra forma: cambiar una pieza sin rehacer la página, diferenciar una marca sin duplicar código y empezar un producto nuevo con casi todo hecho.

Gran parte de mi trabajo fue formar a los equipos y resolver sus dudas mientras el sistema aterrizaba en código. Lo acompañé con datos: el uso real medido en código, hoy 27.158 instancias en las 23 marcas, y la documentación de cada componente con un formato común.

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.

Una variable mal puesta se ve en una revisión; una estructura inventada, no. La pieza parecía correcta y funcionaba sola, pero al meterla en un slot o combinarla con otras dejaba de encajar, y el fallo aparecía después, lejos de donde se había originado. Lo que se ganaba al generar se perdía rehaciendo piezas con los componentes de verdad. Para evitarlo, la IA tenía que trabajar desde la estructura real de los componentes y desde las variables del sistema.

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.

Definí sus reglas de trabajo, y las más eficaces son las restrictivas, las que delimitan lo que la IA no puede hacer. La estructura de un componente no la adivina; la lee de Figma. Tampoco inventa contenido "más realista"; copia los textos de ejemplo tal cual. Si una variante pide cambiar la estructura, para y me avisa antes de construir. Y no da una pieza por terminada hasta cubrir todas sus variantes reales. Los errores del propio Figma no los arregla por su cuenta; los reproduce y me los señala para corregirlos en origen.

Desarrollo ya tenía algunos de los componentes en Angular, pero diseño necesitaba enseñar a negocio el comportamiento, la animación y la interacción que buscábamos antes de que se construyeran, y cambiar el contenido de los slots sin esperar a desarrollo. Para eso hicimos una versión propia en Web Components, independiente de la de producción, con la estructura, las variantes y las variables de las librerías de Figma. Maquetación y desarrollo siguen construyendo los componentes de producción, pero ahora parten de prototipos animados e interactivos.

Cuando esa versión empezó a ser fiable, ya no servía solo para enseñar. En ella se podía modificar una pieza o crear una variante nueva dentro de las reglas del sistema, y ese cambio es el que después vuelve a Figma.

Hay round trip cuando un diseño continúa en código bajo las mismas reglas y vuelve a Figma con sus capas y relaciones, listo para seguir trabajando.

En Figma revisamos si la propuesta reutiliza piezas existentes o necesita una variante o un componente nuevo. Lo que se aprueba va a la librería común o a la específica de un producto, y tratamos de que todo sea lo más transversal posible. Cualquier propuesta puede corregirse o descartarse, y lo que se publica lo decide la revisión, no la automatización.

La librería tiene un responsable de mantenimiento que revisa los cambios del día y publica una versión al cierre de cada jornada, así que el equipo empieza siempre sobre la última versión estable.

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 junto al componente en Figma; yo reviso la nomenclatura y el uso antes de incorporarlas a su colección.

La IA identifica, compara y transporta los cambios siguiendo esas reglas, pero no decide la nomenclatura, el alcance ni qué se publica.

Cuando una pieza pasa a ready for dev, se genera automáticamente su changelog frente a la última versión publicada y queda en la página de changelog de Figma, donde los demás equipos consultan el Design System. Está escrito para el handoff, en un formato que acordamos diseño, maquetación y desarrollo. Recoge, entre otras cosas, quién hizo el cambio y qué proyecto lo provocó, qué componentes internos se modificaron, si alguno pasa a usar otra variable, qué propiedades CSS cambiaron y qué variantes o nombres son nuevos. Si después cambia algo en Figma, se actualiza también el código, para que los dos cuenten siempre lo mismo.

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, con 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, y la pantalla montada se podía recorrer en el navegador. La respuesta a "¿esto ya lo tenemos?" era una página.

La plataforma la construí dirigiendo a la IA, sobre los mismos Web Components del round trip. Decidí qué tenía que poder hacer, qué marcas y layouts entraban y cuándo algo estaba bien; la IA escribió el código y lo revisé en el navegador.

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

El comportamiento responsive también entraba en esa conversación. Se discutía qué debía permanecer visible y qué podía resumirse cuando la pieza se estrechaba.