Prototipar en código con IA: por qué ya no diseñamos solo en Figma

Respuesta corta: un prototipo en código es una aplicación que funciona en el navegador, con interacciones, estados y datos, en lugar de pantallas estáticas enlazadas. Con la IA, construirlo ya cuesta casi lo mismo que un prototipo en Figma, y tiene tres ventajas claras: los usuarios lo prueban como un producto real, las decisiones se toman sobre algo que funciona y el equipo de desarrollo recibe una referencia que no hay que interpretar. Figma sigue siendo útil para explorar y para el design system; el prototipo final, para nosotros, va en código.

Durante años el flujo del diseño de producto fue el mismo: wireframes, pantallas en Figma, prototipo enlazando pantallas y handoff con especificaciones. Funcionaba, pero tenía un problema de fondo: lo que se probaba y se aprobaba no era el producto, sino una simulación. En Pleya Studio hemos cambiado ese flujo. En el rediseño de Mainder entregamos un prototipo navegable en código con las 24 pantallas rediseñadas y los 8 módulos nuevos, y el cliente puede probarlo él mismo.

Prototipo en Figma frente a prototipo en código

Por qué ahora: lo que ha cambiado con la IA

Hasta hace poco, un prototipo en código exigía un desarrollador front-end durante semanas, así que solo tenía sentido en proyectos grandes. Con los asistentes de programación con IA, un diseñador de producto con conocimientos técnicos puede construir pantallas funcionales en horas, partiendo del design system y con datos de ejemplo realistas. La IA no decide el diseño, pero elimina gran parte del trabajo mecánico de convertirlo en código.

Eso cambia la economía del proceso: probar una idea en código ya no es caro, así que podemos probar más y antes.

Cómo lo hacemos, paso a paso

1. Auditoría y flujos

Como siempre: entender el producto actual, a los usuarios y las tareas. La IA no acelera esta parte, y tampoco debería.

2. Design system primero

Antes de cualquier pantalla definimos tokens (color, tipografía, espaciado) y componentes base. En código, esto se traduce en una librería de componentes que todas las pantallas reutilizan, lo que garantiza coherencia. Más en design system para startups.

3. Pantallas en código con IA

Construimos cada pantalla con los componentes del sistema, usando IA para acelerar la escritura del código y generar datos de ejemplo verosímiles: candidatos, posiciones, conversaciones o métricas. Figma se sigue usando para explorar alternativas visuales rápidas cuando hace falta.

4. Sesiones en vivo

Revisamos el prototipo con el equipo del cliente en directo, y muchos cambios se hacen durante la propia sesión. Decidir sobre algo que funciona evita semanas de rondas de comentarios.

5. Pruebas con usuarios

Los usuarios prueban el prototipo como un producto: buscan, filtran, abren fichas, escriben mensajes. Los problemas que aparecen son los reales, no los de navegar por una simulación.

6. Handoff

Desarrollo recibe el prototipo, el código de los componentes, la documentación de estados y comportamiento y un plan de implantación por fases.

El caso Mainder

Mainder es una plataforma SaaS de reclutamiento con IA. El encargo era rediseñar el producto entero y añadir módulos nuevos sin parar el desarrollo. El resultado:

• 24 pantallas rediseñadas y 8 módulos nuevos.
• Un design system propio adaptado a la marca.
• Un prototipo navegable en código, listo para que su equipo lo construya.

Algunas pantallas, como el proceso de selección o la ficha de candidato, dependen tanto de la interacción (mover candidatos de fase, abrir un panel lateral, revisar uno tras otro) que en un prototipo estático habría sido imposible validarlas bien.

Cuándo compensa prototipar en código

Compensa especialmente cuando:

• El producto tiene mucha interacción: tablas, filtros, arrastrar, paneles, formularios largos.
• El producto usa IA: un prototipo estático siempre enseña la respuesta perfecta, y uno en código enseña la real. Lo contamos en cómo diseñar productos con IA.
• Hay que convencer a muchas personas: inversores, clientes piloto, equipo de ventas.
• El equipo de desarrollo es pequeño y agradece una referencia funcional.

Puede no compensar cuando:

• Se trata de exploración visual temprana, donde Figma es más rápido para probar diez direcciones.
• El proyecto es una web de marketing, que se construye directamente en Framer o Webflow, ya de por sí "en código".
• No hay nadie en el equipo con criterio técnico para mantener el prototipo ordenado.

¿El prototipo se convierte en el producto?

A veces, en parte. Los componentes del design system en código suelen reutilizarse directamente. Las pantallas, depende de la arquitectura del producto del cliente: en productos nuevos o MVPs, el prototipo puede ser la base del front-end; en productos maduros con su propia arquitectura, sirve como referencia funcional que el equipo implementa a su manera. Lo importante es que no haya que adivinar cómo debe comportarse cada cosa.

Qué no cambia con la IA

• El criterio: decidir qué diseñar, qué quitar y qué priorizar sigue siendo trabajo humano.
• La investigación: hablar con usuarios no se automatiza.
• La calidad visual: la IA genera interfaces correctas, pero rara vez memorables sin dirección.
• La responsabilidad: alguien tiene que revisar que lo generado es accesible, coherente y mantenible.

Herramientas que usamos

• Figma para exploración visual y documentación del design system.
• React y TypeScript para los prototipos y componentes.
• Asistentes de programación con IA para acelerar el código y los datos de ejemplo.
• Vercel para publicar el prototipo y compartirlo con un enlace.

Este mismo enfoque lo usamos en nuestros productos, Lantis y Citable, donde diseño y código avanzan a la vez.

Errores frecuentes al prototipar en código

• Saltarse el design system y acabar con pantallas incoherentes.
• Pulir el código del prototipo como si fuera producción, perdiendo la ventaja de velocidad.
• Usar datos de ejemplo poco realistas, que esconden problemas de diseño con textos largos o muchos registros.
• No documentar el comportamiento, confiando en que el código lo explica todo.
• Dejar fuera al equipo de desarrollo hasta el final.

Prototipo en código para presentar a inversores y clientes

Un prototipo navegable no solo sirve para validar con usuarios. También es una herramienta muy potente en otros momentos:

• Rondas de inversión: enseñar un producto que funciona en el navegador transmite mucha más ejecución que una presentación con capturas.
• Clientes piloto: permite cerrar acuerdos antes de tener el producto final construido, porque el cliente ve exactamente qué recibirá.
• Equipo de ventas: ventas puede empezar a preparar demos y materiales mientras desarrollo construye.
• Alineación interna: cuando todo el equipo usa el mismo prototipo, desaparecen las discusiones sobre cómo "debería" funcionar algo.

En el caso de Mainder, el prototipo se publicó con un enlace propio y datos de ejemplo, para que cualquier persona del equipo, o un cliente, pudiera explorarlo sin instalar nada.

Datos de ejemplo: el detalle que lo cambia todo

Un prototipo en código es tan bueno como sus datos. Con datos de ejemplo pobres ("Usuario 1", "Lorem ipsum"), muchos problemas de diseño no aparecen. Con datos realistas, sí. Lo que cuidamos:

• Nombres y textos reales del sector del cliente, con longitudes variadas.
• Volúmenes realistas: listas de cientos de elementos, no de cinco.
• Casos incómodos: textos muy largos, campos vacíos, estados poco frecuentes.
• Coherencia entre pantallas: el candidato que aparece en la lista es el mismo que se abre en la ficha y el que tiene una conversación en la mensajería.

La IA ayuda mucho aquí: generar cientos de registros verosímiles y coherentes es una tarea en la que ahorra días de trabajo.

Accesibilidad y rendimiento desde el prototipo

Al construir en código desde el principio, podemos comprobar cosas que en un diseño estático son invisibles: navegación con teclado, contraste real en pantalla, comportamiento con lectores de pantalla, tiempos de carga con muchos datos y adaptación a distintos tamaños. Detectar estos problemas en el prototipo evita que lleguen a producción, donde son mucho más caros de corregir.

Cómo se integra con el equipo de desarrollo

El prototipo en código no compite con el equipo de desarrollo: le ahorra trabajo. Para que la integración funcione, acordamos desde el inicio:

• Tecnología compatible con la del producto, para que los componentes puedan reutilizarse.
• Convenciones de nombres compartidas entre diseño y código.
• Qué es referencia y qué es reutilizable: qué partes del prototipo se copiarán y cuáles solo indican el comportamiento.
• Un canal de dudas abierto durante la implantación.

Así, el handoff deja de ser un momento de entrega y se convierte en una transición continua entre diseño y desarrollo.

Un ejemplo de flujo de trabajo en una semana

Para que se entienda cómo cambia el día a día, así es una semana típica de trabajo en un módulo con prototipo en código:

• Lunes: sesión con el equipo del cliente para revisar el flujo del módulo y decidir el alcance. Por la tarde, primeras pantallas con los componentes del design system.
• Martes: pantallas principales con datos de ejemplo realistas y estados básicos.
• Miércoles: sesión en vivo de revisión; muchos ajustes se hacen durante la propia reunión. Por la tarde, estados de error, vacío y permisos.
• Jueves: pruebas con dos o tres usuarios y ajustes.
• Viernes: documentación del comportamiento, revisión con desarrollo y publicación de la nueva versión del prototipo.

En un flujo tradicional, la misma semana suele acabar con pantallas estáticas pendientes de una ronda de comentarios por escrito.

Qué recibe el cliente al final

Al terminar un proyecto con prototipo en código, el cliente tiene:

• El prototipo publicado con un enlace, para usarlo y enseñarlo.
• El código del prototipo y de los componentes en un repositorio.
• El design system en Figma y en código, con los mismos nombres.
• La documentación de flujos, estados y comportamiento.
• Un plan de implantación por fases.

Todo pensado para que el equipo de desarrollo, interno o externo, construya el producto sin depender de nosotros para cada duda.

¿Sirve también para webs?

Para webs de marketing, el equivalente al prototipo en código es construir directamente en Framer o Webflow, que ya generan la web final. Para webs muy ligadas al producto, como las de Lantis o Citable, usamos código desde el principio, de modo que web y producto comparten componentes.

Preguntas frecuentes

¿Qué es un prototipo en código?

Es una versión navegable de un producto construida con tecnologías web reales, como React, que funciona en el navegador con interacciones, estados y datos, en lugar de pantallas estáticas enlazadas.

¿Es más caro un prototipo en código que uno en Figma?

Con IA, la diferencia es pequeña. Y como reduce rondas de cambios y errores en desarrollo, el coste total del proyecto suele ser menor.

¿Hay que saber programar para prototipar en código con IA?

Hace falta criterio técnico para mantener el código ordenado y coherente con el design system. La IA acelera mucho el trabajo, pero no sustituye ese criterio.

¿Figma deja de ser necesario?

No. Sigue siendo la mejor herramienta para explorar direcciones visuales rápidamente y para documentar el design system. Lo que cambia es dónde vive el prototipo final.

¿El equipo de desarrollo puede reutilizar el código del prototipo?

Los componentes del design system, normalmente sí. Las pantallas, depende de la arquitectura del producto; en productos nuevos pueden ser la base del front-end.

¿Cuánto tarda un prototipo en código?

Depende del alcance. Un MVP de 5 a 15 pantallas puede estar navegable en dos o tres semanas; el rediseño de un SaaS completo, en varias semanas trabajando por módulos.

¿Qué tecnología usáis para los prototipos en código?

Normalmente React con TypeScript, porque es la tecnología más extendida en los equipos de producto y facilita que los componentes se reutilicen. Si el equipo del cliente usa otra tecnología, lo adaptamos para que el traspaso sea lo más directo posible.

¿Un prototipo en código sustituye a las pruebas con usuarios?

No, las hace mejores. Al usar algo que funciona, los usuarios se comportan como lo harían con el producto real, y los problemas que aparecen son los que de verdad tendrá el producto.

Fuentes

• v0, Bolt y Cursor: las herramientas de IA más usadas para generar interfaces y prototipos en código.
• Nielsen Norman Group: por qué basta con probar con 5 usuarios: cinco usuarios encuentran la mayoría de problemas de usabilidad de un diseño.
• Brad Frost: Atomic Design: el método de referencia para construir design systems por componentes.

Siguiente paso

Si ya tienes una app hecha con IA y quieres que parezca un producto profesional, mira rediseño de apps hechas con IA. Si quieres ver cómo funciona un prototipo en código, prueba el de Mainder o agenda una reunión de 30 minutos y te enseñamos cómo aplicarlo a tu producto.