--- title: "AI Tool Playbook" slug: "ai-tool-playbook" description: "Erarbeitet systematisch User Journeys für AI-Tools, um vollständige, testbare Spezifikationen zu erstellen die Qualität der KI Antworten deutlich zu erhöhen" tags: ["AI Tools", "KI Qualität", "AI Config"] updated: 2026-07-14T16:11:52Z published: 2026-07-14T16:11:52Z canonical: "help.foxbase.de/ai-tool-playbook" --- > ## Documentation Index > Fetch the complete documentation index at: https://help.foxbase.de/llms.txt > Use this file to discover all available pages before exploring further. # AI Tool Playbook # 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?** | | **Daten-Tool** | **Api-Tool** | | --- | --- | --- | | Beispiele | Compare Products, Exact Search, Kontaktinfo anzeigen | Bestellung auslösen, Termin buchen, Daten ändern/löschen | | Was passiert | Liest Daten, zeigt sie an | Verändert etwas in der echten Welt (bei einer externen API) | | Risiko bei Fehler | Nutzer sieht falsche/keine Daten – unschön, aber reversibel | Kann irreversible oder kostenpflichtige Folgen haben | | Zusätzlicher Aufwand | Rendering-Pattern + Datenschema reichen meist | Braucht zusätzlich: Auth/Permissions, Nutzerbestätigung vor Ausführung, Fehler-/Retry-Verhalten, Idempotenz | 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. | Station | Leitfragen | | --- | --- | | **1. Einstieg** | Wie kommt der Nutzer zu dieser Absicht? Direkte Eingabe, Klick auf einen Vorschlag, Folgefrage nach einem anderen Tool? | | **2. Interaktion** | Braucht das Tool weitere Angaben vom Nutzer (z. B. "welche zwei Produkte genau")? Muss nachgefragt werden? | | **3. Ergebnis** | Was genau wird angezeigt? Wie viele Optionen/Produkte? Was, wenn es zu viele oder zu wenige sind? | | **4. Folgeaktion** | Was kann der Nutzer von hier aus tun? Zurück zur Suche, ein Produkt im Detail öffnen, Kontakt aufnehmen? | **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:** 1. **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. 2. **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)? 3. **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? 4. **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` | Schritt | Ausarbeitung | | --- | --- | | **1. Intent** | Nutzer will 2–4 Produkte anhand von Eigenschaften vergleichen. Abgrenzung: nicht "ein Produkt finden" (= exact search). | | **2. Trigger** | "Vergleich X vs Y", "was ist besser X oder Y", "Unterschied X und Y" · Negativ: "zeig mir X" | | **3. Journey** | Einstieg: Nutzer nennt 2 Produktnamen → Interaktion: System matcht Namen zu Produkten, fragt nach falls uneindeutig → Ergebnis: Vergleichskarte mit beiden Produkten nebeneinander → Folgeaktion: "Produkt X im Detail ansehen" oder "weiteres Produkt hinzufügen" | | **4. Daten** | Pflicht: Titel, Preis, 3 Vergleichsattribute je Produkt · Optional: Bild, Bewertung, Verfügbarkeit | | **5. UI-Pattern** | Zwei- bis vierspaltige Vergleichskarte, gemeinsame Attributzeilen | | **6. Fallback** | Ein Produktname nicht gefunden → Rückfrage "Meintest du...?" · Mehr als 4 Produkte genannt → nur erste 4 vergleichen + Hinweistext | | **7. Testfälle** | "Vergleiche Produkt A und Produkt B" → Vergleichskarte · "Vergleiche Produkt A, B, C, D, E" → Vergleichskarte mit 4 + Hinweis · "Vergleiche Produkt A und Zzzz" → Rückfrage | --- ## Beispiel durchgespielt: `book_appointment` (API-Tool) | Schritt | Ausarbeitung | | --- | --- | | **0. Tool-Typ** | API-Tool – löst eine echte Terminbuchung über eine externe API aus | | **1. Intent** | Nutzer will einen Beratungstermin buchen. Abgrenzung: nicht "Kontaktinfo anzeigen" (rein informativ). | | **2. Trigger** | "Ich möchte einen Termin buchen", "wann kann ich mit euch sprechen", "Termin für nächste Woche" | | **3. Journey** | Einstieg: Nutzer äußert Buchungswunsch → Interaktion: System fragt nach Datum/Uhrzeit falls fehlend → Ergebnis: Bestätigungskarte mit Termindetails vor der eigentlichen Buchung → Nutzer bestätigt explizit → Aktion wird ausgeführt → Folgeaktion: Bestätigung mit Kalendereintrag-Option | | **4. Daten** | Input: Datum, Uhrzeit, Kontaktdaten · Auth: API-Key des Buchungssystems · Output Erfolgsfall: Buchungs-ID, bestätigter Termin | | **5. UI-Pattern** | Bestätigungskarte vor Ausführung, danach Erfolgs-Karte mit Buchungs-ID | | **6. Fallback** | Zeitslot nicht mehr verfügbar → Alternativvorschläge anzeigen · API-Timeout während Buchung → Nutzer informieren, nicht automatisch retryen (Doppelbuchungsgefahr) · Wiederholter Klick auf "Bestätigen" → Idempotenz-Check verhindert Doppelbuchung | | **7. Testfälle** | "Termin für Montag 14 Uhr" + Bestätigung → Buchung erfolgreich · Slot bereits belegt → Alternativvorschläge · Doppelklick auf Bestätigen → nur eine Buchung | --- ## 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".