Die Methode zielt auf das Testen von computergestützten Funktionen und Benutzeroberflächen ab und kann dementsprechend sehr gut bei der Entwicklung von Assistenzsystemen angewendet werden. Es ist ein Test, bei dem später automatisch ablaufende Funktionen, vor deren Implementierung, von Menschen (Wizards) simuliert werden ohne das der Testnutzer davon weiß. Dadurch kann die zu erwartende Reaktion von Nutzern und die Interaktion mit dem System geprüft werden. Dem Nutzer wird im Idealfall nicht gesagt, dass es sich (in Teilen) um ein simuliertes System handelt.
Verortung im Living Lab: Für die Anwendung der Methode muss ein Konzept und ein erster Prototyp vorliegen, in dessen Rahmen die nachgestellten Funktionen eingebettet und so ggf. iterativ weiterentwickelt werden können. Dementsprechend eignet sich die Methode in den Phasen der Prototypenentwicklung und im Feldtest.
Forschungsumgebung: In Bezug auf die Umgebung ist die Methode relativ unabhängig. In Abhängigkeit von Anforderungen, die sich aus der Steuerung durch den Wizard ergeben (z.B. muss er innerhalb einer bestimmten Reichweite sein, den Nutzer sehen können, o.ä.), können Laborräume benötigt werden; die Durchführung in der realen Umgebung ist ebenfalls denkbar. Welche dieser Umgebungen bessere Ergebnisse liefert, hängt von der Fragestellung ab.
Nutzer-/Stakeholderintegration: Die Nutzer, die bei dieser Methode einbezogen werden, sollten der Zielgruppe des zu testenden Systems entsprechen. Je nach Fragestellung können vorab Schulungen zu dem System durchgeführt oder die Nutzer entsprechend ihrer Kenntnisse ausgewählt werden (z.B., wenn bei einer späteren Nutzung von Vorwissen auszugehen ist). Soll hingegen die intuitive Bedienung getestet werden, wird kein Vorwissen verlangt und Nutzer können ohne Weiteres an dem Experiment teilnehmen.
Aufwand: Der Aufwand für diese Methode ist hoch und sie kann nur von Fachleuten mit technischem Know-How für die Programmierung sowie entsprechenden technischen Geräten durchgeführt werden. Bei dem zeitlichen Aufwand muss zwischen der Vorbereitung und der Durchführung differenziert werden. Da während der Vorbereitung ein Prototyp gebaut und die Schnittstellen für die Interaktion programmiert werden muss, kann diese sehr zeitintensiv sein. Der Aufwand für die eigentliche Durchführung der Methode ist abhängig von der Anzahl an Testnutzern. Als Richtwert können ca. 35-40 Probanden angesetzt werden (in Anlehnung an Ergebnisse einer Literaturanalyse von 54 Veröffentlichungen (Riek, 2012)). Wie lang das jeweilige Experiment dauert, ist von der Fragestellung und der zu testenden Funktion abhängig. Das benötigte Know-How für die Durchführung der Methode ist, nachdem die technische Vorbereitung abgeschlossen wurde, mittel. Die Durchführung fordert den Wizard jedoch in der Form, als dass er verschiedene Aufgaben gleichzeitig erfüllen muss (je nach simulierter Funktion). Hierfür können teilweise eine Schulung bzw. eine gewisse Übung nötig sein.
Für die Umsetzung in der Praxis bedarf es eines bzw. mehrerer Testnutzer. Der Prototyp muss zwei Benutzeroberflächen haben, eine für den Nutzer und einen für den Wizard, sowie einen Assistenten, der den Wizard unterstützt.
In vielen Anwendungen werden Nutzern Instruktionen bzw. Szenarios vorgegeben, die durchgespielt werden. Szenarien, die der Evaluation von Systemen dienen, sollten bereits gemeinsam mit den Nutzern entwickelt werden, um wichtige Nebenbedingungen nicht zu übersehen. Die Anweisungen sollten nicht zu detailliert sein, um die individuelle Umsetzung durch den Nutzer nicht einzuschränken.
Neben den Anweisungen sollten vorab Hypothesen, über das vermutlich zu beobachtende Verhalten des Nutzers sowie des Systems formuliert werden, die im Anschluss an das Experiment mit den tatsächlichen Beobachtungen verglichen werden können.
Zu Beginn des Experiments wird dem Nutzer in der Regel nicht gesagt, dass die Funktionen (teilweise) simuliert werden. Um bei der Wahrheit zu bleiben, können vage Informationen gegeben werden, deren offensichtliche Interpretation auf ein echtes System hindeuten.
Auf Basis der ausgehändigten Anweisung interagiert der Nutzer mit dem System. Das System erwidert, in Teilen durch den Wizard unterstützt. Diese Interaktion wird aufgezeichnet, protokolliert und im Anschluss ausgewertet.
Für die Konzeption und Dokumentation der Methode entwickelte Rieck (2012) einen Leitfaden. Die Methode kann innerhalb des Innovationsprozesses mehrmals eingesetzt werden, um den Prototypen iterativ weiterzuentwickeln.
Riek (2012) fasst einige Kritikpunkte und Einschränkungen für die Wizard of Oz Methode zusammen. Beispielsweise sollten die vom Wizard ausgeübten Funktionen gut durch einen Menschen ausführbar sein (z.B. kognitive Fähigkeiten), jedoch auch zu einem späteren Zeitpunkt durch Technik ersetzt werden können. Die daraus resultierende Komplexität des Systems (z.B. Verwendung kognitiver Funktionen) sollte auf ein Minimum reduziert werden, indem die Anwendungen eingeschränkt werden (z.B. Beschränkung der Sprachsteuerung auf einen definierten Wortschatz).
Insgesamt ist die Methode recht aufwändig. Aus diesem Grund sollte im Vorfeld eine Kosten-Nutzen-Analyse durchgeführt werden.
Allgemeine Kritik bezieht sich auf ethische Bedenken, da Nutzer sich im Nachhinein über ihre Leichtgläubigkeit schämen können. Doch genau diese Illusion von Seiten des Nutzers, dass er mit einem technischen System interagiert, ist grundlegend, um seine Reaktion auf das technische System zu untersuchen. Bei Assistenzsystemen könnten Effekte wie z.B. sozial erwünschtes oder erwartetes Verhalten andernfalls die die Verhaltensweise überdecken.
Die Methode eignet sich in den Phasen der Prototypenentwicklung und im Feldtest um die erwartete Reaktion von Nutzern und die Interaktion mit dem entwickelten Produkt oder Dienstleistungssystem zu prüfen. Da kein fester Rahmen vorgegeben ist, wird ein Bias durch Fragestellungen vermieden und auch Aspekte, die dem Entwickler im Vorhinein nicht bewusst waren (und entsprechend nicht abgefragt worden wären) können vom Nutzer aufgedeckt werden. Ein weiterer Vorteil ist die Realitätsnähe und dennoch Kontrollier- und Standardisierbarkeit.
Anastasiou (2012) beschreibt die Anwendung der Methode im Bereich von Ambient Assisted Living. In dem Bremen Ambient Assisted Living Lab (BAALL) des DFKI wurde ein intelligenter Rollstuhl-Roboter getestet, der über Sprache und Gesten gesteuert werden kann. Um die Steuerung angelehnt an Nutzerbedürfnisse weiterzuentwickeln, wurde untersucht, auf welche Weise Nutzer Befehle formulieren oder ausführen. Hierfür wurden ca. 20-minütige Experimente unter Anwendung der Wizard of Oz Methode durchgeführt (ohne, dass die Teilnehmenden über die Simulation im Bilde gewesen sind).
Der Nutzer bekommt für die Steuerung ein Bluetooth-Mikrofon-Headset, welches die Aufforderungen an den Wizard im Nebenraum überträgt. Per Videoübertragung sieht der Wizard auch die Gesten und was insgesamt in dem Lab geschieht. Die bereits integrierte Sprachsteuerung des Robotor-Rollstuhls wurde ausgeschaltet, da diese, anders als der Wizard, beispielsweise grammatikalischen Restriktionen unterworfen ist. Der Nutzer erhält von einem Assistenten, der mit im Raum ist, Anweisungen (InSitu Tasks), die er ausführen muss. Anschließend werden retrospektive Think-Aloud Protokolle mit den Nutzern erstellt.
Die bereits integrierte Sprachsteuerung des Robotor-Rollstuhls wurde ausgeschaltet, da diese, anders als der Wizards, beispielsweise grammatikalische Restriktionen aufweist. Der Nutzer erhält von einem Assistent der mit im Raum ist, Anweisungen (InSitu Tasks), die er ausführen muss. Anschließend werden retrospektive Think-Aloud Protokolle mit den Nutzern erstellt. Als Nutzer wurden 20 männliche 26-jährige Studenten ausgewählt. Damit ihre Gesten nicht mit landesuntypischen Gesten überprägt werden, wurde darauf geachtet, dass sie nicht für mehrere Jahre im Ausland lebten. In nachfolgenden Experimenten sollte dieser Parameter variiert werden und auch Senioren, die Hauptzielgruppe von AAL, einbezogen werden.
Some features of this website need your consent to remember who you are.