Un equipo quiere probar un asistente capaz de transformar una petición confusa en un plan coherente. Desarrollar el sistema real puede llevar meses, y mostrar una simple diapositiva con la supuesta respuesta apenas revela qué preguntaría la gente en la práctica. Las pruebas de Mago de Oz ofrecen un camino intermedio: una persona genera parte o la totalidad de las respuestas mediante una interfaz que las muestra como si fueran del propio sistema.
Este método recurre a un operador humano (al que a veces se llama «mago») para simular una funcionalidad durante la investigación. Permite explorar la interacción antes de que exista la automatización: qué pide la gente, qué espera recibir a cambio y cómo reacciona cuando algo falla. Eso sí, el rendimiento del operador no debe confundirse con lo que la tecnología final será capaz de ofrecer.
Define los límites del sistema que representa el operador
Imagina un asistente ficticio para planificar comidas. Quien participa pide menús adaptados a un presupuesto, que aprovechen sobras y que eviten una alergia concreta. Un investigador hábil podría dar una respuesta brillante, pero eso aportaría muy poco sobre el sistema futuro si el estudio no define de antemano qué información y qué capacidades tiene permitido usar.
Establece las reglas de funcionamiento antes de las sesiones. Decide qué entradas acepta el asistente, a qué datos tiene acceso, qué tiempo de respuesta debe simular y cómo reacciona ante una petición no compatible. Prepara ejemplos y ensaya la coordinación entre la interfaz que ve la persona y el operador.
La guía de Nielsen Norman Group sobre el método del Mago de Oz explica cómo usar una simulación controlada por humanos para investigar una experiencia sin necesidad de programar toda la funcionalidad. La simulación resulta mucho más útil cuando el comportamiento que se representa está lo bastante delimitado como para interpretar los resultados con claridad.
Pon a prueba una experiencia, no el ingenio del operador
Plantea a los participantes escenarios de tareas realistas, dejando margen para peticiones que el equipo no haya previsto. Registra tanto esas peticiones como las respuestas. Si el operador improvisa y se sale de las reglas acordadas, anota esa variación en lugar de dar por hecho en silencio que es el comportamiento normal del sistema.
El ejemplo de la planificación de comidas podría revelar que la gente quiere cambiar un solo ingrediente sin tener que regenerar toda la semana. Ese es un requisito de interacción muy valioso. En cambio, que alguien quede satisfecho con un menú preparado con sumo cuidado no demuestra que un modelo automatizado vaya a generar recomendaciones igual de acertadas.
Introduce limitaciones realistas cuando aporten valor a la investigación. Probar únicamente respuestas perfectas puede ocultar la necesidad de corregir, rechazar, pedir aclaraciones o recuperarse de errores. Una prueba de prototipo independiente puede servir después para ver cómo gestiona la gente esas situaciones una vez diseñadas.
Planifica el consentimiento y la explicación posterior antes de simular
Es posible que los participantes no sepan qué partes del prototipo están en manos de una persona. Por eso, decidir si se revela o no la simulación es una parte clave del diseño del estudio. Conviene apostar por la transparencia siempre que permita seguir investigando el objetivo marcado, y evitar ocultar cosas de forma innecesaria solo para que parezca más convincente.
Cuando se reserve información, el plan de investigación debe contar con una revisión ética adecuada, límites claros y una explicación final bien pensada. Los participantes deben entender qué ha ocurrido y cómo se tratarán sus datos. El consentimiento informado no se cumple si la revelación final se plantea como una sorpresa divertida.
Mantén la actividad estrictamente dentro del marco de la investigación. Siguiendo con el ejemplo de las comidas, los menús generados no deben tomarse como pautas médicas verificadas sobre alergias ni utilizarse como si el servicio fuera totalmente fiable. El estudio puede explorar expectativas con escenarios adecuados sin pedir a nadie que dependa de una recomendación sin validar.
Traslada los aprendizajes a la versión definitiva
Separa los hallazgos sobre peticiones, comprensión de la interfaz y recuperación de errores de aquellos que dependan de la calidad de las respuestas. Documenta la intervención del operador, los tiempos de espera y las desviaciones para que luego quede claro qué experiencia vivió realmente cada participante.
La siguiente ronda de investigación deberá evaluar la funcionalidad real en cuanto esté disponible. La gente puede plantear las mismas peticiones pero reaccionar de forma muy distinta ante demoras reales, respuestas incoherentes o límites en los datos disponibles. Las pruebas de Mago de Oz ayudan al equipo a descubrir qué merece la pena construir y probar; lo que no pueden hacer es certificar el sistema que finalmente sustituirá al operador.