Iterando el prototipo en vivo mientras los usuarios lo prueban

Siempre que diseñamos una interfaz que no es obvia, pido a mi equipo que la probemos con usuarios reales. Siempre obtenemos aprendizajes que nos hacen diseñar un mejor producto y no tener que volver a esa funcionalidad en siguientes semanas. Lo que no había vivido hasta ahora era poder implementar ese feedback en la propia sesión de pruebas y, al final, mostrar el prototipo ya iterado para validar la solución. Lo que antes tardaba varios días —o incluso una o dos semanas— ahora lo sacamos en el día.

En Punto, parte de lo que hacemos, es automatizar trámites administrativos —matriculaciones, transferencias e informes de vehículos— para grupos de concesionarios y compraventas. Aparte de pagar impuestos y hacer la comunicación a la DGT, terminamos el trámite enviando los permisos de circulación y fichas técnicas al nuevo titular. Con el volumen que ya estamos gestionando, hacer esto a mano empezaba a doler, así que montamos una herramienta interna para el equipo de operaciones. Os comparto el flujo que seguimos para construirla, porque para nosotros ha marcado un antes y un después en cómo vamos a hacer producto.

Del papel al prototipo en código

Empecé con bocetos en papel para pensar la arquitectura de pantallas. Luego pasé a Figma —usando nuestro sistema de diseño— para ver si encajaba. Y de ahí, directo a Claude Code.

Le pasé el enlace de Figma, le pedí que implementara un prototipo funcional en un único fichero HTML fuera del repositorio y le describí las interacciones clave. Lo fui puliendo con vibe-coding hasta que estuvo listo para ponerlo delante de un usuario real.

Las pruebas de usuario

El primer día nos dimos cuenta de algo que no habíamos previsto: como el equipo mueve papeles físicos, era mucho más eficiente hacer ciertos checks en papel impreso que en pantalla. Iteré el prototipo para reducir las acciones digitales e implementé una funcionalidad de imprimir una lista de comprobación.

El segundo día me bajé datos reales de producción, se los metí al prototipo y se lo puse delante a la persona que iba a gestionar los envíos ese día. Según salían casos nicho o cosas que no habíamos previsto, le pedía un par de minutos, iteraba con Claude allí mismo y validábamos al momento si esa era la solución correcta. En una hora cubrimos todos los casos posibles.

Por qué diseñar en código tiene sentido

Diseñar en código, una vez tienes clara la arquitectura en Figma, tiene ventajas concretas:

Te fuerza a diseñar todos los casos e interacciones, no solo el happy path. En Figma es muy fácil ignorar los estados vacíos, los errores o los casos raros. En código, aparecen solos, porque la vida real es más complicada que una pantalla de Figma.

Puedes meter datos de producción en el prototipo. Hay una diferencia enorme entre ver la herramienta con datos de ejemplo y verla con tus propios datos reales.

Cualquier persona puede probarlo y dar feedback sin hacer un ejercicio de imaginación. Con pantallas estáticas, hay que imaginarse cómo encajarán las interacciones. Esa abstracción no es una habilidad común. Un prototipo en HTML lo entiende todo el mundo.

Del prototipo al código de producción

Rubén, el Product Engineer que desarrolló la funcionalidad, partió del prototipo en HTML que ya funcionaba. No tuvo que interpretar nada; cogió los aprendizajes de ese prototipo y le pidió a Claude Code que lo implementara en el código real de nuestra plataforma, siguiendo las fases que habíamos definido y nuestras buenas prácticas. No fue un copia y pega —para tranquilidad de los ingenieros que me leéis.

Además, el prototipo le sirvió para hacer pruebas de integración con nuestro proveedor de mensajería y para proponerme cambios de diseño de forma rápida. Cuando lo teníamos claro, lo implementó en producción.

Qué conclusiónes nos hemos llevado

No nos importa la calidad del código del prototipo. Es una herramienta para diseñar y aprender. Ese prototipo lo tiramos. Por tanto, cualquiera puede prototipar. Diseñadores, ingenieros e incluso perfiles de negocio pueden hacer vibe-coding sobre un HTML sin necesidad de tocar el repositorio de producción para representar ideas. La barrera técnica para prototipar, e importante este detalle, ya no existe.

El tiempo no es una excusa. Me acuerdo de las horas que perdíamos antes en Figma intentando simular interacciones. Ahora es tan rápido que no prototipar y validar con usuarios es, simplemente, dejadez. Si estás diseñando producto hoy y no haces tests de usuario, empieza ya. Hace nueve años en Ontruck compartimos un buen listado de consejos para empezar que sigue vigente.

Al tocar el software tú mismo, ves las casuísticas de verdad en vez de solo imaginartelo. Eso solo te lo da el código y datos reales.