methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session2-10 TageWorkshop oder asyncPrototype Learnings

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.

Die App wählt

Methoden-Session mit 5-20 Nutzer. Der Plan nutzt die vorhandene Methodenlogik und das Run Sheet.

Run Sheet
  1. 1

    Phase 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. 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. 2

    Phase 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. 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. 3

    Phase 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. 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. 4

    Phase 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. 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. 5

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerPrototype Learnings
Nutzbares Artefakt

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.
Nutzbares Artefakt

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 terminieren
Vorlagenbasis

Wizard 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.
Direkt nutzbar, wenn
  • 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.