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.