En Workoholics, los equipos de diseño, desarrollo y comunicación ya trabajan con agentes de IA a través de flujos encadenados para cada perfil: paquetes de habilidades, uno por perfil, que llevan el sistema de diseño de una marca desde Figma hasta su web, sus campañas y sus presentaciones. Cada cambio viaja por GitLab con una merge request revisable, así que nadie copia valores a mano. Lo aplicamos hoy en nuestros proyectos, del arranque al QA visual, para que diseño, código y marca cuenten siempre lo mismo.
Hace unas semanas, Amaia contaba aquí cómo usamos DESIGN.md para que los agentes de IA entiendan nuestros sistemas de diseño. Y terminaba con un reto pendiente: ese archivo no se actualiza solo. Si cambia un token en Figma, alguien tiene que acordarse de trasladarlo. Este post va de cómo lo hemos resuelto, gracias a un flujo de trabajo. O, mejor dicho, con varios. Uno para cada perfil del equipo, encadenados entre sí, que llevan cada decisión de diseño desde Figma hasta el código sin que nadie tenga que copiar un valor a mano.
Del prompt suelto al flujo de trabajo
Cuando una empresa empieza a trabajar con IA, lo habitual es que cada persona tenga sus propios prompts. Funcionan, pero no escalan y cada persona obtiene resultados distintos para la misma tarea.
Con un workflow perfilado, en lugar de pedirle a cada persona que sepa explicarle a la IA cómo trabajamos, empaquetamos ese conocimiento en habilidades (skills) que el agente ya trae aprendidas. Cada skill hace una sola cosa, sabe cuándo debe usarse, qué necesita para empezar y qué entrega al terminar.
Lo importante es que todas estas piezas encajan. Lo que produce una skill de diseño es lo que espera la siguiente skill de desarrollo con exactitud. Y si falta algo, no improvisa: se para, dice qué falta y sabe a quién pedírselo.
Metodología: una sola fuente
De esta forma, Figma se convierte en la fuente de verdad, y de alguna forma el repositorio es el contrato. El diseño se decide y refleja en Figma; lo que llega a GitLab, en la carpeta .claude/design de cada proyecto, es la versión acordada de ese diseño, legible por personas y por agentes.
De ahí salen tres principios:
- No necesitamos tocar manualmente nada dos veces. Los tokens, componentes y plantillas se leen de Figma y se escriben en el repo.
- La automatización respeta el trabajo del equipo. Cada fichero separa lo que llega de Figma de las notas y excepciones que añaden las personas. Al sincronizar, solo se actualiza lo generado; lo que ha escrito alguien del equipo se queda donde está.
- Los originales de diseño no se modifican. Las skills los leen y escriben solo en sus propias páginas (Components, Layout, Screens).
Y se mantiene el orden, porque en un sistema de diseño unas piezas dependen de otras:
- Tokens: color, tipografía, espaciado, radios y motion, normalizados como variables.
- Layout base: grid, contenedores, márgenes y ritmo vertical por breakpoint.
- Componentes: átomos, moléculas y organismos, construidos de abajo arriba con instancias del nivel anterior.
- Plantillas de página: regiones y organismos por plantilla.
- Motion: animaciones e interacciones descritas como datos, con sus propios tokens.
- Pantallas: cada pantalla convertida en una definición reproducible, con contenido real y de prueba.
Cada paso se sube al repositorio y así, cualquier cambio de diseño se revisa como se revisa el código: con un historial, una persona que aprueba y la posibilidad de volver atrás.
Un plugin para cada perfil
La clave de que esto funcione en un equipo es que cada persona use lo que necesita, en su lenguaje. Quien diseña no tiene que saber de ramas. Quien desarrolla no tiene que abrir Figma para buscar un valor.
Diseño: ordenar, documentar y subir
El plugin de diseño convierte un archivo de Figma en un sistema. Extrae los tokens y los normaliza como variables, identifica átomos, moléculas y organismos y los construye como componentes con sus variantes, define el grid y las plantillas de página, y describe el motion en lenguaje natural para traducirlo a una definición estructurada. También funciona con referencias: una web, un vídeo o un GIF para decir "que se mueva así".
Cada subida llega con un informe en lenguaje claro: componentes nuevos, renombrados, valores cambiados, variantes añadidas y qué otras piezas se ven afectadas. Ese informe aparece en la confirmación, en la merge request y en el resumen final.
Desarrollo: implementar lo definido, y solo eso
El plugin de desarrollo recorre el mismo orden: tokens, ui-kit, layout, pantallas y motion. Cada skill lee la especificación del repositorio y la implementa en la tecnología del proyecto, sea Astro, React, Angular u otra. No diseña. Implementa lo que se ha decidido.
Algunas reglas que el agente aplica siempre:
- Los valores visuales solo se escriben como tokens, nunca como números sueltos.
- Los componentes se montan por composición, sin parches de estilo sobre sus hijos.
- Cada componente aparece en un catálogo interno con datos ficticios y escenarios extremos: textos largos, vacíos, muchos elementos.
- Las pantallas se montan primero con contenido de prueba, listas para integrarse después con el CMS.
Y cerramos el círculo con una skill de revisión de interfaz. Compara la pantalla implementada con el frame de Figma y con la especificación, y entrega un informe de hallazgos con evidencia y gravedad. Distingue si el fallo es de código o si el diseño y la especificación se contradicen, en cuyo caso vuelve a diseño. Corrige solo con confirmación.
Comunicación y comercial: la marca sale a la calle
El sistema de diseño no termina en la web. El plugin de comunicación parte de los mismos tokens, componentes y plantillas del repositorio para generar las piezas de cada campaña: un mailing, una landing de campaña o una nueva presentación corporativa. Cada pieza nace con la marca al día, sin rehacer estilos ni buscar el último logo.
El perfil comercial aprovecha esa misma base para preparar propuestas y presentaciones a medida de cada cuenta. Puede adaptar el mensaje, pero no salirse de la identidad. Si la marca cambia en Figma, cambia también en todo lo que se publica.
Casos de uso: cómo se vive en el día a día
Es como trabajamos ya en la agencia. Algunas situaciones reales de nuestro día a día:
Arrancar un proyecto web desde cero. Un solo encargo monta el proyecto completo: un repositorio con la web en Astro, el CMS en Strapi y las librerías compartidas. Después, los tokens llegan desde diseño y el sistema empieza a tomar forma sin configuraciones a medida para cada proyecto.
Un cambio de diseño a mitad de proyecto. Diseño retoca un grupo de colores y dos componentes. Antes de subir nada, pide ver qué ha cambiado, revisa el informe y sube solo esas unidades. Desarrollo recibe una merge request clara, sincroniza el theme y el ui-kit sabe exactamente qué actualizar. Nadie pregunta "¿esto era así o lo he soñado?".
Animaciones que no se pierden por el camino. Queremos que una card entre al hacer scroll o que una sección se quede fija mientras avanza el contenido. Diseño lo describe con palabras o con una referencia; la skill lo convierte en una definición con tokens de duración, curva y distancia. Desarrollo lo implementa con GSAP y ScrollTrigger si el proyecto lo usa, respetando siempre a quien prefiere reducir el movimiento.
Pantallas con contenido realista. Cada pantalla se extrae de Figma como una definición: qué plantilla usa, qué componente va en cada región y qué contenido espera. A partir de ahí se generan juegos de contenido de prueba (vacío, textos largos, muchos elementos, errores) y se construyen en Figma o en código para verlos todos. Los casos límite aparecen antes del lanzamiento, no después.
QA visual con criterio. Antes de dar una pantalla por buena, la revisión de interfaz la compara con el diseño a varios anchos y estados (hover, foco, menú abierto). El resultado es un informe ordenado por gravedad que cualquiera del equipo puede leer.
Lo que hemos aprendido por el camino
No todo salió a la primera. Y lo contamos porque es parte de la historia.
Más rápido no siempre significa más cosas. Nuestras primeras subidas releían Figma entero y reescribían todo el sistema en cada cambio. Funcionaba, pero pesaba. Ahora cada grupo de tokens, componente o plantilla tiene una huella: si no ha cambiado, ni se lee ni se sube. Probamos también a subir desde el equipo de cada persona con git local, y lo descartamos. Todo va por la conexión con GitLab, sin clones ni configuraciones que se desalinean de un ordenador a otro.
Las decisiones técnicas tienen que vivir en la especificación. Un ejemplo: con ciertas librerías de scroll, un elemento fijo no se resuelve con CSS. Por eso ese comportamiento ya no vive en el componente, sino en su definición de motion. Así desarrollo sabe cómo implementarlo según la tecnología de cada proyecto.
Que la IA se pare es una virtud. Cada skill comprueba antes de empezar que tiene lo que necesita. Si no, se detiene, explica qué falta y a quién pedírselo. Menos magia, más confianza.
Lo que ha cambiado en el equipo
La creación de estos flujos está suponiendo una oportunidad para relacionarnos desde una nueva perspectiva entre nosotras, entendiendo las necesidades y urgencias de cada perfil.
- Menos idas y venidas y revisiones más claras, porque cada cambio de diseño se recoge, versiona y aprueba, como el código.
- Coherencia entre personas del equipo. El agente aplica las mismas reglas trabaje quien trabaje y el onboarding es más ágil porque el contexto del proyecto está en el repositorio.
- Más tiempo para lo que importa: crear, decidir, cuestionar y pulir el detalle.
¿Cómo sabemos si funciona? Nos fijamos en tres señales: cuánto tarda en aprobarse un cambio de diseño, cuántos errores encontramos al revisar cada pantalla y cuántas veces aparece un color, una tipografía o una medida que no está en el sistema de marca. Si los cambios se aprueban antes y aparecen menos errores y menos desvíos de la marca, vamos por buen camino.
Y una lección que va más allá del diseño: el mismo patrón sirve para los diferentes perfiles. Marketing, contenidos o ventas pueden tener también sus propias skills, con la marca y el criterio del equipo incorporados, para que cualquier persona produzca con coherencia aunque no tenga perfil técnico.
El criterio, nuestro mayor valor
Decía Amaia que el diseño nunca terminó en Figma. Hoy añadimos que tampoco tiene que perderse por el camino. Cuando el conocimiento de un equipo se convierte en un flujo de trabajo, deja de depender de la memoria de una persona y empieza a trabajar para todas.
Eso sí, las skills no deciden el color que mejor transmite el valor de una marca, o la intención y experiencia de una interacción. Lo seguimos haciendo nosotras. La IA ejecuta y ordena. Y, como decía Amaia, el criterio, las preguntas y las decisiones compartidas siguen siendo cosa nuestra.
Y esto no se queda en casa. Acompañamos a otras compañías en las dos partes del camino: definir la estrategia y el sistema de marca, y diseñar e implantar los workflows que lo llevan a cada equipo, de marketing a desarrollo. En organizaciones grandes, con muchos equipos y proveedores, es donde más se nota: la marca llega igual a cada canal y los equipos de software pueden partir del mismo sistema para crear nuevos aplicativos.
Si tu marca tiene que llegar coherente a muchos equipos, canales y aplicativos, o ya estáis en ello y queréis intercambiar experiencias, escríbenos. Nos encantará hablar de todo esto con un café delante.