Meine Session planen

# Session Brief: Design Thinking

## Ziel
Artefakt: Problem Statement

## Arbeitsfrage
Welches reale Nutzerproblem ist es wert, gelöst zu werden, und welche Lösungsidee überlebt einen Test mit echten Nutzern?

## Kontext
Problembereich als ein Absatz, nicht als Lösungsidee; Zielgruppe und Zugang dazu; bekannte Constraints (Budget, Compliance, Technologie); vorherige Lösungsversuche und warum sie scheiterten.

## Setup
- Format: Methoden-Session
- Dauer: 5 Tage Sprint oder 4-8 Wochen iterativ
- Modus: Workshop
- Teilnehmende: Ein Facilitator für den Gesamtflow; ein bis zwei Researcher für Interviews und Synthese; zwei bis vier Designer und Engineers; ein Sponsor mit Entscheidungsmandat (mindestens an Phasenübergängen); Testnutzer für Phase 5.
- Owner: Ein Facilitator für den Gesamtflow
- 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 Problem Statement hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Workshop-Raum mit Wandflächen oder Miro-Board mit Phasen-Bahnen; Stickies in fünf Farben; Stifte; Prototyping-Material (Papier, Pappe, Klick-Tool wie Figma); Aufnahme-Setup für Tests; Recruiting-Liste für Nutzertests.

## Vorbereitung
Phasen-Bahnen an die Wand: Empathize, Define, Ideate, Prototype, Test. Sponsor-Reviews zwischen jeder Phase fest terminieren. Recruiting für Phase 5 in Phase 1 starten, nicht später.

## Agenda
1. Phase 1: Empathize (3-10 Tage)
   Owner: Facilitator
   Aktion: 5-10 Interviews und 2-3 Beobachtungen im Kontext durchführen. Notizen, Zitate, beobachtete Workarounds und emotionale Reaktionen sammeln. Keine Lösungsfragen stellen. Hinweis: Wenn Interviewfragen mit „Würden Sie X nutzen“ beginnen, produziert die Phase nur Höflichkeitsdaten. Auf vergangene Verhaltensweisen fragen, nicht auf hypothetische. 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: Problem Statement

2. Phase 2: Define (0,5-1 Tag)
   Owner: Facilitator
   Aktion: Patterns clustern. Eine Point-of-View-Aussage formulieren: Nutzer X braucht Y, weil Z (Insight). Anschließend 3-5 How-Might-We-Fragen ableiten und die wichtigste auswählen. Hinweis: Wenn die POV-Aussage eine Lösung enthält („braucht eine App“), neu formulieren. Z (Insight) muss überraschend oder kontraintuitiv sein, sonst war Empathize zu oberflächlich. 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

3. Phase 3: Ideate (0,5-1 Tag)
   Owner: Facilitator
   Aktion: Crazy 8s, Brainwriting oder Worst Possible Idea zur HMW-Frage. Mindestens 40 Ideen, dann Clustern und 2-3 Konzepte zur Prototyping-Auswahl. Hinweis: Wenn die Gruppe nach 20 Ideen aufhört, fehlt Divergenz. Erzwinge mindestens eine Runde mit absurden oder konträren Ideen, sonst landet die Gruppe bei der ersten naheliegenden Lösung. 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: Test Learnings

4. Phase 4: Prototype (1-5 Tage)
   Owner: Facilitator
   Aktion: Low-Fidelity-Prototyp bauen, der genau die zentrale Frage testbar macht. Papier, Klickdummy oder Wizard-of-Oz, kein produktiver Code. Pro Konzept einen Prototyp. Hinweis: Realistisch wirken schlägt vollständig. Prototyp ist eine Frage, keine Antwort. Wer Backend-Logik baut, hat die Phase verlassen und arbeitet bereits an der Lösung. 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: Problem Statement

5. Phase 5: Test (1-3 Tage)
   Owner: Owner
   Aktion: 5-8 moderierte 1:1-Tests pro Prototyp. Beobachten, was Nutzer tun, nicht was sie sagen. Patterns nach Test 5 synthetisieren. Entscheidung: weiter, pivotieren oder verwerfen. Hinweis: Pattern-Erkennung beginnt nach Test 5, nicht nach Test 2. Beobachtungs-Raster pro Test strikt befüllen. Bei Widerspruch zwischen Verhalten und Aussage zählt das Verhalten. 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

6. 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: Problem Statement

## Abschluss
- Ergebnisartefakt aktualisieren: Problem Statement
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Problem Statement: Design Thinking

## Arbeitsfrage
Welches reale Nutzerproblem ist es wert, gelöst zu werden, und welche Lösungsidee überlebt einen Test mit echten Nutzern?

## Kontext
Problembereich als ein Absatz, nicht als Lösungsidee; Zielgruppe und Zugang dazu; bekannte Constraints (Budget, Compliance, Technologie); vorherige Lösungsversuche und warum sie scheiterten.

## Beteiligte
- Owner: Ein Facilitator für den Gesamtflow
- Teilnehmende: Ein Facilitator für den Gesamtflow; ein bis zwei Researcher für Interviews und Synthese; zwei bis vier Designer und Engineers; ein Sponsor mit Entscheidungsmandat (mindestens an Phasenübergängen); Testnutzer für Phase 5.

## Input
Workshop-Raum mit Wandflächen oder Miro-Board mit Phasen-Bahnen; Stickies in fünf Farben; Stifte; Prototyping-Material (Papier, Pappe, Klick-Tool wie Figma); Aufnahme-Setup für Tests; Recruiting-Liste für Nutzertests.

## Vorlage
# Design Thinking Arbeitsvorlage

## Ziel

Iterativer Ansatz, der Nutzerverständnis, Problemframing, Ideation, Prototyping und Testen verbindet.

## 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
- Problem Statement:
- Prototype:
- Test Learnings:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

## Fertigstellungscheck
- Problem Statement 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