Meine Session planen
Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.
Session: Wizard of Oz Test
Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.
Methoden-Session mit 5-20 Nutzer. Der Plan nutzt die vorhandene Methodenlogik und das Run Sheet.
Run Sheet- 1
Phase 1: Experience und Skript definieren
Setup, 1-2 TageDie zu testende Experience als End-to-End-Flow beschreiben. Pro Schritt typische Anfragen und Antworten. SLA, Tonalität und Eskalationspfad festlegen. Hinweis: Wenn Skript am ersten Tag nicht 70% der Anfragen abdeckt, ist die Experience zu weit gefasst. Scope einengen, sonst sind Wizards überfordert. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorPrototype Learnings - 2
Phase 2: Frontend und Wizard-Setup
Setup, 1-3 TageFrontend bauen (Chat, Formular, App-Stub). Wizard-Dashboard mit Eingehende-Anfragen-Queue. Schichtplan für Wizards. Test mit 2-3 internen Probanden. Hinweis: Wizards brauchen Training auf das Skript. Improvisation auf der Live-Linie produziert inkonsistente Experience. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorManual Effort Notes - 3
Phase 3: Live mit echten Testnutzern
Laufzeit, 5-7 TageTestnutzer einladen. Wizards arbeiten in Schichten, SLA halten. UX-Researcher beobachten und sammeln Nutzungsmuster. Tägliches Wizard-Sync für Konsistenz. Hinweis: Wenn SLA bricht (zu lange Wartezeiten), ist Experience inkonsistent und Lernen verzerrt. Lieber weniger Nutzer, dafür stabil bedient. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
FacilitatorRisk List - 4
Phase 4: Aufklärung und Auswertung
Synthese, 1-2 TageNach 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. Hinweis: Aufklärung ist ethische Pflicht, nicht optional. Wer das versäumt, riskiert Reputation und rechtliche Probleme. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
OwnerPrototype Learnings - 5
Artefakt veröffentlichen
10 minArtefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
OwnerPrototype Learnings
Session Brief
Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.
# Session Brief: Wizard of Oz Test
## Ziel
Artefakt: Prototype Learnings
## Arbeitsfrage
Liefert die simulierte automatische Experience den Nutzern erkennbaren Wert, und welche Aufgaben sind realistisch automatisierbar?
## Kontext
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.
## Setup
- Format: Methoden-Session
- Dauer: 2-10 Tage
- Modus: Workshop oder async
- Teilnehmende: Ein Test-Owner, der Experience definiert und Wizards koordiniert; zwei bis fünf Wizards (Operatoren), die manuell antworten; UX-Researcher für Beobachtung; Testnutzer.
- Owner: Ein Test-Owner, der Experience definiert und Wizards koordiniert
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen
## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.
## Ergebnislogik
Die Session arbeitet direkt auf Prototype Learnings hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.
## Input
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.
## Vorbereitung
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.
## Agenda
1. Phase 1: Experience und Skript definieren (Setup, 1-2 Tage)
Owner: Facilitator
Aktion: Die zu testende Experience als End-to-End-Flow beschreiben. Pro Schritt typische Anfragen und Antworten. SLA, Tonalität und Eskalationspfad festlegen. Hinweis: Wenn Skript am ersten Tag nicht 70% der Anfragen abdeckt, ist die Experience zu weit gefasst. Scope einengen, sonst sind Wizards überfordert. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Prototype Learnings
2. Phase 2: Frontend und Wizard-Setup (Setup, 1-3 Tage)
Owner: Facilitator
Aktion: Frontend bauen (Chat, Formular, App-Stub). Wizard-Dashboard mit Eingehende-Anfragen-Queue. Schichtplan für Wizards. Test mit 2-3 internen Probanden. Hinweis: Wizards brauchen Training auf das Skript. Improvisation auf der Live-Linie produziert inkonsistente Experience. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Manual Effort Notes
3. Phase 3: Live mit echten Testnutzern (Laufzeit, 5-7 Tage)
Owner: Facilitator
Aktion: Testnutzer einladen. Wizards arbeiten in Schichten, SLA halten. UX-Researcher beobachten und sammeln Nutzungsmuster. Tägliches Wizard-Sync für Konsistenz. Hinweis: Wenn SLA bricht (zu lange Wartezeiten), ist Experience inkonsistent und Lernen verzerrt. Lieber weniger Nutzer, dafür stabil bedient. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Risk List
4. Phase 4: Aufklärung und Auswertung (Synthese, 1-2 Tage)
Owner: Owner
Aktion: 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. Hinweis: Aufklärung ist ethische Pflicht, nicht optional. Wer das versäumt, riskiert Reputation und rechtliche Probleme. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
Output: Prototype Learnings
5. Artefakt veröffentlichen (10 min)
Owner: Owner
Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
Output: Prototype Learnings
## Abschluss
- Ergebnisartefakt aktualisieren: Prototype Learnings
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.Arbeitsartefakt
Vorgefüllter Startpunkt auf Basis der passenden Vorlage.
# Prototype Learnings: Wizard of Oz Test
## Arbeitsfrage
Liefert die simulierte automatische Experience den Nutzern erkennbaren Wert, und welche Aufgaben sind realistisch automatisierbar?
## Kontext
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.
## Beteiligte
- Owner: Ein Test-Owner, der Experience definiert und Wizards koordiniert
- Teilnehmende: Ein Test-Owner, der Experience definiert und Wizards koordiniert; zwei bis fünf Wizards (Operatoren), die manuell antworten; UX-Researcher für Beobachtung; Testnutzer.
## Input
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.
## Vorlage
# 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.
## Fertigstellungscheck
- Prototype Learnings ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:
## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminierenWizard of Oz Test Arbeitsvorlage
# 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.- Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
- Das Ergebnis passt zu Prototype Learnings.
- 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.
- Offene Fragen sind als Follow-up notiert.
- Der nächste Review oder Entscheidungspunkt ist terminiert.