In diesem Artikel möchte ich der Frage nachgehen, warum die UX-Reife in bestimmten Momenten und unter bestimmten Bedingungen große Entwicklungssprünge innerhalb kurzer Zeit machen kann, während sie in anderen Momenten zu stagnieren scheint.
Einer dieser Momente ist zwar schon sehr lange her. Da es aber mein erster Moment dieser Art war, möchte ich ihn Dir erzählen. Damals hatten wir uns als UX-Team schon sehr lange für mehr Rapid Prototyping und Usability Testing im Entwicklungsprozess eingesetzt. Wir hatten auch immer mal wieder kleinere Erfolge damit. Unsere Hoffnung, dass diese kleinen Erfolgsbeispiele oder Leuchttürme, wie wir sie damals nannten, zu einer nachhaltigen Veränderung des Entwicklungsprozesses führten, stellte sich aber nicht ein. Die Antworten, die wir zu hören bekamen, waren immer dieselben: „Das ist gerade zu viel Aufwand.”, „Fragst Du 10 Anwender, hast Du am Ende 12 Meinungen.”, „Wir haben für sowas keine Zeit.” oder „Das passt nicht ins Budget und macht uns den Deckungsbeitrag kaputt.”. Das war eine frustrierende Zeit. Wir haben so viel investiert, damit UX-Methoden, wie Rapid Prototyping und Usability Testing, im Entwicklungsprozess Fuß fassen können, aber es wollte einfach nicht so richtig funktionieren.
Dann wurde ein neues Produkt gelauncht. Es war die Nachfolge-Version für ein Produkt, das essenziell für einen wichtigen Geschäftsprozess unserer Anwender:innen war. Der damalige Product Owner ist ein schlauer Mensch, der sich fachlich sehr gut in diesem Geschäftsprozess auskannte. Aufgrund seiner fachlichen Expertise hielt er es auch für ausreichend, die Gestaltungsideen für das Produkt mit genau einem Anwender zu diskutieren. Das Problem dabei war nur, dass dieser Anwender das Produkt gar nicht selbst nutzte, sondern lediglich einen Kollegen in seinem Unternehmen kannte, der das Produkt nutzte. Dieses wichtige Produkt kam nun nach langer Entwicklungszeit auf den Markt und floppte total. Der Arbeitsprozess verlängerte sich durch die neue Bedienoberfläche um einen Tag pro Woche – einen ganzen Tag mehr in so einem wichtigen Arbeitsprozess. Das war eine Katastrophe. Du kannst Dir vorstellen, wie groß der Unmut so mancher Anwender:innen war, als sie wegen des neuen Produktes plötzlich auch am Samstag arbeiten mussten, um alle notwendigen Arbeiten rechtzeitig erledigen zu können. Das führte natürlich ganz schnell zu erheblichen Regressforderungen und massivem Druck auf das Management des Entwicklungsbereiches.
In diesem Moment passierte etwas Unerwartetes. Wir konnten dem Entwicklungsteam durch Usability Testing sehr schnell aufzeigen, wo die Probleme konkret lagen und mit Rapid Prototyping schnell Lösungen für diese Probleme entwickeln, die am Ende wirklich zur Linderung des Unmuts beigetragen haben. Das Produkt wurde deshalb kein Musterbeispiel für gute Produktgestaltung. Aber die Anwender:innen schafften ihre Arbeit wieder innerhalb von fünf Arbeitstagen anstatt sechs. Und scheinbar ganz nebenbei gelang es uns außerdem, wesentliche Aspekte des Human Centered Design im Entwicklungsprozess zu verankern und sogar ein eigenes UX-Budget zu bekommen. Das war damals der Hammer. Beides war vorher komplett undenkbar gewesen.
Was war da passiert? War es Glück? Lag es an unseren Leuchttürmen, wie wir lange dachten? Oder steckt dahinter etwa eine wiederholbare Mechanik? In diesem Blogbeitrag möchte ich Dir ein fundiertes Framework vorstellen, das Dir als UX-Manager:in helfen soll, solche Entwicklungssprünge in der UX-Reife gezielt erreichen zu können.
Die Lücke in den gängigen UX-Reifegradmodellen
Der UX-Reifegrad entwickelt sich nicht linear. Das weiß jede UX-Manager:in, die ein paar Jahre im Geschäft ist. Es gibt Phasen, in denen sich scheinbar nichts bewegt, egal wie gut die Arbeit ist. Und es gibt kurze, intensive Zeitfenster, in denen sich Dinge verändern, die vorher undenkbar schienen.
Die gängigen UX-Reifegradmodelle helfen dabei kaum weiter. Sie beschreiben, was auf den einzelnen Stufen vorhanden sein soll, also an welchen Fähigkeiten, Strukturen und Praktiken gearbeitet werden sollte. Aber sie sagen nichts darüber, wie der Sprung von einer Stufe zur nächsten eigentlich gelingt. Die Übergangsmechanik bleibt meist offen.
Genau dort setzt das „The Prepared UX Community Framework“ an. Es ist ein Erklärungsmodell für die Frage, unter welchen Bedingungen sprunghafte UX-Reifegradentwicklung möglich wird. Es basiert auf meiner Praxisbeobachtung, soziologischen Theorien und ist mittlerweile auch durch das sorgfältige Review erfahrener UX-Manager:innen gegangen.
Was da aus soziologischer Sicht passiert ist
Ich habe mich lange damit beschäftigt, warum sich bestimmte organisationale Auslöser positiv auf die Entwicklung der UX-Reife auswirken und warum das bei anderen nicht so ist. Wenn man solche Momente durch soziologische Linsen betrachtet, wird aus einem scheinbar glücklichen Zufall eine erklärbare Mechanik.
Warum der Moment überhaupt entstehen konnte (Kingdon)
John Kingdon hat das Multiple Streams Framework ursprünglich zur Erklärung politischer Entscheidungsprozesse entwickelt. Seine zentrale Beobachtung war, dass grundlegende Veränderungen selten durch kontinuierlichen Druck entstehen. Sie entstehen, wenn drei unabhängig voneinander fließende Ströme gleichzeitig zusammentreffen: die Wahrnehmung eines Problems (Problem Stream), das Vorhandensein von Lösungskonzepten (Policy Stream) und der Wille zur Veränderung (Politics Stream). Wenn alle drei zusammenkommen, öffnet sich ein kurzes „Window of Opportunity“.
Genau das ist damals passiert. Der Produktflop mit seinen Regressforderungen und dem großen Unmut der Anwender:innen hat den Problem Stream aktiviert. Das Problem war intern nicht mehr wegzudiskutieren. Es wurde von Kolleg:innen bis ins Management als relevant angesehen. Den Policy Stream hatten wir als UX-Team selbst durch jahrelange Arbeit gefüllt. Mit dem Aufbau von eingespielte Usability Testing-Prozessen, Rapid Prototyping-Kapazitäten und dem direkten Zugang zu Testpersonen haben wir unbewusst die Grundlage geschaffen, dass wir in diesem Moment handeln konnten. Und der massive Druck auf das Management des Entwicklungsbereiches aktivierte den Politics Steam. Das Management war bereit, etwas grundlegend zu verändern, damit eine solche Situation nie wieder vorkommt.
Warum wir handlungsfähig waren (Tajfel und Turner)
Henri Tajfel und John Turner haben mit ihrer Social Identity Theory gezeigt, dass Gruppen erst dann zu kollektiv handlungsfähigen Einheiten werden, wenn ihre Mitglieder eine gemeinsame soziale Identität entwickelt haben. Ein geteiltes Bewusstsein darüber, wer sie als Gruppe sind, wofür sie stehen und was sie gemeinsam erreichen wollen.
Als das Fenster sich öffnete, haben wir nicht erst diskutiert, was zu tun sei. Wir haben sofort gemeinsam gehandelt. Über die Jahre gemeinsamer Arbeit an dem Ziel, mehr Human Centered Design in die Entwicklung zu bringen, haben wir in unserem kleinen Team ein gemeinsame Identität entwickelt. Wir hatten eine gemeinsame Sprache. Wir wussten, wofür wir stehen. Dieser innere Zusammenhalt war die strukturelle Voraussetzung dafür, dass wir im entscheidenden Moment schnell handeln konnten.
Warum wir gehört wurden (Bourdieu)
Pierre Bourdieu hat Handlungsfähigkeit in sozialen Kontexten nicht als Frage formaler Macht beschrieben, sondern als Frage des Kapitals. Kapital ist bei ihm jede Form von Ressource, die in einem sozialen Feld Macht und Wirkung verleiht. Für UX-Communities sind dabei vor allem zwei Formen relevant: kulturelles Kapital (Methoden-Kompetenz, fachliches Wissen und nachgewiesene Expertise) und soziales Kapital (Netzwerk, Vertrauen und Beziehungen zu strategischen Entscheidungsträger:innen).
Unser kulturelles Kapital war zu diesem Zeitpunkt gut vorhanden. Wir hatten nicht nur über Usability Testing geredet, sondern wir konnten es auch schnell und mit belegbaren Ergebnissen liefern. Gleichzeitig hatten wir durch die Leuchtturm-Projekte über die Jahre genug soziales Kapital aufgebaut, um in dem Moment als relevante Stimme wahrgenommen zu werden. Wir hatten viele gute Kontakte zu den Kolleg:innen in den Entwicklungsteams und ein entsprechend gutes Standing.
Bourdieu erklärt mit seinem Habitusbegriff aber auch, warum die jahrelange Überzeugungsarbeit davor so wenig gefruchtet hat. Habitus beschreibt das System von Wahrnehmungs-, Denk- und Handlungsmustern, das Menschen durch ihre berufliche Sozialisation verinnerlicht haben und das ihr Handeln strukturiert. Wer tief in einer Fachlogik sozialisiert ist, in der Domänenwissen die entscheidende Ressource ist, kann UX-Argumente zwar intellektuell zur Kenntnis nehmen. Sie treffen aber auf eine verinnerlichte Überzeugung, die sich nicht durch Argumente allein verändert sondern nur durch die eigene Erfahrung. Der Produktflop war diese Erfahrung.
Warum wir diesmal die richtigen Worte gefunden haben (Goffman)
Erving Goffman hat in seiner Frame-Analysis gezeigt, dass Menschen Situationen immer durch Deutungsrahmen wahrnehmen. Was als relevant gilt, was als Problem und was als Lösung, das hängt davon ab, in welchem Rahmen eine Situation betrachtet wird.
Jahrelang hatten wir UX in einem einzigen Frame kommuniziert, nämlich, dass Menschzentrierung und Nutzerfreundlichkeit wichtig sind und dass deshalb mehr UX-Methoden genutzt werden sollten. Dieser Frame hat in keinem der organisationalen Momente gepasst, die wir erlebt hatten. Der Entwicklungsbereich dachte in Deckungsbeiträgen, Zeitplänen und technischer Machbarkeit. Die UX-Botschaften in unserem Frame wurden zwar gehört. Sie waren aber nicht anschlussfähig.
Als das Produkt floppte, haben wir eigentlich ganz unbewusst den Frame gewechselt. Wir haben nicht über Menschzentrierung gesprochen. Wir haben über konkrete Probleme gesprochen, über belegbare Ursachen, über sofortige Wirkung auf einen Arbeitsprozess und über die Vermeidung weiterer Regressforderungen. Wir haben uns in den Deutungsrahmen gestellt, der in diesem Moment für das Management zählte, nämlich Schadensbegrenzung, Qualitätssicherung und Risikominimierung. Und genau deshalb wurden wir gehört.
The Prepared UX Community Framework
Nimmt man nun diese soziologische Grundlage zusammen, lassen sich folgende Bedingungen ableiten, die gegeben sein müssen, damit sprunghafte UX-Reifegradentwicklung gelingen kann.
Kohäsion
Eine UX-Community muss im entscheidenden Moment handlungsfähig sein. Sie muss mit einer Stimme sprechen und kollektiv handeln können. Die dafür notwendige Kohäsion ist das Ergebnis einer geteilten professionellen Identität, einer gemeinsamen Zielsetzung und kontinuierlicher Führungsarbeit. Eine fragmentierte UX-Community, die im Trigger-Moment verschiedene Richtungen zieht, kann ein Window of Opportunity nicht nutzen, egal wie gut die einzelnen Mitglieder fachlich sind.
Framing-Kompetenz
Dieselbe UX-Botschaft muss in verschiedenen organisationalen Momenten vollständig unterschiedlich gerahmt werden. In einer Kostenkrise spricht UX über Fehlerkosten und Effizienz. In einem Wachstumsmoment über Differenzierung und neue Nutzergruppen. In einer Qualitätskrise über Risikomanagement und Reputationsschutz. Der naheliegende Frame „Human Centricity ist wichtig” ist an sich nicht falsch, passt nur leider selten zur Situation von Unternehmen.
Darüber hinaus braucht gutes Framing auch ausreichend kulturelles und soziales Kapital. Damit die Botschaft von den Richtigen gehört wird, muss das UX-Team wegen seiner Expertise anerkannt sein und über das passende Netzwerk an Stakeholder:innen verfügen.
Trigger-Moment
Ein organisationaler Auslöser, wie z.B. ein großer Produktflop, ein Führungswechsel oder eine Umorganisation, öffnet ein kurzes Fenster mit erhöhter Aufmerksamkeit und Veränderungsbereitschaft. In unserem Fall war es die Kombination aus einem technischen Produktversagen, massivem Anwenderunmut, Regressforderungen und Management-Druck. Dieses Fenster ist kurz. Ein UX-Team, dass so einen Trigger-Moment erkennt und darauf vorbereitet ist, kann dieses kurze Zeitfenster für nachhaltige Veränderungen nutzen. Vorbereitet sein heißt in diesem Zusammenhang, die richtigen Voraussetzungen geschaffen und die nötigen Maßnahmen vorbereitet zu haben.
Drei Zustände der Vorbereitung
Das Framework beschreibt drei Zustände, die ein UX-Team oder eine UX-Community einnehmen kann und die erklären, warum manche UX-Teams einen Trigger-Moment nutzen können und andere nicht.
Im ersten Zustand ist eine UX-Community kohäsiv. Sie hält zusammen, schützt den erreichten Reifegrad vor Erosion und verhindert Rückschritt. Eine kohäsive, aber nach innen gerichtete UX-Community ist das, was das Framework als wartende UX-Community beschreibt. Sie argumentiert für die Richtigkeit menschzentrierter Arbeitsweisen, baut kulturelles Kapital auf und wartet darauf, dass die Organisation ihre Bedeutung irgendwann anerkennt. Wenn dann ein Trigger-Moment eintritt, fehlen ihr die vorbereiteten Maßnahmen, die Framing-Kompetenz und die Verbindungen zu den Menschen, die im entscheidenden Moment zählen.
Im zweiten Zustand kommt Framing-Kompetenz hinzu, getragen von kulturellem und sozialem Kapital. Die UX-Community beobachtet die Organisation systematisch, pflegt Stakeholder-Beziehungen und passt ihre Argumentation an den jeweiligen Kontext an. Sie wächst langsam, gewinnt schrittweise Einfluss. Dieser Zustand sollte der Normalzustand guter UX-Communities sein.
Im dritten Zustand trifft eine vorbereitete UX-Community auf einen organisationalen Trigger-Moment. Hier werden die Sprünge möglich, die im Normalbetrieb nicht erreichbar gewesen wären.
In unserem Beispiel von damals: Wir befanden uns in Zustand 2. Wir waren nicht perfekt aufgestellt, aber offensichtlich vorbereitet genug. Wir hatten Kohäsion, wir hatten kulturelles und soziales Kapital aufgebaut und wir haben im entscheidenden Moment den richtigen Frame gewählt. Der Produktflop hat das Fenster geöffnet. Unsere Vorbereitung hat dafür gesorgt, dass wir es nutzen konnten.
Die Institutionalisierung nach dem Trigger-Moment
Es gibt einen Schritt, den wir damals intuitiv richtig gemacht haben, ohne ihn damals bewusst als solchen zu erkennen. Und er ist mindestens genauso wichtig wie alles, was davor kam.
Wenn eine UX-Community einen Trigger-Moment nutzt, geht es nach dem ersten Erfolg nicht einfach weiter wie bisher. Es geht darum, was mit dem Erreichten passiert. Gewonnener Einfluss, veränderte Vorgehensweisen oder bereitgestelltes Budget existieren nach einem Trigger-Moment zunächst in einem fragilen Zustand. Die organisationale Aufmerksamkeit, die das Fenster geöffnet hat, wird sich verschieben. Das nächste Thema kommt. Der Druck lässt nach.
Wenn die erreichten Veränderungen nicht aktiv in dauerhafte Strukturen überführt werden, ist selbst der größte Sprung am Ende ein Strohfeuer. Das UX-Budget verschwindet in der nächsten Sparrunde. Die neu verankerten HCD-Prozesse werden still wieder umgangen, wenn der Zeitdruck steigt. Der Reifegrad erodiert zurück.
Institutionalisierung bedeutet deshalb, dass das Erreichte unabhängig von Personen und vom ursprünglichen Trigger im Unternehmen verankert wird. Nicht auf den Schultern einzelner Fürsprecher:innen, sondern in Prozessen, Strukturen und Entscheidungsregeln, die auch dann halten, wenn die Personen wechseln, die den Trigger-Moment erlebt haben.
In unserem Beispiel war genau das der entscheidende zweite Schritt. Das UX-Budget und die verankerten HCD-Aspekte im Entwicklungsprozess wurden formalisiert. Und erst dadurch wurden sie dauerhaft.
Lass uns darüber reden
Das „The Prepared UX Community Framework“ hat eine solide soziologische Basis und basiert auf meiner Praxiserfahrung. Es ist aber noch nicht empirisch validiert. Deshalb möchte ich Dich zum Diskurs darüber auf dem UX-Festival 2026 und auf dem UX-Leadership-Barcamp 2026 einladen. Dort möchte ich dieses Modell mit Dir diskutieren:
- Passt das Modell zu Deinen Erfahrungen bei der Weiterentwicklung der UX-Reife?
- Was fehlt auf Basis Deiner Erfahrungen?
- Welche Trigger-Momente hast Du in Deiner Organisation erlebt? Wie konntet ihr sie nutzen?
Wenn Du vorher tiefer einsteigen möchtest, dann melde Dich gern. Ich schicke Dir gern das vollständige Paper zum Framework.
„Kohäsion, Framing, Trigger sind keine Magie. Es ist eine Mechanik. Und Mechaniken kann man lernen.“
