Prototipar y testear

Prototipar es construir la representación más barata posible de una idea para aprender algo concreto sobre ella. Testear es ponerla frente a personas reales y observar qué pasa. Las dos modalidades van juntas: un prototipo que no se prueba es una maqueta decorativa, y una prueba sin prototipo es una entrevista más.

El principio rector es que el prototipo es una pregunta, no una respuesta. Antes de construir nada, el equipo escribe qué quiere saber; el prototipo es el medio más rápido para averiguarlo.

Las tres ideas seleccionadas en el capítulo anterior para la clínica dental (mover la cita en un toque, confirmación con salida, lista de espera automática) se convierten ahora en prototipos.

Fidelidad: elegir cuánto construir

La fidelidad es el grado de parecido entre el prototipo y el producto final. Más fidelidad cuesta más tiempo y produce respuestas más específicas; menos fidelidad es más rápido y permite cambiar de rumbo sin dolor.

Tipo de prototipo	Fidelidad	Tiempo típico	Qué permite aprender
Boceto en papel	Muy baja	Minutos	Si el concepto se entiende; qué elementos faltan
Storyboard	Baja	Una hora	Si la secuencia de la experiencia tiene sentido para la persona
Wireframe clicable	Media	Horas	Si el flujo de pantallas es navegable; dónde se pierden las personas
Wizard of Oz	Media	Horas a días	Si la persona usaría el servicio, simulando la automatización con humanos detrás
Landing falsa	Media	Horas	Si hay demanda, midiendo cuántos piden acceso a algo que aún no existe
Concierge	Media	Días	Si el servicio resuelve el problema, entregándolo manualmente a pocos usuarios
Maqueta de servicio o role play	Baja a media	Horas	Cómo interactúan personas, espacios y objetos en un servicio físico
Producto mínimo viable	Alta	Semanas	Si la solución funciona en condiciones reales y a escala

flowchart TD
    Q{¿Qué queremos saber?} --> C[¿Se entiende el concepto?]
    Q --> F[¿Funciona el flujo?]
    Q --> D[¿Hay demanda?]
    Q --> V[¿Resuelve el problema en la vida real?]
    C --> P1[Papel o storyboard]
    F --> P2[Wireframe clicable]
    D --> P3[Landing falsa]
    V --> P4[Wizard of Oz o concierge]

Prototipos del caso

Idea	Pregunta	Prototipo elegido
Mover la cita en un toque	¿Las personas entienden el enlace y eligen un horario sin ayuda?	Wireframe clicable de tres pantallas en el celular
Confirmación con salida	¿Cambiar el texto reduce el silencio y aumenta los avisos?	Wizard of Oz: mensajes enviados a mano por una recepcionista a 30 pacientes reales durante una semana
Lista de espera automática	¿Los pacientes aceptan un turno ofrecido con poca anticipación?	Concierge: la recepcionista llama manualmente a quienes pidieron esa franja cuando se libera un turno

Plan de prueba

Cada prototipo tiene un plan de una página con cuatro elementos.

Elemento	Ejemplo para “mover la cita en un toque”
Hipótesis	Creemos que una paciente como Carolina puede cambiar su cita desde el enlace del mensaje sin ayuda en menos de un minuto
Métrica	Proporción de participantes que completan el cambio sin intervención; tiempo hasta completar; número de dudas expresadas
Criterio de éxito	Al menos 4 de 5 completan sin ayuda en menos de 90 segundos
Qué haremos según el resultado	Si se cumple, pasar a Wizard of Oz con pacientes reales; si no, rediseñar la pantalla de selección de horario y repetir

Definir el criterio antes de probar evita el sesgo de interpretar cualquier resultado como un éxito.

Pruebas de usabilidad con cinco usuarios

Jakob Nielsen propuso en 2000, a partir de un modelo matemático y datos empíricos, que probar con cinco usuarios detecta la mayoría de los problemas de usabilidad de una interfaz y que conviene hacer varias rondas pequeñas en lugar de una grande. La cifra no es una ley; aplica a problemas de usabilidad de una interfaz con un perfil de usuario homogéneo. Para medir conversión o preferencia entre alternativas se necesitan muestras mayores.

Guion de test

Bloque	Contenido
Introducción	Explicar que se prueba el diseño, no a la persona; pedir que piense en voz alta; consentimiento
Contexto	Una o dos preguntas sobre su experiencia con el tema para situar la sesión
Tareas	De tres a cinco tareas realistas, formuladas como escenario y sin usar las palabras de la interfaz: “Te surgió un compromiso el jueves y no podrás venir; muéstrame qué harías”
Observación	Registrar qué hace, dónde duda, qué dice; no ayudar salvo bloqueo total
Preguntas finales	Qué le pareció más fácil y más difícil; qué esperaba que pasara y no pasó
Cierre	Agradecimiento e incentivo

Reglas para el moderador: no explicar la interfaz, no preguntar “¿te gusta?”, no defender el diseño, responder a las preguntas del participante con otra pregunta (“¿qué esperarías que pase?”).

sequenceDiagram
    participant M as Moderador
    participant U as Participante
    participant O as Observador
    M->>U: Introducción y consentimiento
    M->>U: Escenario de la tarea 1
    U->>U: Intenta completar pensando en voz alta
    O->>O: Registra acciones, dudas y tiempo
    M->>U: Pregunta de seguimiento sin guiar
    M->>U: Escenarios 2 a 4
    M->>U: Preguntas finales
    O->>M: Resumen de hallazgos en 10 minutos

Capturar feedback

Grilla de retroalimentación

Después de cada sesión, el equipo organiza lo observado en una grilla de cuatro cuadrantes:

Me gusta	Deseo
Qué funcionó, qué el participante valoró	Qué cambiaría, qué pidió o echó en falta

Preguntas	Ideas
Qué dudas surgieron, qué no entendemos aún	Qué nuevas ideas aparecieron durante la prueba

La grilla se usa también con el formato “I like, I wish, What if” para que participantes o colegas den retroalimentación estructurada sobre el prototipo.

Registro de hallazgos

Cada hallazgo se anota con tres datos: qué pasó, cuántos participantes lo vivieron y qué gravedad tiene (bloquea la tarea, la dificulta, es cosmético). Esto permite priorizar las correcciones de la siguiente iteración.

Resultados del caso

Prototipo	Resultado	Decisión
Mover la cita en un toque	5 de 5 completaron sin ayuda; 3 dudaron en la pantalla de horarios porque no indicaba la sede	Corregir y pasar a prueba con pacientes reales
Confirmación con salida	En una semana, de 30 pacientes, 6 movieron su cita por mensaje y 1 faltó sin avisar, frente a 5 faltas sin aviso en la semana anterior con el texto antiguo	Adoptar el nuevo texto de inmediato; medir durante un mes
Lista de espera	De 8 turnos liberados, 5 se llenaron con llamadas manuales; la recepción tardó 20 minutos por turno	Confirma valor; la automatización requiere integración con la agenda, pasa al plan de arquitectura

La gerencia había llegado con “un sistema de recordatorios por WhatsApp”. El resultado validado es diferente: un cambio de texto que elimina la amenaza, un enlace para mover la cita y una lista de espera que requiere integración de sistemas. El primero costó cero y ya está operando.

Iterar y pivotar

Iterar es cambiar el prototipo manteniendo la hipótesis; pivotar es cambiar la hipótesis porque la evidencia la contradice.

stateDiagram-v2
    [*] --> Prototipo
    Prototipo --> Prueba
    Prueba --> Evaluar
    Evaluar --> Iterar: criterio no cumplido, hipótesis sigue en pie
    Evaluar --> Pivotar: la evidencia contradice la hipótesis
    Evaluar --> Construir: criterio cumplido en dos rondas
    Iterar --> Prototipo
    Pivotar --> Definir: volver al Point of View
    Definir --> Prototipo
    Construir --> [*]

Señales de que conviene pivotar: los participantes resuelven el problema de otra forma que el prototipo no contempla; el problema que creíamos central no aparece en las sesiones; el criterio de éxito falla en dos rondas con prototipos distintos.

Cuándo pasar a construir

El equipo deja la modalidad de prototipo cuando:

1. El criterio de éxito se cumplió en al menos dos rondas con participantes distintos.
2. Los hallazgos nuevos de la última ronda son cosméticos, no estructurales.
3. Las tres lentes están cubiertas: hay evidencia de deseabilidad (los tests), una evaluación de factibilidad (con tecnología) y una de viabilidad (con negocio).
4. Lo que se va a construir cabe en una descripción que el equipo de desarrollo entiende sin el diseñador presente.

Pasar antes produce retrabajo; pasar después produce parálisis. En organizaciones grandes, este punto es donde el resultado del diseño entra a la arquitectura y la gobernanza, tema del módulo de TOGAF.

Puente al Doble Diamante

Las cinco modalidades recorridas en este módulo (empatizar, definir, idear, prototipar, testear) se pueden leer como dos movimientos de apertura y cierre: abrir para entender y cerrar para definir el problema; abrir para generar y cerrar para validar la solución. Esa lectura es exactamente el Doble Diamante del Design Council, que el capítulo siguiente presenta como modelo de proceso con sus etapas, principios y componentes transversales.

Ejercicio práctico

1. Para cada una de las dos a cuatro ideas seleccionadas en el capítulo anterior, escribe la pregunta que quieres responder y elige el tipo de prototipo según la tabla de fidelidad.
2. Construye el prototipo de menor fidelidad que responda la pregunta. Límite: medio día por prototipo.
3. Redacta el plan de prueba con hipótesis, métrica, criterio de éxito y decisión según resultado.
4. Prepara un guion de test con tres tareas formuladas como escenarios.
5. Prueba con cinco participantes del perfil correcto, en pareja moderador y observador.
6. Completa la grilla de retroalimentación y el registro de hallazgos con frecuencia y gravedad.
7. Decide para cada prototipo: iterar, pivotar o construir, y justifica con los criterios de este capítulo.

Autoevaluación

1. ¿Qué tipo de prototipo simula una automatización con personas operando detrás?

   • A. Landing falsa
   • B. Storyboard
   • C. Wizard of Oz
   • D. Wireframe clicable

2. ¿Por qué se define el criterio de éxito antes de realizar la prueba?

   • A. Para evitar interpretar cualquier resultado como un éxito
   • B. Porque lo exige la d.school
   • C. Para poder prescindir del observador
   • D. Para reducir el número de participantes a uno

3. ¿A qué tipo de problema se aplica la recomendación de probar con cinco usuarios?

   • A. Medición de conversión entre dos alternativas
   • B. Detección de problemas de usabilidad en una interfaz con perfil homogéneo
   • C. Encuestas de satisfacción a escala
   • D. Estudios de mercado cuantitativos

4. ¿Cuál es la diferencia entre iterar y pivotar?

   • A. Iterar es probar con más usuarios; pivotar es probar con menos
   • B. Iterar cambia la hipótesis; pivotar cambia el prototipo
   • C. No hay diferencia práctica
   • D. Iterar cambia el prototipo manteniendo la hipótesis; pivotar cambia la hipótesis porque la evidencia la contradice

Respuestas

1. C. En Wizard of Oz el participante cree interactuar con un sistema que en realidad operan personas.
2. A. Un criterio fijado de antemano protege contra el sesgo de confirmación en la interpretación.
3. B. La regla de Nielsen aplica a usabilidad de interfaz; para medir preferencias o conversión hacen falta muestras mayores.
4. D. Iterar ajusta la solución; pivotar replantea el problema o la hipótesis.

Checklist

• Cada prototipo tiene escrita la pregunta que responde antes de construirlo.
• Elegí la fidelidad mínima necesaria para esa pregunta.
• Mi plan de prueba tiene hipótesis, métrica, criterio de éxito y decisión según resultado.
• Probé con participantes del perfil correcto, con moderador y observador.
• Registré los hallazgos con frecuencia y gravedad y completé la grilla de retroalimentación.
• Tomé una decisión explícita de iterar, pivotar o construir para cada prototipo.