UX-Management im Realitätscheck

Problemlösung im UX-Management: Ein fallbasierter Workshop zur Entwicklung praxistauglicher Lösungen

‍‍
‍Mein Erfahrungsbericht von der Mensch und Computer 2025, von Andreas Hinderks, Dominique Winter, Ulf Schubert, Uwe Betzin und Sebastian Gerhardt

Montagmorgen, 11 Uhr. Voller Neugier finde ich meinen Platz. Der German UPA Arbeitskreis UX Management steht auf dem Programm – und ich will unbedingt dabei sein. Warum? Weil ich sehen wollte, mit welchen Themen sich der Arbeitskreis aktuell beschäftigt. Und weil ich das UX Management Playbook der German UPA schon beim ersten Lesen enorm spannend fand.

Umso interessanter war es, dass der Arbeitskreis ein konkretes Fallbeispiel mitgebracht hatte – ein realistisches Szenario, das nicht nur die Komplexität von UX im Unternehmensalltag sichtbar machte, sondern auch die Relevanz gemeinsamer Reflexion. Ziel der Session: Erfahrungen bündeln, Perspektiven austauschen und gemeinsam Lösungen entwickeln, die praxistauglich sind.

‍

Der Fall „SWIM“ – UX zwischen Anspruch und Wirklichkeit

Das Beispiel: ein Mittelständler mit rund 4.500 Mitarbeitenden, davon 100 in der Softwareentwicklung. Gearbeitet wird in zehn agilen Teams, unterstützt von einem zentralen UX-Team. Klingt solide. Doch wie so oft liegt der Teufel im Detail.

Das Kernproblem: UX kommt zu spät – und läuft ins Leere.

UX-Research wird meist erst dann beauftragt, wenn Features schon entwickelt sind. Product Owner bestellen Tests zum Projektende, Entwickler:innen empfinden UX als Zusatzaufwand. Das UX-Team arbeitet engagiert, ist aber zunehmend frustriert – weil ihre Erkenntnisse kaum Wirkung zeigen.

Das eigentlich Bittere: Nicht die Research-Arbeit selbst ist langsam, sondern alles drumherum. Unklare Auftragsklärung, lange Wartezeiten, zähe Abstimmungen, schwierige Rekrutierung. Der ganze Prozess dauert 7 bis 14 Wochen. UX kommt zu spät, um mitzugestalten.

Vier Rollen, vier Erwartungen – ein Zielkonflikt

Das Fallbeispiel machte deutlich:

• Product Owner wollen vor allem pünktlich liefern.
• Entwicklungsteams brauchen Fokus und Ruhe.
• UX-Teams streben nach Wirkung und Relevanz.
• Das Management erwartet spürbare Beiträge zur Produktqualität.
  
  

UX sitzt zwischen allen Stühlen – und wird trotzdem zu selten frühzeitig einbezogen.

Der Workshop – kollektives Denken in Aktion

Die Methode: Erst still für sich denken und Ideen auf Post-its sammeln, dann gemeinsam clustern, diskutieren und bewerten. Drei Gruppen bildeten sich und bearbeiteten jeweils das gleiche Fallbeispiel aus unterschiedlichen Perspektiven.

In unserer Gruppe kristallisierten sich drei zentrale Ansätze heraus:

1. UX muss von Anfang an dabei sein – als integraler Bestandteil des Projektteams, nicht als nachgelagerte Prüfinstanz.
   
2. Frühzeitige Integration von Nutzerinsights – durch geeignete Formate, die Erkenntnisse dort einbringen, wo Entscheidungen getroffen werden.
   
3. UX braucht KPIs – um Wirkung zu messen und sichtbar zu machen, gerade gegenüber Stakeholdern.

Andere Gruppen fokussierten sich auf die organisatorische Integration in crossfunktionale Teams, auf optimierte Prozesse oder auf den Aufbau eigener Panels für Nutzerforschung. Die Vielfalt war beeindruckend – und zeigt: UX kann auf vielen Wegen wirksamer werden.

Als besonders wirksam wurde aus der Fallstudie die Auflösung des Agenturmodells hin zur Integration von UX in die Produktentwicklung identifiziert – sowie der Aufbau eines Nutzer:innen-Panels, um kontinuierliche nutzerzentrierte Gestaltung zu ermöglichen.

UX als Team-Mindset – nicht als Spezialdisziplin

Besonders eindrücklich war die Diskussion über Nutzerzentrierung als Teamaufgabe. UX entsteht nicht in der Forschung – sondern im Zusammenspiel. Wenn Teams bei Tests dabei sind, mitschreiben, beobachten und mitfühlen, entsteht ein ganz anderer Bezug zum Produkt. Betroffenheit erzeugt Verantwortung. 

Erkenntnisse, die gemeinsam erarbeitet werden, landen nicht im Confluence, sondern im Backlog. UX wird zur Risikoprophylaxe. Und genau das ist der Brückenschlag zum Management: UX hilft, Fehlentwicklungen zu vermeiden. Auch juristisch – z. B. bei Barrierefreiheit, Datenschutz, gesetzlichen Vorgaben oder Sicherheitsthemen. Aber eben auch emotional: UX zeigt, was Menschen erwarten, erleben, brauchen.

Mein Fazit: UX braucht (immer noch) Erklärung

Was ich aus dieser Session mitnehme? Eine Menge. Vor allem aber: UX muss sich noch immer erklären – obwohl der Mehrwert so offensichtlich ist. Ob in agilen Teams, in Führungsetagen oder in Gesprächen mit Entwickler:innen: Die Frage "Warum UX?" ist immer noch nicht überall durchdrungen. Zumindest nicht so, dass es als selbstverständlich gilt. Es braucht Zeit und Beharrlichkeit. Und es braucht einen Mix an Maßnahmen. Es sind immer wieder dieselben Probleme, die aber individuell gelöst werden müssen.

UX gehört von Anfang an in ein Projekt. Wir brauchen Prozesse, frühzeitige Perspektivenvielfalt und ein gemeinsames Verständnis über die Rollen im Team. UX ist kein Sprint, sondern ein kontinuierlicher, langfristiger Prozess. Interdisziplinäre Zusammenarbeit ist dafür genauso essentiell wie echte Teilhabe aller Projektmitglieder – nicht nur punktuell, sondern als Haltung. Wenn wir wirklich nutzerzentrierte Produkte entwickeln wollen, müssen wir auch die Risiken vermeiden, Produkte zu entwickeln, die später weder akzeptiert noch regulatorisch tragfähig sind. 

Das Fallbeispiel war ein eindrucksvoller Beweis, wie tief verankert die Herausforderungen sind – und wie viel Potenzial wir heben könnten, wenn wir Rollen, Prozesse und Mindsets mutiger denken. Mein Dank gilt Ulf und dem gesamten Arbeitskreis für dieses wichtige Thema. UX braucht einen langen Atem. Aber es lohnt sich.

Ich bin dankbar für diese Session – und überzeugt: Wenn wir weiter gemeinsam denken, verändern wir nicht nur Prozesse, sondern die Kultur.

‍