Dale una pregunta al prototipo
Imagina que quieres un portal para tus clientes. Podrías empezar enumerando funciones: registro, documentos, notificaciones, asistente y panel de seguimiento. Antes de construirlas todas, conviene decidir qué necesitas comprobar primero.
Tal vez la pregunta sea si un cliente puede encontrar el estado de su solicitud sin llamar. Esa pregunta delimita una primera versión: entrada al portal, identificación de la solicitud y una respuesta comprensible.
Un prototipo de ese recorrido puede ayudarte a revisar el lenguaje, los pasos y la información que hace falta. Todavía no demuestra que los permisos, las integraciones o la operación estén listos para producción.
Aclara qué es real en la prueba
Identifica qué elementos funcionan, cuáles están simulados y qué depende de una conexión pendiente. Si el estado de una solicitud viene de datos ficticios, dilo junto a la experiencia. Así quien la revisa sabe qué puede evaluar.
El alcance debería incluir también lo que queda fuera. Un prototipo puede servir para entender una interacción sin resolver aún la carga de usuarios, la recuperación ante fallos o el trabajo cotidiano del equipo.
Prueba más de un recorrido
Pide a una persona que complete una tarea concreta. Observa dónde duda, qué busca y qué interpreta de forma distinta a la esperada. Incluye una situación incompleta: una solicitud sin datos suficientes o una respuesta que necesita aclaración.
Anota el resultado contra el criterio que definiste al inicio. “Se ve bien” puede ser una observación de diseño; “la persona encontró el estado y entendió el siguiente paso” aporta evidencia sobre la tarea.
Al terminar, decide qué conservar, qué ajustar y qué falta validar. El paso a producción necesita su propio alcance y sus pruebas. La primera versión es útil cuando permite tomar esa decisión con más claridad.
Antes de pedir un prototipo, completa tres campos: pregunta que debe responder, recorrido que debe mostrar y evidencia que aceptarás para avanzar.
