Los prototipos ahorran tiempo no porque «se dibujen más rápido», sino porque permiten posponer decisiones caras hasta el momento en que realmente se necesitan. Pero esto tiene una cara B. Cuanto mejor se ve un prototipo, más fácil es confundir «se entiende cómo va a funcionar» con «esto ya casi funciona».
En B2B y en el desarrollo de productos importa una pregunta: qué es exactamente lo que estamos validando ahora. Si validamos el sentido, el flujo y la estructura – el prototipo es casi siempre la mejor herramienta. Si validamos el sistema (datos, roles, integraciones, velocidad, fiabilidad) – el prototipo empieza a mentir rápidamente, aunque sea perfecto a nivel visual.
El prototipo como gestión del riesgo, y no como «una imagen bonita»
El prototipo cubre los riesgos de comportamiento
En las etapas iniciales, más a menudo se equivocan no en la interfaz ni en el código, sino en la suposición sobre el usuario. El prototipo reduce bien el riesgo de «estamos construyendo algo equivocado», si lo usas para comprobar tres cosas:
- flujo: a dónde va la persona, qué intenta hacer, dónde toma una decisión
- prioridades: qué debe estar primero en la pantalla, qué se puede ocultar, qué se puede eliminar
- entendimiento común: si diseño, desarrollo, ventas y el dueño del negocio ven el producto de la misma manera
El código también puede comprobarlo, pero fija las decisiones demasiado rápido. Y en esta fase normalmente es más útil fijar no la interfaz, sino el sentido.
Dónde el prototipo es sistemáticamente más débil
Hay zonas en las que el prototipo casi inevitablemente «alisa la realidad». Y cuanto más complejo es el producto, más cara sale esa ilusión.
- datos: fichas incompletas, duplicados, retrasos, errores, «zonas grises»
- estados: vacío, parcialmente rellenado, «sin permisos», «no encontrado», «servicio no disponible»
- limitaciones de ingeniería: navegadores, móvil, accesibilidad, seguridad, auditoría de acciones
- tiempo: velocidad de respuesta, rendimiento en dispositivos poco potentes, solicitudes concurrentes
Si estas cosas son críticas para el UX (y en B2B son críticas casi siempre), el prototipo no debe ser la principal fuente de confianza.
El prototipo como contrato temporal
Un buen prototipo – es un contrato temporal: ayuda al equipo a ponerse de acuerdo sobre qué hacemos y para qué, antes de acordar cómo exactamente lo implementamos. Pero el contrato se vuelve tóxico si vive más tiempo que el sentido que debía fijar.
Una señal de que estáis atascados: la discusión suena a «pero en el prototipo es así», en lugar de «qué efecto tiene en el escenario y por qué».
Cuándo el prototipo es suficiente y se puede seguir adelante
El escenario dejó de «derivar»
Si el equipo ha dejado de discutir la lógica básica, eso no significa que todo sea perfecto. Pero significa que el prototipo ha hecho el trabajo clave.
Comprueba si hay claridad sobre estas preguntas:
- qué tarea del usuario se resuelve en este flujo
- qué se considera éxito de una sesión y éxito de una semana
- dónde está el punto de decisión y por qué precisamente allí
Cuando estas respuestas son estables, el prototipo ya no debería crecer «a lo ancho».
Los límites del MVP están trazados y defendidos
El prototipo a menudo se infla porque «bueno, es una tontería, lo añadimos». El problema es que las tonterías en la interfaz a menudo son decisiones de producto, y por lo tanto cambian el coste y los plazos.
Una señal normal de preparación para el código: el MVP tiene una lista de «no incluimos», y se sostiene lógicamente bajo presión.
Por ejemplo: «en la primera versión sin roles de equipo, porque primero comprobamos el valor con un solo usuario» – eso es un argumento.
«sin roles porque no llegamos» – eso suele ser una deuda que luego se convertirá en una crisis.
Los criterios de éxito se describen como mediciones
No es obligatorio tener analítica en producción, pero los criterios deben estar formulados de antemano. De lo contrario, el prototipo inevitablemente se evaluará por gusto.
Ejemplos de criterios que de verdad ayudan:
- finalización del flujo en N pasos / sin recurrir al soporte
- porcentaje de usuarios que llegan al «primer resultado» en una sola sesión
- tiempo hasta el primer artefacto útil (solicitud, informe, objeto creado)
El prototipo es suficiente cuando está vinculado a un «para qué» medible, y no a la discusión de detalles.
Se han identificado dependencias que rompen los plazos
Si el producto depende de integraciones, permisos de acceso, fuentes externas de datos, aprobaciones – el prototipo debe ayudar a nombrarlas y evaluarlas como riesgo.
Importante: el prototipo no está obligado a modelarlo todo. Pero sí está obligado a resaltar aquello que puede destruir el plan.
Cuándo el prototipado empieza a perjudicar y es hora de escribir código
Cuando el «pulido» sustituye la validación
La zona de riesgo tiene un aspecto reconocible: la interfaz se vuelve cada vez más limpia, pero no aumenta la claridad sobre plazos y complejidad.
Síntomas típicos:
- las iteraciones giran en torno a microdetalles, y la discusión sobre el sentido sigue sin cerrarse
- el equipo discute componentes, no flujos y prioridades
- el prototipo crece, pero los riesgos de datos, roles e integraciones siguen siendo «ya lo veremos luego»
No es velocidad. Es posponer la realidad.
Cuando el prototipo se desajusta de los datos y del proceso
En B2B a menudo hay una verdad incómoda: los datos llegan sucios, los procesos son semimanuales, hay muchas excepciones, el rol del usuario influye en cada pantalla.
Si este es tu caso, el paso a código hace falta cuando es importante comprobar:
- qué verá el usuario sin permisos o con permisos parciales
- cómo se ve la ficha cuando la mitad de los campos está vacía
- qué ocurre cuando hay un retraso en la integración y se reintenta
- cómo se comporta el sistema ante un conflicto de cambios
El prototipo puede mostrar esto «en una imagen», pero no comprobará lo principal: con qué frecuencia ocurre y cuánto cuesta.
Cuando estimar el coste es imposible sin arquitectura
Hay proyectos en los que la pantalla parece sencilla, pero el coste está en otra parte: modelo de dominio, reglas, auditoría, seguridad, aprobaciones, almacenamiento, sincronización.
Si la pregunta suena «cuánto va a costar esto», y la respuesta honesta se queda en «hay que decidir cómo almacenamos las entidades y dónde están los límites de responsabilidad», el prototipo ya no lidera. Hace falta al menos un diseño técnico mínimo, y mejor aún, un armazón de código.
Cuando el UX depende de la velocidad y la fiabilidad
Si la experiencia de usuario se basa en la sensación de «rápido, estable, predecible», el prototipo da una falsa seguridad. No muestra:
- el tiempo de respuesta y la degradación bajo carga
- los retrasos reales de la red
- el efecto de tablas pesadas, filtros y listas en dispositivos poco potentes
Es hora de ponerse a programar cuando te importa no cómo se ve, sino cómo funciona en el tiempo.
Figma y Framer como diferentes tipos de prototipos
Prototipo para debatir el significado y la estructura
Cuando la tarea es ponerse de acuerdo sobre el flujo y la arquitectura de la interfaz, necesitas un prototipo que sea fácil de cambiar y cómodo de discutir. Aquí el valor no está en «parecerse al producto», sino en que se pueda revisar rápidamente alternativas y cerrar los puntos controvertidos.
Este tipo de prototipo es bueno como especificación del significado: qué ocurre, en qué secuencia, qué considera el usuario un éxito.
Prototipo para demostrar la dinámica y la «sensación de producto»
Hay situaciones en las que es importante mostrar el movimiento: animaciones, transiciones, interactividad, una sensación «viva». Este tipo de prototipo es útil para demos, pilotos, aprobaciones internas, a veces incluso para ventas.
El riesgo es simple: empiezan a percibirlo como «casi listo», aunque no tiene datos, permisos, errores ni infraestructura real.
El error no está en la herramienta, sino en la pregunta
Con demasiada frecuencia no eligen la herramienta para la tarea, sino la tarea para la herramienta. Es más correcto formular primero qué evidencia necesitas.
A continuación, una guía que ayuda a no confundir «mostrar» y «comprobar».
| Tarea | El prototipo ayuda | Dónde aparecerá la brecha |
|---|---|---|
| Alinear el flujo y la estructura | Sí | Cuando los datos reales y los roles son más complejos que el modelo ideal |
| Mostrar la dinámica y las microinteracciones | Sí | Cuando el rendimiento y la estabilidad son importantes |
| Estimar el coste de desarrollo | Parcialmente | Arquitectura, integraciones, seguridad, auditoría |
| Comprobar permisos/roles y excepciones | Poco | Esto se comprueba en el sistema y con datos |
| Preparar una base para escalar | No | Se necesita un modelo de dominio y una base de código |
La frontera en la práctica: híbrido en lugar de «prototipo o código»
El corte vertical como transición honesta
Para B2B y productos complejos casi siempre funciona un modelo: no intentar «terminar de dibujar la verdad» en el prototipo, sino hacer un corte vertical en código.
Un corte vertical – es un escenario end-to-end:
- con datos reales (aunque sean primitivos, pero auténticos)
- con una arquitectura mínima (pero suficiente para no mentir)
- con errores y estados reales
No tiene por qué ser bonito. Tiene que ser honesto.
Dos artefactos en lugar de uno
En la práctica es útil mantener dos líneas paralelas:
- el prototipo se encarga del significado, la estructura y los escenarios
- el armazón de código se encarga de la verdad: datos, permisos, integraciones, velocidad
Cuando un artefacto intenta sustituir a ambos, el equipo lo paga con el aumento de la incertidumbre y los constantes «ya lo reharemos después».
Criterios de transición que se pueden fijar de antemano
Para no discutir «cuándo toca ponerse a programar», conviene fijar de antemano las señales:
- el escenario y los límites del MVP son estables
- las entidades de datos están descritas al menos a nivel de esquema de dominio
- las integraciones críticas están enumeradas y evaluadas como riesgos
- están definidas las métricas de éxito del escenario
- hay zonas en las que el prototipo no dice la verdad (permisos, datos, rendimiento)
Si los dos últimos puntos son relevantes simultáneamente, el paso al código suele estar justificado económicamente: compras previsibilidad.
Por qué el prototipo no debe vivir más que su tarea
El prototipo es bueno mientras reduce la incertidumbre más rápido y más barato que el código. Pero cuanto más te acercas a las cuestiones del sistema, más rápido el prototipo se convierte en una fuente de falsa seguridad: muestra de forma bonita aquello que luego resultará ser lo más caro – datos, roles, integraciones, fiabilidad y velocidad.
Una estrategia práctica no está en elegir «Figma o Framer». Y ni siquiera en elegir «prototipo o código». La estrategia está en la secuencia: primero fijamos el sentido y el escenario, y luego introducimos un elemento de verdad mediante un corte vertical. En este punto, el equipo deja de discutir sobre gustos y empieza a gestionar el riesgo – aquello que realmente afecta a los plazos, el coste y la calidad del producto.
