Wizard of Oz: probar antes de construir, con una persona detrás
Wizard of Oz es una técnica en la que una persona simula las respuestas de un sistema que aún no existe. Aprende cuándo usarla, cómo prepararla y su ética.
¿Qué es Wizard of Oz?
La Usability Body of Knowledge la define como una evaluación de tecnología no implementada en la que un experimentador, el “wizard”, simula las respuestas del sistema, generalmente sin que el usuario lo sepa. El nombre viene de la novela de L. Frank Baum, y se atribuye a J. F. Kelley, quien lo acuñó mientras trabajaba en su tesis a comienzos de la década de 1980.
La técnica es más antigua que el nombre. Wikipedia señala que ya se usaba en investigación sobre interacción humano-computadora, y que la atribución del término tiene matices. Lo importante es la idea: probar la experiencia antes de que exista la tecnología.
¿Por qué le importa a un diseñador?
Porque hay ideas cuyo costo de construcción es alto pero cuya utilidad todavía no está clara. Una función de recomendaciones con IA, un asistente de voz o una búsqueda en lenguaje natural pueden costar semanas de desarrollo antes de saber si la gente las quiere. Con Wizard of Oz, puedes responder esa pregunta con una persona que escribe las respuestas desde otra habitación.
También es útil para comparar varios diseños de forma barata, y para explorar cómo se comporta el usuario cuando el sistema responde como si fuera real.
¿Cómo se prepara?
La Usability Body of Knowledge propone una secuencia clara:
- Diseña la interfaz simulada. Puede ser una pantalla, un chat o una superficie de voz, lo más creíble posible.
- Escribe un plan de pruebas con instrucciones para el facilitador, el wizard, los participantes y el personal de apoyo.
- Recluta usuarios representativos, que cubran el rango de la población objetivo, no a cualquiera disponible.
- Diseña escenarios de tarea realistas, con un objetivo que el participante quiera cumplir.
- Define cómo responderá el wizard a cada acción del participante y entrénalo.
- Avisa a los participantes de que usan un prototipo temprano cuyo rendimiento aún no está optimizado.
- Haz pruebas piloto para refinar el procedimiento y darle práctica al wizard.
- Cierra cada sesión con un debriefing: recoge impresiones y explica qué fue el wizard y por qué no se reveló antes.
Koji sugiere una versión más práctica: define una decisión concreta que quieres tomar con la prueba, escribe un guion operativo para el wizard y pilotea con dos participantes antes de empezar. Un error frecuente es hacer la prueba sin una decisión clara al final.
¿Cuáles son sus límites?
Wizard of Oz se vuelve poco fiable en algunos casos:
- Respuestas inconsistentes. Sin instrucciones precisas, el wizard improvisa de forma distinta en cada sesión. La Usability Body of Knowledge recomienda preparar instrucciones para las situaciones previsibles, no escribir cada reacción.
- Velocidad. Si el sistema real debe responder en milisegundos, el wizard no puede simularlo, y el participante lo nota.
- Lentitud y cansancio. Koji señala que un wizard es más lento que el software, lo que puede confundir los resultados. La Usability Body of Knowledge añade que su rendimiento puede bajar durante una sesión por fatiga cognitiva.
- Errores reales. Según la Usability Body of Knowledge, la técnica no expone los errores que causan el rendimiento del sistema o las tasas de reconocimiento, salvo que se simulen. Sirve mejor para descubrir problemas que para predecir la usabilidad real.
- Comportamiento a largo plazo. Si lo que importa es el uso repetido en semanas, un diary study o un programa beta da mejor información.
La misma fuente señala que es difícil evaluar con ella sistemas con una interfaz gráfica grande, y que las entradas más fáciles de simular son la voz y los movimientos de las manos.
¿Qué ética exige?
Wizard of Oz implica un engaño, aunque sea leve. La Usability Body of Knowledge cita el código de ética de la Asociación Estadounidense de Sociología (ASA): cuando el engaño es parte del diseño, hay que corregir las falsas creencias al terminar la investigación, con un debriefing final que explique por qué no se dijo antes. La misma página admite que este estándar no es universal en las pruebas de usabilidad, pero que conviene tomarlo más en serio.
Koji recomienda una práctica concreta: consentimiento informado previo que diga que el participante usa un prototipo que puede no funcionar como se anuncia, sin revelar la operación humana durante la sesión, y un debriefing al final. Esa es la práctica que conviene adoptar en tu equipo.
Ejemplo
Ejemplo ilustrativo: un equipo de una aseguradora quiere saber si los clientes aceptarían un asistente que resuelve dudas sobre siniestros en lenguaje natural, antes de entrenar un modelo. Un diseñador prepara una pantalla de chat y un guion con respuestas permitidas. Un miembro del equipo, el wizard, responde desde otra sala con esas reglas. Después de diez sesiones, el equipo ve que los clientes preguntan casi siempre por el estado de su trámite, no por las coberturas, y que se molestan cuando el asistente tarda. Con eso decide qué priorizar antes de construir. Al final de cada sesión, el equipo explica que la respuesta era humana.
Errores comunes
- Hacer la prueba sin una decisión concreta que dependa de los resultados.
- Dejar que el wizard improvise sin reglas claras.
- No avisar en el consentimiento de que el producto es un prototipo.
- Omitir el debriefing, lo que deja al participante engañado.
- Usarlo para medir tiempos de respuesta reales, algo que el wizard no puede simular.
- Olvidar el piloto, y descubrir los problemas con los participantes reales.
Si tu idea es un concepto más que una interacción, concept testing te ayuda a validar la propuesta antes de diseñar la interacción. Para una versión más barata, el prototipado en papel sirve para probar flujos sin ninguna simulación. Y para decidir el nivel de detalle de lo que vas a mostrar, revisa la página de prototipos.