Wizard-of-Oz-Test

Ein Wizard-of-Oz-Test ist ein Prototyp-Test, bei dem eine Funktion für die Testperson echt wirkt, während im Hintergrund ein Mensch sie von Hand ausführt. Die Testperson tippt in ein Chatfenster, spricht mit einem Gerät oder bekommt Empfehlungen, und jemand aus dem Team erzeugt die Antworten. Der Name spielt auf den Zauberer aus „Der Zauberer von Oz“ an, hinter dessen großem Auftritt ein gewöhnlicher Mensch steckt, der alles selbst bewegt. Mit dem Test lässt sich klären, ob eine aufwendige Funktion gebraucht wird und wie Menschen mit ihr umgehen, bevor jemand sie programmiert.

Wo der Test im Prozess steht

Der Wizard-of-Oz-Test kommt ins Spiel, wenn eine Idee steht und die Frage nach ihrem Nutzen an einer Funktion hängt, deren Bau teuer wäre. Oft taucht diese Frage in einem Annahmen-Check als die riskanteste Annahme auf: „Menschen würden diesem Assistenten ihre Fragen stellen.“ Manchmal gibt es vorher schon ein Mock-up der Oberfläche, und der Wizard ergänzt nun das Verhalten dahinter.

Danach folgt die Auswertung wie bei jeder Nutzertest-Runde. Zusätzlich hat das Team eine Mitschrift aller Eingaben, die echte Menschen an das vermeintliche System gerichtet haben.

Welche Funktionen sich simulieren lassen

Text und Chat. Eine Person aus dem Team sitzt in einem anderen Raum und tippt die Antworten. Die Testperson sieht nur das Chatfenster.

Sprache. Antworten kommen über einen Lautsprecher oder eine Sprachausgabe, die der Wizard mit vorbereiteten Sätzen füttert.

Empfehlungen und Auswertungen. Die Testperson gibt Daten ein, und nach kurzer Zeit erscheint ein „berechnetes“ Ergebnis. Tatsächlich wählt der Wizard aus einer vorbereiteten Liste.

Geräte und Räume. Licht, Musik oder eine Anzeige reagieren scheinbar von selbst auf die Testperson. Ein Mensch schaltet sie per Fernbedienung oder Laptop.

Neben der verdeckten Form gibt es eine offene. Die Testperson weiß dann, dass ein Mensch die Antworten gibt, und erlebt trotzdem den Ablauf. Diese Form ist die richtige Wahl, wenn eine Täuschung im Kontext nicht in Ordnung wäre. Über den Bedarf erfahrt ihr dabei viel.

Varianten

Online ist der Aufbau oft einfacher als im Raum. Die Testperson öffnet ein Chatfenster oder eine geteilte Oberfläche, der Wizard sitzt an einem anderen Ort, und das Team beobachtet über die Videokonferenz mit ausgeschalteter Kamera.

In großen Gruppen baut jede Kleingruppe ihr eigenes Setup. Die Rollen wechseln reihum: Fassade betreuen, Wizard spielen, beobachten. Wer einmal als Wizard gearbeitet hat, weiß danach sehr genau, wie viele Entscheidungen eine echte Funktion treffen müsste.

Mit wenig Zeit reicht ein Messenger. Das Team legt ein eigenes Konto an, gibt ihm einen Namen und ein Bild und lässt Testpersonen Fragen stellen.

Ein Beispiel

Angenommen, eine Hochschulverwaltung überlegt, einen Chat-Assistenten für Fragen zur Prüfungsanmeldung anzubieten. Bevor jemand Geld in die Entwicklung steckt, will das Team wissen, ob Studierende ihn nutzen würden und was sie fragen.

Eine Person aus dem Team sitzt mit dem Merkblatt zur Prüfungsordnung im Nebenraum und beantwortet die Fragen im Chat. Drei Studierende testen nacheinander. Sie schreiben in kurzen Bruchstücken, oft ohne Satzzeichen. Die meisten Fragen drehen sich um Fristen und um Sonderfälle wie Krankheit, die auf dem Merkblatt nur am Rand vorkommen. Alle erwarten nach der Antwort einen direkten Link zum Formular. Und zwei von drei fragen irgendwann, ob sie auch mit einem Menschen sprechen können.

Das Team weiß danach, welche Fragen der Assistent sicher beantworten muss, in welchem Ton und an welcher Stelle eine Übergabe an das Prüfungsamt nötig ist.

Woran du ein gutes Ergebnis erkennst

Die Testpersonen verhalten sich so, wie sie es mit einem echten System tun würden. Das Team hat eine vollständige Mitschrift aller Eingaben und Antworten. Und es kann die Ausgangsfrage beantworten: Wird die Funktion genutzt, und wofür? Ein klares Nein ist dabei ein wertvolles Ergebnis. Es spart Wochen an Entwicklungszeit.

Was du danach mit dem Ergebnis machst

Die Mitschrift ist Rohmaterial für die Entwicklung. Sie zeigt, wie Menschen formulieren, welche Fragen häufig sind und wo der Wizard improvisieren musste. Sortiert die Eingaben nach Themen, etwa mit Affinity Diagramming, und haltet fest, was das System können muss. Wenn die Entscheidung zum Bau fällt, lässt sich der Test in Stufen wiederholen: Ein Teil der Antworten kommt schon automatisch, den Rest übernimmt weiterhin der Wizard. Für Dienstleistungen, bei denen am Ende doch ein Mensch die Arbeit macht, lohnt sich als Nächstes ein Rollenspiel-Test des ganzen Ablaufs.

Quellen

• Wizard of Oz prototype | Design Thinking Methods Catalogue
• Wizard of Oz Prototyping: What It Is, How & Why It's Done