Diseñar para humanos y agentes · LAB

Todo el mundo habla de IA en diseño. Pocos enseñan lo que pasa de verdad cuando la usas en serio, en un producto que hay que mantener durante meses. En el Runroom LAB de noviembre, Agostina Lotierzo, AI Design System Designer en Manychat, y Thành Đỗ Long, iOS Developer en el mismo equipo, compartieron esa historia desde los dos lados de la mesa: diseño e ingeniería.

Empezaron con una advertencia que vale para todo lo que sigue: lo que cuentan es su experiencia de hoy. "Esto no está escrito en piedra. Todo evoluciona y cambia de una semana a otra", avisó Agostina. Y propusieron tres ideas para llevarse a casa: cómo trabajan juntos diseño e ingeniería, por qué no mataron Figma y cómo construir un design system que los agentes puedan leer.

El punto de partida: un design system con dos tipos de usuarios

Agostina ha colaborado en cinco design systems. Este es el primero que lleva a tiempo completo y el primero con un público nuevo: "Es la primera vez que los usuarios no son solo personas, también son máquinas".

Antes de la IA, el proceso era el de siempre. Ella preparaba la especificación, la pasaba al equipo de desarrollo y cada reunión semanal traía sorpresas. El ejemplo que pusieron es elocuente: la propuesta de colores semánticos para mobile se abrió a revisión el 28 de enero y en marzo seguía en discusión. Más de cinco semanas para cerrar una decisión que pasaba por diseño, ingeniería, producto y marca.

Este año llegaron dos cambios a la vez. Por un lado, la oportunidad de crear un design system desde cero, mucho más cercano a la marca de Manychat. Por otro, la ola AI-native: la compañía pidió a todos los equipos dejar las formas de trabajar anteriores y adoptar herramientas como Claude o Codex.

Lo que se rompió: el "slop" y la IA sin criterio

El primer aprendizaje llegó rápido. Si el design system tiene que servir a un agente, el agente necesita entender lo que se está creando. Y ahí aparece un problema de fondo, en palabras de Thành: "La IA no tiene gusto". Está entrenada con una cantidad enorme de información y tiende a lo que gusta a la mayoría. Para que el resultado tenga criterio humano, la voz y el tono tienen que estar escritos en el propio repositorio.

En el lado de diseño, la IA parecía la gran liberación. Agostina, que hasta entonces corregía la interfaz a base de capturas de pantalla, abrió su cuenta de GitHub, aprendió a clonar el repositorio y empezó a abrir pull requests con ayuda de Claude. Hoy suma más de 300 contribuciones. "Daba miedo, creedme", reconoció.

El problema vino cuando dejó demasiadas decisiones en manos de la IA. Contó una conversación tipo: pide un botón destructivo rojo, luego más claro, luego gris por accesibilidad. A todo la IA responde "tienes toda la razón". Y el resultado seguía siendo incorrecto. Así llegaron las slop grenades: cambios generados por IA, sin documentar y sin revisar, que acaban contradiciendo reglas del sistema. En su caso, un color reservado para bordes acabó usado en superficies.

Thành lo resumió con la diferencia entre vibe coding y programación agéntica. El vibe coding sirve para un proyecto personal. En algo que hay que escalar, "la primera vez puede parecer que está bien", hasta que miras el modo oscuro, el texto ampliado o el contraste. La programación agéntica usa la IA para acelerar el trabajo manteniendo tu propia voz.

Cómo construir un design system que los agentes puedan leer

La idea central de la parte técnica: la documentación antes era para desarrolladores y ahora también la tienen que leer las máquinas. Thành compartió los aprendizajes que les han funcionado:

• Cuando el agente se equivoca, busca la causa antes de corregir la salida. En su caso, la documentación mencionaba un componente que aún no existía y el agente improvisó un apaño. Si solo arreglas el resultado, la próxima vez volverá a fallar. Pregúntale por qué lo ha hecho así y corrige el origen.
• Dale contexto a cada token. "Blue 300" no le dice nada a un agente. Un token semántico como color.background.warning ya indica su uso. Y se puede ir más allá con intents: para qué sirve (banners, alertas en línea), para qué no (errores) y con qué se combina.
• Automatiza lo repetitivo. Cuando diseño cambia un token de base en Figma, un agente detecta el cambio y abre una primera pull request. Si Thành la aprueba, otro proceso genera automáticamente las de iOS, Android y web. Un trabajo que antes le llevaba días.
• Una sola fuente de verdad. Un fichero de registro en el repositorio recoge el estado de cada componente. Al cambiarlo se actualizan solos la documentación, la app que muestra los componentes y el manifiesto que el agente consulta primero. Si algo deja de cuadrar, el sistema avisa.
• Pon barreras antes de la revisión humana. Las PR generadas por IA son largas y nadie puede leerlo todo. Por eso pasan antes por varios filtros: las decisiones documentadas por diseño, el compilador y el linter. Así la persona puede centrarse en lo importante: si eso es lo que se quiere o no.

En la sesión de preguntas añadieron un matiz sobre la documentación: los ficheros para agentes son estructurados (JSON o YAML) y se mantienen sincronizados con la documentación para personas y con los procesos de integración continua. Para diseño, la fuente de verdad sigue siendo Figma. Para los agentes y para ingeniería, el repositorio.

Por qué volvieron a Figma

La charla arrancó con una frase de un compañero de diseño de Manychat de hace unos meses: preferiría morir antes que volver a Figma. Hoy ha cambiado de opinión. Agostina explicó por qué volvieron, en cuatro motivos:

1. Reinventar la rueda. Convencidos de que Figma estaba muerto, crearon su propio espacio para el handoff. Era visualmente impecable. A los desarrolladores no les gustaba y recoger feedback de un prototipo completo, pantalla a pantalla, se volvió muy complicado.
2. El gasto en tokens. "Nadie lo dice en esos posts de LinkedIn y de Twitter" de apps creadas en dos horas: hacerlo así es muy caro si no sabes escribir prompts eficientes.
3. La lentitud en el detalle. Pedir por texto dos o cuatro píxeles más de padding tardaba minutos y seguía saliendo mal. En Figma son dos segundos.
4. La falta de gusto. Lo que generaba la IA no les convencía visualmente. Un día pararon, abrieron un archivo de Figma y trabajaron una semana codo con codo. El rediseño resultante entusiasmó a los stakeholders.

Hoy el flujo combina lo mejor de cada lado. Agostina arranca en Claude, conectado a Linear, Drive, Slack, Notion y sus fuentes de investigación, para preparar el brief, enmarcar el problema y explorar con prototipos. Cuando la dirección está clara, pasa a Figma para las pantallas finales, los casos límite y el ajuste fino a mano, con un plugin que conecta Claude y Figma. Ese plugin, según contó, redujo su gasto de tokens en torno a un 80%. Al terminar, publica la librería y abre ella misma la pull request para que ingeniería revise. La documentación de un componente, que antes le llevaba dos semanas, ahora le lleva minutos.

La demo: un agente que conoce las reglas

En la demo, grabada a propósito "porque cada vez que alguien hace una demo en directo con IA, algo se rompe", Agostina creó un componente botón en un archivo nuevo de Figma. El agente usó las variables semánticas del design system y respetó la nomenclatura documentada. "Cada decisión tiene un documento detrás."

Después intentó saltarse las reglas: pidió un botón primario rosa. El agente le avisó de que contradecía las decisiones del sistema y no cumplía accesibilidad. Lo sabe gracias a los ADR (Architecture Decision Records), documentos que explican el porqué de cada decisión. Son lo que permite a la IA responder a quien llegue después preguntando por qué algo es como es.

Aprendizajes y conclusiones

Cerraron con cuatro ideas, que empezaron siendo tres:

• Acércate al código. Si eres diseñador o diseñadora, hoy entrar en el código está a tu alcance, quieras o no. Te ayuda a diseñar con más cuidado, porque todo lo que entregas tiene un coste para quien lo recibe.
• No dejes que la IA conduzca. "Imagina que la IA es una persona superlista y al mismo tiempo un niño de seis años al que tienes que explicar lo que esperas." Tú decides cómo se ve y a qué sabe. La IA acelera.
• Escribe documentación que la IA pueda leer. Es la condición para que el agente trabaje como esperas.
• Dale otra oportunidad a las herramientas que dan control al diseño. Agostina confesó que al principio temía que la IA le quitara el trabajo. Las slop grenades le demostraron lo contrario.

El resultado, en cifras: crear un design system antes les llevaba entre seis meses y un año. Esta vez, en diez días toda la compañía tenía fundamentos, componentes y moléculas para empezar a construir producto. Y los product managers pueden validar ideas con esos componentes sin esperar a diseño, con la decisión final todavía en manos del equipo de diseño.

El mensaje de fondo fue de humildad. "Lo que hemos contado puede quedar desfasado en un par de semanas", insistió Thành. Su consejo: encuentra tu propio camino, usa la IA para potenciar lo que ya haces y desconfía de quien promete un design system en un día. Su próximo reto ya lo anunciaron: migrar el design system anterior al nuevo, porque trabajar sobre un producto existente es más difícil que empezar de cero.