Playbook: User Journeys für Tools im AI-Chat ausarbeiten

Zweck

Dieses Playbook hilft euch, für jedes Tool (z. B. Compare Products, Exact Product Search, Kontakt) systematisch durchzuspielen, wie der Nutzer dort hinkommt, was das Tool braucht, was es liefert und wie das Frontend es darstellen soll. Ziel: Am Ende hat jedes Tool eine vollständige, testbare Spezifikation – keine Lücken zwischen Intent-Erkennung, Datenlieferung und UI.

Grundprinzip: Jede Tool-Journey folgt derselben Kette:

Nutzer-Absicht (Intent) → Trigger erkannt → Tool ruft Daten/API → Daten-Antwort → UI-Rendering → nächster Schritt

Für jedes Tool müsst ihr jede Station dieser Kette einmal konkret ausfüllen.

Schritt 0: Tool-Typ bestimmen

Bevor ihr in die Journey einsteigt, klärt eine grundlegende Frage: Zeigt das Tool nur Daten an, oder löst es eine echte Aktion/API aus?

Haltet für jedes Tool einfach fest: Typ: Daten-Tool oder Typ: Api-Tool. Das entscheidet, ob ihr bei Schritt 4 und 6 die zusätzlichen Punkte für Api-Tools braucht.

Schritt 1: Intent klar benennen

Bevor ihr irgendetwas designt, schreibt für das Tool eine einzeilige Definition:

• Intent-Name: z. B. compare_products

• Nutzerziel in einem Satz: "Der Nutzer will zwei oder mehr Produkte anhand ihrer Eigenschaften vergleichen."

• Abgrenzung: Was gehört nicht dazu? (z. B. "Ein einzelnes Produkt suchen" ist exact_product_search, nicht compare_products)

Tipp: Wenn ihr die Abgrenzung nicht in einem Satz hinschreiben könnt, ist der Intent wahrscheinlich noch zu unscharf geschnitten.

Schritt 2: Trigger & Beispielformulierungen sammeln

Sammelt für jeden Intent:

• 5–10 positive Beispiele – wie echte Nutzer das formulieren würden (nicht nur die "saubere" Version)

  • "Was ist besser, X oder Y?"

  • "Vergleich X vs Y"

  • "Unterschied zwischen X und Y?"

• 3–5 Negativbeispiele – Formulierungen, die ähnlich klingen, aber ein anderer Intent sind

  • "Zeig mir X" → das ist Exact Search, kein Vergleich

• Mehrdeutige Fälle – wo auch Menschen im Team unterschiedlicher Meinung wären, welcher Intent gemeint ist. Diese Fälle braucht ihr später für Schritt 6 (Fallback).

Schritt 3: Die User Journey durchspielen

Nehmt ein Whiteboard oder eine Tabelle und geht die Journey in vier Stationen durch. Für jede Station: was passiert, was sieht der Nutzer, was könnte schiefgehen.

Ergebnis dieses Schritts: ein kurzer Ablauf-Storyboard (auch als einfache Kästchen-Skizze reicht), das zeigt: Nutzer sagt X → System tut Y → Nutzer sieht Z → Nutzer kann A oder B tun.

Schritt 4: Datenbedarf definieren

Leitet aus dem Storyboard ab, welche Felder die Antwort mindestens enthalten muss.

• Pflichtfelder: ohne die kann das UI-Pattern nicht sinnvoll gerendert werden (z. B. bei Compare: Titel, Preis, mind. 3 Vergleichsattribute)

• Optionale Felder: verbessern die Darstellung, sind aber nicht kritisch (z. B. Produktbild, Kundenbewertung)

• Mengenangaben: Mindest- und Höchstanzahl an Ergebnissen, die das UI sinnvoll darstellen kann (z. B. Compare: 2–4 Produkte, nicht 10)

Schreibt das als einfache Tabelle: Feldname | Pflicht/Optional | Format | Quelle (kommt von welcher API/Datenbank)

Zusätzlich bei API-Tools:

• Input-Schema für den API-Call – welche Parameter sind pflicht/optional, welches Format/welche Validierung

• Auth/Permissions – welche Credentials/Scopes der Call braucht, wer diese verwaltet

• Output-Schema Erfolgsfall – exakte Struktur der Response nach erfolgreicher Aktion (was bekommt der Nutzer als Bestätigung zu sehen)

Schritt 5: UI-Pattern zuordnen

Jetzt erst kommt das visuelle Rendering ins Spiel – bewusst nach den Schritten 1–4, damit das Design auf echten Datenanforderungen basiert und nicht umgekehrt.

• Welches bestehende UI-Pattern passt (Karte, Tabelle, Liste, Einzelkarte mit CTA)?

• Passt ein bestehendes Pattern aus einem anderen Tool, oder braucht es ein neues?

• Wie viel Text (vom Modell generiert) erscheint zusätzlich zur Datendarstellung, und wie lang darf der sein?

Schritt 6: Fallback- und Edge-Cases durchdenken

Für jedes Tool müsst ihr mindestens diese vier Fälle explizit festlegen:

1. Kein Treffer – z. B. 0 Suchergebnisse. Was zeigt das UI? Welcher Text wird generiert?

2. Zu viele Treffer – z. B. 50 Produkte bei Exact Search. Filtern? Top-N zeigen? Nachfragen?

3. Intent unklar / mehrdeutig – System ist unsicher, ob compare_products oder exact_product_search gemeint ist. Nachfrage-Text?

4. Datenquelle nicht erreichbar – API-Fehler oder Timeout. Welche Nutzer-Meldung, welches Verhalten (Retry, Abbruch)?

Diese vier Fälle sind erfahrungsgemäß die, die im Nachhinein am teuersten sind, wenn sie vergessen wurden – deshalb hier explizit einplanen, nicht erst beim Testen entdecken.

Zusätzlich bei API-Tools:

5. Bestätigung vor Ausführung – muss der Nutzer die Aktion explizit bestätigen, bevor sie ausgeführt wird (z. B. "Bestellung wirklich auslösen?")? Bei allem, was Kosten verursacht oder Daten verändert/löscht: ja.

6. Fehler während der Ausführung – die Aktion wurde gestartet, aber die externe API antwortet mit Fehler. Ist der Zustand danach eindeutig (nichts passiert) oder unklar (evtl. teilweise ausgeführt)?

7. Doppelte Ausführung (Idempotenz) – was passiert, wenn der Nutzer den Vorgang wiederholt (z. B. durch erneutes Klicken oder Retry)? Darf die Aktion ein zweites Mal passieren, oder muss das verhindert werden?

8. Timeout – die externe API antwortet nicht rechtzeitig. Wird gewartet, abgebrochen, oder dem Nutzer ein Zwischenstatus gezeigt?

Schritt 7: Review & Validierung

Bevor ein Tool als "fertig spezifiziert" gilt, prüft:

• Tool-Typ ist festgelegt: Daten-Tool oder API-Tool (Schritt 0)

• Intent ist eindeutig von benachbarten Intents abgegrenzt (Schritt 1)

• Mindestens 5 positive + 3 negative Beispielformulierungen liegen vor (Schritt 2)

• Die komplette Journey (Einstieg → Ergebnis → Folgeaktion) ist durchgespielt (Schritt 3)

• Datenschema mit Pflicht-/Optionalfeldern ist dokumentiert (Schritt 4)

• UI-Pattern ist zugeordnet oder als "neu zu designen" markiert (Schritt 5)

• Alle vier Basis-Fallback-Fälle sind definiert (Schritt 6)

• Nur bei API-Tools: Auth/Permissions, Bestätigung vor Ausführung, Fehler-während-Ausführung, Idempotenz und Timeout sind zusätzlich geklärt (Schritt 4 & 6)

• Mindestens 3 Beispieldialoge (Nutzer-Input → erwartete Antwort) sind niedergeschrieben – dienen später als Testfälle

Beispiel durchgespielt: compare_products

Beispiel durchgespielt: book_appointment (API-Tool)

Häufige Fallstricke

• UI vor Daten designen – führt zu hübschen Mockups, die das Backend nicht befüllen kann. Reihenfolge aus diesem Playbook einhalten.

• Nur den Idealfall durchspielen – die Fallback-Fälle (Schritt 6) werden oft erst im Testing entdeckt, wenn es teuer ist, sie nachträglich einzubauen.

• Trigger-Liste zu klein – 2–3 Beispielsätze reichen nicht, um Intent-Erkennung robust zu testen. Reale Nutzerformulierungen sind unordentlicher, als man denkt.

• Fehlende Abgrenzung zwischen ähnlichen Intents – wenn zwei Tools ähnliche Formulierungen triggern können, unbedingt in Schritt 1 explizit klären, wer im Zweifel "gewinnt".