Softwarearchitektur: Technische Entscheidungen sind auch UX-Entscheidungen

Ein Checkout zeigt „Bestellung wird verarbeitet“ und die Anwendung reagiert verzögert. Der Status bleibt unklar, weshalb Nutzerinnen und Nutzer erneut klicken, vielleicht sogar abbrechen oder sich fragen, ob sie gerade doppelt bezahlen. Aus technischer Sicht geht es hier vielleicht um Antwortzeiten, Statuslogik oder Wiederholbarkeit, aber aus UX-Sicht entsteht in diesem Moment bei Nutzerinnen und Nutzern einfach nur Unsicherheit.

Dominique Winter ist Experte für erlebnisorientierte Produktentwicklung und unterstützt Organisationen dabei, begeisternde Produkte zu entwickeln. Praktische Erfahrungen aus der digitalen und nicht-digitalen Produktentwicklung ergänzt er durch langjährige Forschung in den Bereichen Organisationsentwicklung und User Experience. Seine Erfahrungen teilt er mit jedem, der Lust hat etwas Neues auszuprobieren und persönlich zu wachsen.

Auf den ersten Blick wirkt das wie ein Designproblem. Vielleicht ist das Interface nicht klar genug oder es fehlen Hinweise an den richtigen Stellen. Vielleicht müsste man die Nutzerführung verbessern oder die Texte überarbeiten. Das kann alles richtig sein, aber häufig zeigt sich im Interface nur, was vorher bereits in der Architektur, in der Priorisierung, im Datenmodell, in der Fehlerbehandlung oder in den Zielsystemen der Organisation entschieden wurde. Entwicklungsteams behandeln die UX oft dort, wo sie sichtbar ist. Doch die Entscheidung darüber findet an vielen Stellen statt, an denen niemand ausdrücklich über UX spricht.

Viele UX-Probleme entstehen lange vor dem Interface

Wenn beispielsweise der Checkout eines Onlineshops langsam reagiert, arbeiten Entwicklerinnen und Entwickler am sichtbaren Teil des Problems. Sie passen die Texte an, ergänzen Hinweise, bauen Tooltips ein oder erweitern Hilfeseiten. Das kann hilfreich sein, löst aber nicht zwingend die Ursache. Wenn der eigentliche Grund eine unklare Statuslogik oder vielleicht auch eine instabile Schnittstelle ist, die verlässliche Rückmeldungen erschwert, bleibt die UX-Schwäche bestehen – egal, wie viele visuelle Änderungen man durchführt.

Das gleiche Muster findet sich auch in internen Anwendungen. Eine Anwendung kann fachlich korrekt sein und trotzdem schlechte Nutzungserlebnisse erzeugen, wenn Statuswechsel nicht nachvollziehbar sind. Ein Formular kann alle notwendigen Felder enthalten und trotzdem überfordern, vor allem dann, wenn Begriffe aus dem Datenmodell nicht zur Sprache der Anwenderinnen und Anwender passen.

UX entsteht im Erleben, nicht in der Zuständigkeit

User Experience ist nicht das, was UX-Designerinnen und -Designer tun. Sie ist das, was bei Menschen entsteht, wenn sie mit einem Produkt, Service oder System in Berührung kommen. Menschen haben dabei Erwartungen und sie interpretieren Rückmeldungen. Sie bewerten, ob ein System für sie zuverlässig, verständlich, hilfreich oder hinderlich ist. Aus jeder einzelnen Nutzung entsteht eine Erfahrung, die sich zu einer gesamten Erfahrung aggregiert, die wiederum die zukünftigen Nutzungen prägt.

Die Product Owner Days 2027 am 10. und 11. März in Köln zeigen Product Ownern und Produktmanagerinnen praxisnah, wie sie in einem sich rasant verändernden Umfeld wirksam agieren können. Updates zum Programmstart via Newsletter.

Das Interface spielt dabei eine zentrale Rolle, weil es die Schnittstelle zwischen Mensch und System bildet. Jedoch prägen auch Geschwindigkeit, Stabilität, Datenqualität, Fehlermeldungen, Prozesslogik, Barrierefreiheit, Dokumentation und Supportfähigkeit, wie Menschen ein Produkt erleben.

Viele Entscheidungen haben UX-Folgen. Manche davon sind gestalterisch, manche technisch, manche produktstrategisch und manche organisational.

Wenn eine Architektur Veränderungen erschwert, wirkt sich das auf die UX aus, weil Nutzerprobleme langsamer gelöst werden. Bleiben technische Schulden dauerhaft unbehandelt, kann das UX-relevante Verbesserungen verhindern. Wenn ein Unternehmen vor allem den Featureumfang misst, aber nicht, ob Menschen ihre Aufgaben besser erledigen können, beeinflusst auch das die UX.

UX lässt sich deshalb nicht einfach an UX-Professionals delegieren. Nicht als nachgelagerte Prüfung, nicht als Hübschmachen fertiger Funktionen und nicht als Aufgabe einer einzelnen Rolle. UX muss als Kriterium in Entscheidungen sichtbar werden.

Technische Entscheidungen sind auch UX-Entscheidungen

Viele Entwicklungsteams diskutieren technische Entscheidungen vor allem unter technischen Kriterien. Das ist nachvollziehbar, denn oft werden von der Entwicklerorganisation, etwa von Vorgesetzten, insbesondere Kriterien wie Wartbarkeit, Sicherheit, Performance, Skalierbarkeit, Stabilität oder Kosten immer wieder in Gesprächen in den Fokus gebracht. Diese Kriterien sind wichtig, aber sie sind nicht von der UX getrennt.

Architektur bestimmt zum Beispiel unter anderem, wie schnell sich ein Produkt verbessern beziehungsweise überarbeiten lässt. Wenn jede kleine Änderung viele Abhängigkeiten berührt, wird Nutzerfeedback langsamer umgesetzt. Aus Sicht des Entwicklungsteams ist das eine Architekturfrage, aus Sicht der Nutzerinnen und Nutzer bedeutet es, dass bekannte Probleme länger bestehen bleiben.

Performance wiederum beeinflusst Vertrauen und wahrgenommene Qualität. Eine Anwendung, die langsam reagiert, wirkt unsicherer. Menschen warten, klicken erneut oder zweifeln daran, ob ihre Aktion erfolgreich war. In transaktionalen Prozessen kann das Abbrüche erzeugen, in internen Anwendungen kostet es Zeit, Aufmerksamkeit und Akzeptanz.

Aber auch Datenmodelle beeinflussen die User Experience, denn dort entscheidet sich, ob Nutzer Informationen verstehen und wiederfinden. Wenn Kundinnen und Kunden nach „Rechnung“ suchen, das System intern aber zwischen „Beleg“, „Abrechnungslauf“ und „Zahlungsdokument“ unterscheidet, entsteht nicht nur ein Suchproblem, sondern ein Bedeutungsproblem. Menschen müssen lernen, wie das System denkt, statt ein System zu nutzen, das ihrer Denkweise entspricht.

Selbst die Fehlerbehandlung ist eine UX-Entscheidung. Eine Meldung wie „Ein Fehler ist aufgetreten“ hilft Nutzerinnen und Nutzern nicht weiter. Gute Fehlerbehandlung macht verständlich, was passiert ist, was User tun können und wann externe Hilfe nötig ist. Dafür braucht es häufig technische Voraussetzungen: nachvollziehbare Status, Logging, Wiederholbarkeit, eindeutige Fehlercodes und Supportprozesse, die den konkreten Fall sichtbar machen.

Und letztlich entscheiden Monitoring und Observability darüber, ob UX-relevante Probleme überhaupt auffallen. Wenn Entwicklungsteams nur Serververfügbarkeit messen, aber keine Abbruchpunkte, Antwortzeiten in kritischen Nutzerflüssen oder Fehlerraten auf Prozessschritten, bleibt vieles unsichtbar. Dann sieht das System stabil aus, obwohl Menschen regelmäßig scheitern.

Technische Entscheidung	Mögliche UX-Wirkung	Beobachtbares Signal
unklare Statuslogik	Unsicherheit	Wiederholklicks, Rückfragen, Supportfälle
langsame Antwortzeiten	Vertrauensverlust	Abbrüche, sinkende Conversion, Beschwerden
unpassendes Datenmodell	kognitive Last	Suchfehler, Fehlbedienung, Workarounds
fehlende Fehlerdiagnose	Hilflosigkeit	Eskalationen, lange Supportzeiten
nur technisches Monitoring	UX-Probleme bleiben unsichtbar	stabile Uptime trotz negativer Rückmeldungen

Tabelle: Technische Entscheidung, UX-Wirkung, beobachtbares Signal

Technische Qualität und UX sind deshalb keine getrennten Welten. Gute technische Entscheidungen schaffen Voraussetzungen dafür, dass gute User Experience entstehen und erhalten bleiben kann.

UX muss in die Routinen

User Experience wird stärker berücksichtigt, wenn sie regelmäßig in den Momenten auftaucht, in denen Entscheidungen ohnehin getroffen werden. Dafür braucht es keine zusätzlichen Großprozesse. Häufig reichen kleine Ergänzungen bestehender Routinen.

In Feinabstimmungen können Entwicklerinnen und Entwickler zusätzlich zu Akzeptanzkriterien auch UX-Kriterien besprechen. Welche Nutzergruppen sind betroffen? Welche Reibung möchte man reduzieren? Welche Fehlersituationen muss man verständlich behandeln? Welche Annahmen über das Verhalten der Nutzerinnen und Nutzer trifft man?

Reviews können nicht nur zeigen, was gebaut wurde. Teams können darin auch sichtbar machen, welche Nutzung sie verbessert haben, welche Annahmen noch offen sind und welche Signale sie nach dem Release beobachtet haben. Dadurch verschiebt sich der Fokus von Umsetzung zu Wirkung.

Bei Architekturentscheidungen kann man fragen, welche Auswirkungen eine Entscheidung auf Änderbarkeit, Lernfähigkeit und Nutzungserleben hat. Eine Architektur, die kurzfristig schneller ist, kann langfristig verhindern, dass das Entwicklungsteam Nutzerfeedback sinnvoll umsetzt. Umgekehrt kann ein technisch aufwendigerer Ansatz gerechtfertigt sein, wenn er kritische Nutzerflüsse stabiler, verständlicher oder fehlertoleranter macht.

In der Priorisierung sollten UX-relevante Risiken neben Business Value, Aufwand und technischen Risiken sichtbar sein. Nicht jedes Nutzerproblem ist automatisch wichtiger als andere Themen, aber wenn es nicht explizit vorkommt, verliert es leicht gegen andere Größen wie Umsatz oder Deadlines.

Auch technische Schulden lassen sich als UX-Risiken beschreiben. Natürlich ist nicht jede technische Schuld für User unmittelbar relevant. Aber wenn ein veraltetes Modul präzise Fehlermeldungen verhindert, ein Datenmodell die Suche erschwert oder fehlende Tests jede Änderung an einem kritischen Prozess riskant machen, ist das nicht nur ein internes Technikproblem.

• Welche Nutzergruppen sind von dieser Entscheidung betroffen?
• Welches Erlebnis verbessern oder verschlechtern wir dadurch?
• Welche Reibung entsteht für Nutzerinnen und Nutzer?
• Welche UX-Risiken gehen wir bewusst ein?
• Woran erkennen wir später, ob die Entscheidung richtig war?
• Welche technische Entscheidung verhindert oder ermöglicht eine bessere Nutzung?
• Welche Nutzerprobleme können wir wegen aktueller technischer Schulden nicht lösen?
• Wie würden Nutzerinnen und Nutzer im Idealfall über unsere Lösung sprechen?

Gemeinsame Verantwortung braucht klare Verankerung

UX als Entscheidungsgröße bedeutet nicht, dass alle alles entscheiden oder überall mitreden müssen. Es bedeutet auch nicht, dass jede technische Entscheidung eine ausführliche Diskussion mit UX-Professionals nach sich ziehen muss. Das wäre weder effizient noch praktikabel.

Es bedeutet, dass relevante Rollen verstehen, wie ihre Entscheidungen das Erleben der Nutzerinnen und Nutzer beeinflussen können.

Entwicklerinnen und Entwickler, Softwarearchitektinnen und -architekten sehen oft früh, wenn ein Datenmodell spätere Nutzung erschwert, wenn eine Schnittstelle Prozessbrüche erzeugt oder wenn technische Schulden Verbesserungen blockieren. Diese Beobachtungen sind nicht nur technische Hinweise, sondern sie sind Beiträge zur Produktqualität.

Product Owner und Product Manager setzen Prioritäten, formulieren Ziele und vermitteln zwischen Interessen. Sie müssen dafür sorgen, dass UX nicht nur als Wunsch auftaucht, sondern als Kriterium in Produktentscheidungen.

UX-Professionals bringen Nutzungskontexte, Wahrnehmung, Interaktion und qualitative Erkenntnisse systematisch ein. Ihre Arbeit wird wirksamer, wenn sie nicht nur Lösungen gestaltet, sondern Entscheidungsprozesse beeinflusst.

Führungskräfte und Organisationen schaffen schließlich die Bedingungen, unter denen UX Entscheidungsrelevanz erlangt. Sie entscheiden mit, welche Ziele zählen, welche Metriken ernst zu nehmen sind, welche Routinen etabliert werden und welche Kompromisse akzeptabel sind.

Gemeinsame Verantwortung darf aber nicht bedeuten, dass am Ende niemand verantwortlich ist. Gute UX darf nicht vom Engagement einzelner Personen abhängen. Sie muss in Routinen, Entscheidungslogiken, Metriken und Teamprozessen verankert sein.

Am Ende zählt, welche Entscheidungen sich verändern

UX wird nicht dadurch besser, dass Organisationen häufiger über UX sprechen. Sie wird besser, wenn sich Entscheidungen verändern – und zwar dann, wenn man technische Schulden nicht nur als internes Ärgernis versteht, sondern als mögliches Risiko für Nutzungsqualität. Aber auch, wenn Architekturentscheidungen nicht nur auf Wartbarkeit und Skalierung beruhen, sondern darin Veränderungsgeschwindigkeit, Statuslogik und Fehlerbehandlung Berücksichtigung finden. Und wenn Entwicklungsteams sowie Product Owner und Product Manager UX nicht erst nach der Umsetzung prüfen, sondern als Kriterium in Priorisierung und Zielsysteme einbauen, dann wandelt sich UX von einem nachgelagerten Gestaltungsthema zu einer gemeinsamen Entscheidungsgröße.

Digitale Produkte entstehen nicht nur aus Ideen, Anforderungen und Code. Sie entstehen aus vielen Entscheidungen, die über die Zeit getroffen, wiederholt oder korrigiert werden. Wer bessere Produkte bauen will, muss also dafür sorgen, dass Entwicklungsteams und Organisationen die Entscheidungen verbessern, aus denen Interfaces, Systeme, Prozesse und Erlebnisse entstehen.

Gute User Experience entsteht dort, wo man technische, fachliche und organisationale Entscheidungen konsequent daran misst, ob sie Menschen helfen, mit einem Produkt besser zurechtzukommen.