Bild: Mit KI generiert
AR-Prototypen testen: Warum klassische Usability-Methoden an ihre Grenzen stoßen
AR-Prototypen testen: Warum klassische Usability-Methoden an ihre Grenzen stoßen
24 Juli, 2026
Einen AR-Prototypen in Figma oder Unity zu bauen ist lösbar. Ihn sinnvoll mit echten Nutzer:innen zu testen ist eine andere Aufgabe — und eine, für die die meisten Designteams keine spezifischen Methoden haben.
Das Problem ist strukturell: Klassische Usability-Testing-Methoden wurden für Bildschirm-Interfaces entwickelt. Sie gehen davon aus, dass die Testumgebung kontrollierbar ist, dass Interaktion auf einer definierten Fläche stattfindet und dass alle Testpersonen dieselbe Ausgangssituation haben. Keine dieser Annahmen trifft auf AR-Anwendungen zu.
In diesem Artikel erfährst du, wo klassische Testmethoden im AR-Kontext strukturell scheitern, welche Methoden sich für verschiedene Phasen der AR-Entwicklung eignen und was beim Testen von AR-Erlebnissen spezifisch gemessen werden sollte.
Warum klassisches Usability Testing für AR nicht ausreicht
Im klassischen Usability Test sitzt eine Testperson vor einem Bildschirm, führt definierte Aufgaben aus und spricht dabei laut, was sie denkt. Beobachter:innen sitzen dahinter oder schauen auf einen zweiten Monitor. Die Umgebung ist kontrolliert, das Interface stabil.
Im AR-Test ändert sich fast alles davon:
Die Umgebung ist Teil der Erfahrung. Ein AR-Interface, das in einem hellen Testraum gut funktioniert, kann in einer anderen Lichtsituation oder vor einer texturarmen Wand zusammenbrechen. Das Tracking verliert seinen Anker, virtuelle Objekte driften oder erscheinen nicht korrekt verankert. Diese Probleme entstehen nicht im Prototypen; sie entstehen im Zusammenspiel von Prototyp und physischer Umgebung.
Physische Bewegung verändert das Nutzungsverhalten grundlegend. Nutzer:innen bewegen sich im Raum, drehen sich, heben die Arme. Klassisches Think-Aloud wird schwieriger, weil kognitive und physische Aufmerksamkeit gleichzeitig gefordert werden. Eine Person, die durch einen AR-Raum navigiert, kann nicht in demselben Maß kommentieren wie eine Person, die auf einem Stuhl sitzt und tippt.
Die Testperson sieht etwas, das andere nicht sehen. Im klassischen Test sehen Beobachter:innen dasselbe wie die Testperson — entweder direkt am Bildschirm oder auf einem Spiegel-Monitor. Im AR-Test sieht die Testperson durch ein Gerät, das für alle anderen nicht transparent ist. Ohne zusätzliche Aufnahme des Gerätedisplays fehlt der Beobachtung die entscheidende Perspektive.
Diese drei strukturellen Unterschiede erfordern angepasste Methoden — keine grundlegend anderen, aber spezifisch angepasste.
Wizard of Oz: Die wertvollste Low-Fi-Methode für AR
Der Wizard-of-Oz-Ansatz stammt aus dem Bereich der frühen HCI-Forschung und beschreibt eine Testsituation, in der eine versteckte Person (der „Wizard") in Echtzeit Systemreaktionen simuliert, die die Testperson für automatisch hält. Im AR-Kontext ist diese Methode besonders wertvoll, weil sie aufwändige technische Implementierungen in frühen Phasen ersetzt.
Ein konkretes Beispiel: Statt einen vollständig entwickelten AR-Prototypen zu bauen, der auf Gesten reagiert und Objekte im Raum verankert, kann eine Facilitator:in aus einem Nebenraum Slideshow-Elemente steuern, die auf dem Gerät der Testperson erscheinen — synchronisiert mit den Aktionen der Testperson. Die Testperson nimmt eine AR-Erfahrung wahr, der Prototyp ist aber ein kontrolliertes manuelles System.
Was Wizard of Oz für AR in frühen Phasen leistet:
- Konzeptionelle Entscheidungen können getestet werden, bevor technische Infrastruktur existiert
- Interaktionsmomente und Informationsarchitektur werden sichtbar, ohne vollständige Implementierung
- Das Feedback fokussiert auf die Designidee, nicht auf technische Artefakte des Prototyps
Die Grenze: Wizard-of-Oz-Tests bilden physikalische Verhaltensweisen des Systems nicht ab. Tracking-Fehler, Beleuchtungsprobleme und räumliche Verankerung können in dieser Methode nicht untersucht werden.
Lab vs. Field: Wann wo getestet werden sollte
Die Entscheidung zwischen Labortests und Feldtests ist im AR-Kontext wichtiger als bei Bildschirm-Interfaces, weil die Testumgebung selbst ein Einflussfaktor auf das Testergebnis ist.
Labortest eignet sich für frühe Phasen, wenn konzeptionelle Fragen im Vordergrund stehen: Verstehen Nutzer:innen, was das Interface kommuniziert? Sind Interaktionsmuster intuitiv? Ist die Informationshierarchie in der Raumansicht nachvollziehbar? Für diese Fragen ist eine kontrollierte Umgebung vorteilhaft, weil sie Störvariablen reduziert und Aufgaben vergleichbar macht.
Feldtest ist notwendig, sobald die Frage lautet: Funktioniert das AR-Interface unter realen Bedingungen? Reale Lichtverhältnisse, wechselnde Umgebungsgeräusche, Bewegungsfreiheit und unvorhersehbare räumliche Situationen können nur im Feld untersucht werden. Eine AR-Anwendung für den Einzelhandel muss in einem echten Laden getestet werden, nicht in einem Testraum mit weißen Wänden.
Ein Ansatz, der beiden Anforderungen Rechnung trägt, ist die kontextuelle Untersuchung: Eine Beobachter:in begleitet die Testperson in die reale Nutzungssituation, dokumentiert Verhalten und stellt Fragen direkt im Kontext. Diese Methode, bekannt aus dem Usability Engineering, ist für AR besonders wirkungsvoll, weil sie die Trennung zwischen Testsituation und Nutzungssituation aufhebt.
Was im AR-Test spezifisch gemessen werden sollte
Neben klassischen Usability-Metriken wie Task Completion Rate und Time-on-Task gibt es AR-spezifische Dimensionen, die im Test aktiv beobachtet und dokumentiert werden sollten:
Räumliche Orientierung. Verstehen Nutzer:innen, wo sich virtuelle Objekte im Raum befinden? Können sie AR-Elemente, die sich außerhalb des aktuellen Sichtfelds befinden, wiederfinden? Diese Dimension ist für AR-Interfaces ohne klassische Navigation besonders relevant.
Tracking-Stabilität aus Nutzungsperspektive. Nehmen Nutzer:innen Tracking-Fehler wahr? Wie reagieren sie, wenn ein virtuelles Objekt seinen Anker verliert oder driftet? Die technische Stabilität des Trackings ist eine Entwicklungsaufgabe, die wahrgenommene Stabilität ist eine Designaufgabe.
Physische Angemessenheit. Werden Gesten oder Interaktionen nach längerer Nutzung als anstrengend empfunden? Das Gorilla-Arm-Problem, ausführlich im AR Interaction Design Artikel beschrieben, zeigt sich häufig erst nach mehreren Minuten Nutzung, nicht in einer kurzen Demo.
Kontextuelles Verstehen. Weiß die Nutzer:in zu jedem Zeitpunkt, was das AR-Interface ist und was die reale Umgebung ist? Verschwimmen diese Grenzen ungewollt?
Heuristische Evaluation für AR: Ein angepasster Rahmen
Vor dem Einsatz echter Nutzer:innen bietet die heuristische Evaluation für AR-Interfaces einen schnellen ersten Qualitätsfilter. Nielsens klassische zehn Heuristiken greifen im AR-Kontext nur teilweise: Forschungsgruppen wie Grubert et al. haben AR-spezifische Erweiterungen vorgeschlagen, die zusätzliche Dimensionen einbeziehen.
Für die Designpraxis relevant sind insbesondere:
Räumliche Konsistenz. Verhält sich das AR-Interface konsistent in verschiedenen räumlichen Kontexten und Beleuchtungssituationen? Was passiert, wenn die Testbedingungen von der Designannahme abweichen?
Kalibrierungsaufwand. Wie viel Einrichtungsaufwand erfordert das System von Nutzer:innen, bevor sie die eigentliche Aufgabe erledigen können? Jeder Kalibrierungsschritt ist ein potenzielles Abbruchszenario.
Fehlertoleranz im Raum. Wie verhält sich das Interface bei SLAM-Fehlern oder Tracking-Verlusten? Ein gutes AR-Interface kommuniziert Systemzustände so, dass Nutzer:innen verstehen, was passiert und wissen, was sie tun können.
Ein systematisches Review in Frontiers Virtual Reality (Dezember 2025) bestätigt, dass es noch keinen einheitlichen Standard für AR-UX-Evaluation gibt — was bedeutet, dass Teams heute mit bestehenden Frameworks arbeiten und diese situativ anpassen müssen.
Take Away Message
AR-Prototypen zu testen erfordert keine völlig anderen Methoden als klassisches Usability Testing — aber spezifisch angepasste. Wizard of Oz eignet sich für konzeptionelle Fragen in frühen Phasen. Feldtests sind spätestens dann notwendig, wenn Tracking-Stabilität, Lichtverhältnisse und physische Nutzungskontexte Teil der Fragestellung sind. Und neben klassischen Usability-Metriken braucht es AR-spezifische Beobachtungsdimensionen: räumliche Orientierung, wahrgenommene Tracking-Stabilität und physische Angemessenheit. Wer diese Methoden kennt und situativ einsetzt, testet nicht nur, ob das AR-Interface funktioniert, sondern ob es im realen Kontext wirklich nutzbar ist. Genau das ist der Anspruch, der im AR App Design Kurs der UIX Academy von Anfang an mitgedacht wird.
