Produktmanager (PMs) und UX-Researcher stehen nach der Durchführung Dutzender Tiefeninterviews häufig vor einem Berg von 50.000 bis über 300.000 Wörtern an unstrukturiertem Text. Die manuelle Codierung von Aussagen und das Erstellen von Affinitätsdiagrammen nehmen oft Tage oder Wochen in Anspruch. Gleichzeitig zwingen herkömmliche KI-Modelle mit begrenzten Kontextfenstern Teams dazu, Transkripte in kurze Textfragmente zu zerlegen oder sich auf Retrieval-Augmented Generation (RAG) zu verlassen. Diese Aufteilung zerstört jedoch den übergreifenden Zusammenhang zwischen den Befragten, verfälscht Häufigkeitsstatistiken und übersieht Widersprüche zwischen verschiedenen Nutzer-Personas.
Das Sprachmodell Kimi von Moonshot AI überwindet diesen Engpass. Mit Kontextfenstern von bis zu 1 Million Tokens im Flaggschiffmodell Kimi K3 sowie 256K Tokens in K2.6 und K2.7 Code können Produktteams einen gesamten qualitativen Studienzyklus in einer einzigen aktiven Sitzung verarbeiten. Dieser Leitfaden erläutert die Bereinigung von Transkripten, den Aufbau eines dreistufigen Prompt-Frameworks, die Nutzung von Context Caching zur Kostenoptimierung sowie bewährte Methoden zur Qualitätssicherung.
Warum Kimi den Engpass qualitativer Studien löst
Qualitative Nutzerforschung ist primär eine vergleichende Disziplin. Die isolierte Beschwerde von Teilnehmer 3 erhält erst dann echtes Gewicht, wenn sie den Arbeitsabläufen und Blockaden von Teilnehmer 12 und 27 gegenübergestellt wird. Bei herkömmlichen KI-gestützten Ansätzen treten drei fundamentale Schwachstellen auf:
- Verlust der Gesamtperspektive: RAG-Verfahren rufen Textteile rein nach semantischer Ähnlichkeit ab. Sie können zwar beantworten, ob jemand Fehler beim Export erwähnt hat, scheitern aber daran, die fünf häufigsten systemischen Hürden über alle 25 Interviews hinweg verlässlich zu gewichten und nach Benutzerrollen zu differenzieren.
- Kontextfragmentierung: Werden Transkripte nacheinander in separaten Chats zusammengefasst, muss der Forscher Dutzende Einzelberichte manuell zusammenfügen. Dies führt erneut zu hohem Zeitaufwand und subjektiven Verzerrungen.
- Oberflächliche Standardfloskeln: Ohne strenge Leitplanken erzeugen Sprachmodelle oft vage Zusammenfassungen wie „Nutzer wünschen sich eine intuitivere Bedienung“. Dabei gehen die exakten Fehlerstellen im Arbeitsablauf und wörtliche Zitate verloren, die für Entwicklungsentscheidungen unverzichtbar sind.
Die Architektur von Kimi verarbeitet umfangreiche Textkorpora nativ. Ein Fenster von 1 Million Tokens fasst mühelos 40 bis 60 vollständige 45-minütige Interview-Transkripte (wobei Einzeldateien bis zu 100 MiB in Formaten wie txt, md, docx und pdf unterstützt werden). Dadurch kann das Modell vergleichende Analysen und exakte Häufigkeitszählungen über den gesamten Datensatz hinweg in einem Schritt durchführen.
Der 4-Schritte-Workflow: Vom Rohdaten-Transkript zur Produktentscheidung
Ein strukturierter vierstufiger Ablauf gewährleistet qualitative Zuverlässigkeit und reduziert manuelle Kodierarbeiten um 80 Prozent.
Schritt 1: Transkripte anonymisieren und Metadaten standardisieren
Vor dem Hochladen in Kimi müssen sensible Daten bereinigt (PII Scrubbing) und Metadaten einheitlich strukturiert werden:
- Entfernung personenbezogener Daten: Ersetzen Sie Klarnamen, Kundennamen, Passwörter und vertrauliche Finanzkennzahlen durch einheitliche Bezeichner wie
P01_Designer_MittelstandoderP02_IT_Admin_Konzern. - Standardisierte Kopfzeilen-Metadaten: Versehen Sie jedes Transkript zu Beginn mit vier Zeilen Kontext:
- Teilnehmer-ID: P01
- Persona/Rolle: Senior Operations Manager
- Unternehmensgröße: 500-1000 Mitarbeiter
- Hauptarbeitsaufgabe: Monatlicher Inventarabgleich und Berichtsexport
- Formatvereinheitlichung: Speichern Sie die Texte als Plain Text (
.txt), Markdown (.md) oder Word (.docx). In der Kimi-Weboberfläche können Dateien gesammelt per Drag-and-Drop hochgeladen werden; bei API-Aufrufen werden sie als strukturierter Prompt-Block übergeben.
Schritt 2: Kontext-Anker und Expertenrolle etablieren
Bitten Sie Kimi im ersten Dialogschritt nicht sofort um eine Gesamtzusammenfassung. Definieren Sie stattdessen die Rolle, die Analysekriterien und die Arbeitsweise:
Du agierst als leitender UX-Researcher und Principal Product Manager.
Ich habe 20 anonymisierte Interview-Transkripte aus unserer aktuellen Studie zum Enterprise-Reporting-Modul hochgeladen.
Deine Aufgabe ist es, als qualitative Analyse-Engine zu arbeiten. Befolge strikt diese Regeln:
1. Alle Erkenntnisse müssen sich ausnahmslos auf die bereitgestellten Texte stützen. Erfinde keine Zitate und ziehe keine unbegründeten Schlüsse.
2. Belege jede Aussage mit der entsprechenden Teilnehmer-ID (P01 bis P20).
3. Unterscheide strikt zwischen oberflächlichen Funktionswünschen ("Ich möchte einen Button für CSV-Export") und tiefer liegenden funktionalen Schmerzpunkten ("Der Vorgang bricht ab, wenn mehr als 10.000 Zeilen synchronisiert werden").
Bestätige, dass du alle 20 Transkripte vollständig eingelesen hast, liste die erkannten Teilnehmer-IDs und Rollen auf und warte auf meine konkreten Analyseanweisungen.
Das 3-Stufen-Prompt-Framework zur Schmerzpunkt-Extraktion
Um verwertbare Produktanforderungen statt generischer Zusammenfassungen zu gewinnen, empfiehlt sich ein dreistufiger Analyseprozess.
Stufe 1: Detaillierte Erfassung von Hürden und Originalzitaten
Dieser Prompt veranlasst das Modell, alle Dokumente systematisch nach konkreten Reibungspunkten zu durchsuchen und wörtliche Belege zu sichern:
Führe eine lückenlose thematische Extraktion über alle 20 Interview-Transkripte durch.
Identifiziere jede Situation, in der ein Teilnehmer Frustration, Verwirrung, Arbeitsunterbrechungen oder Unzufriedenheit geäußert hat.
Gib das Ergebnis als Markdown-Tabelle mit folgenden Spalten aus:
- Schmerzpunkt-ID (PP01, PP02 etc.)
- Phase der User Journey (z. B. Onboarding, Datenimport, Filterkonfiguration, Berichtsexport)
- Konkrete Problembeschreibung (präzise Darstellung des aufgetretenen Hindernisses)
- Schweregrad (Hoch: Arbeitsaufgabe bricht ab/kann nicht beendet werden; Mittel: aufwendiger Workaround erforderlich; Niedrig: geringfügige Unannehmlichkeit)
- Betroffene Teilnehmer (Liste aller IDs, die das Problem genannt haben, z. B. P03, P07, P12)
- Repräsentatives Originalzitat (ein wörtliches Zitat des Nutzers mit Angabe der Teilnehmer-ID)
Stufe 2: Häufigkeitsanalyse und rollenspezifischer Quervergleich
Produktteams müssen priorisieren. In dieser Stufe werden Hürden thematisch gebündelt, quantitative Häufigkeiten berechnet und Nutzergruppen verglichen:
Gruppiere die extrahierten Schmerzpunkte, die von mindestens 3 Teilnehmern genannt wurden, zu übergeordneten Kernthemen und sortiere sie absteigend nach der Anzahl der betroffenen Personen.
Analysiere für jedes Kernthema folgende Aspekte:
1. Thementitel und Kernproblem
2. Häufigkeit: Anzahl der eindeutigen betroffenen Teilnehmer und prozentualer Anteil (z. B. 14/20 Teilnehmer, 70%)
3. Rollenunterschiede: Wie äußert sich dieser Schmerzpunkt bei IT-Administratoren im Vergleich zu operativen Sachbearbeitern?
4. Ursachenanalyse: Liegt die Ursache in technischen Leistungsgrenzen, unklarer Informationsarchitektur oder einem Bruch zwischen mentalem Modell und Systemlogik?
5. Kompensationsverhalten: Welche Notlösungen nutzen die Anwender derzeit (z. B. manuelle Excel-Zusammenführung, eigene Hilfsskripte, paralleler Papierabgleich)?
Stufe 3: Übersetzung in Jobs-to-be-Done (JTBD) Handlungsempfehlungen
Überführen Sie validierte Probleme in klare Aufgabenstellungen für das Produktmanagement, ohne verfrühte technische Lösungen vorzugeben:
Formuliere die Top-5-Schmerzpunkte in Jobs-to-be-Done (JTBD) Opportunity Statements um, basierend auf folgender Struktur:
"Wenn [spezifische Situation/Auslöser], möchten Anwender [Handlung/Motivation], um [gewünschtes Geschäftsergebnis] zu erreichen; derzeit werden sie jedoch daran gehindert, weil [von Kimi verifizierter Kernengpass]."
Erstelle für jedes JTBD-Statement:
- 2 konkrete, überprüfbare Hypothesen für das Produktteam.
- Hinweise auf potenzielle Zielkonflikte (z. B. wenn erweiterte Expertenfunktionen die Einstiegshürde für Gelegenheitsnutzer zu stark erhöhen würden).
Technische Optimierung: Kosten senken mit Context Caching
Wenn Transkripte über die Kimi-API (mit Modellen wie kimi-k3 oder kimi-k2.6) automatisiert analysiert werden, verursacht das wiederholte Übertragen von Hunderttausenden Wörtern hohe Token-Kosten und längere Antwortzeiten.
Die Funktion Context Caching von Moonshot AI löst dieses Problem:
- Funktionsweise: Werden die vollständigen Transkripte am Anfang des Prompts (im
system-Bereich) platziert und Caching-Parameter (prompt_cache_optionsodercache_control) aktiviert, speichert Kimi diesen statischen Präfix im Cache. - TTL-Optionen: Für automatisierte Skriptabläufe eignet sich ein TTL von 5 Minuten (
5m), für interaktive Analysesitzungen mit manuellen Zwischenschritten ein TTL von 1 Stunde (1h). Jeder Cache-Treffer verlängert die Gültigkeit kostenfrei. - Kostenreduktion: Bei einem Cache-Treffer betragen die Input-Token-Gebühren nur etwa ein Zehntel des regulären Preises (bei
kimi-k3beispielsweise ¥2 pro 1 Million Tokens im Cache gegenüber ¥20 pro 1 Million Tokens bei einem Cache-Miss). Ein Researcher kann so Dutzende Detailabfragen an denselben Datensatz stellen – bei minimalen Kosten und fast verzögerungsfreier Antwortzeit.
from openai import OpenAI
client = OpenAI(
api_key="DEIN_MOONSHOT_API_KEY",
base_url="https://api.moonshot.cn/v1",
)
# Transkripte als Prefix mit 1 Stunde Cache-Gültigkeit übergeben
completion = client.chat.completions.create(
model="kimi-k3",
messages=[
{
"role": "system",
"content": f"Du bist ein UX-Research-Assistent. Transkriptdaten:\n\n{bulk_transcripts_text}",
},
{
"role": "user",
"content": "Vergleiche, wie Enterprise-Admins und KMU-Anwender die Latenz beim Datenexport beschreiben.",
},
],
prompt_cache_options={"mode": "implicit", "ttl": "1h"},
)
print(completion.choices[0].message.content)
Leitfaden zur Qualitätssicherung und Fehlervermeidung
Trotz der enormen Effizienzgewinne durch KI müssen Forschungsteams methodische Prüfmechanismen beibehalten:
| Prüfdimension | Typischer Fehler | Empfohlene Vorgehensweise |
|---|---|---|
| Zitatauthentizität | Paraphrasierte KI-Aussagen als wörtliche Zitate missverstehen | Explizit wörtliche Zitate mit Teilnehmer-ID fordern und Stichproben im Rohdokument nachschlagen |
| Häufigkeitsverzerrung | Einen besonders lautstarken Einzelteilnehmer als Mehrheitsmeinung werten | Eindeutige Teilnehmerzahlen verlangen; mehrfache Beschwerden derselben Person zählen als eine Stimme |
| Datenschutzkonformität | Unbereinigte Namen, E-Mail-Adressen oder vertrauliche Firmendaten hochladen | Transkripte vor dem Upload systematisch per Skript anonymisieren |
| Halluzinationsvermeidung | Spekulationen des Modells über nicht erwähnte Aspekte ungeprüft übernehmen | Die feste Anweisung vorgeben: „Nicht erwähnte Themen sind explizit als ‚In den Transkripten nicht erwähnt‘ auszuweisen“ |
Fazit
Durch das Zusammenspiel aus Kimis 1-Million-Token-Kontextfenster und einem dreistufigen strukturierten Prompt-Framework können Produktmanager und UX-Researcher die qualitative Analyse von mehreren Wochen auf wenige Stunden verkürzen. Statt mühsam fragmentierte RAG-Ausschnitte zusammenzusetzen oder vage Zusammenfassungen zu akzeptieren, erhalten Teams eine nachvollziehbare, faktenbasierte Übersicht der Kundenbedürfnisse, die als verlässliche Entscheidungsgrundlage für die Roadmap dient.