
Wizard of Oz Prototyp
Vorgespielte Magie
Was ist ein Wizard-of-Oz?
Mit dem „Wizard of Oz“ testen Entwicklungsteams, wie Nutzer mit einem System interagieren. Der Nutzer bedient dabei ein Interface. Die Reaktionen des Systems werden aber nicht maschinell, sondern durch einen Menschen ausgelöst. Dabei ist dem Nutzer unter Umständen nicht bewusst, dass er nicht mit einer intelligenten Software, sondern einem verborgenen Menschen interagiert.
Der Begriff hat seinen Ursprung in der Kindergeschichte „Der Zauberer von Oz“. In diesem Film treffen die Protagonisten auf einen vermeintlich mit Superkräften ausgestatteten Zauberer. Der Zauberer entpuppt sich letztlich als normaler Mensch, der seine Magie nur inszeniert.
Genau wie der Zauberer im Film spielt das Entwicklungsteam beim Bau und Test eines Wizard-of-Oz-Prototyp“ zentrale Funktionen nur vor.
Um die Wizard-of-Oz-Methode anzuwenden sind drei Elemente erforderlich: Ein Skript, dass vorgibt, was passieren soll, eine Person als Testnutzer und ein menschlicher Zauberer, der die Interaktion des Systems steuert.

Für welche Produkttypen und in welchen Phasen wird ein „Wizard of Oz“ eingesetzt?
Ein Wizard of Oz wird besonders häufig eingesetzt, um digitale Produkte mit komplexer nur aufwendig zu entwickelnder Logik zu testen. Gerade wenn Produkte und Geschäftsmodelle im Bereich künstlicher Intelligenz kreiert werden, eignen sich diese Prototypen hervorragend. Die Bandbreite reicht dabei von digitalen Assistenzsystemen und Chatbots bis hin zu komplexen Dienstleistungen bei denen ganze Prozessketten automatisiert werden.
Am häufigsten werden Wizard of Ozs in sehr frühen Entwicklungsphasen eingesetzt, wenn ein interdisziplinäres Team Ideen gerade erst entwickelt hat. Das Team testet dann, ob es überhaupt Bedarf für einen vermuteten Anwendungsfall für künstliche Intelligenz gibt.
Agile Entwicklungsteams setzen Wizard of Ozs aber auch in späteren Iterationen ein. Dabei wird die bestehende künstliche Intelligenz um weitere Funktionen oder Algorithmen erweitert. Im Nutzertest wird überprüft, ob sich das Nutzererlebnis durch weitere Funktionen so stark verbessert, dass ein zusätzlicher Aufwand gerechtfertigt ist.
Was sind die Stärken von Wizard-of-Oz-Prototyping?
Mit Prototypen der Kategorie Wizard of Oz können Teams Nutzerfeedback zu sehr aufwendigen Produktideen einholen. Mit einem guten Setup geben sich die Testuser der Illusion eines funktionierenden Echtsystems vollständig hin. Die Daten zur User Experience haben dadurch eine sehr hohe Qualität. Im Verhältnis zur Datenqualität sind Wizard of Oz sehr günstig zu entwickeln.
Wenn die Testergebnisse gut dokumentiert und aufbereitet werden, können die positiven Nutzerreaktionen auch gut genutzt werden, um das Potential einer Innovation gegenüber anderen Stakeholdern zu kommunizieren. Das Video eines begeisterten Testnutzers öffnet Budgettöpfe häufig leichter als ein Boxplot.
Einschätzung Wizard-of-Oz
Nutzendimensionen
Eignung für Use Cases
Physische Produkte
Digitale Produkte
Prozesse und Services
Geschäftsmodelle
Plattformen
Zeitaufwand
niedrig
Anspruch
mittel
Was sind die Schwächen von Wizard-of-Ozs?
Bei der Entwicklung von Wizard-of-Oz-Prototypen lernt das Team nur sehr wenig über die Machbarkeit und geschätzte Entwicklungskosten. Man kann verifizieren, wie ob ein intelligentes System Nutzer begeistern wird, aber nicht, ob dieses System jemals durch das Team fertiggestellt werden kann.
Wenn die Wizards zu schnell und schlecht gemacht sind, kann das im Test unfreiwillig komisch wirken und die Ergebnisse verfälschen.
Wie viel Aufwand ist notwendig, um einen "Wizard of Oz Prototype" zu erstellen?
In der Regel sind die Prototypen schnell und mit wenig Aufwand gemacht. Im einfachsten Fall chattet der Wizard mit dem Test User nur von einem anderen Raum aus. Es gibt aber auch Ausnahmen. In einem uns bekannten Falls inszenierten über zwanzig Mitarbeiter über mehrere Monate eine AI-gestützte Marktplattform für Industrieprodukte. Auf der einen Seite ging es dabei um ein Milliardenpotential. Auf der anderen Seite sollte erst geprüft werden, ob in einer sehr konservativen Branche genug Kunden gefunden werden können, die den Sprung vom Faxgeräte in die digitale Welt wagen.
Wer kann den Prototypen bauen?
Jeder!
Wer sollte an der "Wizard of Oz Methode" beteiligt werden?
Wir empfehlen einen People-Guy, der den Nutzer durch das System führt und mindestens eine Person, der als Wizard agiert. Ein größeres Team für eine bessere Inszenierung schadet nicht.
Welche Tools sind notwendig?
Um einen Wizard of Oz zu entwickeln sind keine speziellen Tools erforderlich. Häufig werden Monitore, Laptops und eine Internetverbindung genutzt. Systeme, für die schnelle Controller oder andere Eingabewerkzeuge zur Verfügung stehen eignen sich natürlich besser.
Wie setzt man "Wizard of Oz Prototyping" so ein, dass es den größten Nutzen bringt?
Die Ergebnisse sind besser, wenn Testnutzer und Zauberer räumlich getrennt sind. Wir empfehlen, dass sich Teams beim Prototyping auf die Kernfunktionen konzentrieren und andere Bestandteile der Interaktion bewusst weglassen.
Was sollte man vermeiden, wenn man mit Wizard-of-Ozs arbeitet?
Da fällt uns nicht viel ein, außer, dass sich die Testnutzer respektiert und nicht betrogen fühlen sollten.
Was wir noch los werden wollen:
Offiziell wurde der Wizard-of-Oz-Prototyp um 1980 herum in den USA erfunden. Wir haben mal wieder eine andere Meinung: Der Schachtürke von 1769 oder 1770 ist der erste Wizard of Oz: Ein Prototyp für moderne Schachcomputer. Eine der ersten Testnutzerinnen war Maria Theresia von Österreich.
Über den Autor
Daniel Herrmann
Ehemaliger Business-Kasper | Ausgewildertes Spielkind
Ich bin Game Thinker, Consultant und fanatischer Anhänger der Theorie Y. Meine Frau findet mich unfreiwillig komisch. Maximal 2 von 100 Menschen werden in Gesprächen mit mir dümmer.
Co-Founder von Monokel Consulting, Serious PlayScape und RokaEnergy.

Spielerisch die Welt retten
Warum brauchen wir gerade in Zeiten der digitalen Transformation Playful Organizations, Economies und Societies? Wie uns spielen hilft, humane und wettbewerbsfähige Unternehmen und Gesellschaften zu erschaffen.

TTT Johanna Rosenbusch
Johanna Rosenbusch und Daniel Herrmann über Gründen, Scheitern, Schuld und das Gute im „nicht ganz so guten.“

Wizard of Oz Prototype
Mit einem „Wizard of Oz Prototype“ spielen Entwicklungsteams funktionierende Systeme vor. Die Kernfunktionen werden dabei von Menschen ausgeführt.

parkinsonsche Gesetze angst vor der digitalen transformation
Schon einmal gefragt, warum die Mitglieder des Vorstands so ungern über die digitale Transformation reden, aber dafür umso lieber über das Buffett auf der Weihnachtsfeier? Oder in diesem Jahr darüber, ob die wegen Corona eingesparten Kosten für das Buffett an die Mitarbeiter ausgezahlt werden?
Der Verwaltungsforscher Cyril Northcote Parkinson hat schon vor Jahrzehnten festgestellt, dass Entscheidungsgremien länger über Trivialitäten reden, als über komplexe Sachverhalte. Je weniger finanzielle Auswirkungen ein Thema hat, desto länger dauert die Diskussion darüber.

minecraft-notch-innovation-wirtschaft
Am Morgen des 14. Juni 2014 feuerte Notch – geboren als sterblicher Markus Persson – einen folgenschweren Tweet ab. Ausgelaugt von Gegenwind auf den Social-Media-Kanälen und getrieben von den unerfüllbaren Erwartungen der Fans fragte er: „Wer will meine Firma kaufen?“ Jemand in Redwood griff zum Hörer und Microsoft kaufte Mohjang und den zugehörigen Spielehit Minecraft für 2,5 Milliarden Dollar.
Aber wie hat ein Indie-Game-Designer es ohne Investoren aus dem schwedischen Kaff Edsbyn in eine geschmacklose Villa in L.A. geschafft? Auf diese Villa hatten übrigens auch JAY-Z und Beyoncé ein Auge geworfen bis Notch das Ding für 80 Millionen Dollar geritzt hat. War es einfach Glück? Gottgegebenes Talent? Oder hat Notch – möglicherweise unbewusst – Regeln befolgt, die auch unter anderen Umständen Erfolg versprechen?

Finanzielle Vorteile von Prototyping: Scheitern ohne Untergang
Prototyping wird in der Kantine vor allem am Tisch der „Kreativen“ diskutiert. Aber was ist mit dem finanziellen Nutzen? Was hat das Controlling von Prototyping und Game Thinking?