Im UX Heroes Podcast: Strukturierte Daten, Metriken und KI-moderierte Interviews

Ich war bei Markus Pirker im UX Heroes Podcast von Userbrain zu Gast und habe erzählt, wie ich Research tatsächlich durchführe: strukturierte versus unstrukturierte Methoden, die Metriken, die eine Geschäftsentscheidung überleben, und ein achtmonatiges Nebenprojekt, in dem ich einen eigenen KI-Interviewer gebaut habe. Das hier ist eine schriftliche Zusammenfassung des Gesprächs, nach Themen geordnet.

Die Spannung, mit der jedes moderierte Interview lebt

Nach über tausend moderierten Tests und Interviews ist mein größtes persönliches Learning keine Technik. Es ist eine Spannung, mit der ich zu leben gelernt habe, statt sie zu lösen.

Ich liebe einen genauen Plan. Es gibt kaum etwas Schöneres als eine Studie, die vorab vollständig durchdacht ist. Aber genau die Würze und der Spaß an einem moderierten Interview liegen darin, dass man auf die Person eingehen, auf ihre Aussagen reagieren und im Flow vom Plan abweichen kann, wenn es sich lohnt. Das widerspricht zutiefst der Art, wie ich arbeite: methodisch, immer auf Datenaggregation und Struktur bedacht. Es gibt hier keinen sauberen Trade-off. Die unstrukturierten Momente innerhalb einer strukturierten Session sind manchmal am meisten wert, und man überlegt sich danach, wie man mit diesen Abweichungen in der Auswertung umgeht. Früher hat mich das gestresst. Mittlerweile kann ich gut damit leben.

Was Struktur wirklich bedeutet

Struktur verstehen die meisten sofort, wenn ich sie mit einer Umfrage vergleiche. In einer Umfrage werden die Fragen definiert, die die Leute bekommen. Ein Test oder ein Interview ist dieselbe Idee: alles, was man erfragt, alles, was beobachtet werden soll, jedes Kriterium (zum Beispiel, ob jemand einen E-Commerce-Checkout wirklich schafft) muss vorher festgelegt werden. In welcher Struktur, in welcher Reihenfolge, mit welchen Hilfestellungen unterwegs.

Das ist unabhängig davon, wer oder was die Session führt, moderiert, unmoderiert oder KI-moderiert. Die Ursprünge liegen in der Psychologie und den experimentellen Verhaltenswissenschaften: Ein Experiment braucht ein genaues Setup, weil man die Reaktionen von Menschen misst und der Input für alle gleich sein muss. Auch die Real-Life-Momente lassen sich planen. Probing ist der Klassiker: Wo fragt man nach, wo hilft man, wo gibt man einen Hinweis. Das gilt genauso für unmoderierte Tests, denn auch dort muss man sich überlegen, welche Instruktionen die Leute bekommen und ob ab einem bestimmten Punkt Spoiler oder Hilfestellungen auftauchen.

Angewandte UX-Research ist offener als ein rein akademisches qualitatives Interview, aber das Ziel ist ein anderes. Man liefert eine Entscheidungsgrundlage und löst ein Problem, nicht Wissensgenerierung um ihrer selbst willen. Es gibt kein Standardskript. Man startet von Templates, aber was die Arbeit trägt, ist Vertrauen: Habe ich eine Beziehung aufgebaut, die richtigen Teilnehmenden ausgewählt, Fragen gestellt, die auf den echten Business Case zurückgehen. Rigor und Methode sind enorm wichtig, aber im Stakeholder-Meeting treten sie in den Hintergrund. Die zentrale Diskussion ist das Designproblem oder die Monetarisierung, nicht die Konfidenzintervalle.

Warum ich Time on Task skeptisch sehe

Time on Task erhebe ich, wenn es gefordert wird, aber ich bin ehrlich: So richtig gern habe ich es nicht, aus mehreren Gründen.

Rein quantitative Daten geben mir wenig Ansatzpunkte zur Interpretation. Aus einem Chart allein einen wirklich guten Insight zu liefern, ist schwer. Die Verteilungen sind unangenehm: Viele Leute sind sehr schnell fertig, mit wenig Varianz, und ein paar brauchen sehr lang, sodass der Schwanz nach hinten rausläuft und man ewig nach Artefakten sucht (hat die Person abgebrochen oder war sie nur langsam?). Dann ist da die goldene Frage, die ich bis heute nicht gut beantworten kann: Was ist eigentlich eine gute Time on Task? Benchmarks gibt es bei großen Unternehmen, aber weniger, als man denkt. Und die Definition, wann ein Task startet und endet, hört sich trivial an, bis man es an einem echten digitalen Produkt versucht. Was darf zwischendrin passieren? Können Leute einen anderen gültigen Weg gehen? Dann sind die Zahlen nicht mehr vergleichbar.

Dieselbe Spannung zeigt sich zwischen Thinking Aloud und Time on Task. Bittet man alle, ihre Gedanken laut auszusprechen, tun das manche mehr, manche weniger. Die Hälfte schweigt, die andere Hälfte erzählt die halbe Lebensgeschichte, wenn etwas am Bildschirm sie daran erinnert. Das ist menschlich, und das soll auch so sein. Aber es widerspricht einem strikten Zeitplan. Man kann den Leuten nicht sagen, alles sei willkommen, und sie gleichzeitig bitten, nur über diesen einen Flow zu reden, weil man die Zeit misst. Also akzeptiert man die Unschärfe und interpretiert entsprechend. Dieselbe Vorsicht gilt, wenn bei fünf bis zehn Personen eine Verbesserung der Time on Task um 20% als signifikant gefeiert wird. Die Debatten zu Small-Sample-Statistik sind spannend für die Research Community und für Podcasts wie diesen, haben aber wenig Impact auf den Alltag kleiner und mittelgroßer Unternehmen.

Die zwei Metriken, die ich in jedem Test einsetze

Wenn man mich fragt, welche Metrik den größten Impact auf die Praxis hat, ist meine Antwort im Jahr 2026 eine, die ich vor zehn Jahren nicht vorhergesagt hätte, und es ist immer noch die gute alte System Usability Scale.

Die SUS ist über dreißig Jahre alt und ziemlich antiquiert, mit vielen bekannten Problemen. Aber unter den UX-Metriken hat sie alles. Sobald man von Time on Task weg in die psychometrische Richtung geht (Ästhetik, Flow, wahrgenommene Usability), ist die SUS kurz, sie ist ein Faktor, sodass man nie erklären muss, wie man von einer Anzahl Fragen auf einen Score kommt, und sie liefert einen Wert von 0 bis 100. Sie hat die größte Benchmark im Hintergrund, mit Adjektiv-Ankern wie „Excellent", die man auf die Punkte mappen kann, sie ist gut zitierbar, es gibt große zugängliche Datenbanken zum Benchmarken, und viele kennen den kritischen Wert (68) aus dem Kopf. Sie hat sogar eine bekannte Visualisierung. Ich setze sie in wirklich jedem Test ein.

Die zweite ist der Net Promoter Score, und über den diskutiere ich mehr, weil ihn viele UX-Leute hassen. Die methodische Kritik ist teils berechtigt: Er verspricht zu viel und ist nicht diagnostisch für Usability-Probleme. Aber das Argument für ihn spiegelt die SUS. Die Leute kennen ihn. Business-Entscheiderinnen und -Entscheider haben ihn im Kopf. SUS und NPS zusammen sind kurz, gefühlt jede und jeder im Feld kennt sie oder findet sie in Sekunden, und diese weite Verbreitung gibt einem Glaubwürdigkeit und Vergleichbarkeit über Services, Branchen und Wettbewerber hinweg. Diese schiere Marktmacht macht sie zu meinem Go-To-Setup, und ich sehe nicht, dass sie so bald abgelöst werden.

Die Reihenfolge zählt: erst SUS, dann NPS. Der Grund ist psychologisch. Die usability-nahe Variable sollte vor der business-orientierten kommen, und die Weiterempfehlungswahrscheinlichkeit gehört ganz ans Ende. Methodisch am wichtigsten ist, dass die Reihenfolge über alle Teilnehmenden gleich bleibt. Auf das alte Meme, man empfehle ja auch kein Betriebssystem beim Abendessen weiter, gehe ich gar nicht mehr ein. Diese Scores liefern einen kleinsten gemeinsamen Nenner, der vergleichbar ist, keine Vorhersage der Zukunft, und meine Erwartungen an eine einzelne Metrik sind bescheiden, weil kein Tool die Zukunft so genau vorhersagt, wie man es sich wünscht.

Strukturierte Daten sind die Grundlage

Über strukturierte Daten haben Markus und ich schon in einem früheren Userbrain-Webinar gesprochen, und sie sind der rote Faden hinter allem oben. Unmoderierte User Tests sind in gewisser Weise genau darauf getrimmt, strukturierte Daten zu liefern.

Das Problem ist, dass Leute ohne Research-Training naiverweise von einer Struktur ausgehen, die im Zeitalter von KI stark auf Transkripten und Zusammenfassungen aufbaut. Die Mitte fehlt: Es ist nicht definiert, wann welche Metrik oder welche Frage erhoben wird. Am Ende gibt es eine Zusammenfassung, und Zusammenfassungen findet man intuitiv gut. Sie sind auch okay, aber sie sind eben nur eine Zusammenfassung. Genau die Information, mit der man Stakeholdern klarmachen kann „das basiert nicht auf Vibes", geht dabei verloren.

Das Konzept, auf das ich immer wieder zurückkomme, ist Tidy Data: normale Spreadsheets, mit Spalten, Zeilen und Zellen. Es hört sich unglaublich trivial an, und ich kann kaum glauben, dass ich das in Vorlesungen ausspreche. Aber die Kunst ist, genau zu überlegen, welche Variable, welche Beobachtung, welche Frage in einer Spalte liegt, dass die Person eine Zeile ist, und was eine Zelle ausmacht, wo sie anfängt und wo sie endet. Denn am Ende (und das tut meinem akademischen Herzen weh, weil es sogar für qualitative Arbeit gilt) müssen Dinge gezählt werden, und jede Aussage muss zurückverfolgbar sein zu ihrer Quelle. Nur eine Struktur, die das vorgibt, sagt einem, welchen Indikator man aggregieren kann und wie oft ein bestimmtes Thema oder Issue tatsächlich auftauchte.

Bei unmoderierten Tests zählt das noch mehr. Der ganze Reiz ist, dass man nicht jedes Video anschauen müsste. Ich bin paranoid genug, es trotzdem zu tun, das ist der Forscher in mir, der wissen will, ob es wirklich so war. Und ich gebe zu, dass ich Features wie Clip-Highlights und vorstrukturierte Momente genieße, mit denen ich direkt zur richtigen Stelle springe. Erfahrene Leute kommen damit aus, vielleicht 20% der Videos zu schauen und den Rest dem System zu überlassen, aber Struktur ist es, die das sicher macht: Wenn ich mir bei einer bestimmten Frage unsicher bin, muss ich nur die Abschnitte zu diesem Issue anschauen. Ohne Struktur, moderiert oder nicht, braucht man den Test gar nicht zu machen. Am Ende glaubt einem sonst keiner.

Einen KI-Interviewer bauen, und warum er schlechter als eine Umfrage sein kann

Einige Kundinnen und Kunden haben mich gefragt, welche Plattform für KI-moderierte Interviews die beste sei. Alles, was mir als fertige Blackbox präsentiert wird, macht mich skeptisch, also habe ich die Tools recherchiert, ausprobiert und schließlich beschlossen, es selbst zu bauen. Wir leben in einer Zeit, die verspricht, dass jede und jeder über Prompts alles bauen kann, also dachte ich: gut, mache ich.

Der Twist ist, dass am Ende ein echter Entwickler kommen musste, um meinen ganzen Vibe-Coded-Mess aufzuräumen, damit das überhaupt funktioniert, und ich hatte irgendwann Vibe-Prompt-Verbot. Spaß gemacht hat es trotzdem. Über etwa acht Monate (angefangen als Ein-Monats-Idee im letzten Sommer, eskaliert zu einem Abend- und Wochenendprojekt) haben wir 60 Personen in unterschiedlichen Gruppen interviewt und mit mehreren Ansätzen experimentiert.

Mein Fazit: Vorerst sind KI-moderierte Interviews immer noch schlechter als eine Umfrage, weil die einfachste Form eines KI-moderierten Interviews eine interaktive Umfrage ist. Man sagt etwas, bekommt eine Frage, sagt etwas, bekommt eine Frage, genau wie beim Login in das Lieblings-Chat-Tool. Ein echtes qualitatives Interview ist anders, weil die Möglichkeit dazukommt, nachzufragen, zu proben und bei Problemen in die Tiefe zu gehen. Auf einer abstrakten Ebene bewegt sich eine Branching-Survey, die an bestimmten Stellen tiefer geht, in diese Richtung. Wir haben auch ausgelotet, was Large Language Models beitragen: einzuschätzen, ob ein Thema ausgeschöpft ist, die Sättigung zu prüfen, und eine Tagebuch-Variante, in der Leute per Sprachnachricht antworteten und Nachfragen per Text bekamen. Am schwierigsten ist mit Abstand die Echtzeit-Unterhaltung: zu erkennen, wann jemand fertig ist, natürliches Turn-Taking, der Umgang mit Unterbrechungen. Je mehr Modelle und Checks man dazwischenschaltet, um die Qualität zu heben, desto mehr Latenz spürt die teilnehmende Person.

Das wiederkehrende Problem über alle drei Ansätze war die Nachvollziehbarkeit. Wenn ich nur eine KI-generierte Zusammenfassung bekomme und das Gespräch nicht im Detail tracen kann, kann ich niemandem authentisch sagen, er solle viel Geld in Änderungen investieren. Wir UX-Leute denken oft nur bis zu einem bestimmten Punkt. Wir stecken viel Liebe ins Studien-Setup und vergessen, dass das Research-Budget nichts ist im Vergleich zu dem Budget, das freigegeben werden muss, wenn man allen Recommendations glaubt. Ehrlich gesagt habe ich mich so sehr auf Methodik und Technik fokussiert, dass ich die Outcomes nicht so überzeugend präsentieren konnte wie bei Research, wo ich zumindest ein paar Videos gesehen oder echten Kontakt zu den Leuten hatte. In einer Umfrage ist es trivial zu zählen, wie oft ein Tag oder Thema vorkam. Mit Probing-Magic und LLM-Magic, die Dinge tun, die ich nicht mehr ganz tracen kann, kann ich nicht überzeugend begründen, wie ich zu einem Schluss gekommen bin.

Ja, mir wird gesagt, ich verkenne den Sinn eines qualitativen Interviews, es gehe nicht ums Tracen und Zählen. Damit haben sie teilweise recht. Aber als Researcher ist von mir trotzdem immer gefordert, meine Recommendations glasklar und nachvollziehbar zu machen, wenn Leute Budget, Zeit und Effort investieren, und die Entwicklerinnen und Entwickler, die es umsetzen, haben jedes Recht, zu fragen, ob ich mir sicher bin. Eine KI tut sich leicht damit, zu sagen „ihr müsst das ganze Geschäftsmodell ändern". Was das für das Business bedeutet, ist der KI egal, und meine Rolle ist nicht, nur ein Readout vorzulesen. Der LinkedIn-Post, mit dem das begann, war bewusst provokativ geschrieben. Es gibt echte Unterschiede zu einer reinen Umfrage, und das wird sich ändern, wenn die Technologie besser wird und Vertrauen wächst. Ich bin weiter am Thema und überlege, wie ich es integriere.

Die harten Regeln, die KI-Probing brauchbar gemacht haben

Die nützlichsten Learnings waren die Constraints, nicht die Cleverness.

Wir hatten Durchläufe, in denen die KI es gut meinte und eine Frage in Grund und Boden gebohrt hat. Ich habe zwei Wochen versucht, einen sicheren Weg zu finden, Sättigung zu erkennen, und die Antwort, die funktioniert hat, war eine harte Regel: pro Frage höchstens zweimal proben, that's it. Eine zweite Regel folgte: Die Probes müssen einander besonders ähnlich sein, damit die Antworten aggregierbar bleiben.

Das lustigste Learning zeigt, in welche Richtung das Ganze geht. Wir haben die Studie in Tranchen gemacht, nicht alle 60 Personen auf einmal, weil ich wusste, dass die frühen Durchläufe holprig werden. Je mehr Testinterviews wir mit dem Leitfaden führten, den die KI am Ende nutzte, und je mehr echte Antworten ich hörte, desto besser wusste ich, wohin die Probes gehen sollten, und desto weniger musste ich der LLM-Magic überlassen. Am Ende war es im Grunde ein Entscheidungsbaum, in dem die KI den konversationellen Fluff lieferte, damit es sich unterhaltsam anfühlte, während sie keine echten Entscheidungen traf, sondern höchstens zwischen zwei oder drei Optionen wählte. Und genau da fühlte ich mich als Researcher besser, weil ich es kontrollieren konnte. Kontrolle ist ein gutes, und notwendiges, Wort für KI im Moment.

Die wichtigsten Take-aways

1. Struktur und Flow sind eine Spannung, kein Trade-off. Genau planen, dann im Nachhinein entscheiden, wie man mit den Abweichungen umgeht, die die Session wertvoll gemacht haben.
2. Probing wird designt, nicht improvisiert. Vorab festlegen, wo man nachfragt und wo man hilft, egal ob moderiert, unmoderiert oder KI-geführt.
3. Die Interaktion sauber halten. Das Post-Experience-Interview als einen Block nach der Aufgabe, weil Eingriffe mitten im Flow die Leute aus dem natürlichen Verhalten reißen.
4. Bei Time on Task ehrlich sein. Erheben, wenn gefordert, aber vielleicht 80% als Signal und den Rest als Rauschen behandeln.
5. Immer erst SUS, dann NPS. Nicht weil sie perfekt sind, sondern weil ihre Verbreitung Glaubwürdigkeit und Vergleichbarkeit bringt.
6. Tidy Data ist die Voraussetzung, um geglaubt zu werden. Spalten, Zeilen, Zellen, und jede Aussage zurückverfolgbar zu ihrer Quelle.
7. KI-Probing braucht harte Grenzen. Höchstens zwei Probes pro Frage, ähnlich genug zum Aggregieren, und die KI liefert Fluff, keine Entscheidungen.

Weiterlesen

Die KI-Interviewer-Geschichte geht weiter in KI-moderierte Interviews: Das Flickenteppich-Problem, das erklärt, warum inkonsistentes adaptives Nachfragen die Aggregierbarkeit zerstört. Zur Metrik-Seite siehe UX-Messinstrumente über die SUS und andere validierte Skalen. Und für die menschlichen Fähigkeiten, die Struktur nicht ersetzen kann, siehe Die Kunst der Moderation.