Ein Team möchte einen Assistenten testen, der aus einer unstrukturierten Anfrage einen sinnvollen Plan erstellen kann. Die Entwicklung des zugrunde liegenden Systems kann Monate dauern, während eine Folie mit einer beispielhaften Antwort wenig darüber verrät, was Nutzer tatsächlich fragen würden. Wizard-of-Oz-Tests bieten hier einen Zwischenschritt: Eine Person liefert einige oder alle Antworten über eine Oberfläche, die diese als Verhalten des Systems darstellt.
Bei dieser Methode simuliert ein menschlicher Operator – manchmal als „Wizard“ oder „Zauberer“ bezeichnet – während der Untersuchung eine bestimmte Funktion. So lässt sich eine Interaktion bereits erkunden, bevor die Automatisierung steht: etwa was Nutzer anfragen, was sie als Antwort erwarten und wie sie reagieren, wenn etwas schiefgeht. Die Leistung des Menschen muss dabei klar von dem getrennt werden, was die spätere Technologie tatsächlich leisten kann.
Definieren, welches System der Operator darstellen darf
Stellen wir uns einen fiktiven Assistenten für die Essensplanung vor. Eine Testperson fragt nach Gerichten, die ins Budget passen, Reste verwerten und eine Allergie im Haushalt berücksichtigen. Eine erfahrene Research-Fachkraft könnte eine extrem durchdachte Antwort formulieren – das sagt jedoch wenig über ein künftiges System aus, solange in der Studie nicht festgelegt ist, welche Informationen und Funktionen diesem überhaupt zur Verfügung stehen.
Legen Sie die Spielregeln vor den Sessions fest. Entscheiden Sie, welche Eingaben der Assistent akzeptiert, auf welche Daten er zugreifen kann, welche Antwortzeit er ungefähr nachahmen soll und wie er mit nicht unterstützten Anfragen umgeht. Bereiten Sie Beispiele vor und proben Sie die Übergabe zwischen der Nutzeroberfläche und dem Operator.
Der Leitfaden der Nielsen Norman Group zur Wizard-of-Oz-Methode beschreibt, wie eine von Menschen gesteuerte Simulation genutzt werden kann, um eine Interaction Experience zu untersuchen, ohne direkt alle Funktionen ausprogrammieren zu müssen. Die Simulation liefert die wertvollsten Erkenntnisse, wenn das dargestellte Verhalten präzise genug definiert ist, damit das Team die Ergebnisse sauber einordnen kann.
Das Gesamterlebnis testen – nicht den Einfallsreichtum des Operators
Geben Sie den Teilnehmenden realistische Aufgabenszenarien und lassen Sie Raum für Anfragen, mit denen das Team nicht gerechnet hat. Protokollieren Sie sowohl diese Anfragen als auch die gegebenen Antworten. Wenn der Operator über die vereinbarten Regeln hinaus improvisiert, halten Sie diese Abweichung fest, anstatt sie stillschweigend als normales Systemverhalten zu werten.
Das Beispiel mit der Essensplanung könnte zeigen, dass Nutzer eine einzelne Zutat ändern möchten, ohne gleich die ganze Woche neu zu planen. Das ist eine wertvolle Interaktionsanforderung. Doch die Zufriedenheit mit einem sorgfältig ausgearbeiteten Plan beweist noch nicht, dass ein automatisiertes Modell ebenso treffende Empfehlungen generieren kann.
Bauen Sie plausible Einschränkungen ein, wo sie für die Fragestellung relevant sind. Wer nur ideale Antworten testet, übersieht schnell den Bedarf an Korrekturen, Absagen, Rückfragen oder Fehlerbehebungen. In einem separaten Prototyp-Test lässt sich dann untersuchen, wie Nutzer mit solchen Zuständen umgehen, sobald das Team sie ausgearbeitet hat.
Einwilligung und Debriefing vor der Simulation planen
Teilnehmende wissen oft nicht genau, welche Teile des Prototyps von einem Menschen gesteuert werden. Die Aufklärung darüber ist daher eine grundlegende Entscheidung im Research-Design. Setzen Sie auf Transparenz über die Simulation, solange die Forschungsfrage dadurch nicht verfälscht wird, und vermeiden Sie unnötige Geheimniskrämerei, die nur dazu dient, das Erlebnis überzeugender wirken zu lassen.
Werden Informationen vorenthalten, braucht der Forschungsplan eine angemessene ethische Prüfung, klare Grenzen und ein sorgfältiges Debriefing. Die Teilnehmenden sollten verstehen, was passiert ist und wie ihre Daten verarbeitet werden. Eine informierte Einwilligung wird nicht dadurch erfüllt, dass man die Auflösung am Ende als unterhaltsame Überraschung verpackt.
Halten Sie den Ablauf sicher im Rahmen der Forschung. Im Beispiel der Essensplanung sollten generierte Pläne nicht als geprüfte Allergieberatung missverstanden werden, und niemand sollte so handeln, als sei der simulierte Dienst bereits verlässlich. Die Studie kann Erwartungen anhand passender Szenarien untersuchen, ohne dass sich jemand auf eine ungeprüfte Empfehlung verlassen muss.
Erkenntnisse in die echte Entwicklung übertragen
Trennen Sie Erkenntnisse über Anfragen, das Verständnis der Benutzeroberfläche und die Fehlerbehebung klar von jenen, die von der reinen Antwortqualität abhängen. Dokumentieren Sie die Beteiligung des Operators, Verzögerungen und Abweichungen, damit spätere Leser genau nachvollziehen können, was die Teilnehmenden tatsächlich erlebt haben.
Die nächste Research-Runde sollte die tatsächliche technische Lösung prüfen, sobald sie einsatzbereit ist. Nutzer stellen möglicherweise dieselben Fragen, reagieren aber ganz anders auf echte Ladezeiten, uneinheitliche Antworten oder Einschränkungen bei den verfügbaren Daten. Wizard-of-Oz-Tests helfen dem Team herauszufinden, was es sich zu bauen und zu testen lohnt – sie können das System, das den Operator später ablöst, jedoch nicht vorab zertifizieren.