Enseñarle a un sistema de diseño a trabajar con IA

Contexto

Slingshot es la plataforma empresarial de gestión de trabajo de Infragistics, construida sobre un sistema de diseño grande, en un framework de UI propietario y en Figma.

Recién había empezado a trabajar cuando vi cuál era el workflow de mis compañeros: preguntarse cuál era la última versión de la pantalla de tareas, o del componente de People Picker. La respuesta era un link a un archivo de Figma de una feature.

Intenté acoplarme a los componentes de la librería y era un caos. La mitad de las cosas no estaban actualizadas, no funcionaban. Muchas habían sido traídas de Sketch a Figma directo, sin testing y sin review. Era un sistema que estaba básicamente muerto: se usaban los iconos y, máximo, seis a ocho componentes. No más que eso.

Puse un artboard sobre la mesa y vi que estaba todo desconectado. Que nada era un componente.

Y el equipo estaba empezando a escribir código con IA. Un sistema que una persona nueva no podía leer tampoco lo iba a poder leer una máquina.

Mi rol

Estuve a cargo de la preparación del sistema para IA de punta a punta — arquitectura de tokens, el mapeo diseño↔código, el vocabulario compartido y las reglas de qué puede y no puede hacer una IA. Esas reglas se volvieron el contrato con el que trabajaba el equipo de diseño todos los días, y el que tenía que cumplir cualquier cosa que construyera desde el sistema. Mi contraparte fue el product owner.

Investigación e insight

Observé dónde se rompían las cosas:

• Diseño y código se habían distanciado. Un botón, cientos de variantes en Figma, sin un mapa autoritativo hacia sus props de código — así que todos adivinaban.
• Los tokens existían; las reglas no. No había guía sobre qué nivel usar, así que se colaban valores crudos.
• El vocabulario se había desviado. Una misma idea, muchos nombres (“rest” vs. “default”).
• El contexto vivía en la cabeza de la gente — cada nuevo colaborador empezaba de cero.

El insight: una IA no es descuidada porque sea torpe, sino porque el sistema nunca le dijo la verdad. Dale el mismo contrato claro que le darías a un nuevo compañero de equipo, y se comporta como uno.

Qué hice

Lo primero que probé fue acoplarme a su workflow, pero no podía, era más fuerte que yo. Entonces, en paralelo, cada vez que estaba trabajando en una feature específica iba generando los componentes y iba en silencio actualizando el design system de a poco. Si tengo que usar un ítem de lista, voy, lo busco, lo traigo, veo qué problema tiene y lo arreglo. Entonces ya queda arreglado y lo empiezo a usar.

Funcionó para mí. Para mis compañeros no tanto. Por más que cada tanto les iba pasando las actualizaciones, ellos ya estaban aferrados a su workflow: copiar y pegar cosas desconectadas. Ir creciendo de a poco no les era rentable, porque tenían que cambiar partecitas y componentecitos. No había algo que fuera tipo una pasada y listo.

Estaba trabajando solo en el design system: creé un archivo de Figma nuevo de cero y ahí empecé a generar los componentes nuevos. Como era todo el tiempo work in progress, no era práctico que mis compañeros lo adquirieran en ese momento.

Cada vez que tenía que trabajar en una feature —una de la sección de tareas, por ejemplo— lo generaba todo con componentes del design system nuevo, y a medida que iba necesitando cosas las iba agregando. No solo componentes: también moléculas y templates.

Fue un under construction del design system. Lo usé solo yo, hasta que llegó un punto en que estaba lo suficientemente maduro para que mis compañeros lo empezaran a usar — y a usarlo también con herramientas de inteligencia artificial. En ese momento pasamos al 70%.

Dejé afuera los componentes a nivel de pantalla. Un componente a nivel de pantalla en Figma significa que todo es configurable desde el sidebar y que no se puede construir arriba — y todavía no existían los slots de Figma, lo cual era más limitante todavía. Lo que propuse fue usar un nivel menos de componentización: la navegación, la UI fija, el shell, la barra de título, el toolbar — toda una carcasa fija conectada a componentes — y después un sector de contenido vacío, para construir a partir de ahí.

Le di una columna vertebral a los tokens. ~800 tokens en una cadena de cuatro niveles, una regla por nivel, con claro/oscuro como un modo de la capa semántica — una respuesta correcta para cada valor.

Definí un solo vocabulario. Kebab-case, una sola escala de tamaños, un nombre por concepto en Figma y en código.

Dejé el contexto por escrito. Las reglas viven como documentación versionada que una herramienta carga de cero en cada sesión — cambiás una regla, el próximo build ya la sigue.

La IA propone, el diseñador aprueba

Hacer un sistema legible para una máquina obliga a decir exactamente qué decide y qué no:

• Planificar antes de construir — la herramienta propone un enfoque y la forma se aprueba antes de que exista una línea de código. Corregir un esquema es más barato que corregir un diff.
• Nunca inventar — si falta algo, se detiene y pregunta en vez de tapar el hueco con una suposición verosímil. Un sistema que adivina deja de ser fuente de verdad.
• Las decisiones estructurales son trabajo de diseño — componente nuevo vs. composición, qué patrón reemplaza a cuál, cómo se forman los niveles. Definen lo que hereda todo lo que viene después, y por eso quedan del lado del diseñador.

Resultado

El sistema se convirtió en algo desde lo que una IA podía construir y en lo que una persona podía confiar. Para el final, todos empezábamos una feature nueva con el 70% del trabajo que antes nos llevaba, ya hecho — on-token y on-brand, en vez del 25% de un archivo a medio cablear con todas las decisiones importantes por tomar. En la práctica eso convirtió levantar una pantalla nueva de cerca de una semana en uno o dos días. El tiempo del diseñador va al 30% final: el pulido que define si está bien de verdad.

La ganancia no fue solo velocidad. Escribir las reglas con la precisión suficiente para que las siga una máquina las dejó lo bastante precisas para que las siga gente nueva.

Ese es el modelo en el que creo: no una automatización que reemplaza al diseñador, sino un sistema lo bastante explícito como para que todo lo que construya desde él termine en el mismo lugar, y la atención del diseñador vaya donde el criterio realmente rinde.