Cómo estamos haciendo que el Harness Design suceda de verdad

Escribí sobre Harness Design como concepto. Sobre lo que creo que va a redefinir el papel del designer de producto. Sobre poner la IA en el centro de la producción y rediseñar todo alrededor de eso.

Pero un concepto sin ejecución es solo texto bonito.

Este artículo trata de lo que viene después: la obra, las decisiones difíciles, los días que no salieron como se planeó. Todavía estamos en medio de eso. Y es exactamente por eso que vale la pena contarlo ahora.

El problema se volvió urgente con la IA

El uso de IA aceleró el desarrollo de software de una manera que ya no se puede ignorar. Pero esa ganancia de velocidad en ingeniería creó un cuello de botella nuevo: el diseño. El equipo de ingeniería avanza rápido, y el diseño tiene que acompañarlo.

La pregunta que surgió para nosotros fue cómo prototipar interfaces más rápido, con calidad suficiente, sin aumentar el equipo. Y cómo tener squads sin designers asignados produciendo interfaces con consistencia.

Ya teníamos personas usando IA para crear interfaces consumiendo el Design System que estaba en el código. Pero no era suficiente. Muchos errores, mucho retrabajo, velocidad todavía lejos de lo que los desarrolladores lograban. Quedó claro que necesitábamos evolucionar el Design System para poner la IA en el centro, con los designers construyendo, manteniendo, alimentando y revisando lo que sale de esa cadena.

¿Hacerlo internamente, comprarlo hecho o tercerizarlo?

Antes que nada, necesitábamos decidir el camino.

Tercerizar se descartó rápido. Costo alto, el conocimiento quedaría fuera del equipo, y además sobrecargaría a alguien para seguir de cerca el trabajo externo.

Comprar un Design System ya hecho tampoco resolvía. Ya teníamos muchos componentes. Adoptar una biblioteca externa significaría ajustar todo lo que ya existía y aun así lidiar con lo que ella no cubriera.

Quedó hacerlo internamente. Y lo que lo hizo viable fue el apoyo del CTO desde el inicio. Él vio el retorno: un Design System optimizado genera velocidad de prototipado, y velocidad significa producir más con menor costo. Esa alineación rara vez ocurre. En muchas empresas, evolucionar el Design System es siempre secundario, siempre despriorizado, siempre difícil de defender. Que el liderazgo viera el valor fue lo que desbloqueó todo.

La estructura del proyecto

Organicé el trabajo en seis hitos: diagnóstico, base técnica con tokens, gobernanza, dos ciclos de construcción de componentes por prioridad y, por último, calidad y adopción.

Lo que importa no es el detalle de cada fase. Es lo que pasó cuando intentamos ejecutar.

El diagnóstico: cuando tres días se volvieron cinco

Para el proyecto contaría con un Product Designer, un Developer Flutter y un Developer React. Pequeño, pero necesario. No se puede hacer un diagnóstico real de Design System sin quienes conocen el código de cada stack en detalle.

El plan era de tres días. En el segundo día ya estaba claro que había mucho más trabajo del esperado. Lo estiramos a cinco.

Esto parece un detalle pequeño. No lo es.

Ese segundo día, yo podría haber ignorado la señal y mantenido el plazo original. Habría entregado un diagnóstico incompleto, tomado decisiones sobre premisas equivocadas y el problema que intentábamos resolver se habría repetido más adelante. La tentación de cumplir el cronograma es real, especialmente cuando se le reporta a liderazgos que aprobaron el proyecto con una estimación.

Mantuve alineaciones diarias con mi liderazgo directo durante todo ese período y creé un grupo en el chat interno con los liderazgos de producto e ingeniería siguiendo el avance. El cuarto día presenté a qué habíamos llegado: los resultados del análisis, las propuestas de cómo seguir y los riesgos de cada camino. No llegué con una respuesta lista. Llegué con el mapa para decidir juntos.

Esa reunión ocurrió con el gerente de producto presente, y no fue por casualidad. El Design System es responsabilidad del diseño, pero necesita el impulso de los demás liderazgos. Cuando hablamos de evolucionar un DS, hablamos de impacto en el roadmap, en la asignación, en las entregas. Sin esa alineación, el proyecto no sale del papel. O sale y muere a mitad de camino.

La decisión fue reservar dos semanas de dedicación exclusiva con el PD y los desarrolladores para atacar los hitos siguientes.

Para el inventario en sí, creé una planilla para cada stack, con el PD y los devs llenando cada uno su lado, y centralicé todo en Notion. Elegí Notion porque el MCP de Claude trabaja bien con él, lo que facilitó vincular y crear las tablas. La priorización fue por frecuencia de uso.

La IA ayudó bastante en el levantamiento del código. En Figma fue más difícil y laborioso. Intentamos usar el MCP de Figma para automatizar el análisis. No funcionó. Terminó siendo trabajo manual.

Tokens y el experimento con IA

Con el inventario en mano, empezamos la base técnica: colores, tipografía, espaciado, sombras, breakpoints. Los tokens son la fuente de verdad que alimenta Figma, React y Flutter al mismo tiempo. Sin ellos, cualquier componente que crees vive aislado.

Glauber Franco y yo pasamos una semana con foco casi total en esto. Repasé los conceptos de Atomic Design de Brad Frost y usé como base los videos del canal TD Sunshine sobre variables en Figma. Probamos los tokens directamente en componentes reales y en pantallas existentes del producto. Esa prueba práctica hace una gran diferencia frente a trabajar solo en lo abstracto.

El próximo paso es el experimento con LLM-readiness. La referencia que más influyó en nuestro enfoque fue un artículo de Kartva llamado "Your Next Design System User Is an AI Agent", que describe cómo hacer que un DS sea consultable por agentes de IA. La idea central es que cada componente necesita explicarse a sí mismo: cuándo usarlo, cuándo no usarlo, qué props existen, ejemplos de código. Sin eso, herramientas como Claude Code inventan variaciones que no existen, y el retrabajo vuelve por la ventana.

El plan es empezar con pocos componentes, probar con Claude Code y aprender antes de escalar. Todavía no sabemos qué vamos a encontrar, y por eso no tiene sentido avanzar a muchos componentes antes de entender qué funciona.

Lo que este proceso está enseñando

Un Design System no es un proyecto de diseño. Es un proyecto de producto, y necesita al equipo de ingeniería desde el inicio. Sin el Developer Flutter y el Developer React en el diagnóstico, el inventario habría sido superficial y las decisiones siguientes, equivocadas.

El diagnóstico antes de crear es innegociable. La tentación de salir a construir de inmediato es grande. Pero crear sin inventario es garantizar que el problema actual se repita con componentes nuevos encima.

La alineación del liderazgo no es protocolo. Es lo que mantiene vivo el proyecto. La comunicación constante con todos los liderazgos a lo largo del camino fue lo que aseguró la prioridad cuando el cronograma tuvo que cambiar.

Y la IA todavía no lo resuelve todo. Acelera partes, falla en otras, y por ahora necesita mucho contexto estructurado para funcionar bien. El MCP de Figma no entregó lo que esperábamos. El trabajo manual volvió. Es parte del proceso.

Hacer que el Harness Design suceda no es glamoroso. Es un diagnóstico que se estira, una reunión de alineación con el liderazgo, una planilla llenada a mano, un experimento que no funciona. Eso es lo que estamos construyendo, y este artículo es parte del registro de cómo estamos aprendiendo a hacerlo de verdad.

Anexos