Eine Sachbearbeiterin öffnet die Auftragsliste, setzt ihre Filter, exportiert das Ergebnis und rechnet in Excel weiter. Die Software kann diese Sicht liefern. Sie tut es nur an einer Stelle, die seit dem letzten neuen Modul niemand mehr auf Anhieb findet. Solche Umwege haben einen Namen: UX-Schulden in Bestandssoftware, im Englischen UX Debt, manchmal auch Schulden im Design genannt.
Jede Entscheidung, die das Interface schneller fertig gemacht hat als richtig, arbeiten eure Nutzer täglich ab: mit Klicks, mit Rückfragen, mit Excel. Dieser Artikel zeigt, woran ihr UX-Schulden erkennt, wie ihr sie priorisiert und wie ihr sie abbaut, ohne die Software neu zu bauen. Ich schreibe aus über zehn Jahren Arbeit mit komplexer B2B-Software.
Was UX-Schulden sind und warum sie in B2B-Software anders wirken als auf Websites
Technische Schulden kennt ihr: Code, der schnell entstanden ist und später Zeit kostet. UX-Schulden folgen demselben Prinzip, nur an der Oberfläche.
Die Nielsen Norman Group beschreibt in „UX Debt: How to Identify, Prioritize, and Resolve“ einen Dreischritt: identifizieren, nachhalten und priorisieren, beheben. Metzger Consult ordnet den Begriff in „Was sind UX-Schulden und wie geht man damit um?“ für den deutschen Markt ein und zitiert dabei Baymard: 69 % aller UX-Probleme im E-Commerce sind vermeidbar. Der Kontext dort ist der Onlineshop, nicht die Bestandssoftware.
Genau hier liegt der Unterschied. Auf einer Website hat die Schuld eine natürliche Grenze: Der Besucher geht. In eurer Software geht niemand. Die Sachbearbeiterin muss den Auftrag anlegen, der Disponent muss die Tour planen, die Teamleiterin muss freigeben. Sie arbeiten um die Schuld herum, und der Umweg wird Routine.
Dazu kommt die Dichte. B2B-Oberflächen müssen Tabellen, Filter, Massenbearbeitung, Rollen und Rechte aushalten. Ein unklares Datumsfeld taucht nicht auf einer Seite auf, sondern in jeder Maske, die das Feld verwendet. Deshalb hilft es wenig, einzelne Screens zu polieren.
Wir arbeiten nach dem Grundsatz „Systeme statt Screens“: Komponenten, Zustände und Regeln statt Einzelbildschirme.
Woran ihr UX-Schulden in eurer Software erkennt
Ihr braucht kein Analysetool, um den Verdacht zu prüfen. Setzt euch neben eure Nutzer und achtet auf diese Muster.
Nutzer weichen aus, brechen ab oder öffnen Excel
Das sind die drei Handlungen, nach denen wir bei der Beobachtung suchen. Ein Export nach Excel heißt: Die Software liefert die Sicht nicht, oder nicht dort, wo der Nutzer sie gerade braucht. Ein Abbruch heißt: Der Vorgang ist länger als die Geduld dafür.
Niemand findet etwas auf Anhieb
Module kamen dazu, die Navigation blieb. Neue Kolleginnen brauchen für Funktionen eine mündliche Erklärung, die eigentlich im Menü stehen müsste.
Dieselbe Funktion sieht an drei Stellen anders aus
Jedes Team baut eigene Komponenten. Der Nutzer lernt jede Variante des Datumsfelds, jeder Tabelle, jedes Dialogs einzeln und traut keiner davon ganz.
Entwickler raten Zustände
Was zeigt die Liste, wenn sie leer ist? Was passiert, wenn das Laden hängt oder die Berechtigung fehlt? Steht das nirgends, entscheidet es der Entwickler beim Bauen.
Der Sprint diskutiert, was die Spezifikation nicht sagt
Das Ergebnis wird zweimal gebaut, und das Budget geht nicht in neue Funktionen, sondern in Rework.
Die Übergabe blockiert den Termin
Screens ohne Dokumentation stoppen die Entwicklung und mit ihr den Termin.
Dazu kommen Signale, die ihr vermutlich aus anderen Abteilungen hört: mehr Rückfragen im Support, längere Einarbeitung neuer Mitarbeitender. Wenn ihr mehrere dieser Muster wiedererkennt, habt ihr UX-Schulden, und jetzt ein Wort dafür, das die Entwicklung versteht.
Warum die Schulden in gewachsener Software entstehen
Niemand plant UX-Schulden. Sie entstehen aus Entscheidungen, die einzeln vernünftig waren. Die Zinsen darauf zahlen eure Nutzer, jeden Tag, in Klicks.
Jedes Symptom aus der Liste oben hat eine Entscheidung dahinter: das Modul musste schnell rein, das Designsystem fehlte, die Regel stand nirgends, die Spezifikation hatte Lücken. Jeder Schritt für sich verständlich, zusammen ergeben sie eine Oberfläche, die niemand entworfen hat.
Das ist kein Sonderfall gewachsener Mittelstandssoftware. Das Software Quality Journal hat UX-Schulden in agilen Teams in „UX debt in an agile development process: evidence and characterization“ wissenschaftlich charakterisiert. Die Kyle David Group vertritt in „The UX Debt Audit Leaders Need Before Q4 Renewals“ die These, dass UX-Reibung 6 bis 18 Monate still kumuliert. Still heißt: Niemand eskaliert.
Schulden inventarisieren: das UX-Audit
Bevor ihr abbaut, braucht ihr eine Liste. Nicht die Beschwerden aus Support, Vertrieb und Key Accounts, verstreut über Mails und Tickets, sondern eine Inventur der Oberfläche.
Der Weg dahin ist unspektakulär: Wir sehen euren Nutzern bei der Arbeit zu und finden die Stellen, an denen sie ausweichen, abbrechen oder Excel öffnen. Dazu kommen Interviews und ein Usability Test; das Ergebnis ist ein Analyse Report. Zusehen findet, was eine Umfrage nicht findet: Umwege, die Nutzer für normal halten und nicht mehr erwähnen.
Ein Beispiel aus meiner Arbeit: die Zeiterfassung von Troi+. Aus einem Workshop und der Analyse der Bestandssoftware wurden verbindliche Prinzipien für die Bedienung und eine begründete Anforderungsliste, priorisiert und in Phasen gebracht. Am Ende stand kein behobenes Problem, sondern eine Reihenfolge.
Die Kyle David Group nennt diesen Schritt Friction Inventory, die Nielsen Norman Group „Identify“. Die Namen unterscheiden sich, das Prinzip nicht: erst sehen, dann bewerten, dann bauen.
Priorisieren: welche Schuld zuerst getilgt wird
Eine Liste von Schwachstellen behebt niemand gleichzeitig. Sie ist erst dann etwas wert, wenn sie eine Reihenfolge hat. Erkennen und priorisieren gehören deshalb zusammen.
Die Nielsen Norman Group schlägt vier Kriterien vor: Impact, Stage, Häufigkeit und Aufwand.
Bei uns kommt eine Regel dazu, die den Ausschlag gibt: Wir ordnen die Informationsarchitektur, bis der häufigste Vorgang auch der kürzeste ist. Für die Priorisierung heißt das: Die Schuld im häufigsten Vorgang kommt zuerst, auch wenn sie unscheinbar wirkt. Ein Klick zu viel in einem Vorgang, den jeder Nutzer täglich ausführt, wiegt schwerer als ein Fehler in einer Maske, die nur der Admin gelegentlich öffnet.
Wir gewichten nach denselben Kriterien, also wie oft, wie stark und wie teuer zu beheben, und setzen die Häufigkeit an die erste Stelle. Bei Troi+ stand am Ende eine priorisierte Liste. Welche Schwachstelle dort zuerst dran war, bleibt beim Kunden. Das Prinzip gilt trotzdem: Häufigkeit schlägt Sichtbarkeit.
Tilgen ohne Neubau: Designsystem und dokumentierte Zustände als Tilgungsplan
Die Frage, die jede Diskussion darüber irgendwann erreicht: neu bauen oder nicht? Meine Antwort aus der Erfahrung: in der Regel nicht. Ein Neubau ohne System und Dokumentation nimmt die Schulden mit, er tauscht nur die Technik darunter. So baut ihr sie ab, ohne die Software neu zu bauen: in zwei Teilen.
Ein Designsystem für die gewachsene Oberfläche
Ein Designsystem ist eine Component Library mit Tokens und Dokumentation in Figma, damit die zehnte Seite aussieht wie die erste. Für Bestandssoftware heißt das: Ihr ersetzt Schritt für Schritt drei Datumsfelder durch eines, drei Tabellen durch eine. Jede neue Seite entsteht dann aus dem System, nicht daneben.
Für ABUS (August Bremicker Söhne KG) haben wir ein solches System für ein historisch gewachsenes Produktumfeld aufgebaut. Es trägt heute die Produktoberflächen, und die Übergabe läuft fortlaufend im Dev Mode weiter: Die Entwicklung zieht aktuelle Werte direkt aus der Datei.
Zustände, die dokumentiert sind
Der zweite Teil ist unscheinbarer und wirkt genauso: Jeder Zustand ist dokumentiert: leer, ladend, fehlerhaft, zu lang, keine Berechtigung. Damit hört das Raten in der Entwicklung auf, und mit ihm der Doppelbau im Sprint.
Der Rahmen: Bausteine oder Sprint
Beide Teile sind einzeln buchbar; zusammen ergeben sie ein System, das euer Team ohne uns weiterbaut. Wer einen festen Rahmen braucht, nimmt den zolu sprint: 30 Tage von der Analyse zum Paket, das ready for dev ist.
Tag 30 ist Ready for Dev: alle Zustände und Edge Cases dokumentiert, Bibliothek in Figma, Session zur Übergabe. Tag 30 heißt nicht: Software fertig. Es heißt: Die Entwicklung hat alles, was sie zum Bauen braucht.
Wie ein Designsystem in gewachsene Bestandssoftware kommt, ohne dass alles neu gebaut wird, ist ein Thema für sich.
Neue Schulden verhindern: Regeln, die stehen
Ein Designsystem hilft nur, solange die nächste Funktion nicht wieder daneben entsteht. Deshalb gehört die Dokumentation für die Entwicklung zum Paket, das ready for dev ist: Spezifikation, Edge Cases, Session zur Übergabe. Die Regel für euer Team ist kurz: kein Feature ohne dokumentierte Zustände.
Bei ABUS läuft die Zusammenarbeit nach dem Designsystem weiter, als Übergabe im Dev Mode direkt mit dem Entwickler, etwa für die Benachrichtigungen und die Dokumentation der Asset Library. So bleibt das System in Bewegung.
Neue Schuldenquelle: Features mit KI ohne Bedienkonzept
Eine neue Quelle kommt gerade dazu. Ein Chatfenster ersetzt kein Interface. Wird ein Feature mit KI nur als Chat auf die Software gesetzt, sehen Nutzer nicht, woher eine Antwort kommt und wie sie sie korrigieren.
Früher war das Ergebnis vorhersehbar. Heute liefert das Modell einen Vorschlag, den jemand prüfen muss. Vertrauen, Korrektur und Kennzeichnung sind deshalb Gestaltungsaufgaben. Behandelt sie wie jeden anderen Zustand: dokumentiert, bevor gebaut wird.
Häufige Fragen
Technische Schulden stecken im Code: Abkürzungen, die später Entwicklungszeit kosten. UX-Schulden stecken in der Oberfläche und im Verhalten der Software. Die Nielsen Norman Group behandelt sie als eigene Kategorie mit eigenem Prozess, das Software Quality Journal hat sie für agile Teams charakterisiert. Ein Beispiel: Regeln für die Bedienung, die nirgends stehen, sodass Entwickler Ladezustände, Fehler und leere Listen raten. Der Code ist sauber, die Schuld liegt trotzdem vor.
Selten ist das die Voraussetzung. Wer neu baut, ohne Designsystem und dokumentierte Zustände anzulegen, verschiebt die alten Probleme nur in neue Technik. Der andere Weg führt durch die bestehende Oberfläche: bei ABUS ein Designsystem, an dem die Entwicklung direkt arbeitet, bei Troi+ verbindliche Prinzipien für die Bedienung, an denen die Entwicklung sich ausrichtet. Die Bausteine dafür bucht ihr einzeln; das Ergebnis baut euer Team ohne uns weiter.
Eine allgemeine Dauer nennen wir nicht; sie hängt vom Umfang der Software ab. Die Zeitmarke aus unserer Arbeit: Der zolu sprint führt in 30 Tagen von der Analyse zum Paket, das ready for dev ist. Ein einzelner Baustein, etwa die Analyse der Bedienung, dauert entsprechend kürzer und ist einzeln buchbar.
Die Produktverantwortung, gemeinsam mit der Entwicklung, weil dort die Zustände geraten werden, wenn niemand sie festlegt. Im zolu sprint zeigt sich das am Tag 14: Das Design Review stimmt Informationsarchitektur und Prototyp mit Fachbereich und Entwicklung ab. Wer die Liste der Schwachstellen pflegt, entscheidet über die Reihenfolge. Das ist weniger eine Frage des Titels als eine Frage, wer den Nutzern zusieht.
Eine Zahl dafür haben wir nicht. Sichtbar wird der Preis an drei Stellen: bei Nutzern, die Excel öffnen statt der Software; im Sprint, der nachbaut, was die Spezifikation nicht sagte; im Termin, der auf eine fehlende Übergabe wartet. Die Kyle David Group vertritt die These, dass sich diese Reibung 6 bis 18 Monate still aufsummiert.
Über die Autorin
Nadia Wiegand gestaltet unter der Marke zolu (Studio Wiegand, Sprockhövel) Interfaces für komplexe B2B-Software und Produkte mit KI. Sie arbeitet seit über zehn Jahren in diesem Feld.
