Harness Design en la práctica: cómo destrabar la fila de pantallas cuando no hay designer para todas

Este artículo cuenta cómo aplicamos Harness Design a un problema muy práctico en Prolog, la empresa donde trabajo: hay muchas pantallas por hacer y pocos designers para hacerlas. Harness Design es la disciplina de darle a la IA el contexto, los criterios y las decisiones que el equipo de design ya tomó, para que produzca con dirección en lugar de improvisar. Aquí, eso se convirtió en una herramienta que genera prototipos de pantalla con apoyo de IA, siguiendo nuestras decisiones. Se llama design-draft.

Voy a explicar el contexto, el problema, lo que resolvimos y cómo funciona. Los números y el detalle técnico quedan en el Anexo, al final, para quien quiera profundizar. Un término que aparece bastante: Glorp es el design system de Prolog.

El problema: la fila de pantallas

Con IA, quienes programan se volvieron mucho más rápidos. Pero antes de programar alguien necesita entender el problema y diseñar la solución, y esa etapa, que llamo upstream, no acompañó. En el Artículo 2 escribí que la aceleración de la ingeniería creó un cuello de botella en el design. En Prolog la cuenta no cierra: hay más pantallas por hacer que designers para diseñarlas.

Cuando la fila no avanza, los desarrolladores diseñan la pantalla por su cuenta, con ayuda de la IA. Yo haría lo mismo en su lugar. El problema está en el resultado. Hice una prueba simple: pedí una lista con detalle, edición y eliminación sin dar ninguna regla, y en 13 decisiones la IA eligió algo distinto de lo que adopta el producto. Ella copia el código que encuentra, y el código de un producto antiguo mezcla aciertos y errores. Sin alguien que diga cuál es cuál, adivina. (El Anexo B explica esta prueba y la salvedad que merece.)

Hoy el repositorio de prototipos tiene 71, guardados por 14 personas, y solo una parte pequeña viene de designers. La demanda existe y no va a esperar.

Dos frentes, uno corto y otro largo

Yo ya trabajaba en una respuesta de largo plazo, que conté en los artículos anteriores: tokens y componentes preparados para que la IA los lea, con una herramienta de línea de comandos inspirada en Astryx, el design system que Meta abrió. Está bien encaminada y sigue avanzando, pero es pesada. En un producto legado, los componentes estaban dispersos en repositorios distintos, y el proyecto no se trabaja a tiempo completo. No entrega en el corto plazo.

Entonces abrí un segundo frente, para entregar algo útil ahora: skills para Claude Code. Una skill es un paquete de instrucciones que él sigue en una tarea específica. Los dos frentes usan Harness Design de maneras distintas. En el de los componentes, construyo de abajo hacia arriba: cada token y cada componente recibe documentación que dice cuándo usarlo y cuándo evitarlo. En el de las skills, voy de arriba hacia abajo: miré las pantallas que ya existen en el producto, separé lo que está bien de lo que está mal y lo convertí en reglas. Uno ayuda al otro, porque lo que decidimos en las skills vuelve al trabajo con los componentes.

La herramienta: prototipos de pantalla guiados por Harness Design

La primera skill es design-draft. Describes una pantalla o funcionalidad, en un texto o en una tarea, y recibes un prototipo clicable de mediana fidelidad: más detallado que un boceto, menos que la pantalla final. En las pruebas que cronometré, un flujo nuevo tardó de 12 a 27 minutos en quedar listo y revisado. Ese tiempo es de la IA, y no medí cuánto tardaría un designer con el mismo pedido.

Quien creó la primera versión fue Gustavo Navarro, nuestro gerente de ingeniería, con Kas, a principios de junio. Nació como un generador de bocetos en gris. Yo tomé la skill después y fui mejorándola, y Gabriel Tavares también contribuyó.

Para ser rápida, no usa los componentes reales de React y de Flutter. Le pedí a Claude que copiara los componentes necesarios a una versión ligera en HTML y CSS. En la práctica, es una segunda versión del design system, hecha para la skill. A ese conjunto de piezas lo llamamos kit. Esto tiene un costo que debo decir: la copia puede quedar distinta de lo que está en producción, y alguien tiene que mantener las dos al día.

El prototipo sale con varias pantallas conectadas entre sí, la barra lateral y la barra superior del producto, y las reglas de negocio y de interfaz escritas como comentarios sobre cada pantalla. La skill también dibuja las situaciones que suelen olvidarse: campo con error, lista vacía, falla al guardar, salida sin guardar y falta de permiso. Y usa más que el design system. Entran heurísticas de usabilidad, arquitectura de información, diseño de interacción y texto de interfaz, para acercarse a un designer que mira el conjunto.

Las imágenes siguientes son de una entrega real, el flujo de una pantalla para administrar los banners del login de un producto. Dentro de un canvas, el espacio donde aparece el prototipo, la IA coloca comentarios sobre cada pantalla. Cada comentario dice si vino de la IA o de una persona y en qué estado está: por revisar, respondido, aceptado o rechazado.

En la vista de tablero, el flujo completo aparece de una vez, con todas las pantallas lado a lado.

Y un botón llamado Componentes muestra, sobre cada parte de la pantalla, qué pieza de Glorp se usó. Cuando el kit no tenía la pieza, la marca avisa. Esto ayuda a ver dónde la pantalla se apoya en el design system y dónde no.

El flujo de revisión es simple. El desarrollador genera el prototipo, envía el artefacto a un designer, el designer comenta, y los comentarios vuelven al desarrollador a través del propio Claude Code. Esto agiliza la revisión para desarrolladores, designers, product managers y quien más esté en el proceso.

Lo que hace que la IA acierte: decisiones humanas antes que ella

design-draft no inventa criterio. Sigue tres curadurías hechas por personas, y aquí es donde el Harness Design ocurre de verdad.

La primera es la de los patrones de pantalla. Glauber Franco y yo levantamos cómo el producto resuelve cada tipo de pantalla y decidimos qué está bien. Salieron 19 reglas para la web y 15 para la aplicación. Por ejemplo, el detalle de un registro se abre en un panel que se desliza por el costado, y la eliminación no abre una ventana en medio de la pantalla. La segunda fue una prueba con una pantalla real, que levantó seis puntos en los que la regla no existía o se contradecía, y decidimos todos. La tercera fue revisar, uno por uno, los componentes copiados al kit: 124 fueron aprobados y 10 descartados.

La regla que considero más importante cabe en una frase: cuando la curaduría no cubre un caso, la IA no elige. Devuelve el caso como pregunta para una persona.

Después viene una especie de portero. El ensamblador es un pequeño código que forma parte de la propia herramienta. No usa IA ni es otra skill: solo sigue reglas escritas, siempre de la misma manera. Ensambla el prototipo y rechaza la pantalla cuando rompe una de esas reglas, por ejemplo un botón que no lleva a ningún lado, un componente dibujado a mano en lugar del que ya existe o un emoji donde debería haber un ícono de Glorp. Además, la pantalla web se abre en el navegador y se revisa.

Casi toda regla del portero nació de un error real. Un ejemplo: el submenú del producto, que se abre al pasar el mouse, desaparecía a mitad de camino porque el prototipo cargaba un ajuste heredado de una versión antigua. Hoy el menú pertenece al kit y ninguna pantalla lo toca, con una prueba solo para eso. La tabla completa de errores está en el Anexo D.

Dónde usamos la IA sola y dónde entra un designer

No toda pantalla merece la misma inversión de design, y aquí es donde decidimos dónde gastar el escaso tiempo de los designers. El criterio es el riesgo para la experiencia del cliente.

Donde el flujo es crítico para el producto y para quien lo usa, un designer trabaja de la manera más tradicional: descubrimiento, investigación, conversación con clientes y el método Double Diamond, que alterna entre abrir el problema y cerrar la solución. Donde el apetito de riesgo es mayor, lo que incluye funcionalidades y productos internos, asumimos el riesgo de no asignar ese trabajo. Ahí design-draft la usan personas que no son designers, principalmente desarrolladores, y el designer entra si lo considera necesario, como consultor que revisa lo que hizo otra persona o la IA.

Qué cambia para el designer

Este arreglo cambia el trabajo del designer hacia la curaduría. Pasa a ser la persona con conocimiento especialista para decir qué es un buen design y para convertir ese juicio en algo que la IA pueda seguir.

En la práctica, el designer actúa en dos capas al mismo tiempo. En una, construye el harness: las reglas, los criterios y las piezas aprobadas que hacen que la IA diseñe bien. En la otra, revisa el design que produjo otra persona o la IA, y cada revisión alimenta de vuelta el harness. Es un flujo continuo, en el que revisar mejora la base y la base mejora la siguiente pantalla.

El manifiesto de Harness Design pregunta quién responde por lo que se produjo. En este arreglo la respuesta tiene nombre: responde quien curó la regla y quien juzga la revisión. La IA genera y verifica, y la decisión sobre qué vale como estándar del producto sigue en manos de una persona.

El lugar donde esto va a vivir es GlorpLabs, la plataforma interna que estamos construyendo para hacer la curaduría y el mantenimiento del design system y del Harness Design. Las skills entregan ahora lo que GlorpLabs entregará después. Cuando esté más avanzado, la idea es que design-draft deje de ser necesaria, porque el conocimiento y el harness estarán todos ahí dentro.

Lo que este artículo no resuelve

Mejorar la operación de prototipado aumenta la probabilidad de que la pantalla salga mejor. Eso no garantiza que estemos construyendo lo correcto, ni que vaya a generar ingresos, ni que los clientes la quieran. Ese es un tema de descubrimiento de producto, que no es el tema aquí. En este artículo hablo de la parte operativa del design: cómo mejorar, agilizar y escalar la creación de pantallas y flujos. En otros artículos cuento cómo estamos escalando el descubrimiento y la investigación con usuarios.

La otra mitad de esta operación es medir si una pantalla está bien. Eso se convierte en un puntaje de 0 a 100, y es el tema del Artículo 12.

Lo que todavía no sé

No sé cuánto de lo que produce design-draft acepta el equipo. Cuando la respuesta de las personas vuelve al archivo, el rechazo es bajo (11 de 612 anotaciones decididas), pero solo volvió en 20 de los 65 prototipos guardados. Tampoco sé cuánto tardaría un designer con el mismo pedido, cuántas rondas de ajuste exige el promedio real, ni si la pantalla construida queda igual al prototipo. En el único caso revisado hasta ahora, el código siguió el contrato, el documento que dice qué componente usar en cada parte de la pantalla, en los 11 componentes y las 22 reglas. Y no sé si lo que las personas que no son designers le piden a la herramienta es lo que el producto necesita: ellas diseñan las cards (las tareas) que el producto ya priorizó, lo que no prueba que la solución sea la correcta. Las próximas semanas responderán parte de esto.

---

Anexo técnico

Esta parte es para quien quiere el detalle del detalle. No es necesaria para entender el artículo.

A. Quién está creando pantallas

En el repositorio donde se guardan los prototipos hay 71, guardados por 14 personas. Yo aparezco en 8. Las otras 13 personas no son designers, y juntas guardaron la gran mayoría de los prototipos. Casi todos nacieron de tareas reales registradas en Jira o ClickUp, las herramientas de gestión de tareas del equipo.

Dos salvedades sobre estos números. El repositorio registra el nombre de quien guardó el archivo, que casi siempre es quien ejecutó la herramienta, pero no necesariamente. Y no medí si esas pantallas fueron aprobadas, ni si llegaron a construirse.

B. Las tres curadurías en detalle

Patrones de pantalla (5 de octubre). Levantamos cómo el producto resuelve lista, detalle, formulario, eliminación, filtros e indicadores, y decidimos qué está bien. Salieron 19 reglas para la web y 15 para la aplicación. Algunos ejemplos:

• Los detalles de un registro se abren en un panel que se desliza por el costado de la pantalla.
• El botón de exportar queda en el pie de la tabla y no debe aparecer en el encabezado de la pantalla.
• Eliminar no abre una ventana en medio de la pantalla.
• En la aplicación, el botón de crear es una píldora azul, un botón alargado de esquinas redondeadas con texto. El botón redondo con signo + no se usa.

Lo que motivó esta curaduría fue una prueba hecha el mismo día. En un pedido común de lista con detalle, edición y eliminación, la IA decidió por su cuenta en 6 puntos en la web y 7 en la aplicación. Según nuestras reglas, se equivocó en los 13. Puso el botón de exportar en el encabezado de la pantalla, abrió la eliminación en una ventana en medio de la pantalla e inventó el ancho del panel lateral, entre otras cosas.

Hay un límite que debo decir sobre ese número. Quienes definimos qué es lo correcto fuimos Glauber y yo, después de mirar el código. Los 13 errores miden la desviación respecto de las reglas que nosotros mismos escribimos. Lo que la prueba muestra es que la IA, sin esas reglas, elige algo distinto de lo que el producto quiere. Elegía distinto porque copiaba lo que hace el código, y el código de un producto legado mezcla aciertos y errores. En el Artículo 4 escribí que Claude Code inventa cuando no encuentra. Aquí vi el caso complementario: cuando encuentra dos respuestas en el código, no tiene cómo saber cuál es la decisión del producto.

Preguntas de la primera prueba (6 de octubre). Una prueba con una pantalla del módulo de telemetría del producto levantó 6 puntos en los que la regla no existía o se contradecía. Para mostrar que una pantalla está cargando, la skill usa la animación de neumático girando que Glorp ya tiene, y no un esqueleto, el dibujo gris con la forma de la pantalla. Elegimos así porque 71 de 99 pantallas con tabla ya lo hacían de esa manera. Cuando una lista no tiene acción de crear, queda sin botón de crear, en lugar de recibir uno inventado.

Piezas (15 al 19 de octubre). Revisé cada componente copiado de React y de Flutter a la versión HTML y CSS y lo marqué como aprobado, descartado o aprobado con ajuste. Fueron 124 liberados y 10 descartados, entre ellos el breadcrumb (la ruta de navegación en la parte superior de la pantalla), la línea de tiempo y el botón dividido. Las observaciones se convirtieron en regla: una pieza que no está en la lista no se usa. Esa lista aprobada es el kit de piezas de la skill. La curaduría también alimenta el otro frente: lo que quedó decidido aquí vuelve al trabajo con la CLI, la herramienta que entrega la documentación de los componentes a la IA, y con el harness de los componentes.

C. Cuestionario, ensamblador y pruebas

Antes de diseñar, la skill responde un cuestionario de 17 preguntas sobre la pantalla, como dónde queda la acción principal, dónde se abre la edición y cómo se confirma una eliminación. Cada respuesta cita la regla de la curaduría que la respalda. Después ensambla la pantalla a partir de una plantilla lista, ya con las piezas del kit, cambiando solo texto y datos.

El ensamblador rechaza la pantalla en más de 20 situaciones, divididas en cuatro grupos:

• flujo roto: un botón que lleva a una pantalla que no existe, una pantalla del mapa sin archivo o un comentario que apunta a una pantalla inexistente;
• patrón de pantalla de la curaduría: el botón "Exportar" o el conteo de registros en el encabezado de la pantalla, o un componente antiguo que imita el cajón lateral o el asistente por pasos, en lugar del componente del kit;
• barra y menú del producto: la pantalla que dibuja su propia barra lateral o su barra superior, en lugar de usar la barra del producto que el kit encaja, o la pantalla cuyo estilo toca el menú del kit (en el submenú, en el área por donde pasa el mouse o en el desplazamiento de la barra);
• marca: cualquier emoji en la interfaz, porque la marca de Prolog lo prohíbe. La verificación detecta los emojis de imagen, como caras, objetos y símbolos de colores. Los símbolos simples, como ✓ o ⚠, pasan.

El ensamblador también verifica que el propio kit esté completo, por ejemplo si existe el archivo de la barra del producto.

Cada pantalla web debe abrirse en el navegador a 1366 por 700 píxeles, el tamaño de una pantalla de laptop común, y revisarse antes de ir a aprobación. Cuando la sesión no tiene navegador disponible, la skill no puede revisar y está obligada a declarar "no revisado visualmente", con el motivo.

Cuando el prototipo crea un módulo nuevo en el menú lateral, una prueba automática mueve el mouse en diagonal hasta el submenú, para garantizar que no se cierra en el camino. La prueba tarda cerca de un minuto. Sin el navegador automático, se omite, y la regla indica a la persona que pase el mouse hasta el submenú a mano antes de la aprobación. El kit tiene 16 archivos de prueba, y la prueba estándar ejecuta 13 de ellos a la vez. La prueba del submenú queda fuera y se ejecuta aparte.

En las pantallas nuevas, la skill todavía hace tres revisiones antes de pedir aprobación, de design, de texto y de accesibilidad, y corrige lo que es barato.

D. Errores de uso que se convirtieron en regla

| Qué salió mal | Qué cambió | | --- | --- | | Un agente dijo que una pantalla del producto no existía, y existía (23 de septiembre) | Cuando la búsqueda dice "no encontré", la skill busca de nuevo antes de creerlo | | Un prototipo fue reprobado porque la skill usó una copia desactualizada del código del producto, 1.136 cambios por detrás de la versión en uso (5 de octubre) | Antes de diseñar, la skill verifica que la copia esté al día | | Un prototipo de 30 pantallas dibujó a mano filtros, paneles y gráficos que ya existían como componente (6 de octubre) | Usar la pieza del kit pasó a ser obligatorio, y lo que se dibuja a mano para imitar un componente se rechaza | | La lista ya se abría con filas seleccionadas, y botones de prueba, como "simular error", aparecían en las pantallas | La lista se abre sin selección, y la selección tuvo su propia pantalla. Solo aparecen botones que el producto tendrá | | El submenú se cerraba a mitad del camino del mouse por un ajuste heredado de un prototipo antiguo (8 de octubre) | El comportamiento del menú pasó a ser del kit, nunca de la pantalla, con una prueba propia |

Cada error se convierte en una regla escrita, y cada regla queda trabada por una prueba automática para que el error no vuelva.

E. Qué mostraron las pruebas comparativas

23 de septiembre: boceto contra prototipo. Hice el mismo pedido de las dos maneras, boceto en gris y prototipo clicable. El prototipo tardó 4 minutos más (13 contra 9) y entregó 9 pantallas en lugar de 4 y 73 reglas anotadas en lugar de 26. Tres de las pantallas adicionales nadie las había pedido: campo con error, descartar cambios y falla al guardar. Eso decidió el cambio al prototipo.

6 de octubre: tres versiones de la skill. Comparé tres versiones, cada una hecha por un agente nuevo que no veía las anteriores, con el conteo hecho por un programa. Repetí la medición después y el resultado salió igual. El programa cuenta una pantalla como "hecha con piezas del kit" cuando carga el estilo de esas piezas. Fueron 0 de 30 pantallas en la primera versión, 28 de 29 en la segunda y 32 de 32 en la actual. Elementos dibujados a mano para imitar un componente: 393, 0 y 0. Avisos del ensamblador: 8, 8 y 0.

Ese número necesita contexto. El ensamblador rechaza la imitación, así que el 32 de 32 está garantizado por la regla. Muestra que la regla funciona. Si la pantalla quedó bien para quien la usa, ese número no lo dice. Y cargar el estilo de las piezas no quiere decir que todo componente de la pantalla sea una pieza real: en la versión actual, 68 de las 358 áreas marcadas quedaron como "sin pieza capturada", y la pantalla lo dice.

13 y 14 de octubre: unificación de dos herramientas. Unificamos dos herramientas parecidas y cronometramos 24 rondas antes y después. La versión nueva generó más pantallas (de 8 a 13) y 8 veces más hallazgos de revisión, con 40% más de tiempo hasta la aprobación. Esto viene de un único pedido y no debe leerse como regla general.

Tiempos. Un flujo nuevo a partir de una tarea tardó de 12 a 27 minutos entre el pedido y el prototipo revisado. Un ajuste en una pantalla existente tardó de 6 a 21 minutos. Todos estos tiempos son de la IA.

F. Cuánto de lo que produce la skill acepta el equipo

De los 65 prototipos con anotaciones guardados en el repositorio, que suman 3.063 anotaciones, 2.435 (79%) siguen marcadas como "por revisar", 601 (20%) fueron aceptadas, 16 respondidas y 11 rechazadas. Esto ocurre porque las respuestas de las personas solo volvieron a los archivos guardados en 20 de los 65 prototipos. Entre las anotaciones decididas (aceptadas y rechazadas, 612 en total), el rechazo es bajo: 11. Aun así, el número no dice cuánto se aceptó de verdad en los otros 45 prototipos.