KI in UX Research und Discovery

KI in UX Research und Discovery

0:00 Im letzten Modul haben wir Material erhoben — Interviewnotizen, Supportanfragen, Beobachtungen. Jetzt liegt ein Berg unsortierter Text auf dem Tisch, und genau an dieser Stelle kommt künstliche Intelligenz ins Spiel. Sprachmodelle sind hervorragend darin, große Mengen Text zu ordnen, zu bündeln und zusammenzufassen. Was sie nicht können, steht im Leitsatz dieses Moduls: Sie beschleunigen die Auswertung, sie ersetzen nicht die Erhebung.

0:25 Diese Unterscheidung klingt selbstverständlich und wird trotzdem laufend übergangen — weil ein generiertes Ergebnis genauso überzeugend aussieht wie ein erarbeitetes. Wir schauen uns deshalb an, wo der Einsatz sich lohnt und wo er gefährlich wird.

KI in UX Research und Discovery

0:40 Acht Kapitel liegen vor Ihnen, und sie sind bewusst nach steigendem Risiko sortiert. Wir beginnen beim Zusammenfassen und Clustern — das ist unstrittig nützlich. Dann werden Stories abgeleitet, da beginnt die Sorgfaltspflicht. Danach kommen Szenarien und Edge Cases, wo der Einsatz wieder klar lohnt. Und am Ende die beiden heikelsten Themen: generierte Personas und der Datenschutz bei Forschungsdaten. Die Eingabe für all das ist das Material aus Modul zwei.

1:07 Wer ohne echte Erhebung arbeitet, lässt am Ende nur die eigenen Vermutungen clustern — und hält das Ergebnis danach für Forschung.

Interviewnotizen und Nutzerfeedback zusammenfassen

1:15 Fangen wir mit der offensichtlichsten Anwendung an: dem Zusammenfassen. Hier ist der Nutzen groß und die Falle fein. Sie hat mit einer Eigenschaft dieser Modelle zu tun, die auf den ersten Blick wie eine Stärke wirkt. Rohmaterial aus einer Discovery ist unstrukturiert, lang und liegt in fünf verschiedenen Formaten vor — Notizen, Transkripte, Tickets, Screenshots.

1:37 Ein Sprachmodell bringt das in Minuten in Form, wofür ein Mensch Tage braucht. Der Haken liegt in der Qualität, die uns überzeugt: Diese Modelle schreiben flüssig. Und flüssig geschriebene Texte wirken belastbar, auch wenn sie es nicht sind. Das Gegenmittel ist erstaunlich simpel und steht auf der nächsten Folie: Verlangen Sie zu jeder Aussage ein wörtliches Zitat aus der Quelle.

1:59 Damit wird aus einer Erzählung wieder Material, dessen Herkunft sich prüfen lässt. Diese beiden Aufträge unterscheiden sich um vier Sätze, und der Unterschied im Ergebnis ist gewaltig. Der erste erzeugt eine glatte Erzählung, die sich gut liest und nirgends nachprüfen lässt. Der zweite erzwingt Belege, Zeilennummern und ein ausdrückliches Weglassen von allem, was sich nicht belegen lässt.

2:23 Der wertvollste Satz ist aber der letzte: Nenne, was unklar geblieben ist. Sprachmodelle neigen dazu, Lücken zu füllen statt sie zu zeigen — das liegt in ihrer Natur, sie sind darauf trainiert, plausibel weiterzuschreiben. Wer ausdrücklich nach den Lücken fragt, bekommt sie meistens auch genannt. Und Lücken sind Forschungsfragen.

2:43 Der erste Stolperstein ist eine Frage von zehn Minuten Aufwand: die Zusammenfassung weiterreichen, ohne eine Stichprobe gegen die Quelle zu prüfen. Ziehen Sie drei Aussagen und suchen Sie die Belegstelle — das reicht meist, um Vertrauen oder Misstrauen zu begründen. Der zweite ist der psychologische Kern des Kapitels: Flüssige Sprache für Belastbarkeit halten. Wir alle tun das, es ist ein tief sitzender Reflex.

3:07 Und der dritte ist ein inhaltlicher Verlust: Widersprüche im Material glattbügeln lassen. Widersprüche sind aber wertvoll — sie zeigen, dass es verschiedene Nutzungssituationen gibt. Ein harmonischer Bericht über widersprüchliches Material ist kein guter Bericht.

Themen, Probleme und Nutzungsmuster clustern

3:23 Weiter zur zweiten großen Fleißarbeit jeder Auswertung: dem Gruppieren. Wer das schon mal mit Haftnotizen an einer Wand gemacht hat, weiß, wie lange es dauert. Eine Maschine schafft es in Minuten — mit einer wichtigen Einschränkung. Hunderte Feedbackzeilen zu gruppieren ist die klassische Wandtapeten-Arbeit einer Auswertung: zwei Tage, drei Leute, viel Klebstoff.

3:46 Ein Modell macht das in Minuten und schlägt dabei durchaus Kategorien vor, auf die man selbst nicht gekommen wäre — das ist ein echter Gewinn. Aber der Nutzen liegt im ersten Entwurf, nicht im Endergebnis. Der Grund ist grundsätzlicher Natur: Modelle gruppieren nach sprachlicher Ähnlichkeit, nicht nach Ursache. Zwei Zeilen, die beide „das Datumsfeld ist blöd" sagen, können zwei völlig verschiedene Probleme meinen.

4:09 Ähnliche Formulierung heißt eben nicht gleiches Problem — und diesen Unterschied kann nur ein Mensch treffen. Fünf Schritte, die aus einem Entwurf eine Auswertung machen. Lassen Sie die Kategorien benennen statt nummerieren — ein Name zwingt zur Aussage, eine Nummer verbirgt sie. Ziehen Sie je Cluster drei Originalzeilen und lesen Sie gegen; dabei fällt sehr schnell auf, wo die Sprache passt und die Ursache nicht.

4:34 Cluster mit verschiedenen Ursachen lösen Sie auf. Und dann Schritt vier, mein Favorit: Sehen Sie sich die Restkategorie an. Dort steckt regelmäßig das Unerwartete, weil dort landet, was ins Muster nicht passte. Das Zählen kommt zuletzt — wer vorher zählt, verteidigt anschließend die Größe seiner Cluster statt die Zuordnung zu prüfen.

4:55 Der erste Stolperstein ist ein Reihenfolgefehler mit großer Wirkung: die Clustergröße als Priorität lesen, bevor die Zuordnung geprüft ist. Ein großes Cluster kann schlicht aus einem sprachlichen Zufall entstanden sein. Der zweite: die Restkategorie wegwerfen, weil sie unordentlich aussieht. Sie ist unordentlich, weil sie interessant ist. Und der dritte ist der methodisch heikelste — zweimal clustern lassen und die Fassung nehmen, die besser gefällt.

5:21 Das ist verständlich, aber damit wählen Sie nicht das bessere Ergebnis, sondern das angenehmere. Wenn Sie zweimal clustern, dann um zu sehen, wie instabil die Cluster sind. Diese Erkenntnis ist wertvoller als jede der beiden Fassungen.

User Stories und Jobs-to-be-Done ableiten

5:36 Jetzt kommt das Kapitel mit dem größten stillen Risiko dieses Moduls. Denn ab hier wandert das Ergebnis in die Planung — und dort verliert es unterwegs die Information, wo es eigentlich herkommt. Aus geclustertem Material lassen sich Stories erzeugen, und das funktioniert erstaunlich gut. Genau deshalb beginnt hier die Sorgfaltspflicht.

5:56 Denn eine Story, die aus fünf Interviews stammt, und eine Story, die das Modell sinnvoll ergänzt hat, sehen absolut identisch aus. Beide sind gut formuliert, beide klingen plausibel, beide passen ins Backlog-Format. Der Unterschied ist unsichtbar — und er ist der wichtigste. Deshalb die klare Regel: Zu jeder generierten Story gehört ein Herkunftsfeld.

6:17 Ohne das wandert eine Erfindung in die Sprintplanung und wird dort behandelt wie eine belegte Anforderung. Niemand hat betrogen, die Information ist nur unterwegs verloren gegangen. Diese Tabelle ist im Grunde eine Ampel. Mehrfach beobachtet heißt grün — das können Sie einplanen. Einmal genannt ist gelb: ein Hinweis, kein Befund, vor der Planung nachprüfen.

6:40 Supportdaten sind ein Sonderfall, den wir schon kennen: Der Ort ist bekannt, die Ursache offen, also mit einer Beobachtung ergänzen. Und vom Modell ergänzt ist rot — eine Vermutung, die gekennzeichnet und geprüft werden muss. Das Schöne an diesem Schema: Es kostet ein einziges zusätzliches Feld im Ticket. Der Aufwand ist minimal, und er entscheidet darüber, ob Ihre Planung auf Beobachtungen oder auf plausiblen Sätzen beruht.

7:07 Der erste Stolperstein ist der direkte Weg ins Problem: generierte Stories ohne Herkunftsfeld ins Backlog übernehmen. Ab dann ist die Information weg, unwiederbringlich. Der zweite ist eine Verwechslung von Form und Gehalt: Aus einer einzelnen Nennung wird eine Anforderung, weil sie gut formuliert ist. Sprachmodelle formulieren alles gut, auch das Dünne.

7:28 Und der dritte ist der schleichende: Die Kennzeichnung wird nach zwei Wochen weggelassen, weil sie im Ticketsystem stört und Platz kostet. Das ist der Moment, in dem eine Vermutung ihren Status verliert. Halten Sie die Kennzeichnung durch — sie ist billig und sie ist irgendwann Ihr einziger Schutz.

Alternative Nutzungsszenarien erzeugen

7:45 Nach dem riskantesten Kapitel jetzt das unstrittigste. Beim Erzeugen von Varianten spielt die Maschine ihre Stärke aus, ohne dass ein echtes Risiko entsteht — weil hier vorschlagen und entscheiden sauber getrennt bleiben. Modelle sind ausgesprochen stark darin, Varianten zu produzieren. Was passiert, wenn die Fahrt ausfällt, während der Reisende schon unterwegs ist?

8:07 Was, wenn zwei Personen dieselbe Buchung ändern wollen? Was, wenn das Telefon unterwegs leer ist? Solche Fälle kosten im Workshop viel Diskussionszeit und lassen sich hervorragend vorbereiten. Der entscheidende Punkt ist die Rollenverteilung: Die Maschine schlägt vor, das Team entscheidet, welche Fälle das Produkt tragen soll.

8:25 Diese Entscheidung wird durch einen breiteren Vorschlagsraum nicht schlechter — im Gegenteil. Sie wird nur besser informiert getroffen, und zwar zu deutlich geringeren Kosten als in einer Diskussionsrunde. Vier Gründe, warum ich diesen Einsatz uneingeschränkt empfehle. Das Erzeugen von Varianten ist Fleißarbeit, das Auswählen ist die Fachaufgabe — und die bleibt bei Ihnen.

8:48 Ein breiter Vorschlagsraum verhindert die frühe Festlegung auf den ersten Einfall, und diese frühe Festlegung ist eine der zähesten Kräfte in Workshops. Das Ergebnis ist unkritisch: Ein schlechtes Szenario wird verworfen, mehr passiert nicht. Es gibt keine stille Fehlinformation wie bei den Stories. Und die Diskussion startet bei zwanzig Fällen statt bei drei — das verschiebt die ganze Qualität des Gesprächs. Sie priorisieren dann, statt zu brainstormen.

9:15 Der erste Stolperstein ist ein Mengenproblem: Alle zwanzig vorgeschlagenen Szenarien umsetzen wollen. Ein Vorschlag ist keine Verpflichtung; die Priorisierung bleibt Ihre Arbeit. Der zweite: Die Liste als vollständig behandeln. Sie ist ein Vorschlag, keine Analyse — es fehlt garantiert etwas, und zwar besonders das, was in Trainingsdaten selten vorkommt.

9:37 Und der dritte führt uns zurück zu Modul zwei: Szenarien ohne Nutzungskontext bewerten. Wer den Bahnsteigfall vergisst, hält ein Szenario für unrealistisch, das im Alltag ständig eintritt. Bewerten Sie Vorschläge immer gegen den Kontext-Steckbrief, nicht gegen die eigene Vorstellung vom Nutzer.

Edge Cases und übersehene Nutzergruppen

9:55 Damit zu einem Einsatz, der für dieses Seminar besonders passt: der gezielten Suche nach dem blinden Fleck. Denn genau darin sind wir Menschen schlecht — im Erkennen dessen, woran wir gar nicht gedacht haben. Ein blinder Fleck hat die unangenehme Eigenschaft, dass man ihn nicht sieht — sonst wäre er keiner. Genau hier kann ein Modell nützlich sein, weil es aus einem viel breiteren Erfahrungsraum schöpft als Ihr Team.

10:20 Der Auftrag lautet: Nenne Personengruppen, die mit diesem Ablauf Schwierigkeiten hätten, und begründe jeweils, warum. Was zurückkommt, ist zu zwei Dritteln erwartbar. Aber im letzten Drittel finden sich Gruppen, an die im Projekt niemand gedacht hat — Menschen ohne dauerhafte Adresse, Personen mit gesetzlicher Betreuung, Reisende ohne Smartphone.

10:40 Dieses Drittel rechtfertigt den Aufwand. Es muss trotzdem geprüft werden. Die obere Frage ist zu allgemein — sie bekommt eine allgemeine Antwort, meist eine Aufzählung bekannter Barrierekategorien. Die untere Fassung arbeitet mit vier Kunstgriffen. Eine feste Zahl zwingt das Modell über die naheliegenden Fälle hinaus. Die Begründungspflicht je Gruppe macht die Antwort prüfbar statt behauptend.

11:04 Die Sortierung nach Häufigkeit erzeugt eine Diskussionsgrundlage — Achtung, sie ist eine Schätzung des Modells und kein Befund. Und die Aufforderung, Unsicherheit zu markieren, liefert Ihnen die Stellen, an denen Sie zuerst nachsehen sollten. Merken Sie sich dieses Muster: Zahl vorgeben, Begründung verlangen, Unsicherheit einfordern. Es funktioniert bei fast jeder Fragestellung.

11:27 Der erste Stolperstein ist der Statuswechsel, der uns in diesem Modul immer wieder begegnet: Die genannten Gruppen werden als erhoben behandelt statt als Vermutung. Es ist eine Liste, kein Forschungsergebnis. Der zweite ist eine Verengung — nur nach Behinderungen fragen und Lebenslagen auslassen. Kein Konto, kein Drucker, kein fester Wohnsitz, keine gemeinsame Sprache: Das sind Barrieren, die in keiner Prüfliste stehen und trotzdem den Abschluss verhindern.

11:54 Und der dritte ist der ernüchterndste: die Liste abarbeiten, ohne je mit einer der Gruppen gesprochen zu haben. Dann haben Sie eine Vorstellung von den Menschen entwickelt, aber keine Kenntnis.

Generierte Personas und synthetische Nutzer

12:05 Jetzt zum Thema, das derzeit am stärksten beworben wird und meine deutlichste Warnung bekommt: künstliche Nutzer. Die Idee ist verführerisch — Nutzerforschung ohne Terminfindung. Und sie hat einen strukturellen Fehler. Eine generierte Persona bildet ab, was in den Trainingsdaten häufig war. Sie bildet nicht ab, was Ihre Nutzenden tun.

12:26 Das ist ein feiner, aber entscheidender Unterschied — Sie bekommen den Durchschnitt des Internets, nicht Ihr Publikum. Noch einen Schritt weiter geht die Idee, einen Nutzer simulieren zu lassen und ihm die Anwendung vorzulegen. Das Modell antwortet dann auf Ihre Frage, nicht auf die Wirklichkeit. Es wird nie ungeduldig, es versteht jedes Fachwort, es bricht nie ab. Und damit fällt genau das weg, was Sie in einem Test eigentlich suchen.

12:52 Die Ungeduld ist nicht der Störfaktor — sie ist der Befund. Lesen Sie die rechte Spalte, das ist die Bilanz. Abbruchgründe bleiben unsichtbar, weil der simulierte Nutzer bis zum Ende bleibt. Sprachprobleme fallen nicht auf, weil er jedes Fachwort versteht — auch das, das Ihre Kundschaft noch nie gehört hat. Barrieren treten nicht auf, weil überhaupt keine Technik im Spiel ist: kein Screenreader, keine Vergrößerung, keine wackelige Mobilverbindung.

13:20 Und überraschende Wege gibt es nicht, weil das Modell den erwarteten Weg nimmt. Damit fehlen genau die vier Dinge, wegen derer man testet. Ein simulierter Test bestätigt zuverlässig Ihren Entwurf — und das ist kein Ergebnis, sondern ein Echo. Der erste Stolperstein ist wieder der Statuswandel: Generierte Personas werden später als Forschungsergebnis zitiert. Nach drei Monaten weiß niemand mehr, woher sie kamen.

13:44 Der zweite ist der Auslöser dafür — die Kennzeichnung als generiert fällt weg, sobald das Dokument geteilt wird, weil es dann ordentlicher aussehen soll. Schreiben Sie es in den Titel, nicht in die Fußnote. Und der dritte ist der schwerwiegendste: einen simulierten Testlauf als Ersatz für eine Sitzung mit Menschen führen.

14:03 Als Vorbereitung einer echten Sitzung kann das nützlich sein — als Ersatz erzeugt es Sicherheit ohne Grundlage, und das ist gefährlicher als gar kein Test.

Datenschutz und Vertraulichkeit bei Forschungsdaten

14:12 Bleibt ein Kapitel, das gern als Formalie behandelt wird und in diesem Feld besonders ernst ist. Denn Forschungsdaten aus Barrierefreiheitsstudien sind fast immer mehr als gewöhnliche personenbezogene Daten. Ein Interviewmitschnitt enthält personenbezogene Daten — so weit, so bekannt. In unserem Feld kommt aber etwas hinzu: Sobald jemand über seine Behinderung, seine Sehfähigkeit oder seine Medikation spricht, liegen Gesundheitsdaten vor.

14:38 Das ist keine Formalie, das ändert die Rechtsgrundlage und die Anforderungen an die Verarbeitung. Bevor also irgendetwas davon in ein Modell wandert, brauchen Sie drei Dinge geklärt: eine Rechtsgrundlage, eine belastbare Aussage darüber, was der Dienst speichert und ob er auf Eingaben trainiert, und eine ordentliche Pseudonymisierung.

14:58 Das ist kein Grund, auf die Werkzeuge zu verzichten. Es ist ein Grund, vorher fünf Minuten nachzudenken. Fünf Schritte, die sich in der Praxis bewährt haben. Zuerst klären, welcher Dienst verarbeitet und ob er auf Eingaben trainiert — das steht in den Nutzungsbedingungen und unterscheidet sich zwischen Privat- und Geschäftstarifen erheblich.

15:18 Dann Namen, Orte, Arbeitgeber und Fallnummern durch Platzhalter ersetzen. Gesundheitsangaben behalten Sie nur, wenn die Fragestellung sie wirklich braucht. Schritt vier ist der, der über alles entscheidet: Die Zuordnungstabelle gehört getrennt und zugriffsbeschränkt abgelegt. Liegt sie im selben Dokument, haben Sie nicht pseudonymisiert, sondern nur umbenannt.

15:38 Und Schritt fünf: eine Löschfrist festlegen und im Forschungsplan notieren, sonst liegt das Material in fünf Jahren noch herum. Der erste Stolperstein passiert täglich und fast unbemerkt: Screenshots aus der Produktivumgebung hochladen. Auf so einem Bild stehen echte Namen, echte Buchungsnummern, manchmal komplette Adressen — man sieht sie nur nicht mehr, weil man sie tausendmal gesehen hat.

16:02 Der zweite ist der eben erwähnte: pseudonymisieren und die Zuordnung im selben Dokument stehen lassen. Das ist die häufigste Fehlanwendung überhaupt. Und der dritte ist ein rechtlicher: die Einwilligung für die Erhebung mit der für die Verarbeitung verwechseln. Wer dem Interview zugestimmt hat, hat nicht automatisch zugestimmt, dass sein Transkript in ein Sprachmodell wandert. Das gehört ins Einwilligungsformular, und zwar vorher.

Übung — aus verstreutem Feedback einen Problemraum bauen

16:27 In der Übung machen Sie den ganzen Weg dieses Moduls einmal selbst — und zwar mit dem Prüfschritt, der im Alltag so gern wegfällt. Sie werden dabei sehen, wie wackelig maschinelle Cluster tatsächlich sind. Sie bekommen achtzig Zeilen verstreutes Feedback und machen daraus einen geprüften Problemraum. Geübt wird dabei nicht das Clustern — das macht die Maschine — sondern das Gegenprüfen: eine maschinell erzeugte Auswertung gegen das Rohmaterial halten und daraus belastbare Hypothesen ableiten.

16:55 Erfolgreich sind Sie mit drei Hypothesen samt Schwelle und drei offenen Forschungsfragen, wobei jede Hypothese auf mindestens zwei Originalzeilen zurückführbar sein muss. Wer schnell fertig ist, lässt dasselbe Material ein zweites Mal clustern und vergleicht. Das ist der lehrreichste Teil der Übung: Die Cluster sind nicht stabil, und das glaubt man erst, wenn man es selbst gesehen hat.

17:17 Der Ablauf spiegelt genau das, was wir besprochen haben: clustern mit Belegpflicht, dann je Cluster drei Originalzeilen ziehen und gegenlesen, dann auflösen oder zusammenlegen, wo es nicht passt. Danach formulieren Sie drei Hypothesen mit Wirkung und Schwelle — genau in der Form aus Modul zwei. Der fünfte Schritt ist die eigentliche Prüfung Ihrer Arbeit: drei Fragen notieren, die nur eine echte Erhebung beantworten kann.

17:41 Wer keine einzige offene Frage findet, hat das Material nicht gelesen, sondern nur die Zusammenfassung. Diese drei Fragen sind übrigens das wertvollste Ergebnis der Stunde — sie sagen Ihnen, wo Sie als Nächstes hinschauen müssen. Der erste Stolperstein ist der, der in der echten Projektarbeit fast immer eintritt: Die Cluster werden übernommen und der Gegenlesen-Schritt aus Zeitgründen gestrichen.

18:04 Damit haben Sie die Auswertung nicht beschleunigt, sondern ausgelassen. Der zweite: Hypothesen ohne Schwelle. Wir hatten das in Modul zwei — ohne Schwelle bleibt es eine Meinung mit besserer Grammatik. Und der dritte ist verräterisch: die offenen Fragen weglassen, weil das Ergebnis dann vollständiger wirkt. Genau umgekehrt.

18:23 Ein Bericht ohne offene Fragen ist nicht vollständig, sondern unehrlich — und erfahrene Leser erkennen das sofort. Vier Punkte. Erstens: Die Belegpflicht im Auftrag ist der Unterschied zwischen Material und Erzählung — vier Sätze im Prompt, große Wirkung. Zweitens: Cluster sind ein erster Entwurf und zwischen zwei Läufen nicht stabil; behandeln Sie sie entsprechend.

18:46 Drittens: Jede generierte Story braucht ein Herkunftsfeld, sonst wird aus einer Vermutung unbemerkt eine Anforderung. Und viertens: Vor der Verarbeitung bereinigen, denn sobald Behinderungen zur Sprache kommen, liegen Gesundheitsdaten vor. Der Rahmensatz zum Schluss: Nichts in diesem Modul ersetzt die Erhebung aus Modul zwei. Es beschleunigt ihre Auswertung — und das ist schon viel wert.