Ejercicios: Validación y testado de prototipos

Explica qué es validar un prototipo y en qué se diferencia de «que a tu equipo le guste». ¿Por qué no basta con preguntar a tus amigos si tu idea es buena?

Vas a testar el puesto de zumos con $5$ compañeros. Describe qué les darías a probar, qué tres cosas anotarías de cada uno (qué elige, cuánto tarda en decidir, si pagaría el precio) y por qué es mejor observar lo que hacen que preguntarles solo si les gusta.

La figura muestra el bucle de trabajo de un equipo que valida su prototipo, pero una de las estaciones está tapada con un signo de interrogación.

1. a) Indica qué estación falta en el bucle (qué hace el equipo con lo aprendido en el test) y por qué sin ella el bucle no gira.
2. b) Explica qué representa el centro del bucle y por qué no puede ser «la opinión del propio equipo».

Explica qué es un usuario de prueba (tester) y por qué tu abuela o tu mejor amigo son testers sospechosos. Describe el perfil de tres buenos testers para una app de apuntes del instituto (quiénes son y por qué su opinión cuenta más que la de tu familia).

Distingue validar de verificar con un ejemplo del puesto de crepes: verificar es comprobar que la crepe está hecha según la receta; validar es comprobar que la gente quiere comprarla. Explica por qué un producto puede estar «bien hecho» y aun así no vender.

Nombra tres cosas que puedes anotar en un test sin preguntar nada (dónde duda el usuario, qué botón pulsa primero, cuánto tarda) y explica qué ventaja tiene observar frente a preguntar «¿te gusta?».

Explica qué es una métrica y por qué «parece que gustó» no es una métrica. Escribe una métrica concreta para cada proyecto: el puesto de desayunos, la app de apuntes y el punto de intercambio de libros.

Tu equipo ha testado el prototipo y tiene una lista de $12$ fallos. Explica por qué no conviene arreglar los $12$ a la vez y en qué orden razonable atacarlos (primero los que bloquean el uso, luego los que molestan mucho, al final los detalles). Pon un ejemplo de cada tipo.

Diseña el test de un prototipo de app del instituto hecho con pantallas de papel: escribe el guion de $5$ pasos que pedirás al usuario (buscar el horario, apuntar una tarea…), qué debe hacer solo (sin que le ayudes) y qué anotarás en cada paso. Explica por qué en el test el usuario «conduce» y tú callas.

En el primer test del puesto de crepes, $3$ de cada $10$ probadores piden la versión salada y la valoración media del sabor dulce es de $7,2$ sobre $10$; tras cambiar la receta, la media sube a $8,5$ y $5$ de cada $10$ piden salados.

1. a) Interpreta las dos métricas y explica qué decisiones tomarías con la carta (precio, protagonismo de lo salado, receta dulce).
2. b) Propón una tercera métrica útil para el próximo test (tiempo de cola, repetición, precio aceptado) y justifícala.

Del test de vuestra app salen $15$ comentarios: dos personas piden modo oscuro, una pide que hable con Alexa, ocho se quejan de que no se entiende el botón principal y cuatro no comentan nada. Explica cómo distingues la señal del ruido (cuánta gente lo pide, cuánto bloquea el uso) y decide qué dos cambios haríais primero, defendiendo el orden.

Diseña el test de usabilidad del prototipo del punto de intercambio de libros: el guion de $4$ pasos que pedirás a cada usuario (encontrar el punto, buscar un libro, registrar la entrega), qué debe hacer solo sin ayuda, qué anotarás en cada paso y cuántos testers buscaréis. Explica por qué con $5$ buenos testers se detectan ya la mayoría de los problemas grandes.

En el test del puesto de desayunos, $6$ de $10$ probadores completan la compra en menos de $2$ minutos; $3$ preguntan por opciones sin gluten (no hay) y la valoración media del producto es $8,1$ sobre $10$.

1. a) Interpreta las tres métricas y decide las dos primeras mejoras, justificando el orden.
2. b) Propón la hipótesis que probaríais en el siguiente test («si añadimos una opción sin gluten, $X$ pasará») y la métrica que la confirmaría.

El equipo testó su app con $20$ alumnos y recogió $25$ comentarios: $9$ piden modo oscuro, $6$ se quejan de que no encuentran el buscador, $4$ piden avisos de exámenes, $3$ piden stickers y $3$ no dijeron nada.

1. a) Ordena los cambios por señal (cuánta gente lo pide y cuánto bloquea) y decide qué dos entran en la próxima versión, defendiendo el criterio.
2. b) Explica qué harías con el comentario de los stickers y por qué «contentar a todos» es la receta para no lanzar nunca.

Vuestra primera validación salió «demasiado bien»: enseñasteis el prototipo a $8$ amigos explicándolo vosotros, y todos dijeron que «está genial». Al probarlo solos, $3$ compañeros de otra clase no supieron ni empezar.

1. a) Identifica los tres errores del primer test (muestra, explicación previa, preguntas que empujan al elogio).
2. b) Rediseña el test con las reglas correctas (usuario conduce, tú callas, tareas en vez de opiniones) y escribe las dos primeras frases que dirás al tester.

El puesto de zumos hizo dos rondas de test. Ronda 1: $40\ \%$ de los que se acercaban compraban, espera media de $6$ minutos, valoración del sabor $6,5$. Ronda 2 (con receta nueva y dos jarras): $55\ \%$ de compra, espera de $3$ minutos, sabor $8,2$.

1. a) Interpreta la evolución: qué cambió, qué métrica lo confirma y qué dirías si alguien del equipo afirma que «ya está perfecto».
2. b) Propón la siguiente métrica a mejorar (porcentaje que repite, ventas por hora punta) y diseña cómo la mediríais en la feria.

El equipo testó su app de apuntes con $10$ usuarios: sus $8$ mejores amigos y $2$ familiares. Todo fueron elogios y ninguna pega. Al lanzarla, el alumnado la encuentra confusa.

1. a) Analiza por qué el test salió «perfecto» y aun así falló: qué sesgos tenía la muestra y el guion.
2. b) Rediseña el test: a quiénes elegirías, qué instrucciones les darías y qué harías para que las críticas salgan a la luz.

Dos rondas de test del puesto de desayunos dan estos datos: versión $1$: $3$ de $10$ clientes completan la compra y valoran la espera con un $4$ sobre $10$; versión $2$ (con pedido anticipado y dos cajas): $8$ de $10$ completan y la espera se valora con un $8$.

1. a) Interpreta la evolución: qué problema tenía la versión $1$, qué cambió y qué métrica lo demuestra.
2. b) Propón la siguiente hipótesis a testar (qué mejoraría aún más la compra) y diseña la mini-prueba con su métrica de éxito.

Validar no es solo el producto: también el proceso del equipo. Diseña una autoevaluación del proyecto con cinco preguntas que el equipo responderá individualmente (reparto justo de tareas, cumplimiento de plazos, calidad de las decisiones, clima del grupo, aprendizaje personal). Explica cómo se pondrán en común las respuestas y qué haréis si una pregunta sale muy baja.

El equipo de la app de organización la lanzó sin validar: $6$ meses de trabajo, $200$ descargas la primera semana… y el $80\ \%$ la desinstaló al segundo día. Las reseñas dicen «no se entiende» y «no encuentro nada».

1. a) Reconstruye qué validación habría detectado el desastre en la semana $2$ (test con pantallas de papel, $5$ usuarios, tareas concretas) y qué habría costado frente a $6$ meses.
2. b) Diseña el plan de rescate: qué test hacéis ahora con la app real, a cuántos usuarios, qué tres tareas les pedís y qué dos cambios urgentes esperáis encontrar antes de relanzar.

Dos equipos validan el mismo tipo de puesto. El A pregunta: «¿te gustaría que hubiera un puesto de desayunos sanos?» ($90\ \%$ dice que sí). El B monta un puesto mínimo un recreo y mide: $15$ compras de $60$ personas que pasaron.

1. a) Explica qué midió realmente cada equipo y por qué el «sí» del equipo A vale menos que las $15$ compras del B (diferencia entre opinión declarada y comportamiento real).
2. b) Diseña vuestra validación definitiva para la feria: qué experimento con dinero real haríais antes, con qué umbral de éxito escrito de antemano («si menos de $X$ de cada $Y$ compran, cambiamos de producto»).

«Validar es para los que no creen en su idea; los grandes emprendedores siguen su instinto.»

1. a) Resume el argumento y detecta qué confunde (la idea con su ejecución: el instinto propone, el usuario dispone).
2. b) Rebátelo con el caso del equipo que «sabía» que las pulseras rojas serían las más vendidas y acabó regalándolas mientras se agotaban las azules, y extrae una regla práctica: qué decisiones pueden dejarse al instinto y cuáles no.

Vuestra cooperativa lanza la v3 del puesto tras dos validaciones. La feria real, sin embargo, sale peor que los tests: colas largas, agotáis el género a media mañana y varios clientes se van sin comprar.

1. a) Explica por qué los tests no predijeron esto (escala, hora punta, estrés del equipo: el laboratorio no es el mundo real) y qué aprende un equipo ágil de esta «falla» del test.
2. b) Diseña el informe post-feria: qué cinco datos recogeréis durante el evento (ventas por hora, cola máxima, momento de agotamiento, quejas, qué se agotó primero) y qué tres decisiones tomaréis para el próximo evento con esos datos.

Diseña el sistema completo de validación del proyecto de tu clase para este curso: qué se valida antes de construir (concepto), qué se valida con el prototipo (uso), qué se valida en el lanzamiento (mercado real) y qué se valida después (mejora continua). Para cada fase indica el método, el número de personas implicadas, la métrica de éxito y la decisión que tomaréis si el resultado es malo. Defiende por qué validar es un seguro y no una pérdida de tiempo.