Die Jury

Diese Woche saß ich in einer Jury. Es ging um die Vergabe eines Jugend-Kunst-Preises, also um junge Menschen, die etwas gemacht haben, das ihnen wichtig ist, und um eine Runde von Erwachsenen, die herausfinden soll, was da eigentlich passiert ist. Der Anteil der Sitzung, der aus Anschauen besteht, ist der einfache. Der Anteil, der aus Fragen besteht, ist der schwierige.

Ich wollte gute Fragen stellen. Nicht originelle, nicht clevere, sondern solche, die etwas hervorholen, das ich vorher nicht wusste. Das ist, wenn man ehrlich ist, exakt dasselbe Problem wie im UX Research. Also habe ich mich an dem orientiert, was ich kenne: Interviewfragen aus der Nutzendenforschung. Und weil das schnell gehen sollte, habe ich sie mir mit einem LLM erarbeiten lassen.

Das Ergebnis war korrekt und trotzdem unbrauchbar

Was zurückkam, sah gut aus. Höflich, neutral, sauber formuliert, keine offensichtliche Suggestion. Und trotzdem war es genau das, was ich für mich intern „Median-Output“ nenne: der Durchschnitt aller Fragen, die man zu diesem Thema stellen könnte. „Erzähl mir etwas über deinen Arbeitsprozess.“ „Was war die größte Herausforderung?“ „Was möchtest du mit der Arbeit ausdrücken?“

Das sind keine Interviewfragen. Das sind Überschriften.

Interessanterweise ist die Neutralität selbst ein Teil des Problems. Trevor Calabro, UX-Researcher und Autor des Newsletters UX Research in the Wild, hat dafür im Dezember 2025 einen guten Begriff geprägt. Er schreibt: „Instead of unintentional leading questions, I think what we are seeing is unintentional over-neutrality.“ Unbeabsichtigte Über-Neutralität also. Wer viel mit LLMs arbeitet, trainiert sich an, jede Anweisung von Kontext, Szenario und Richtung zu befreien, weil das Modell sonst schlechter antwortet. Menschen brauchen aber genau das Gegenteil. Sie brauchen eine Szene, einen Moment, eine Richtung, an der entlang sie sich erinnern können. Eine Frage ohne Kontext bekommt eine Antwort ohne Kontext. Das ist keine Bosheit des Modells, sondern eine Übertragung, die man erst bemerkt, wenn man sie einmal gesehen hat.

Und die dritte Frage oben, die nach dem, was die Künstlerin ausdrücken wollte, ist obendrein handwerklich falsch. Sie verlangt von der befragten Person, meine Arbeit zu übernehmen. Dazu gleich mehr.

Dann habe ich angefangen zu suchen: 14 Fehlerkriterien aus der Forschung

Gefunden habe ich ein Paper von Yuchen Shen, Anmol Singhal und Travis Breaux von der Carnegie Mellon University, vorgestellt auf der IEEE International Requirements Engineering Conference 2025 (arXiv:2507.02858). Die Autoren untersuchen, ob ein LLM in Anforderungsinterviews brauchbare Nachfragen erzeugen kann.

Der eigentliche Schatz steckt aber nicht im Ergebnis, sondern im Zwischenschritt. Die Autoren haben vierzehn Publikationen aus Requirements Engineering, HCI und Software Engineering durchgesehen und daraus 28 Fehlerkriterien für Interviewfragen synthetisiert. Vierzehn davon haben sie ausgewählt, in zwei Kategorien.

Kategorie 1: Fehler bei Nachfragen

Kategorie 2: Fehler in der Formulierung

Nichts davon ist überraschend, wenn man es liest. Alles davon macht man trotzdem, wenn man zuhört und gleichzeitig denken muss.

Und dann habe ich die Liste in den Prompt gepackt

Nicht als Inspiration, sondern als Regelwerk: Halte dich daran, prüfe jede Frage gegen diese vierzehn Kriterien, gib mir nur, was durchkommt.

Der Unterschied war deutlich. Aus „Was war die größte Herausforderung?“ wurde „Erzähl mir von dem Moment, an dem du die Arbeit fast anders gemacht hättest. Was hätte sich geändert?“ Aus der Frage nach der Aussageabsicht wurde eine Frage danach, was jemand zuerst sieht, der die Arbeit nicht kennt, und ob das dem entspricht, was gedacht war. Fragen, die einen Ort haben. Fragen, auf die man mit einer Geschichte antworten kann statt mit einer Zusammenfassung.

Das deckt sich mit den Zahlen im Paper, und die sind für mich der eigentliche Punkt. In der ersten Studie, ohne Regelwerk, waren die vom Modell erzeugten Nachfragen statistisch nicht besser und nicht schlechter als die von geschulten Interviewenden. Unentschieden. In der dritten Studie, mit den Fehlerkriterien als Vorgabe, wurden die Fragen des Modells in 87 von 128 Paarvergleichen bevorzugt. Bei Relevanz, Klarheit und Informationsgehalt lagen sie durchgehend vorn, alle Unterschiede signifikant.

Im Abstract fassen die Autoren beide Befunde in einem Satzpaar zusammen: „LLM-generated questions are no worse than the human-authored questions with respect to clarity, relevancy, and informativeness.“ Und: „LLM-generated questions outperform human-authored questions when guided by common mistakes types.“

| | Erste Studie: ohne Regelwerk | Dritte Studie: mit den 14 Kriterien | |---|---|---| | Verglichen mit | geschulten Interviewenden | geschulten Interviewenden | | Ergebnis | statistisch unentschieden | 87 von 128 Paarvergleichen bevorzugt | | Relevanz, Klarheit, Informationsgehalt | kein Unterschied | durchgehend vorn | | Signifikanz | keine Unterschiede | alle Unterschiede signifikant | | Modell und Aufgabe | identisch | identisch |

Gleiches Modell. Gleiche Aufgabe. Der Unterschied liegt vollständig im Harness.

Zwei Details, die ich ehrlich finde

Erstens: Kriterium 11, das Fragen nach Lösungen, musste dem Modell mit einem Beispiel erklärt werden, weil es sonst nicht zuverlässig griff. Shen, Singhal und Breaux formulieren es sinngemäß so: Es ist unangemessen, Nutzende zu fragen, wie ein Feature gestaltet sein sollte oder wie eine ideale Oberfläche aussähe. Das ist die direkte Entsprechung zu meiner Jury-Frage nach der Aussageabsicht. Beide verlangen von der befragten Person, die Arbeit des Fragenden zu übernehmen. Interpretation ist mein Job, nicht der der Künstlerin.

Zweitens: Als das Modell alle vierzehn Fehler gleichzeitig vermeiden sollte, gelang das nur bei einer von dreißig Fragen vollständig. Immerhin vermieden 28 von 30 mindestens elf. Einen Fehler auf Ansage wegzuoptimieren ist also leicht. Alle vierzehn im Blick zu behalten, während man zuhört, bleibt schwer. Für Maschinen wie für Menschen. Genau deshalb ist eine Jurysitzung anstrengend, und ich finde es beruhigend, dafür jetzt eine Zahl zu haben.

Ein drittes Detail für alle, die Prompts bauen: Die Autoren mussten die Kriterien von negativer in positive Formulierung übersetzen, weil LLMs mit Verneinungen schlecht umgehen. Also nicht „versäume es nicht, nach Alternativen zu fragen“, sondern „eine gute Nachfrage sucht nach Alternativen“. Außerdem hat allein das Großschreiben der Rollenbezeichnungen im Prompt die Fehlerrate messbar gesenkt, weil das Modell sonst Interviewende und Befragte verwechselte. Robustheit hängt an solchen Kleinigkeiten.

Die eigentliche Lektion

Ich merke, wie oft ich inzwischen bei derselben Beobachtung lande. Ein LLM ist kein Werkzeug, das man bedient, sondern eines, das man einspannt. Ohne Harness zieht es in die Mitte der Verteilung, weil die Mitte statistisch die sicherste Antwort ist. Das sieht dann aus wie ein Ergebnis, ist aber nur ein Durchschnitt.

Das Harness ist die eigentliche Arbeit. In diesem Fall waren es vierzehn Zeilen aus einem Paper. In anderen Fällen ist es eine Quellenhierarchie, eine Prüfschleife, ein Kriterienkatalog. Immer ist es etwas, das jemand vorher durchdacht hat und das explizit gemacht wurde. Der Prompt ist der Zügel. Das Harness ist das, woran der Zügel überhaupt erst befestigt ist. Für Entwicklungsteams habe ich denselben Punkt in AI-Dev#1 beschrieben; wie ich das in Projekten begleite, steht auf der Seite zur KI-gestützten Entwicklung.

Und die schöne Nebenwirkung: Die vierzehn Regeln haben nicht nur meine Prompts verbessert. Sie haben meine eigenen Fragen in der Sitzung verbessert. Die Checkliste funktioniert offline.

Kompakt zum Mitnehmen: die vierzehn Fehler auf einen Blick

| Der Fehler | Woran du ihn in der Sitzung merkst | |---|---| | Annahmen nicht aufdecken | Du nickst bei einem „natürlich“ | | Keine Alternativen | Niemand fragt, was noch möglich gewesen wäre | | Keine Klärung bei Unklarheit | Du hoffst, dass es später klar wird | | Keine Klärung bei Widersprüchen | Dir fällt es auf, du sagst nichts | | Implizites Wissen nicht heben | Alle reden über das Sichtbare | | Generische Frage | Die Frage passt auch auf jede andere Arbeit | | Zu lange Frage | Rückfrage: „Wie war die Frage nochmal?“ | | Jargon | Höfliches Nicken ohne Antwort | | Technische Frage | Die Antwort beginnt mit „Ich glaube“ | | Falsches Profil | Betretenes Schweigen | | Nach Lösungen fragen | Du bittest um Interpretation deiner Aufgabe | | Mehrere Fragen in einer | Nur der zweite Teil wird beantwortet | | Mehrdeutige Frage | Zwei Personen verstehen sie verschieden | | Frage ohne Kontext | Die Antwort ist eine Gegenfrage |

Wer selbst hineinschauen möchte: Shen, Singhal, Breaux, Requirements Elicitation Follow-Up Question Generation, arXiv:2507.02858. Der Anhang mit den 28 ursprünglichen Kriterien liegt im zugehörigen Repository.

Falls du eine ähnliche Liste für andere Formate hast, Retrospektiven, Bewerbungsgespräche, Elterngespräche, schreib mir. Ich sammle Harnesses.

Ein Bürger fragt: „Wann wird das Altpapier abgeholt?" Der Bot antwortet freundlich, präzise und vollkommen falsch. Er liefert den Abfuhrkalender der Pappelstraße. Der Bürger wohnt in der Häfkerstraße.

Was ist passiert? Eine Ähnlichkeitssuche hat gefunden, was ähnlich klingt. Papier, Pappel, passt schon. Für die Mathematik ein Treffer. Für den Bürger eine falsche Auskunft. Und für das Vertrauen in den Bot der Anfang vom Ende.

Ich habe in den letzten Monaten einen Chatbot für eine Kommune gebaut: chat-weyhe.de beantwortet Fragen von Bürgerinnen und Bürgern der Gemeinde Weyhe. Öffnungszeiten, Ausweise, Kitas, Abfuhrtermine, Vereine, Ortsgeschichte. In diesem Artikel geht es nicht um Tools oder Frameworks. Es geht um die Konzepte dahinter. Denn die wichtigste Lektion des Projekts lautet: Das Sprachmodell ist der einfachste Teil. Die eigentliche Arbeit steckt in allem, was drumherum passiert.

Die acht Konzepte im Überblick

| # | Konzept | Kernregel | |---|---|---| | 1 | Wissen einsammeln | Struktur retten statt verflachen, laute Fehler statt stiller | | 2 | Vertrauensreihenfolge | Fünf Quellen in fester Rangfolge, geprüfte oben | | 3 | Türsteher | Zuständigkeit klären, bevor Teures passiert | | 4 | Folgefragen | Frage erst eigenständig machen, dann suchen | | 5 | Deterministische Netze | Exakte Schlüssel exakt abfragen, ohne KI | | 6 | Ähnlichkeit ist kein Wissen | Lücke per Prüfschritt feststellen, nicht per Schwellwert | | 7 | Weglassen statt ermahnen | Was nicht im Kontext steht, kann nicht falsch zitiert werden | | 8 | Sichere Ausfallrichtung | Jeder Fehlerpfad endet konservativ, nie im Raten |

Das Ziel: Vertrauen, nicht Technikschau

Das Ziel eines Organisations-Chatbots ist nicht „Wir haben jetzt auch KI". Das Ziel ist: Menschen bekommen schnell eine richtige Antwort. Rund um die Uhr, ohne Warteschleife, ohne Verwaltungsdeutsch.

Das entscheidende Wort ist „richtig". Daraus folgt die härteste Anforderung des ganzen Projekts: Eine falsche Antwort ist schlimmer als keine Antwort. Erfundene Öffnungszeiten, ein falscher Abfuhrtermin, eine ausgedachte Telefonnummer. Jeder dieser Fehler kostet Vertrauen, und Vertrauen ist die einzige Währung, in der so ein Bot bezahlt wird. Deshalb zieht sich ein Leitmotiv durch die gesamte Architektur: Der Bot darf lieber nachfragen als raten. Und er darf ehrlich sagen, dass er etwas nicht weiß.

Was mir wichtig war

Vier Dinge standen für mich fest, bevor die erste Zeile Code entstand.

Korrektheit vor Eloquenz. Sprachmodelle formulieren wunderbar. Das ist ihr Charme und ihre Gefahr, denn eine falsche Antwort klingt genauso überzeugend wie eine richtige. Die Architektur muss dafür sorgen, dass das Modell nur über Dinge sprechen kann, die es tatsächlich weiß.

Ehrlichkeit als Feature. „Das weiß ich nicht, frag bitte im Bürgerbüro nach" ist keine Schwäche. Es ist eine der wertvollsten Antworten, die der Bot geben kann.

Souveränität als Architekturentscheidung. Bürgerfragen sind sensibel. Deshalb: ein europäisches Sprachmodell, eine selbst betriebene Suchmaschine, eine eigene Datenbank, keine gespeicherten IP-Adressen. Souveränität steht bei diesem Projekt nicht in den Datenschutzhinweisen. Sie steht im Code.

Der Ton macht die UX. Der Bot hat eine klare Persona: ein guter Freund, der sich im Ort auskennt. Er duzt, er ist warm im Ton und trotzdem sachlich. Und er ist transparent: Jede Antwort zeigt ihre Quellen, und ein Hinweis macht klar, dass hier eine KI antwortet.

Konzept 1: Wissen einsammeln, ohne es zu zerstören

Ein Chatbot ist nur so gut wie seine Wissensbasis. Die Grundidee ist unter dem Namen Retrieval Augmented Generation (RAG) bekannt und schnell erklärt: Inhalte aus den eigenen Quellen werden gesammelt, in kleine Abschnitte zerlegt und so gespeichert, dass sie sich nach Bedeutung durchsuchen lassen. Bei einer Frage werden die passendsten Abschnitte herausgesucht und dem Sprachmodell als einzige Grundlage mitgegeben.

Klingt einfach. Ist es nicht. Denn das Einsammeln ist vor allem Fehlerarbeit. Mein teuerster Bug: Beim Bereinigen der Seiten sollten Cookie-Banner entfernt werden. Ein Content-Management-System markiert den sichtbaren Cookie-Hinweis aber ausgerechnet am äußersten Rahmen der Seite. Die Bereinigung löschte deshalb nicht den Banner, sondern die komplette Seite. Acht von neun Infoseiten eines Entsorgers kamen leer an, darunter ausgerechnet die Sperrmüll-Anmeldung. Die landete damit selbst im Sperrmüll. Und niemand hat es gemerkt, weil leere Seiten stillschweigend übersprungen wurden.

Daraus habe ich drei Prinzipien abgeleitet:

• Laute Fehler statt stiller. Eine Seite, aus der nichts extrahiert wurde, ist ein Fehler und kein Achselzucken.
• Sicherheitsstopps. Liefert ein Durchlauf plötzlich nur noch die Hälfte der bisherigen Inhalte, wird nichts gelöscht und nichts ersetzt. Ein abgebrochener Lauf darf niemals einen guten Datenbestand wegräumen.
• Struktur retten statt verflachen. Ein Abfuhrkalender ist kein Fließtext, sondern eine Tabelle mit einem Schlüssel, nämlich der Straße. Wer diese Struktur beim Einsammeln als Metadaten bewahrt, kann später exakt abfragen statt ungefähr suchen. Genau das rettet den Bürger aus der Pappelstraße.

Konzept 2: Nicht ein Weg zur Antwort, sondern eine Vertrauensreihenfolge

Der Bot hat fünf Wege zu einer Antwort, und sie sind streng geordnet:

| Rang | Quelle | Beispiel | Verlässlichkeit | |---|---|---|---| | 1 | Deterministische Fakten | Abfuhrkalender je Straße | exakt, kein „ungefähr" | | 2 | Kuratierte Fakten | kanonische Kontaktdaten der Gemeinde | handgepflegt, überlebt jeden Neuimport | | 3 | Wissensbasis | eingesammelte Inhalte der Websites | gut, aber ähnlichkeitsbasiert | | 4 | Live-Daten | Wetter | aktuell, nie aus der Datenbank | | 5 | Freies Internet | alles Übrige | Notlösung, sichtbar als „nicht amtlich" markiert |

Ganz oben stehen harte Fakten, die deterministisch abgefragt werden. Hier gibt es kein „ungefähr". Darunter liegen kuratierte Fakten: handgepflegte Dokumente für Dinge, die auf keiner Website sauber stehen. Sie überleben jeden automatischen Neuimport. Dann folgt die eigentliche Wissensbasis aus den eingesammelten Inhalten. Daneben gibt es Live-Daten: Das Wetter kommt nie aus der Datenbank, denn gespeichertes Wetter ist wie eine Zeitung von gestern, nur aufwendiger. Und ganz unten, nur als Notlösung, steht das freie Internet. Es wird nur befragt, wenn die eigene Basis die Frage nachweislich nicht beantworten kann, und jede Antwort daraus trägt ein deutliches Warnschild: nicht amtlich.

Diese Reihenfolge ist eine Vertrauensordnung, und sie zieht sich bis in die Antwort durch. Geprüfte Quellen stehen im Kontext oben, Internetfunde unten und markiert.

Konzept 3: Ein Türsteher vor der teuren Technik

Bevor irgendetwas Aufwendiges passiert, prüft der Bot, ob die Frage überhaupt zu ihm gehört. Gestaffelt von billig nach teuer: erst einfache Muster (nein, er schreibt keine Gedichte und löst keine Mathe-Hausaufgaben), dann eine Liste lokaler Schlüsselwörter, dann erlaubte Allgemeinfragen, und erst ganz am Ende eine semantische Prüfung. Der Bot klärt also zuerst seine Zuständigkeit. Für einen kommunalen Bot ist das fast schon rührend authentisch.

Wichtig dabei: Jede Ablehnung wird mit Grund und Konfidenz protokolliert. Die Grenzfälle von heute sind das Material, mit dem die Regeln von morgen besser werden.

Konzept 4: Folgefragen sind ein eigenes Problem

„Und wann Papier?" Ohne Gesprächsverlauf ist diese Frage sinnlos. Mit ungeprüftem Verlauf wird sie gefährlich, denn alte Themen und womöglich alte Fehler verunreinigen die Suche. Auf die Frage nach dem Bürgermeister von 1997 kann schließlich ein komplett neues Thema folgen.

Deshalb entscheidet ein vorgeschalteter, bewusst günstiger Schritt zwei Dinge: Ist das eine Folgefrage oder ein Themenwechsel? Und wie lautet die Frage als eigenständige, vollständige Suchanfrage? Aus „Und wann kommt Papier?" wird so „Wann wird das Altpapier in der Häfkerstraße abgeholt?". Erst diese Frage geht in die Suche.

Konzept 5: Deterministische Netze unter dem Sprachmodell

Für Fakten mit exakter Schlüsselstruktur ist eine exakte Abfrage der Ähnlichkeitssuche haushoch überlegen. Also werden Straßennamen normalisiert (Straße, Strasse und Str. sind dasselbe Wort), Tippfehler tolerant behandelt (die „Häferkstraße" findet trotzdem die Häfkerstraße), und wenn gar keine Straße genannt wurde, übernimmt der Bot die zuletzt von der Person genannte Straße aus dem Verlauf.

Ein Detail daran ist mir besonders wichtig: Übernommen wird nur, was die Person selbst geschrieben hat, niemals etwas aus den Antworten des Bots. Der zählt nämlich gern fremde Straßen auf, und die dürfen sich nicht als „Deine Straße" festsetzen. Dieses ganze Netz ist bewusst reiner, langweiliger Code ohne jede KI. Gerade weil das Modell hier gelegentlich falsch läge und der Fehler teuer wäre.

Konzept 6: Ähnlichkeit ist kein Wissen

Die unbequemste Erkenntnis des Projekts: Ein Ähnlichkeitswert sagt nicht, ob eine Frage beantwortbar ist. Alles, was halbwegs nach der Region klingt, bekommt hohe Werte. Echte Wissenslücken schneiden dabei teils besser ab als eindeutige Treffer. Ein Schwellwert kann die beiden Fälle schlicht nicht trennen.

Die Lösung ist unspektakulär und wirksam: ein zweiter, sehr günstiger Prüfschritt, der genau eine Frage beantwortet. Steht die konkret gesuchte Information wirklich in dem, was gefunden wurde? Erst wenn die Antwort Nein lautet, darf das Internet aushelfen.

Dieselbe Einsicht kenne ich aus meiner Wissensdatenbank Destille: Ein Vektorindex ist gut im Wiederfinden und in der Recherche. Ob das Gefundene die Frage tatsächlich beantwortet, entscheidet er nicht.

Konzept 7: Weglassen ist stärker als ermahnen

Man kann einem Sprachmodell im Prompt verbieten, den Kalender einer fremden Straße zu nennen. Oder man sorgt dafür, dass dieser Kalender gar nicht erst im Kontext steht. Das Zweite funktioniert. Kann keine Straße bestimmt werden, fliegen sämtliche Kalenderdaten aus dem Kontext, und der Bot fragt freundlich nach. Prompt-Regeln sind die zweite Verteidigungslinie, nicht die erste.

Dazu passt die Geschichte mit den Links. Der Bot hat sich anfangs Webadressen zusammengereimt, plausibel klingend und falsch. Verschwunden ist das nicht durch strengere Ermahnungen im Prompt, sondern dadurch, dass die echten Adressen überhaupt erst in den Kontext kamen. Halluzinationen entstehen oft aus Lücken im Kontext, nicht aus Bosheit des Modells.

Konzept 8: Jeder Fehler fällt in die sichere Richtung

Alles fällt irgendwann aus. Die Frage ist nur, wohin. Bei diesem Bot führt jeder Fehlerpfad in die sichere Richtung:

• Fällt die Folgefragen-Erkennung aus, wird nur die aktuelle Frage verwendet, der Verlauf bleibt aber erhalten.
• Fällt der Prüfschritt aus, gilt der eigene Kontext als ausreichend, statt unnötig das Internet zu befragen.
• Ist ein externer Dienst nicht erreichbar, läuft der Chat ohne dieses eine Feature weiter.

Was Du mitnehmen kannst

Wenn Du für Deine Organisation einen Chatbot planst, egal ob Kommune, Hochschule oder Unternehmen: Fang nicht beim Modell an. Fang bei diesen fünf Fragen an.

Das Sprachmodell ist austauschbar. Das Konzept ist es nicht. Das ist derselbe Punkt, den ich in AI-Dev#1 für Entwicklungsteams beschrieben habe: Die Werkzeuge sind selten das Problem, die Ordnung darum herum ist es. Wie ich das in Projekten begleite, steht auf der Seite zur KI-gestützten Entwicklung.

Zum Schluss eine Frage an Dich: Welche Frage müsste ein Chatbot in Deiner Organisation als Allererstes fehlerfrei beantworten können? Ich tippe auf die Öffnungszeiten. Es sind erstaunlich oft die Öffnungszeiten.

Ich lese viel. Ich schreibe viel. Und trotzdem habe ich mich jahrelang dabei ertappt, dieselbe Arbeit zweimal zu machen.

1. Warum ich eigentlich eine Destille haben möchte

Mein Arbeitsalltag hat vier Ströme. Ich schreibe wissenschaftliche Paper. Ich führe eigene Studien durch. Ich betreue Abschlussarbeiten und halte Lehrveranstaltungen. Und ich entwickle nebenher ein eigenes Produkt, für das ich Marktdaten und Entscheidungen dokumentiere.

Jeder dieser Ströme produziert Material. Keiner produziert von allein Wissen.

Das Ergebnis nach ein paar Jahren sieht bei den meisten von uns ähnlich aus: PDFs in Zotero, Notizen in irgendeiner App, Manuskripte in Dropbox, Gutachten im Mailpostfach, Marktdaten in einer Tabelle, dazu Chatverläufe mit einem Sprachmodell, in denen erstaunlich gute Gedanken stecken, die nie wieder auftauchen. Wenn ich ein neues Paper anfange, beginne ich faktisch bei null, obwohl ich vor zwei Jahren schon einmal genau diese Literatur gelesen habe.

Der Punkt, an dem mich das wirklich gestört hat, war nicht das Wiederfinden. Das kriegt man mit Suche halbwegs hin. Es war etwas anderes: Ich wollte, dass ein System meine Position kennt.

Ein Beispiel, das ich ständig brauche. Was ist eigentlich User Experience? In den USA wird UX häufig aus der Designperspektive gedacht: Usability plus Design. In Europa liegt der Schwerpunkt eher auf Usability plus der emotionalen Ebene. Und die DIN-Norm definiert es wieder anders: die Wahrnehmungen und Reaktionen einer Person vor, während und nach der Nutzung.

Keine dieser Sichtweisen ist falsch. Aber wenn ich eine Einleitung schreibe, schreibe ich eine davon, und zwar immer dieselbe, weil sie meine ist. Genau das soll ein System wissen. Nicht den Durchschnitt des Internets referieren, sondern meine Sicht auf die Welt reproduzieren, mit der Norm als Grundlage, der Faktorzerlegung als Operationalisierung und der UEQ-Familie als Instrument.

Das kann ein Ordner nicht. Und ein Suchindex auch nicht.

2. Der Auslöser: Sprachmodelle sind gut im Bewerten, wenn man ihnen die Kriterien gibt

Die eigentliche Idee kam nicht aus dem Wissensmanagement, sondern aus meiner eigenen Forschung.

Ich habe mich in mehreren Arbeiten damit beschäftigt, wozu große Sprachmodelle in der wissenschaftlichen und gestalterischen Arbeit taugen und wozu nicht. Wie ich sie in meinem eigenen Arbeitsalltag einsetze, habe ich in UX-AI#1 beschrieben. Ein Befund zieht sich durch: Frei formulierte Urteile sind unzuverlässig, Urteile entlang eines vorgegebenen Kriterienkatalogs sind es nicht.

Fragt man ein Modell offen „Ist dieser Text gut?", bekommt man Höflichkeit. Gibt man ihm dagegen einen festen Raster vor (welche Kriterien, welche Skala, welche Belegpflicht), dann wird die Bewertung erstaunlich stabil und, was wichtiger ist, nachvollziehbar. Nicht weil das Modell klüger wird, sondern weil die Aufgabe eine andere ist: nicht mehr „urteile", sondern „ordne dieses Material in diese vorgegebenen Fächer ein".

Das war der Moment, in dem ich das auf mein eigenes Problem übertragen habe.

Denn was mache ich, wenn ich ein fremdes Paper lese? Ich mache immer dasselbe, seit Jahren, ohne es je aufgeschrieben zu haben. Ich frage mich vier Dinge:

• Was sind die Kernaussagen? Das ist der Baustein: zitierfähige Ergebnisse, die ich später mit Fundstelle in mein Related Work übernehmen kann.
• Wie sind die vorgegangen? Das ist das Muster: Methodik, die ich auf eigene Arbeiten übertragen kann.
• Woran muss sich meine Arbeit messen lassen? Das ist die Messlatte: Baselines und Benchmarks.
• Wie gut ist das eigentlich? Die Bewertung: Qualität, Limitationen. Eine qualitative Studie mit drei Teilnehmenden ist nun einmal keine Validierung, auch wenn im Abstract etwas anderes steht.

Das ist der Kern der Destille: Nicht das Modell denken lassen, sondern ihm ein Raster geben, in das es das Gelesene einsortiert. Der Rest ist Infrastruktur.

3. Warum mir „Second Brain" zu wenig ist

Zur selben Zeit lief auf YouTube die große Second-Brain-Welle. Ich habe mir das angesehen, und ich fand die Grundidee gar nicht schlecht. Nur habe ich mich innerlich dagegen gewehrt und eine Weile gebraucht, um zu benennen, warum.

Der typische Aufbau ist: Markdown-Dateien in Obsidian, ein Modell verlinkt sie automatisch, und am Ende gibt es einen hübschen Graphen. Ich hatte diese Version selbst gebaut. Das Ergebnis war eine nette Grafik ohne Nutzen.

Denn eine Kante in so einem Graphen sagt nur: Datei A hängt irgendwie mit Datei B zusammen. Sie sagt nicht, wie. Zitiert A die Datei B, oder widerspricht sie ihr? Ist B eine Norm, eine Methode oder eine flüchtige Notiz? Ist der Inhalt geprüft oder hat ihn gestern ein Modell hingeschrieben?

Und vor allem: Es wurde nichts Neues extrahiert. Die Dateien wurden nur miteinander in Beziehung gesetzt. Der Schritt, um den es mir eigentlich ging, nämlich aus vorhandenen Artefakten neues, verdichtetes Wissen zu destillieren, findet dort gar nicht statt.

Der zweite naheliegende Weg ist die reine RAG-Datenbank: alle PDFs vektorisieren, indexieren, per MCP-Server durchsuchbar machen. Das funktioniert gut, ich nutze es selbst als Baustein. Aber es löst zwei von vier Problemen:

| Ziel | Löst ein Index? | |---|---| | Wiederfinden: wo stand das noch mal? | ja | | Recherche: was gibt es zu Thema X? | ja | | Strukturen sichtbar machen: was hängt womit zusammen? | nein | | Widersprüche aufdecken: wo sagt A etwas anderes als B? | nein |

Die unteren beiden sind Akkumulationsprobleme. Sie entstehen erst dadurch, dass Wissen über Jahre zusammengeführt und gepflegt wird. Ein Index, der bei jeder Anfrage frisch zusammensucht, akkumuliert nichts. Deshalb brauche ich beides: einen Suchindex über das Rohmaterial und eine gepflegte Wissensschicht darüber.

4. Anforderungen an die Destille

Daraus wurden sieben Anforderungen, die ich vorab festgelegt habe:

5. Das Grundgerüst

Die tragende Entscheidung ist eine Trennung: Roharchiv und Destillat.

Das Roharchiv enthält Originale und deren maschinelle Lesefassungen: unveränderlich, vollständig, ungewichtet. Das Destillat enthält, was daraus an Erkenntnis gewonnen wurde: verdichtet, verlinkt, gepflegt, widerspruchsgeprüft. Der Name beschreibt genau diesen Vorgang: Rohes kommt in den Kessel, das Konzentrat bleibt übrig. Und das Original wird nie angefasst, denn es ist die Belegkette.

Darüber liegt eine einfache Ordnung. Es gibt Collections: grundlagen/, paper/, studien/, lehre/, abschlussarbeiten/, sondierung/ und mein Produkt. In jeder Collection liegen Bundles; ein Bundle ist ein Vorhaben: ein Paper, eine Erhebung, ein Modul, eine betreute Arbeit.

Und jedes Bundle sieht von innen gleich aus:

`` / ├── CLAUDE.md Steckbrief: Was ist das für ein Vorhaben? ├── raw/ Originale. Unveränderlich. Nur ich lege hier ab. ├── sources/ Normalisierte Markdown-Fassungen. Maschinenprodukt. ├── assets/ Abbildungen, Datensätze, Exporte ├── wiki/ Das Destillat. Hier entsteht Wissen. └── work/ Meine Werkbank: Manuskripte und Entwürfe `

Die Regeldateien. In jedem Bundle liegt eine CLAUDE.md. Sie erbt von der Collection, die von einer globalen Datei. Dort steht, was der Agent darf und was er ausdrücklich nicht darf. Das macht das System in der Struktur sehr hart und in der Anwendung trotzdem weich, weil ich mit normalen Sätzen damit arbeite, nicht mit Kommandos.

Der Reifegrad. Jede Seite trägt einen von vier Werten: keim, entwurf, belastbar, kanonisch. Der Agent darf höchstens entwurf vergeben. belastbar und kanonisch vergebe ausschließlich ich. Das ist die wichtigste Einzelregel im ganzen System, und sie ist absolut: Keine Bundle-Regel kann sie aufweichen.

Recherche. Und zwar zuerst im eigenen Bestand: „Beantworte mit der Destille: Was wissen wir über Thema X?" Existiert bereits ein Paper-Profil zu einer Quelle, ist die Arbeit schon getan: Es wird verlinkt, nicht neu geschrieben. Erst danach ergänze ich von außen. Neue PDFs wandern in raw/.

Schreiben. Das Manuskript entsteht in work/`, und dort schreibt der Agent nur auf ausdrücklichen Auftrag. Das ist meine Werkbank. Der wertvollste Auftrag in dieser Phase ist übrigens nicht „schreib mir einen Abschnitt", sondern: „Lies Abschnitt 3 und prüfe, ob jede Aussage durch ein Paper-Profil gedeckt ist." Das findet unbelegte Behauptungen, bevor ein Reviewer sie findet.

Konflikte. Wenn Quelle A sagt, nachts ist es dunkel, und Quelle B sagt, nachts ist es hell, dann entsteht daraus kein stiller Überschreibvorgang, sondern eine Notiz mit beiden Positionen, sowohl in der betroffenen Seite als auch in einem zentralen Register. Aufgelöst wird sie von mir. Manchmal lautet die Auflösung: B ist mir zu dünn belegt, A gilt. B bleibt trotzdem im System, nur niedriger bewertet. Denn Wissenschaft ist selten eindeutig, und die Entscheidung darüber ist genau der Teil, den ich nicht delegieren will.

7. Der Abschluss: Promotion

Wenn ein Paper fertig ist, kommt der Schritt, der aus lauter Projekten mit der Zeit eine Wissensdatenbank macht.

Ich starte einen Promotion-Durchlauf. Der Agent geht durch, was im Projekt-Wiki entstanden ist, und schlägt vor: Was davon hat über dieses Vorhaben hinaus Bestand? Ein Paper-Profil einer fremden Arbeit, die ich sicher wieder brauche, steigt ins Collection-Wiki auf. Ein Begriff wie Vibe Coding, der inzwischen für alle Bereiche relevant ist, steigt zwei Ebenen höher in die Grundlagen.

Entschieden wird das von mir. Der Agent macht Vorschläge, ich sage „ja", „nein" oder „mehr davon".

Am alten Ort bleibt ein Stub zurück. Und das ist keine Kopie, sondern der Rest nach dem Herausziehen des Allgemeinen: die lokale Sicht, wie dieses Projekt den Begriff einsetzt, unter welcher Referenznummer das Paper im Manuskript steht. Er verweist auf die Heimat, damit die Verbindung nicht verlorengeht.

So wächst das Langzeitgedächtnis organisch, statt am Reißbrett geplant zu werden. Projekt-Bundles sind kurzlebiger Arbeitsspeicher. Die Collection-Wikis und die Grundlagen sind das, was bleibt.

Und weil das kein harter Abschluss ist, kann ich den Vorgang jederzeit wiederholen.

8. Der Viewer

Zum Schluss noch das, was am besten aussieht und am wenigsten die eigentliche Arbeit ist.

Aus den Regeldateien, den Frontmatter-Feldern, den Links und den Konfliktnotizen baut ein Indexer einen Wissensgraphen (aktuell 288 Knoten und 1702 Kanten). Der Viewer zeigt ihn zweispaltig: links die Karte, rechts die gerenderte Seite.

Vier Darstellungskanäle tragen dabei Information:

• Farbe zeigt, zu welchem Bundle oder Typ ein Knoten gehört.
• Größe zeigt den Grad, also wie stark etwas vernetzt ist.
• Deckkraft zeigt den Reifegrad. Was blass ist, ist ungeprüft. Der Blick auf den Graphen sagt mir also sofort, wie viel meines Vaults noch auf mein Urteil wartet.
• Hohle Knoten sind Geisterknoten: verlinkt, aber nie geschrieben. Das ist keine Fehlermeldung, sondern eine Arbeitsliste.

Ein Beispiel. Ich bin dort über eine Notiz gelaufen, die ich selbst hatte anlegen lassen: „Kollaborationsverlust auf Teamebene". Der Befund dahinter war mir in dieser Zuspitzung nie aufgefallen: Beim Einsatz von KI in Entwicklungsteams steigt die individuelle Effizienz, während die kollektive Leistung sinkt, weil man den Kollegen nicht mehr fragt, sondern das Modell. Er stand verteilt in zwei Studien, die ich für verschiedene Vorhaben gelesen hatte. Ulfsnes et al. (2024) beschreiben in einer Interviewstudie mit 13 Personen, wie generative KI das individuelle Lernen beschleunigt und zugleich den Lernkreislauf im Team unterbricht. Wivestad et al. (2024) messen dasselbe Muster quantitativ: In einem Quasi-Experiment mit 115 Teilnehmenden arbeiten Copilot-Nutzende fokussierter und sind weniger auf Kolleginnen und Kollegen angewiesen, ein individueller Gewinn bei sinkender Teaminterdependenz.

Keine der beiden Arbeiten sagt das für sich genommen. Erst nebeneinander ergeben sie den Satz, der mir vorher nie so klar war: Der Gewinn wird auf Individualebene realisiert, der Verlust auf Teamebene. Auf der Karte lagen die beiden plötzlich nebeneinander.

Aus Einzelkämpfern statt Teamkämpfern kann man ein eigenes Paper machen. Genau dafür ist so ein System da. Die organisatorische Seite dieser Frage behandle ich in AI-Dev#1: Warum KI kein Tool-Problem ist, sondern ein Organisationsproblem.

9. Was es mir bringt

Ich habe schon einige Systeme gebaut und wieder verworfen. Der Grund war immer derselbe: Es entstand Arbeit, aber kein Mehrwert. Und ein System, in das man nur hineinsteckt, ohne etwas herauszubekommen, stirbt zu Recht.

Die Destille ist das erste, bei dem ich das umgekehrt erlebe. Wenn ich heute sage „Erkläre den Unterschied zwischen Usability und User Experience", dann bekomme ich nicht den Durchschnitt des Internets, sondern meine Position: Usability als Gebrauchstauglichkeit (Effektivität, Effizienz, Zufriedenheit, gemessen während der Nutzung); User Experience als das Subjektive, vor, während und nach der Nutzung, messbar nur am Menschen. Mit den Belegen, die ich selbst geprüft und freigegeben habe.

Das ist der Unterschied zwischen einer Materialsammlung und einer Wissensdatenbank.

Die entscheidende Einsicht war dabei nicht technischer Natur. Sie war: Die Arbeit mache ich mir ohnehin. Jedes Paper wird gelesen. Jede Studie wird ausgewertet. Jede Abschlussarbeit wird begutachtet. Der einzige Unterschied ist, ob das Ergebnis danach in einem Ordner verschwindet, oder ob es beim nächsten Mal von allein wieder auftaucht.

Nur Daten sammeln war mir zu wenig.

Quellen

• Ulfsnes, R. et al. (2024). Transforming Software Development with Generative AI. Springer.
• Wivestad, V. T. et al. (2024). Copilot's Island of Joy. Springer LNBIP.

Die Destille läuft vollständig lokal: Markdown-Dateien im Git, eine lokale Hybridsuche, ein Agent mit Dateizugriff und ein paar Regeldateien. Nichts davon ist an ein bestimmtes Werkzeug gebunden: Ausgetauscht wird der Motor, nicht der Vault.

Es ist kurz vor zehn, die Kaffeemaschine läuft. Vier Entwicklerinnen und Entwickler stehen in der Küche, und das Gespräch dreht sich wie fast jeden Morgen um Tools. Die eine ist vergangenen Monat komplett auf Cursor umgestiegen, weil der Editor endlich ihren Codestil gelernt habe. Der zweite nutzt seit letzter Woche Claude Code für Refactorings und erklärt, warum das alles verändert. Der dritte darf nur Copilot einsetzen, weil die Rechtsabteilung die anderen Tools noch prüft. Die vierte hat am Wochenende ein Agenten-Setup aus drei Komponenten gebastelt und ist überzeugt, dass das der einzig vernünftige Weg sei.

Vier Personen. Vier völlig unterschiedliche Arbeitsumgebungen. Alle produktiver als vor einem Jahr. Und alle in verschiedenen Universen.

Wenn dir diese Szene bekannt vorkommt, bist du nicht allein. Sie beschreibt ziemlich genau den Zustand, in dem sich ein Großteil der Softwareentwicklung gerade befindet. Und sie ist der Ausgangspunkt für diese neue Blog-Reihe. In den nächsten sechs Beiträgen geht es nicht darum, welches KI-Tool gerade das beste ist. Es geht um eine These, die unbequem ist, aber empirisch immer besser abgestützt: KI-Integration ist kein Tool-Problem, sondern ein Organisationsproblem.

Die Copilot-Metapher führt in die Irre

Die Sprache, die wir rund um KI im Engineering benutzen, hat uns in eine Denkfalle manövriert. „Assistent". „Copilot". „Pair Programmer". Jeder dieser Begriffe suggeriert dasselbe Bild: Ein Mensch macht die eigentliche Arbeit, eine Maschine hilft freundlich dabei. Das Team bleibt, wie es ist. Die Prozesse bleiben, wie sie sind. Nur jede Einzelperson bekommt einen kleinen Produktivitätsschub.

Dieses Bild ist nicht nur unvollständig. Es ist irreführend.

Ein Assistent hilft. Infrastruktur ermöglicht. Das ist ein kategorialer Unterschied. Wenn in einem Unternehmen jede Person ihr eigenes Wiki führt, sagt niemand, man habe eine „Wissens-Infrastruktur". Wenn alle dasselbe Confluence nutzen, auf das sich Prozesse, Onboarding und Governance beziehen, dann hat man eine. KI-Tools sind gerade dabei, in genau diese zweite Kategorie zu rutschen. Sie werden zu dem Ort, an dem Code entsteht, an dem Spezifikationen formuliert werden, an dem Architekturentscheidungen geschliffen werden. Nur behandeln wir sie weiterhin, als wären sie eine besonders schlaue Form von IntelliSense.

| | KI als Assistent | KI als Infrastruktur | |---|---|---| | Entscheidung | Jede Person wählt selbst | Team entscheidet gemeinsam | | Scope | Einzelplatz-Abo | Geteilte Umgebung | | Governance | Keine | Explizite Regeln (Datenzugriff, Prompts, Reviews) | | Lerneffekt | Individuell | Kumulativ auf Organisationsebene | | Analogie | Privates Dropbox-Konto | Gemeinsames Confluence |

Im XP 2025 Workshop zu KI und Agilität haben Herda und Kolleginnen über 120 Schmerzpunkte von Praktikerinnen und Praktikern gesammelt. Die häufigste Frustration, genannt von 73,3 Prozent der Teilnehmenden: fragmentierte Tool-Landschaften. Menschen, die alleine gut mit KI zurechtkommen, aber im Team nicht mehr zueinander finden. Das XP 2026 Position Paper, das den Ausgangspunkt für unsere Forschung bildet, nennt dieses Muster Vibe Coding: eine Arbeitsweise, in der die KI-Nutzung opportunistisch, unstrukturiert und individuell geschieht. Mit isolierten Erfolgen, aber ohne kumulativen Lerneffekt auf Organisationsebene.

AI-Dev-Systems: Wenn aus Werkzeugen Infrastruktur wird

Um dieser Falle zu entkommen, braucht es einen anderen Begriff. Im XP 2026 Paper führen wir dafür den Ausdruck AI-Dev-System ein. Ein AI-Dev-System ist eine konfigurierte Umgebung aus KI-Agenten, Tools, Workflows und Wissensdatenbanken, die bewusst für systematische Softwareentwicklung entworfen wurde.

Das klingt abstrakt, also konkret: Ein AI-Dev-System ist es, wenn ein Team gemeinsam festlegt, welches Basismodell genutzt wird, welche Prompt-Konventionen gelten, welche internen Dokumente per Model Context Protocol verfügbar sind, welche Test- und Review-Workflows automatisch greifen und welche Daten die KI niemals sehen darf. Es ist nicht „wir haben alle Copilot gekauft". Ein Einzelplatz-Abo in jeder IDE ist genauso wenig eine gemeinsame Infrastruktur wie fünf private Dropboxen eine gemeinsame Datenablage sind.

Das entscheidende Wort in der Definition lautet intentional design: bewusste Entscheidungen über Fähigkeiten, Interaktionsmuster und Domänenwissen, die für das ganze Team gelten. Genau hier wird aus einem Werkzeug etwas anderes. Nämlich der Rahmen, in dem gearbeitet wird.

Was 99 Entwicklerinnen und Entwickler dazu sagen

Für unsere ISD 2026 Studie haben wir 99 professionelle Entwicklerinnen und Entwickler über Prolific befragt. Auf einer Skala von −3 (starke Ablehnung) bis +3 (starke Zustimmung) haben sie eine Reihe von Aussagen zur organisatorischen Dimension von KI bewertet. Drei Ergebnisse greifen die These dieses Beitrags direkt auf.

Erstens: Geteilte Infrastruktur wird klar bevorzugt. Die Aussage „KI-Tools sollten wie CI-Pipelines oder Versionskontrolle als geteilte Infrastruktur verwaltet werden" kam auf einen Mittelwert von +1,38. Das ist eine deutliche moderate Zustimmung und eines der stärksten Signale im gesamten Block. Übersetzt: Die Befragten wollen genau nicht, dass jede Person ihr eigenes Setup zusammenklickt.

Zweitens: Dedizierte Teams für KI-Entwicklungsumgebungen werden als hilfreich gesehen. Die Aussage „Es wäre hilfreich, wenn dedizierte Teams die KI-Entwicklungsumgebungen verwalten würden" erreichte +1,13. Auch das ein klares, moderat zustimmendes Signal. Man will nicht, dass jedes Team diese Arbeit nebenbei mitmacht.

Drittens, und das ist der spannendste Befund: Es gibt keinen Konsens darüber, ob KI hauptsächlich ein technisches Problem ist. Die entsprechende Frage (umgepolt formuliert) landete bei einem Mittelwert von +0,08, also praktisch neutral, und das Konfidenzintervall schließt die Null ein. Das ist kein Widerspruch zu den beiden anderen Ergebnissen. Es ist eine ehrliche Zwischenposition: Ja, KI hat eine gewichtige technische Seite. Aber nein, allein auf der technischen Ebene ist das Problem nicht mehr zu lösen. Praktikerinnen und Praktiker sehen die Doppelnatur der Herausforderung.

Der überraschende Teil: Der Schmerz ist noch nicht akut

Hier wird es interessant. Man könnte jetzt erwarten, dass die Fragmentierung auch im konkreten Arbeitsalltag als schmerzhaft empfunden wird. Ist sie aber nur begrenzt.

Die Aussage „Die unabhängige Tool-Auswahl führt in meinem Team bereits zu Fragmentierung" erreichte einen Mittelwert von +0,46. Das ist neutral. Das Konfidenzintervall reicht von +0,14 bis +0,78. Also leicht ins Positive, aber weit weg von echtem Leidensdruck.

Es entsteht ein bemerkenswertes Bild: Die Befragten wollen geteilte Infrastruktur (+1,38), bevor sie den Schmerz fehlender geteilter Infrastruktur wirklich spüren (+0,46). Das ist weitsichtig. Und das ist die eigentliche Botschaft dieses Beitrags.

Wir befinden uns in einem Zeitfenster, das so nicht bleiben wird. Die allermeisten Unternehmen stehen gerade erst am Anfang breiter KI-Nutzung. Die Tools sind noch neu genug, dass jeder Workaround als Lernphase durchgeht. Die Teams sind noch klein genug, dass fünf unterschiedliche Setups noch nicht in einem unauflösbaren Knoten enden. Aber die Fragmentierung kommt, genauso sicher, wie sie bei Testwerkzeugen, bei CI-Systemen oder bei Monitoring-Stacks gekommen ist. Jedes Unternehmen, das in den 2010er Jahren überlebt hat, hat irgendwann gelernt: Individuelle Tool-Entscheidungen funktionieren, bis sie es nicht mehr tun. Dann kommt der Konsolidierungsschmerz mit voller Wucht.

Bei KI ist die Chance, diese Phase nicht erst durchleiden zu müssen, sondern sie zu überspringen. Nicht weil jemand die Warnung ernst nimmt, sondern weil man die Antwort schon kennt, bevor das Problem richtig anfängt wehzutun.

Warum das die Perspektive ändert

Wenn du die Copilot-Metapher loslässt und KI stattdessen als Infrastruktur denkst, stellen sich plötzlich andere Fragen. Nicht mehr „Welches Tool sollen wir kaufen?", sondern:

• Wer entscheidet, welche KI-Umgebung wir bereitstellen?
• Wer pflegt diese Umgebung, wenn sich das Basismodell monatlich ändert?
• Welche Workflows sollen automatisch greifen, welche bleiben menschlich?
• Wie gehen wir mit Wissen um, das in Prompts und Kontextfenstern liegt?
• Was dürfen Modelle sehen, was nicht?
• Wie messen wir überhaupt, ob unsere KI-Infrastruktur funktioniert?

Die Antwort, die wir im XP 2026 Paper vorgeschlagen haben, ist ein Drei-Schichten-Modell mit System Teams, Platform Teams und Product Teams. Ob dieses Modell trägt, ob es praxistauglich ist, wo es hakt, das wird Thema von AI-Dev#2. Hier reicht vorerst die Feststellung: Der Boden, auf dem dieses Modell steht, ist empirisch deutlich tragfähiger, als wir beim Schreiben des Position Papers vermutet hatten.

Die Reihe im Überblick

Diese Reihe besteht aus sechs Beiträgen. In AI-Dev#2 stellen wir das Drei-Schichten-Modell im Detail vor und zeigen, wie es sich an Team Topologies (Skelton und Pais) anlehnt. In AI-Dev#3 geht es um den Rollenwandel der Entwicklerinnen und Entwickler selbst: vom Code-Schreibenden zum Steward, zur Person, die KI-Outputs bewertet und lenkt. AI-Dev#4 widmet sich TDD und CI als neuen Governance-Mechanismen für KI-generierten Code. In AI-Dev#5 nehmen wir uns den spannendsten Befund der Studie vor: Die Praktikerinnen finden das Modell überzeugend, bezweifeln aber, dass ihre eigene Organisation reif genug ist. Und AI-Dev#6 stellt die provokanteste Frage: Braucht der Zwei-Wochen-Sprint überhaupt noch ein Update?

Wer schon einen Vorgeschmack möchte, wie sich diese Perspektive auf den individuellen Arbeitsalltag auswirkt, findet im älteren Beitrag UX-AI#1: „Wie ich AI-Tools als UX-Professional einsetze" die Tool-Sicht. Diese Reihe ist das Gegenstück dazu: der Blick auf die Organisation, in der diese Tools eingebettet sind.

Was du aus diesem Beitrag mitnehmen solltest

Im nächsten Beitrag geht es konkret um das Drei-Schichten-Modell. Wer baut? Wer betreibt? Wer nutzt? Und welche Erkenntnisse aus Team Topologies helfen uns dabei, diese Rollen sinnvoll zu trennen?

Bis dahin.

Quellen

Dieser Beitrag basiert auf den folgenden Quellen:

• Hinderks, A., Thomaschewski, J., & Schön, E.-M. (2026). From AI Assistants to AI-Dev-Systems: A Three-Layer Model for Human-AI Collaboration in Agile Software Development. Position Paper, XP 2026 Workshop, São Paulo, Brazil.
• Hinderks, A., Thomaschewski, J., & Schön, E.-M. (2026). Prolific-Umfrage mit n=99 professionellen Softwareentwicklerinnen und -entwicklern.
• Herda, T. et al. (2025). XP 2025 Workshop on AI and Agile Software Development. Synthese von über 120 Praktiker-Schmerzpunkten
• Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
• Kudina, O., & van de Poel, I. (2024). A Sociotechnical Perspective on AI.

Warum eine KPI für User Experience?

Bevor wir zu den drei Schritten kommen, kurz ein Blick auf den Sinn von UX-KPIs:

• Messbarkeit und Vergleichbarkeit: UX-Erlebnisse sind subjektiv. Eine Kennzahl wie die UEQ KPI übersetzt dieses Erleben in messbare Zahlen, sodass sich Produkte, Versionen oder Zeitpunkte miteinander vergleichen lassen.

• Schwerpunktsetzung: Gerade in agilen Teams sind Ressourcen begrenzt. Eine KPI kann helfen, Entwicklungsaufgaben zu priorisieren – d. h. dort zu investieren, wo das größte UX-Potenzial wartet.

• Langfristige Weiterentwicklung: Wer regelmäßig misst, erkennt Trends und kann gezielt korrigieren, bevor Probleme groß werden.

In der folgenden Abbildung ist eine Übersicht über die gängigsten UX KPIs dargestellt.

Die UEQ KPI kombiniert die Skalen des UEQ (z. B. Effizienz, Perspicuity, Stimulation) und gewichtet sie je nach Bedeutung für das jeweilige Produkt. Doch was nützt das Zahlenwerk, wenn man nicht weiß, wie es zustande kommt und wie man es im Kontext richtig interpretiert?

Schritt 1: Kopieren

Im Unternehmensumfeld werden gern etablierte Kennzahlen genutzt. Das „Kopieren“ einer KPI – also ihre direkte Übernahme – ist dabei oft die erste Wahl:

1\. Bekanntheit: Die UEQ ist ein standardisiertes, validiertes Verfahren, hinter dem eine größere Community steht. Es funktioniert natürlich auch mit anderen KPIs. Diese sollte nur zum Produkt passen.

2\. Einfacher Start: Erste Studien und Messungen lassen sich schnell umsetzen; man erhält rasch Ergebnisse und kann sie im Team teilen.

3\. Allerdings: Blinder Aktionismus kann dazu führen, dass man zwar Werte sammelt, diese aber weder versteht noch nachhaltig nutzt.

Kopieren ist kein Verbrechen – ganz im Gegenteil: Es spart Zeit und schließt an vorhandene Best Practices an. Aber dieser Schritt ist nur der Anfang.

Schritt 2: Kapieren

Jetzt wird es entscheidend: Was misst die UEQ KPI eigentlich genau?

• Inhalte verstehen: Das UEQ erfasst (vereinfacht gesagt) pragmatische und hedonische Qualitäten eines Produkts. Die daraus resultierenden Skalenwerte lassen sich mit Bedeutungsgewichten zu einer Gesamtkennzahl – der UEQ KPI – zusammenfassen.

• Kontext prüfen: Wird das Produkt sehr selten genutzt? Handelt es sich um eine komplexe Businesssoftware oder um eine Consumer-App? Die Bedeutung einzelner Skalen (z. B. Effizienz vs. Attraktivität) variiert stark nach Produkt- und Nutzertyp.

• Datenerhebung hinterfragen: Wie oft wird gemessen? Mit welcher Zielgruppe? Unter welchen Bedingungen? Nur wenn das alles transparent ist, kann man die Ergebnisse richtig einordnen.

Dieser Schritt des Verstehens ist enorm wichtig, denn wer die UI-Skalen, ihre Hintergründe und die Gewichtung in der KPI nicht durchdringt, kann schnell in die Falle tappen, Zahlen zu überinterpretieren oder falsche Schlüsse zu ziehen.

Schritt 3: Adaptieren

Sobald man „kapiert“ hat, was die UEQ KPI misst und wie sie zustande kommt, sollte man sie auf das eigene Produkt und die Unternehmenskultur abstimmen. Das nenne ich „Adaptieren“:

• Faktoren-Auswahl: Vielleicht sind manche UEQ-Faktoren (z. B. „Novelty“) weniger wichtig. Andere, wie „Perspicuity“, sind essenziell. Die Auswahl sollte den tatsächlichen Prioritäten des Produkts entsprechen.

• Sinnvolle Kommunikation: Habt ihr die KPI im Team angepasst, kommuniziert sie erst dann im gesamten Unternehmen. Zeigt auf, warum und wie ihr euch genau diese Faktorenwerte anschaut und was sie bedeuten.

• Kombination mit anderen Methoden: Die UEQ KPI liefert einen Überblick, aber qualitative Methoden wie Interviews oder Beobachtungen sind oft wertvoll, um Ergebnisse zu untermauern.

Genau in diesem Schritt etabliert ihr die Kennzahl wirklich in eurem Unternehmen – und zwar so, dass alle mitreden und sie annehmen können.

Warum das Ganze Zeit braucht

Man könnte meinen, das Einführen einer KPI wie der UEQ KPI geht zack-zack. In der Praxis trifft man jedoch auf verschiedene Hürden:

1\. Vorwissen aufbauen: Viele Teams wissen nicht, was hinter Begriffen wie „Pragmatic Quality“ oder „Hedonic Quality“ steckt.

2\. Org-Strukturen: Oft existieren Reporting- und Meetingstrukturen, in die eine neue Kennzahl sauber eingepasst werden muss.

3\. Kulturwandel: Eine KPI bildet Realität nur bedingt ab. Werden die Beteiligten schnell KPI-„gläubig“, wird es schwierig, sie später wieder abzuschaffen oder zu ersetzen.

Gerade das Abschaffen einer Kennzahl gestaltet sich mitunter komplizierter als die Einführung. Und zum Schluss geht es doch um ein zielgerichtetes UX-Management.

Fazit: Kopieren - Kapieren - Adaptieren

Die UEQ KPI ist ein hervorragendes Instrument, um UX in eine aussagekräftige Kennzahl zu übersetzen. Doch sie erfüllt ihren Zweck nur, wenn man sie nicht bloß „blindlings kopiert“, sondern sie verstanden und kontextgerecht weiterentwickelt hat. Eine KPI, die man nicht durchdringt oder falsch einsetzt, kann zu falschen Entscheidungen führen – und das Gegenteil einer echten UX-Verbesserung bewirken.

Mit dem dreistufigen Ansatz – Kopieren, Kapieren, Adaptieren – legt ihr hingegen eine solide Basis, um Daten wirklich zu verstehen und in strategische Maßnahmen zu übersetzen. Und glaubt mir: Das lohnt sich! Ihr sichert damit sowohl das Vertrauen in die Kennzahl als auch langfristig zufriedene, loyale Nutzer.

ChatGPT - Der Klassiker

ChatGPT ist mein Schweizer Taschenmesser. Ich nutze es als Lektor:in, Rechercheassistent:in und Ideengeber. Die Antworten sind oft klarer und besser als das, was ich bei Google finde. Besonders wenn ich Texte verfasse, hilft mir ChatGPT, den richtigen Ton zu treffen oder Ideen zu verfeinern. Es fühlt sich an, als hätte ich einen zweiten Kopf, der immer mitdenkt.

Whisper – Transkriptionen leicht gemacht

Wer kennt es nicht: Interviews oder Meetings, die stundenlange Transkriptionen benötigen. Dank Whisper (kombiniert mit Python) läuft das jetzt vollautomatisch. Egal ob Videokonferenzen, YouTube-Videos oder Nutzerinterviews – die Genauigkeit und Effizienz von Whisper sparen mir wertvolle Zeit, die ich besser in die Analyse und das Design investieren kann.

Midjourney – Kreativität aus der Cloud

Ich bin kein geborener Grafiker, aber mit Midjourney kann ich visuell beeindruckende Grafiken erstellen, die in Präsentationen und Berichten glänzen. Es ist faszinierend, wie AI aus wenigen Eingaben fantastische Visuals zaubert – perfekt für Leute wie mich, die besser im Konzipieren als im Zeichnen sind.

Napkin.ai – Abbildungen aus Text

Abbildungen und Diagramme gehören zu fast jedem UX-Bericht. Mit Napkin.ai kann ich diese direkt aus Texten oder Tabellen generieren. Das Tool verwandelt trockene Daten in visuell ansprechende und leicht verständliche Grafiken – ein echter Gamechanger in der Datenvisualisierung.

CrewAI – Mein digitales Forscherteam

Stell dir vor, du hättest ein Team, das für dich das gesamte Internet und LinkedIn nach relevanten Themen durchsucht, diese kritisch beleuchtet und dir eine fundierte Zusammenfassung liefert. Genau das macht CrewAI. Ob Markttrends oder UX-spezifische Themen, mit CrewAI bin ich immer einen Schritt voraus.

Flowise – Lokale AI Agents

Datenschutz ist mir wichtig, deshalb setze ich Flowise ein, um AI Agents direkt auf meinem lokalen Rechner zu erstellen. Ein Beispiel ist mein persönlicher Chatbot, der auf alle meine gescannten Dokumente und Dateien zugreifen kann. Alles bleibt offline und sicher.

Tempo Labs – React-Frontend per Prompt

Dieses Tool ist noch neu für mich, aber extrem spannend. Mit Tempo Labs kann ich React-Frontends einfach per Texteingabe erstellen. Die Möglichkeit, komplexe Interfaces allein durch Prompts zu bauen, könnte UX Design und Prototyping revolutionieren. Ein echter Kandidat für die Zukunft.

Warum AI und UX perfekt zusammenpassen

Künstliche Intelligenz ist für uns UX-Expert:innen ein Innovationsmotor. Mit den richtigen Tools können wir Arbeitsprozesse beschleunigen, kreativere Lösungen finden und noch besser auf die Bedürfnisse unserer Nutzer:innen eingehen. Es geht nicht darum, AI die Arbeit zu überlassen, sondern sie als starken Partner in unserem Werkzeugkasten zu sehen.

Die drei Bereiche: Usability, User Experience und Customer Experience

Um Missverständnisse zu vermeiden, ordne ich KPIs drei Bereichen zu: Usability, User Experience (UX) und Customer Experience (CX). Lasst uns diese Begriffe genauer definieren, um ein besseres Verständnis dafür zu entwickeln, welche KPIs zu welchem Bereich gehören.

Usability

Die ISO 9241-210 definiert Usability als das Ausmaß, in dem ein Produkt, System oder Service von bestimmten Nutzern genutzt werden kann, um bestimmte Ziele mit Effektivität, Effizienz und Zufriedenheit in einem bestimmten Nutzungskontext zu erreichen.

Für mich ist Usability direkt am Produkt messbar. Das bedeutet, ich kann bei dem Produkt messen, ob es effektiv und effizient ist. Bei der Effizienz spielt die Wahrnehmung des Nutzers ebenfalls eine Rolle, da sie beeinflusst, wie schnell und angenehm Aufgaben erledigt werden können.

User Experience (UX)

Die ISO 9241-210 beschreibt User Experience als die Wahrnehmungen und Reaktionen von Nutzern, die aus der tatsächlichen oder erwarteten Nutzung eines Produkts, Systems oder Services resultieren.

Ich messe die User Experience immer beim Menschen. Das Produkt wirkt auf den Nutzer und verursacht dort eine positive oder negative Erfahrung. Diese Reaktionen – emotional, kognitiv und physisch – werden entsprechend erfasst und ausgewertet.

Customer Experience (CX)

Gartner definiert Customer Experience als die Wahrnehmungen und Gefühle des Kunden, die durch die einmalige und kumulative Wirkung von Interaktionen mit den Mitarbeitern, Systemen, Kanälen oder Produkten eines Anbieters verursacht werden.

Bei der Customer Experience wird das Feld weiter aufgespannt. Hier zählen Aspekte wie Markenwahrnehmung, Kundenservice und alle Interaktionen des Kunden mit dem Unternehmen dazu. Es geht also darum, wie das Unternehmen insgesamt mit dem Produkt auf den Menschen wirkt.

Warum die korrekte Zuordnung von KPIs wichtig ist?

Es ist entscheidend, dass wir genau wissen, was eine KPI misst und in welchem Kontext sie steht. Eine vermeintliche UX-KPI könnte in Wirklichkeit eher eine Usability-KPI oder sogar eine CX-KPI sein. Wenn wir KPIs falsch zuordnen, riskieren wir:

• Falsche Schlussfolgerungen zu ziehen- Ineffektive Maßnahmen zu ergreifen- Ressourcen zu verschwenden- Stakeholder zu verwirren

Beispiele für Missverständnisse**

Ein häufiges Missverständnis ist die Verwendung von Conversion Rates als UX-KPI. Während die Conversion Rate ein wichtiger Indikator ist, misst sie oft eher die Effektivität von Marketingmaßnahmen oder die Attraktivität eines Angebots und weniger die tatsächliche User Experience des Produkts.

Ein anderes Beispiel ist der Net Promoter Score (NPS) - mein Liebling ;-). Obwohl er Einblicke in die Kundenzufriedenheit gibt, spiegelt er nicht ausschließlich die User Experience wider, sondern wird von vielen Faktoren beeinflusst, einschließlich Markenimage und Kundendienst. Das werde ich in einem nächsten Post näher beleuchten.

Fazit

Nicht jede KPI, die als UX-KPI bezeichnet wird, misst tatsächlich die User Experience. Es ist unerlässlich, dass wir die Unterschiede zwischen Usability, User Experience und Customer Experience verstehen und die KPIs korrekt zuordnen. Nur so können wir fundierte Entscheidungen treffen und die richtigen Maßnahmen ergreifen, um unsere Produkte und Dienstleistungen zu verbessern.

Indem wir uns bewusst machen, was wir messen und warum, erhöhen wir die Effektivität unserer UX-Strategien und tragen zum langfristigen Erfolg unseres Unternehmens bei.

Und gerne auch mein Newsletter "UXplorer Weekly - Mehr Durchblick pro Woche" abonnieren: Anmeldung zum Newsletter

Welche UX-KPIs nutzt Ihr?

Es gibt zahlreiche Metriken, die als UX-KPIs genutzt werden, um die User Experience effektiv zu evaluieren. Daher stelle ich mir die Frage: Welche spezifischen Metriken nutzt Ihr in Eurer Evaluation? Sind diese Metriken tatsächlich geeignet, um als UX-KPIs zu dienen, und spiegeln sie genau wider, wie Nutzer mit Eurem Produkt interagieren?

Meine Definition einer UX-KPI

Key Performance Indicators (KPIs) sind messbare Werte, die genutzt werden, um den Erfolg von UX-Initiativen zu verfolgen. Eine UX-KPI (User Experience Key Performance Indicator) ist also eine Metrik, die den Erfolg von UX-Maßnahmen über die Zeit hinweg misst. Sie zeigt auf, ob und in welchem Ausmaß ein Unternehmen seine UX-Ziele erreicht. Damit hilft sie dem Management, den Fortschritt von UX-Aktivitäten zu beurteilen und fundierte Entscheidungen zu treffen.

Warum sind UX-KPIs wichtig?

Eine gute UX-KPI schafft Messbarkeit, indem sie die oft abstrakte User Experience greifbar macht. Sie ermöglicht es, den Fortschritt von UX-Maßnahmen über die Zeit zu verfolgen und fundierte Entscheidungen zu treffen. Mit den richtigen Daten können Strategien angepasst und Ressourcen effizient eingesetzt werden. Zudem helfen klare Kennzahlen dabei, die Wichtigkeit von UX im Unternehmen zu kommunizieren und Stakeholder zu überzeugen.

Was macht eine gute UX-KPI aus?

Nicht jede Metrik eignet sich als KPI. Eine gute UX-KPI sollte mehrere Eigenschaften aufweisen. Sie muss relevant sein und direkt mit den UX-Zielen des Unternehmens verknüpft sein. Die Messbarkeit ist entscheidend; die Daten müssen zuverlässig und konsistent erhoben werden können. Nicht zuletzt ist die Verständlichkeit wichtig; die KPI muss für alle Stakeholder verständlich sein, um effektiv kommuniziert zu werden.

Herausforderungen bei der Definition von UX-KPIs

Es ist nicht immer einfach, die richtigen KPIs zu finden. Einige der Herausforderungen, denen ich begegnet bin, sind unter anderem die Datenqualität. Unvollständige oder ungenaue Daten können zu falschen Schlussfolgerungen führen. Eine Überfrachtung mit Metriken kann verwirrend sein und den Fokus verwässern. Zudem gibt es oft organisatorische Hürden; nicht alle im Unternehmen verstehen die Bedeutung von UX-KPIs. Und: Oftmals werden UX-KPIs verwendet, die nicht wirklich die UX repräsentieren.

Fazit

Die Definition einer UX-KPI ist ein entscheidender Schritt, um den Erfolg von UX-Maßnahmen messbar und nachvollziehbar zu machen. Indem wir klare, relevante und verständliche KPIs definieren, können wir den Wert der User Experience in unserem Unternehmen sichtbar machen und gezielt verbessern.

Eure Erfahrungen sind gefragt!

Welche Erfahrungen habt Ihr mit der Definition und Nutzung von UX-KPIs gemacht? Gibt es spezifische Metriken, die für Euch besonders wertvoll sind? Teilt Eure Gedanken und Fragen gerne per E-Mail (andreas(@)hinderks.org) mit!

Und gerne auch mein Newsletter "UXplorer Weekly - Mehr Durchblick pro Woche" abonnieren: Anmeldung zum Newsletter

Was habe ich vor?

In einer mehrteiligen Blog-Reihe möchte ich tief in die Welt der UX-KPIs abtauchen. Mein Ziel ist es, die verschiedenen Kennzahlen vorzustellen und zu zeigen, wie man sie sinnvoll interpretiert und bewertet, die richtigen KPIs für das eigene Produkt auswählt und sie effektiv kommuniziert.

Die Themen im Überblick:

• Übersicht der wichtigsten UX-KPIs: Ich werde die gängigsten Kennzahlen vorstellen und erklären, was sie bedeuten und wann sie eingesetzt werden.
• Methoden zur Bewertung von UX-KPIs: Hier geht es darum, wie man die erhobenen Daten interpretiert und welche Tools und Methoden dabei helfen können.
• Auswahl der richtigen UX-KPIs für Dein Produkt: Nicht jede KPI passt zu jedem Produkt. Ich zeige Strategien auf, wie Du die für Dich relevanten Kennzahlen identifizierst.
• Best Practices zur Kommunikation von UX-KPIs: Wie kannst Du Deine Erkenntnisse effektiv an Stakeholder, Teammitglieder oder Kunden vermitteln?
• Fallstudien und Praxisbeispiele: Anhand realer Beispiele werde ich zeigen, wie UX-KPIs in der Praxis angewendet werden und welchen Unterschied sie machen können.

Warum ist das wichtig?

Die UX-Branche ist dynamisch und ständig im Wandel. Gerade in der aktuellen Zeit kommen immer mehr UX-Professionals unter Druck und müssen sich und ihre Arbeit erklären, bzw. verteidigen. Und Nutzer haben hohe Erwartungen und eine Vielzahl von Optionen. Eine herausragende User Experience ist daher entscheidend, um sich von der Konkurrenz abzuheben und Nutzer langfristig zu binden.

• Messbarkeit schaffen: Durch UX-KPIs wird die oft abstrakte UX greifbar und messbar gemacht.
• Gezielte Optimierung: Mit den richtigen Daten können Schwachstellen identifiziert und gezielt verbessert werden.
• Effektive Kommunikation: UX-KPIs ermöglichen es, Erkenntnisse klar und verständlich an alle Beteiligten zu vermitteln. Manage lieben Zahlen ;-)

Was bringt Euch das?

Am Ende dieser Blog-Reihe werdet Ihr:

• Die wichtigsten UX-KPIs kennen und verstehen: Ihr wisst, welche Kennzahlen es gibt und was sie aussagen.
• Die passenden KPIs für Eure Projekte auswählen: Ihr lernt, wie Ihr die relevanten Kennzahlen identifiziert, die zu Euren Zielen passen.
• Ergebnisse effektiv kommunizieren: Ihr erfahrt, wie Ihr Eure Erkenntnisse überzeugend präsentiert und so Unterstützung für Eure UX-Maßnahmen gewinnt.

Eure Beteiligung ist gefragt!

Ich möchte diese Reihe so interaktiv wie möglich gestalten. Daher freue ich mich über Eure Fragen, Anregungen und Themenwünsche. Gibt es spezifische Herausforderungen, vor denen Ihr steht? Oder bestimmte KPIs, über die Ihr mehr erfahren möchtet? Lasst es mich gerne wissen und schreibt mir eine E-Mail an andreas(@)hinderks.org.

Bleibt dran – es wird spannend!

Ich bin überzeugt, dass das Verständnis und die gezielte Anwendung von UX-KPIs einen großen Unterschied in Euren Projekten machen kann. Gemeinsam können wir tief in dieses Thema eintauchen und voneinander lernen.

Ich freue mich auf die kommenden Wochen mit Euch!

Und gerne auch mein Newsletter "UXplorer Weekly - Mehr Durchblick pro Woche" abonnieren: Anmeldung zum Newsletter

UX Management am Produkt: Eine tiefe Betrachtung

UX Management am Produkt ist ein facettenreicher Ansatz, der sich auf die Schaffung und Pflege eines exzellenten Nutzererlebnisses konzentriert. Es geht darum, Geschäftsresultate zu erzielen, indem man die Bedürfnisse und Erwartungen der Nutzer übertrifft. Dies erfordert eine sorgfältige Planung, strategische Ausrichtung und den Einsatz geeigneter Ressourcen.

Die Säulen des UX Managements

1.) Setzung von UX-Zielen

2.) Entwicklung einer UX-Strategie

3.) Einsatz von UX-Ressourcen

Zusammenfassung

UX Management am Produkt ist eine komplexe, aber lohnende Aufgabe. Es erfordert ein tiefes Verständnis der Nutzer, eine klare strategische Ausrichtung und die Fähigkeit, sich schnell an verändernde Bedingungen anzupassen. Durch die kontinuierliche Abstimmung von Zielen, Strategien und Ressourcen können Teams Produkte schaffen, die Nutzer begeistern und binden. In einer Welt, in der das Nutzererlebnis oft über Erfolg oder Misserfolg entscheidet, ist ein effektives UX Management unerlässlich.

Bei der Einführung eines agilen UX Management kann ich Teams unterstützen. Dabei gehe ich in vier Schritten vor: Vorbereitung, UX in der Entwicklung, UX Messung und UX-Retrospektive. Die einzelnen Schritte werden im Folgenden näher beschrieben.

1 Vorbereitung: Was werden wir in der Vorbereitungsphase durchführen?

Wir werden mit dem Team zusammen die UX-Faktoren bestimmen, die für die User Experience Ihres Produkts am wichtigsten sind. Das können zum Beispiel sein: Attraktivität, Durchschaubarkeit, Vertrauen, Inhaltsqualität, etc.

Auf Grundlage dieser Faktoren werden wir eine UX-Vision erstellen. Diese UX-Vision soll als Leitbild für das angestrebte Nutzungserlebnis dienen. Eine UX-Vision könnte beispielsweise sein: „Durch uns können unsere Kunden schnell, einfach und sorgenfrei bezahlen.“

Nach der UX-Vision werden wir erstmalig die User Experience mittels des User Experience Questionnaire (UEQ+) messen. Wir messen dabei genau die UX-Faktoren, die wir vorher als wichtig ausgewählt haben. Diese erste Messung der UX bildet die Vergleichsgrundlage für die nächsten Messungen.

2 UX in der Entwicklung: Was werden wir mit der Entwicklung durchführen?

Im ersten Schritt ermitteln wir den agilen Reifegrad des Teams. Dafür verwenden wir einen standardisierten Fragebogen. Das Ergebnis ist ein Reifegrad zwischen Stufe 1 – Kollaborativ und Stufe 5 – Umfassend.

Zusätzlich zum agilen Reifegrad ermitteln wir auch den UX-Reifegrad im Unternehmen mit einem standardisierten Fragebogen. Die Stufen des UX-Reifegrads liegen zwischen Stufe 1 – Kein UX-Bewusstsein und Stufe 6 – Institutionalisierte UX.

Mit UX-Poker werden wir dann die User Experience ausgewählter User Stories aus dem Product Backlog schätzen. Durch UX-Poker lässt sich der Einfluss auf die UX quantifiziert für die wichtigen UX-Faktoren schätzen.

3 UX Messung: Was werden wir nach der Entwicklung durchführen?

Nach zwei bis drei Iterationen werden wir die User Experience noch einmal mittels des UEQ+ messen. Es werden, wie schon währen der

Vorbereitungsphase, die wichtigsten UX-Faktoren für Ihr Produkt gemessen. Nach der Durchführung der UX-Messung haben wir folgende Auswertungen:

Die Auswertungen helfen Ihnen, die User Experience Ihres Produkts bewerten zu können.

4 UX-Retrospektive: Was werden wir bei der UX-Retrospektive durchführen?

Die UX-Retrospektive ist eine Gelegenheit für das Team, sich selbst zu überprüfen und einen Plan für Verbesserungen zu. Dabei geht es im ersten Teil darum, den Reifegrad des Teams hinsichtlich der Agilität und der UX-Aktivitäten zu überprüfen.

Der zweite Teil der UX-Retrospektive ist die Bewertung der Wirksamkeit der letzten zwei bis drei Iterationen. Unter Berücksichtigung der Ergebnisse von UX-Poker und den Ergebnissen aus der UX-Messung werden wir Maßnahmen zur Verbesserung ableiten.

Das Ziel ist es, die UX Ihres Produkts im Team und Unternehmen sichtbar zu machen. Nur wenn die UX sichtbar ist, können gezielte Maßnahmen zur Verbesserung ergriffen werden.