Was vorher fertig sein muss
Das Solution-Konzept wurde mit Zielnutzern besprochen, sodass die zu testende Experience grob abgesichert ist.
Was vor Start vorliegen muss
Funktionierender Frontend-Prototyp (Klickdummy oder einfaches Web-Frontend); Backend-Skripte oder manuelle Operatoren („Wizards“); Logging-Setup; SLA-Plan für Antwortzeiten; ethisches Briefing für Testteilnehmer.
Ein Test-Owner, der Experience definiert und Wizards koordiniert; zwei bis fünf Wizards (Operatoren), die manuell antworten; UX-Researcher für Beobachtung; Testnutzer.
Zu testende Experience in einem Satz; SLA-Erwartung (z. B. „Antwort in 30 s“); Skript für typische Anfragen; Eskalationsregel für unklare Fälle; Aufklärung über manuelle Beteiligung nach dem Test.
2-10 Tage
Frontend so bauen, dass Anfragen an einen Wizard-Channel (z. B. Slack oder internes Dashboard) gehen. Wizards arbeiten in Schichten mit klaren Antwortregeln. Logging aller Anfragen und Antworten. Nutzer werden nach dem Test über manuelle Beteiligung informiert.
Die eine Frage, die diese Methode beantwortet
Liefert die simulierte automatische Experience den Nutzern erkennbaren Wert, und welche Aufgaben sind realistisch automatisierbar?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Experience und Skript definieren | Setup, 1-2 Tage | Die zu testende Experience als End-to-End-Flow beschreiben. Pro Schritt typische Anfragen und Antworten. SLA, Tonalität und Eskalationspfad festlegen. | Wenn Skript am ersten Tag nicht 70% der Anfragen abdeckt, ist die Experience zu weit gefasst. Scope einengen, sonst sind Wizards überfordert. |
2Phase 2: Frontend und Wizard-Setup | Setup, 1-3 Tage | Frontend bauen (Chat, Formular, App-Stub). Wizard-Dashboard mit Eingehende-Anfragen-Queue. Schichtplan für Wizards. Test mit 2-3 internen Probanden. | Wizards brauchen Training auf das Skript. Improvisation auf der Live-Linie produziert inkonsistente Experience. |
3Phase 3: Live mit echten Testnutzern | Laufzeit, 5-7 Tage | Testnutzer einladen. Wizards arbeiten in Schichten, SLA halten. UX-Researcher beobachten und sammeln Nutzungsmuster. Tägliches Wizard-Sync für Konsistenz. | Wenn SLA bricht (zu lange Wartezeiten), ist Experience inkonsistent und Lernen verzerrt. Lieber weniger Nutzer, dafür stabil bedient. |
4Phase 4: Aufklärung und Auswertung | Synthese, 1-2 Tage | Nach Test-Ende Nutzer aufklären über manuelle Beteiligung. Interview oder Survey zu Erleben. Logs analysieren: häufige Anfragen, Wizard-Aufwand pro Anfrage, Anteil eskalierter Fälle. | Aufklärung ist ethische Pflicht, nicht optional. Wer das versäumt, riskiert Reputation und rechtliche Probleme. |
Was am Ende rauskommt
Experiment-Bericht mit Experience-Beschreibung, Logs der Anfragen und Antworten, Wizard-Aufwand pro Anfrage, Nutzungsmustern, Nutzer-Feedback nach Aufklärung, Risikoliste für Skalierung und Empfehlung für Build, Iterate oder Kill.
Pro Iteration eigener Bericht mit Datum, Scope und Wizard-Setup. Bei Skript-Updates Delta dokumentieren. Bei Folge-Experimenten mit echtem Backend Vergleichsmetriken (Aufwand, Qualität) führen.
Kompakte Arbeitsvorlage für Wizard of Oz Test mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Wizard of Oz Test Arbeitsvorlage
## Ziel
Simuliert ein automatisiertes Produktverhalten manuell hinter den Kulissen.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Prototype Learnings:
- Manual Effort Notes:
- Risk List:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Wizard of Oz — KI-Buchungsassistent (12.05.-22.05.2026)
**Experience**: Nutzer reicht Belege als Foto ein. „Assistent“ kategorisiert, schlägt Konto vor und gibt Hinweise auf Auffälligkeiten. Antwort in unter 2 min.
**Setup**: Mobile-Web-Frontend mit Upload. Anfragen landen in Slack-Channel #wizard-queue. Drei Wizards (Steuerberater-Studenten) in Schichten Mo-Fr 9-18 Uhr. Skript mit 80 typischen Buchungssätzen.
**Ergebnisse (5 Testnutzer, 7 Tage, 247 Belege)**:
- Wizard-Aufwand: durchschnittlich 1 min 50 s pro Beleg, Median 80 s.
- Eskalationsrate: 14% (Belege außerhalb des Skripts, z. B. Auslandsfaktura).
- Nutzer-Feedback: 4 von 5 bewerten Experience als hilfreich, einer kritisiert Tonfall.
- Zitat (Sabine): „Wenn das automatisch ginge, wäre das 5 h pro Woche.“
**Empfehlung**: Build. Skript deckt 86% der Fälle, Restautomatisierung mit RegEx und ML realistisch. Spike-Plan: ML-Modell für Top-20-Kategorien bis 30.06., Owner: @ben.Symptome erkennen, gegensteuern
Antworten variieren stark, Nutzer-Experience inkonsistent.
Skript-Training vor Live-Phase. Tägliches Sync. Bei häufiger Eskalation Skript erweitern, nicht improvisieren lassen.
Antwortzeiten variieren zwischen 30 s und 30 min, Nutzer-Erlebnis unbrauchbar.
Wizard-Kapazität gegen Anfragelast prüfen. Bei Überlast Nutzer-Zahl reduzieren. Lieber 5 Nutzer mit konsistenter Experience als 50 mit Chaos.
Nutzer glauben, die Lösung sei bereits real und KI-getrieben.
Aufklärung nach Test-Ende Pflicht. Bei längeren Tests im Onboarding bereits andeuten, dass Experience im Aufbau ist.
Skript versucht alle Use Cases abzudecken, Wizards können sich nicht einarbeiten.
Auf einen End-to-End-Flow begrenzen. Nebenfälle bewusst ausschließen oder eskalieren.
Auswertung kaum möglich, Wizard-Aufwand wird geraten.
Pro Anfrage strukturierte Logs (Zeitstempel, Anfrage-Typ, Antwort, Eskalation, Aufwand-Schätzung). Tools wie Airtable oder Webhook ins Notion-Repository.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.