Prototipo navegable. Qué valida y qué no valida

Editorial

28 sept

5 min de lectura

Prototipo navegable Qué valida y qué no valida Revista ideas antes del código

Un prototipo puede parecer una app terminada y dejar abiertas las preguntas más costosas del proyecto. Distinguir lo que permite comprobar de lo que requiere otras pruebas ayuda a tomar mejores decisiones antes de comprometer presupuesto de desarrollo.

El equipo presenta las pantallas, recorre los pasos y llega a una confirmación. Todo parece funcionar. Entonces aparece una conclusión apresurada: el producto ya está validado y solo falta programarlo. Sin embargo, una demostración conducida por quien conoce el diseño no permite saber si otras personas comprenderán el recorrido, encontrarán lo que necesitan o resolverán su tarea sin ayuda.

Un prototipo navegable permite evaluar cómo las personas entienden y utilizan una propuesta en las tareas y situaciones que representa. Esa evidencia puede respaldar o cuestionar un supuesto concreto, pero no demuestra por sí sola que exista demanda, que la tecnología sea viable o que el negocio pueda cumplir lo prometido. Validar exige precisar qué se puso a prueba y hasta dónde alcanza la conclusión.

Un recorrido conectado todavía necesita una prueba

Un prototipo navegable es una representación interactiva de una solución: permite pasar entre pantallas y simular acciones, decisiones y respuestas. Puede mostrar cómo alguien busca un servicio, selecciona una opción y recibe una confirmación, aunque detrás no existan datos reales, pagos ni procesos operativos. Su utilidad depende de representar lo necesario para investigar una pregunta específica.

El nivel de detalle debe responder a esa pregunta. Para explorar la organización de un recorrido puede bastar una versión sencilla; para evaluar mensajes, formularios o interacciones concretas puede hacer falta mayor realismo. Nielsen Norman Group distingue la fidelidad de la interacción, la apariencia y el contenido. Por eso, una interfaz puede verse terminada y representar apenas una parte de su comportamiento.

“Un prototipo que se puede recorrer todavía necesita demostrar que se puede entender.”

Puedes escuchar este artículo aquí:

Qué permite evaluar con usuarios

Cuando se prueba con personas que representan a los usuarios previstos, el prototipo permite observar si encuentran una opción, interpretan una instrucción, comprenden las consecuencias de una acción y completan una tarea. También puede revelar dudas, retrocesos o expectativas que el equipo no había considerado. La evidencia surge del comportamiento observado, más allá de la opinión que alguien exprese sobre el diseño.

Imaginemos una app para reservar servicios de mantenimiento. La prueba consiste en solicitar una visita para una fecha determinada y explicar cómo quedó la solicitud. El participante llega a la pantalla final, pero interpreta que la visita ya está confirmada cuando todavía depende de la disponibilidad del técnico. Aunque completó el recorrido, el mensaje produjo una expectativa equivocada: avanzar entre pantallas no bastó para comprender el resultado.

También conviene representar qué ocurre cuando no hay disponibilidad. Si la persona no encuentra cómo elegir otra fecha o cree que perdió su solicitud, aparece una dificultad que el recorrido ideal habría ocultado. La guía de pruebas de usabilidad moderadas de GOV.UK recomienda plantear tareas relevantes sin anticipar la respuesta. Pedir una reserva permite investigar la navegación; indicar qué botón presionar impide observar si la persona lo encontraría por sí misma.

Revista ideas antes del código Prototipo navegable Qué valida y qué no valida

Qué no demuestra una navegación exitosa

Una persona puede comprender la propuesta y completar una tarea simulada sin necesitar el producto lo suficiente para adoptarlo o pagar por él. Una reacción favorable aporta información, pero no acredita demanda, uso recurrente ni rentabilidad. Esas preguntas requieren evidencia adicional sobre el problema, las alternativas actuales y decisiones reales de uso o compra.

Tampoco se comprueba la viabilidad técnica de una función al conectar dos pantallas. Mostrar un pago aprobado no demuestra que la integración funcione; presentar disponibilidad no prueba que los calendarios se sincronicen. Incluso un prototipo en código tiene límites. GOV.UK advierte que su implementación no necesariamente cumple los requisitos de seguridad o rendimiento exigidos en producción. Las conclusiones técnicas deben corresponder a lo que efectivamente se construyó y evaluó.

La operación también sigue abierta: alguien debe asignar al técnico, gestionar cancelaciones y responder ante una visita incumplida. Además, revisar la legibilidad no acredita toda la accesibilidad de la implementación. Un prototipo permite explorar barreras, pero no reemplaza las evaluaciones del producto construido. Las orientaciones de GOV.UK para la fase de exploración señalan que todavía no pueden aplicarse todas las pruebas técnicas de accesibilidad propias de un servicio en producción.

“Una pantalla que promete un resultado no demuestra que el producto pueda cumplirlo.”

Puedes ver este artículo aquí:

https://youtu.be/sYVwczV4wfc

Cómo probar sin confundir ayuda con evidencia

Antes de preparar la sesión, conviene escribir qué se quiere aprender, con quién y qué hallazgo obligaría a modificar la propuesta. En la app de mantenimiento, el supuesto podría ser que las personas distinguen una solicitud recibida de una visita confirmada. El prototipo necesitaría representar ambos estados y sus mensajes para poner esa diferencia a prueba.

Durante la sesión, el facilitador debe observar sin enseñar el recorrido. Si necesita intervenir, esa ayuda debe registrarse: completar una tarea con orientación aporta una conclusión distinta de completarla de manera autónoma. También hay que separar una dificultad del diseño de una limitación del prototipo. Si alguien intenta cambiar la fecha y esa interacción no fue construida, se identifica una expectativa relevante, pero todavía no puede evaluarse la solución.

Los resultados tienen un alcance concreto: dependen de las personas participantes, las tareas, el dispositivo y la versión probada. Observar que un grupo comprende el recorrido aporta evidencia para ese contexto; no permite extender automáticamente la conclusión a todos los usuarios. Del mismo modo, una prueba de la reserva inicial no demuestra que la cancelación o la recuperación ante errores estén resueltas.

La prueba debe terminar en una decisión

El resultado útil es una conclusión delimitada que conecte cuatro elementos: el supuesto evaluado, lo observado, el cambio acordado y lo pendiente. En el ejemplo, el equipo podría registrar que se investigó la comprensión del estado de la reserva, se detectó una confusión con la confirmación y se decidió ajustar el mensaje. La asignación real del técnico seguiría pendiente de revisión operativa.

Revista Ideas antes del código infografía Prototipo navegable Qué valida y qué no valida

Ese registro permite elegir el siguiente paso. Si las personas confunden los estados, corresponde corregir y repetir la prueba. Si comprenden el flujo, pero la asignación del técnico sigue indefinida, el avance de diseño debe acompañarse de una revisión operativa antes de incluir esa función en el alcance de desarrollo. Si aparece una dificultad que cuestiona la propuesta, puede ser necesario cambiarla antes de invertir más.

Un prototipo cumple su propósito cuando reduce incertidumbre suficiente para decidir. Su valor está en hacer visibles los problemas mientras todavía es posible modificar la solución. Documentar lo aprendido y lo pendiente evita que una presentación convincente se convierta en una autorización de desarrollo sustentada en supuestos invisibles.

¿Qué supuesto de tu producto sigue sin comprobarse aunque el prototipo ya se pueda recorrer? Comparte tu experiencia: identificar esa diferencia puede cambiar la siguiente decisión del proyecto.

Tu idea puede necesitar más claridad antes de convertirse en código. En Señor Zorro Estudio de diseño de productos digitales, te ayudamos a definir, validar y diseñar productos digitales listos para desarrollo. Conoce más en www.srzorro.com.