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 Figma. A medida que el equipo adoptaba herramientas de IA para codificar, apareció un vacío: el sistema que debía mantener todo consistente no podía leerse de forma confiable — ni por la IA, ni por gente nueva. Lideré el trabajo para resolver eso: hacerlo legible para las máquinas, manteniendo el criterio en manos de las personas.

The design system's component gallery — buttons, inputs, cards, and charts shown across their states on one token-driven foundation. — El sistema de diseño de Slingshot — 180+ componentes sobre una única fuente de verdad basada en tokens. El punto de partida para hacerlo legible para una IA.

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 — trabajando junto a un product owner, para los demás diseñadores que usaban el sistema a diario.

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

A single color token climbing the tiers — primitive #6988FF to semantic accent/primary to component button/primary/surface — rendering the Task button. — Un valor subiendo la cadena — un color crudo trazado primitivo → semántico → componente, directo al botón que una IA termina construyendo.

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.

Before and after of the token naming — scattered names like rest, normal, and base collapsing into single canonical tokens: default, md, disabled. — Una misma idea, antes repartida en muchos nombres — asentada en un solo vocabulario entre Figma y 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.

Qué se mantuvo humano

El objetivo no era dejar que la IA construyera el sistema. Era mantener el criterio humano al mando:

Planificar antes de construir — la IA propone; yo apruebo o rechazo antes de escribir una línea.
Nunca inventar — si falta algo, se detiene y pregunta en vez de simularlo.
Las decisiones reales siguieron siendo nuestras — componente nuevo vs. composición, qué patrón reemplaza a cuál, cómo se forman los niveles.

Resultado

El sistema se convirtió en algo con lo que una IA podía construir y una persona podía confiar — los agentes ahora producen código on-token y on-brand, así que los diseñadores dirigen el trabajo en vez de corregirlo. Y como cada cambio igual pasa por una instancia de aprobación humana, la velocidad subió sin ceder el control.

Ese es el modelo en el que creo: no una automatización que reemplaza al diseñador, sino una estructura que le permite moverse más rápido mientras sigue siendo dueño de cada decisión.