La técnica Mago de Oz es una prueba en la que el usuario recibe el resultado de un producto automático, pero la función la ejecuta una persona oculta. Mide si esa función aporta valor antes de invertir en los sensores, la electrónica y el software que la harían real.
Qué valida la técnica Mago de Oz se resume en una frase, el valor de la función y nunca su viabilidad técnica. Lo que se pone a prueba no es la máquina, es la promesa. Si quien tiene el equipo delante cree que detecta, dosifica o clasifica solo, su reacción mide el valor de esa función y no la calidad de un control que todavía no existe. Por eso la técnica pertenece a la fase de ideación y conceptos, donde una idea se descarta en días, y no a la fase de ingeniería, donde descartarla cuesta un proyecto entero.
Decidir qué funciones merecen automatizarse es una decisión de desarrollo de producto que se toma en diseño e innovación, antes de que exista un pliego de sensores. Cuando se decide mal, el error no aparece en la prueba, aparece con el firmware escrito y el molde mecanizado.
IDEACIÓN Y CONCEPTOS
¿Vas a automatizar una función sin saber si el usuario la va a usar? Conoce nuestro servicio de ideación y conceptos
Qué es la técnica Mago de Oz y qué parte de la prueba es real
En una prueba Mago de Oz la interfaz es real y el mecanismo es falso. El usuario pulsa, habla o deposita una pieza, y al otro lado un operador que no ve hace el trabajo que haría la máquina, con el mismo resultado y en un tiempo parecido.
El nombre viene de la escena en la que el mago resulta ser un hombre accionando palancas detrás de una cortina. La cortina es lo único que separa una prueba válida de un engaño inútil, porque en cuanto el usuario intuye que hay alguien decidiendo por él, deja de comportarse como un usuario y empieza a comportarse como un examinador.
Mago de Oz y Concierge, la diferencia está en lo que sabe el usuario
La diferencia entre el Mago de Oz y el Concierge es el conocimiento del usuario, no el montaje. En el Mago de Oz cree que interactúa con un producto automático, mientras que en el Concierge sabe que el servicio lo presta una persona.
Esa distinción cambia lo que puedes leer de cada prueba. El Mago de Oz da una reacción espontánea, porque nadie perdona a una máquina lo que perdona a un operario que está haciendo un esfuerzo. El Concierge, en cambio, permite preguntar en mitad de la sesión y explorar varias versiones de la función en una sola visita, a cambio de perder esa reacción limpia.
Para una función que el usuario va a usar sin asistencia, el Mago de Oz es el montaje adecuado. Para una función cuyo criterio no está definido, el Concierge rinde más, porque lo que buscas no es una nota, es la regla que aplicaría un experto.
Qué se simula y qué tiene que ser auténtico en una prueba Mago de Oz
Lo único que se simula es el mecanismo. Todo lo que el usuario percibe tiene que ser auténtico, porque de ahí sale el dato, y eso incluye la interfaz, el formato de la respuesta, el retardo y los errores.
El retardo es el parámetro que más pruebas arruina. Un operador oculto responde en el momento, sin la latencia de una captura, un cálculo y una decisión, así que entrega una experiencia que la tecnología real no va a poder dar. La regla que sostiene la prueba es acotar al simulador al rendimiento que el sistema definitivo sí podría alcanzar, lo que obliga a estimar antes el tiempo de respuesta plausible, que es el trabajo previo de selección y testeo de tecnologías.
Lo mismo vale para los fallos. Un sistema automático se equivoca, y un operador oculto que acierta siempre está vendiendo una fiabilidad inexistente. Introducir en el guion una proporción de errores coherente con la tecnología candidata convierte la sesión en una prueba de la función y no en una demostración comercial.
La validez de una prueba Mago de Oz depende de que el simulador esté limitado a lo que la tecnología real podría hacer. Un operador oculto más rápido y más preciso que el sistema definitivo no valida la función, mide el entusiasmo del usuario ante una capacidad que nadie va a entregar.
Qué decisiones cierra la técnica Mago de Oz y cuáles deja abiertas
La técnica Mago de Oz cierra preguntas de valor y de uso, y no cierra ninguna pregunta de viabilidad técnica. Confundir los dos grupos es el origen de los proyectos que automatizan con brillantez una función que nadie usa.
Valor de la función, frecuencia de uso y disposición a pagar
La prueba contesta si el usuario usa la función cuando la tiene delante, con qué frecuencia la usaría y en qué orden espera que ocurran los pasos. Son respuestas de comportamiento observado y no de opinión declarada, y por eso valen.
La norma ISO 9241-210 fija los requisitos y recomendaciones del diseño centrado en las personas para sistemas interactivos, y uno de sus principios es que el diseño se refine mediante evaluación con usuarios y no solo con el criterio del equipo de desarrollo. El Mago de Oz es una forma económica de aplicar ese principio cuando el sistema todavía no se puede construir, y encaja con el resto de estudios de usuario que preceden a una decisión de alcance.
También informa sobre el precio, aunque con cuidado. Una función que el usuario reclama cuando se la quitas tiene valor demostrado, y una que hay que recordarle que existe no lo tiene, independientemente de lo que haya respondido en un cuestionario. En las entrevistas en profundidad para validar una solución de aspiración se ve el mismo principio aplicado a una fase previa, cuando lo que se contrasta es la necesidad y no todavía la función.
Viabilidad técnica, tiempo de ciclo y precisión, lo que la simulación no mide
Ninguna conclusión técnica sobre el sistema automático sale de una prueba Mago de Oz, porque en la prueba no hay sistema. El operador oculto demuestra que la función es útil, nunca que sea construible.
Las preguntas que quedan intactas son las que deciden el presupuesto. Si un sensor detecta el defecto con la pieza en movimiento, si el conjunto aguanta el tiempo de ciclo de la línea, cuántos falsos positivos va a generar y cuánto cuesta la electrónica necesaria son asuntos de análisis de viabilidad técnica y de ensayo, y se responden con el sensor y la pieza reales delante. El sistema de visión artificial para clasificar albaranes de forma automática es un ejemplo de ese segundo tramo, el que empieza cuando ya sabes que la función merece existir.
La tabla separa unas preguntas de otras, con lo que hace falta para cerrar cada una y el precio de cerrarla antes de tiempo.
| Pregunta del proyecto | Qué contesta la prueba Mago de Oz | Qué hace falta para cerrarla | Qué pasa si la cierras con el Mago de Oz |
|---|---|---|---|
| ¿Usa el operario la función cuando la tiene delante? | La contesta por completo | Nada más, basta la interfaz real | Nada, es su terreno natural |
| ¿En qué orden espera que ocurran los pasos? | La contesta observando la sesión | Nada más si el guion no dirige | Nada, siempre que no hayas sugerido el orden |
| ¿Detecta el sensor el defecto con la pieza en movimiento? | No la contesta | Ensayo con el sensor y la pieza reales | Escribes un pliego sobre una capacidad sin comprobar |
| ¿Aguanta el tiempo de ciclo de la línea? | No la contesta | Banco con el accionamiento definitivo | Prometes una cadencia que el equipo no da |
| ¿Cuántos falsos positivos va a dar? | No la contesta | Serie con piezas conformes y no conformes | Dimensionas el puesto de repaso a ciegas |
| ¿Cuánto cuesta la electrónica que hace falta? | Da una pista del alcance, no un coste | Arquitectura y lista de materiales | Presupuestas sobre una función sin definir |
Las dos primeras filas se resuelven en una tarde con una cortina y un guion. Las cuatro siguientes necesitan material, instrumentación y tiempo de laboratorio, y ese reparto es justamente el que convierte al Mago de Oz en una herramienta rentable.
CUÉNTANOS TU CASO
¿No sabes si la función que quieres automatizar merece la electrónica que pide? Envíanos la función y el perfil de quien la va a manejar y te proponemos el montaje de la prueba y el guion del operador oculto
El coste de confundir la deseabilidad con la viabilidad
El error no se paga en la prueba, se paga en la siguiente fase. Una prueba Mago de Oz bien montada y mal interpretada autoriza un desarrollo que la tecnología no sostiene, o mata una función que habría funcionado.
Automatizar una función que el usuario no llega a usar
El falso positivo más caro es la función que encanta en la sesión y se abandona en planta. Ocurre cuando el operador oculto ha resuelto sin esfuerzo aparente un caso que el sistema real resuelve mal, y el usuario ha valorado un rendimiento imaginario.
La factura llega en la cuenta de la automatización, la partida con el ciclo más largo y la menos reversible del proyecto. Un sensor elegido, un bastidor diseñado a su alrededor y un software escrito contra su salida forman un bloque difícil de deshacer, y rehacerlo obliga a volver a la arquitectura, no a ajustar un parámetro.
Descartar una función buena por una simulación mal montada
El falso negativo es más silencioso y por eso más frecuente. La función se descarta porque la sesión salió mal, y la sesión salió mal por el montaje, no por la idea.
Las causas habituales se identifican de antemano. Un operador oculto con un criterio distinto en cada repetición, un formato de respuesta que no se entiende, una cortina que se nota, un guion que pregunta en lugar de observar, y sale un rechazo que habla del experimento y no del producto. Antes de enterrar una función conviene comprobar si el montaje la representaba, igual que antes de descartar un diseño por un ensayo conviene comprobar si rompió la pieza o rompió el proceso que la fabricó, un problema que el prototipo de baja fidelidad plantea en el terreno físico.
Un rechazo en una prueba Mago de Oz solo es un dato sobre la función si el simulador aplicó el mismo criterio en todas las repeticiones. Si el operador oculto improvisó, lo que has medido es la variabilidad del operador y no la utilidad de la función.
Cómo se monta una prueba Mago de Oz que sirva para decidir
Una prueba Mago de Oz es un experimento, y como experimento necesita hipótesis, criterio y registro. Sin esas tres cosas es una demostración con público.
Guion, operador oculto y registro de lo que ocurre
El guion fija qué hace el operador oculto ante cada entrada posible, para que la respuesta del simulador sea reproducible. Es el algoritmo que todavía no existe, escrito en lenguaje natural, y redactarlo revela antes que cualquier ensayo las decisiones que el sistema automático tendrá que tomar.
La especificación técnica ISO/TS 20282-2 define un método de ensayo con usuarios para medir la usabilidad de productos de consumo en términos de eficacia, eficiencia y satisfacción. Está pensada para una medición final y no para una prueba exploratoria como esta, pero señala bien qué merece registrarse, tareas completadas, tiempos, errores y el punto exacto en que el usuario se detiene. Lo que no se registra en el momento no se recupera después, porque la sesión no se repite en las mismas condiciones.
Queda la parte del consentimiento, que no es un trámite. Al participante se le dice que está probando un prototipo y que la sesión se registra, y lo único que se reserva es qué parte del sistema está automatizada. Al terminar se le explica el montaje completo, que es lo que distingue un experimento de un engaño y además permite preguntarle qué habría hecho distinto de saberlo.
Del Mago de Oz a la prueba de la automatización real
El resultado de una prueba Mago de Oz es una especificación, no un veredicto. Lo que entrega es la función que merece automatizarse, el criterio que debe aplicar y el nivel de error que el usuario tolera, y eso es exactamente la entrada de la fase siguiente.
Con ese pliego, la prueba de concepto deja de ser una exploración abierta y pasa a ser una verificación acotada, porque ya sabes qué tiene que demostrar el sensor y con qué margen. Es el momento en que la tolerancia al error registrada en la sesión se traduce en un umbral medible y la lista de casos del guion se traduce en una serie de ensayo.
El orden importa más que la velocidad. Un Mago de Oz de una semana que fija el criterio ahorra meses de desarrollo contra el criterio equivocado, y saltárselo no adelanta el proyecto, adelanta el gasto.
La técnica Mago de Oz no sustituye al ensayo, decide si merece la pena hacerlo
La técnica Mago de Oz separa dos preguntas que los proyectos tienden a resolver juntas, si la función aporta valor y si la función se puede construir. La primera se contesta con una cortina y un guion, y la segunda solo con el sensor, la pieza y el instrumento delante.
Puestas en ese orden, cada fase paga lo que cuesta. La sesión descarta ideas por el precio de una mañana y deja escrito el criterio con el que juzgar la tecnología, y el ensayo verifica una capacidad concreta en lugar de explorar un terreno sin límites.
Si tienes una función que piensas automatizar y todavía no sabes si el usuario la va a usar, envía la descripción de la función, el perfil de quien la va a manejar y la tecnología que tienes en mente, y recibirás el montaje de la prueba, el guion del operador oculto y los ensayos que harían falta después para confirmar que esa tecnología llega. Habla con el equipo de desarrollo de producto antes de redactar el pliego de sensores, no después.
Preguntas frecuentes
¿Es legítimo que el usuario no sepa que detrás hay una persona?
Es legítimo si hay consentimiento informado y explicación final. Al participante se le dice antes de empezar que va a probar un prototipo y que la sesión se registra, de modo que sabe que participa en un experimento, y lo único que se reserva es qué parte del sistema funciona sola. Al terminar se le describe el montaje completo y se le pregunta qué habría hecho distinto, que suele ser el dato más útil de la sesión. Lo que no es admisible es usar el montaje en una demostración comercial o en una presentación a inversores presentándolo como un producto terminado.
¿Sirve la técnica Mago de Oz en un producto industrial o solo en software?
Sirve en cualquier producto cuya función principal sea una decisión automática, y en la industria eso abarca inspección, clasificación, dosificación y arranque o parada por condición. El montaje físico es distinto, porque hay que ocultar al operador y no solo el código, pero la lógica es la misma, el usuario deposita la pieza y recibe un veredicto que ha emitido una persona. En productos donde la función principal es mecánica y no una decisión, la técnica aporta poco y el camino es un prototipo mínimo viable que reproduzca el comportamiento real.
¿Qué factores determinan el coste de una prueba Mago de Oz?
El coste lo determinan el número de sesiones, la fidelidad de la interfaz que ve el usuario y el esfuerzo de ocultar el mecanismo. Una prueba con una tableta y un operador en la sala contigua es barata, y una que necesita carcasa creíble, espacio preparado y varios perfiles de usuario convocados sube de orden. El capítulo que sorprende no es la maqueta, es el reclutamiento, porque los participantes tienen que ser quienes van a usar el producto y no personas disponibles. Frente al coste de automatizar una función equivocada, la prueba es una fracción pequeña del presupuesto.
¿Cuántos usuarios hacen falta para que la prueba sirva?
Para decidir si una función aporta valor bastan pocos participantes, porque el dato que buscas es cualitativo y los patrones de uso se repiten pronto. Lo que no se puede con ese tamaño es estimar porcentajes de aceptación ni proyectar demanda, que piden una muestra planificada con otro método. La regla práctica es parar cuando dos sesiones consecutivas no aportan ningún comportamiento nuevo, y combinar la prueba con entrevistas en profundidad cuando interese entender el motivo detrás de lo observado.
¿Cuánto se tarda en pasar de un Mago de Oz a un prototipo con la automatización real?
El plazo habitual va de una a cuatro semanas según la tecnología implicada, con modalidad urgente de 24 a 72 horas para casos críticos. El reparto típico es corto en la traducción del guion a especificación, medio en el montaje del ensayo y variable en la obtención de las piezas representativas, que es lo que manda en el calendario. Envía la función y la tecnología candidata y recibirás el plan de ensayo con su plazo, además del criterio que tendrá que cumplir el sensor.
