Designschulden (UX Debt): was sie sind und wie man sie abbaut

Was sind Designschulden?

Anna Kaley von NN/g definiert UX-Schulden so: andauernde Probleme in der Erfahrung, die bleiben, wenn eine schnelle, einfache oder nachlässige Lösung live geht. Diese Schuld kann bewusst entstehen oder aus Versehen. Ich finde, in beiden Fällen zahlt zuerst der Nutzer.

„Designschulden“ und „UX-Schulden“ meinen dasselbe. In englischen Quellen stehen „design debt“ und „UX debt“. Ich nutze auf dieser Seite alle Begriffe gleichbedeutend.

Kaley betont, dass die Schuld wie Zinsen wirkt. Probleme, die niemand angeht, addieren sich, und das Aufräumen wird immer größer.

Ähnlich wie technische Schulden, und doch anders

Die Metapher stammt von den technischen Schulden. Laut Kaley hat Ward Cunningham den Begriff technische Schulden 1992 geprägt. Das Team bringt statt des besten Ansatzes eine schnellere oder einfachere technische Lösung live und zahlt später dafür.

Die Ähnlichkeit ist klar. In beiden Fällen nehmen Sie heute eine Abkürzung und zahlen morgen die Zinsen. Laut Kaley ist es immer teurer, nach dem Launch zu korrigieren, als gleich die richtige Lösung zu veröffentlichen.

Der eigentliche Unterschied ist für mich, wer die Zinsen zuerst spürt. Technische Schulden spürt zuerst das Team, weil jede Änderung etwas schwerer wird. Designschulden spürt zuerst der Nutzer, und oft verlässt er das Produkt, ohne etwas zu sagen.

Beide kommen oft zusammen. Lässt sich ein alter Screen nicht ins neue Designsystem bringen, liegt es meist am alten Code. Auch Kaley empfiehlt, beide Schulden gemeinsam anzugehen und keine zu ignorieren.

Schulden sind nicht immer schlecht. Laut Kaley bedeutet die Metapher nicht, dass man Schulden um jeden Preis vermeiden muss. Entscheidungen, die bewusst Schulden erzeugen, sollten sorgfältig und im Team fallen. Ich ergänze einen Schritt: Schreiben Sie die aufgenommene Schuld irgendwo auf.

Wie Designschulden entstehen

Kaley schreibt, dass Schulden oft unter engen Zeitplänen oder unpraktischen Projektvorgaben entstehen. Sie nennt diese Gründe:

• Nutzertests überspringen.
• Markenstandards und Styleguides ignorieren.
• Design durch ein Komitee, bei dem jede Interessengruppe ein Stück hinzufügt.
• Die Produktvision falsch verstehen.
• Ein anderes Produkt kaufen oder mit ihm fusionieren.
• Schwache Kommunikation oder fehlende Dokumentation.
• Unzureichende Qualitätssicherung.
• Alter Code oder aufgeschobenes Refactoring.

In Audits begegnen mir die Folgen dieser Gründe am häufigsten in diesen Formen.

Inkonsistente Komponenten

Zwei Buttons für dieselbe Aufgabe oder zwei verschiedene Datumsauswahlen. Jede entstand in einem anderen Sprint, in der Eile des Tages. Der Nutzer lernt auf jedem Screen neu, was klickbar ist.

Flicken

Ein Aktionsbanner oder eine „Neu“-Plakette kommt als vorübergehend dazu und bleibt dann. Je mehr Flicken übereinanderliegen, desto mehr verschwindet die eigentliche Aufgabe des Screens im Hintergrund.

Alte Abläufe

Der neue Registrierungsablauf ist gestaltet, aber der alte ist noch live. Die Screens eines zugekauften Produkts nutzen nicht das Menü des Hauptprodukts. Der Nutzer hat das Gefühl, zwischen zwei Produkten hin und her zu wechseln.

KI kann diese Anhäufung beschleunigen. Laut einem Text von Kaley und Raluca Budiu aus dem Jahr 2026 ist Produzieren billiger geworden als UX-Evaluation. Bleibt die Evaluation hinter der Umsetzung zurück, häufen sich Schulden an.

Warum später zahlen teurer ist

Eine Geldsumme nenne ich hier nicht. In den Quellen, die ich geöffnet habe, fand ich keine verallgemeinerbare Kostenzahl. Kaley nennt dagegen diese Gründe:

• Mit einem schwachen Design zu starten, wirkt sich langfristig auf den Marktanteil aus.
• Nutzer gewöhnen sich an schlechtes Design und wehren sich dann gegen Änderungen.
• Wiederholte Änderungen zermürben das Gefühl von Konsistenz.
• Ihre Fehler bleiben im Internet. Blogs, Foren und Videokanäle beschreiben die alte Version noch jahrelang.

Der zweite Punkt wird meiner Meinung nach am häufigsten übersehen. Bleibt ein schlechter Ablauf ein Jahr live, ist seine Korrektur eine „Änderung“. Dann müssen Sie auch die Nutzer überzeugen, die sich an den Ablauf gewöhnt haben.

Wie man Designschulden misst

Der erste Schritt beim Messen ist, die Schulden sichtbar zu machen. Kaley empfiehlt, zuerst auf riskante Bereiche zu schauen: Oberfläche, Interaktion, Text und Inhalt, Informationsarchitektur und Barrierefreiheit. Auch die Konsistenz der Customer Journey und der Wechsel zwischen Kanälen stehen auf der Liste.

An den Anfang der Methoden stellt sie den Nutzertest. Sie empfiehlt, vor jedem Sprint-Release und mindestens einmal im Monat zu testen. Dazu kommen Umfragen auf der Seite, CSAT- oder NPS-Werte und Berichte aus dem Kundenservice. In regelmäßigen Teamrunden mit der Entwicklung kann jede Person Einträge vorschlagen.

Ich ergänze ein UX Audit oder eine heuristische Evaluation. Wer von außen schaut, sieht Inkonsistenzen, an die sich das Team gewöhnt hat, leichter. Für Stellen, an denen Nutzer klicken und nichts passiert, sind Daten zu Rage Clicks und Dead Clicks ein guter Hinweis.

Halten Sie eine Ausnahme getrennt. Laut Kaley sind die Varianten eines A/B-Tests vorübergehend und bewusst, deshalb zählen sie nicht als Schulden. Die siegreiche Variante sollte aber ins Designsystem übernommen werden.

Wo man das Verzeichnis führt

Kaley beschreibt zwei Wege. Sie können jede Schuld direkt ins Backlog schreiben, als eigenen Eintrag oder mit einem Label. Beim anderen Weg führen Sie zuerst eine Tabelle und übertragen ausgewählte Einträge später ins Backlog.

In großen Organisationen können Einträge im Backlog verloren gehen oder immer wieder nach hinten rutschen. Deshalb hilft die Tabelle.

Kaley empfiehlt als Spalten eine Beschreibung aus Sicht des Nutzers, die Stelle in der Erfahrung und die Häufigkeit. Dazu kommen, wer es gemeldet hat, und der Aufwand der Behebung (gering, mittel, hoch).

Wie man Designschulden priorisiert

Kaley empfiehlt, jeden Eintrag auf zwei Achsen einzuordnen: Wert für den Nutzer und Aufwand der Behebung. Außerdem schauen Sie, wie schwer das Problem wiegt, wie oft es auftritt und wo im Ablauf es liegt. Ein Problem im Bezahlschritt kommt vor einem Problem ganz unten in den Einstellungen.

Kaley hat noch eine Empfehlung: UX-Probleme in bestehenden Funktionen sollten oft höhere Priorität bekommen als neue Funktionen. Für mich ist das der Satz, den Produktteams am schwersten akzeptieren.

In der Arbeit mit Teams reduziere ich jede Achse auf zwei Stufen. Ist die Wirkung gering oder hoch, ist der Aufwand gering oder hoch? So entstehen vier Listen. Probieren Sie es im Verzeichnis unten selbst aus.

Schuldenverzeichnis

Die Liste zeigt die Ausgangsverteilung der Beispieleinträge. Mit JavaScript können Sie jeden Eintrag selbst einordnen.

Einträge der Schuld

• S1 Im Bezahlschritt erscheint die Fehlermeldung nicht neben dem Feld, sondern ganz oben auf der Seite.

  Wirkung hoch, Aufwand gering. Liste: Sofort

• S2 Warenkorb, Kasse und Profil haben drei verschiedene Stile für den primären Button.

  Wirkung gering, Aufwand gering. Liste: Bei Gelegenheit

• S3 Der alte Registrierungsablauf ist noch live. Der neue ist gestaltet, aber nicht programmiert.

  Wirkung hoch, Aufwand hoch. Liste: Planen

• S4 Für die Datumsauswahl gibt es zwei Komponenten: einen Kalender und Auswahllisten.

  Wirkung gering, Aufwand hoch. Liste: Liegen lassen

• S5 Das für eine Aktion eingefügte Banner lässt sich nicht schließen und liegt über dem Menü.

  Wirkung hoch, Aufwand gering. Liste: Sofort

• S6 Die Seite mit Suchergebnissen nutzt die alte Schrift und die alten Abstände.

  Wirkung gering, Aufwand gering. Liste: Bei Gelegenheit

• S7 Die Retourenscreens aus einem zugekauften Produkt nutzen eine andere Menüstruktur.

  Wirkung hoch, Aufwand hoch. Liste: Planen

• S8 Den alten Berichts-Screen im Admin-Bereich öffnen wenige. Ihn neu zu schreiben, ist viel Arbeit.

  Wirkung gering, Aufwand hoch. Liste: Liegen lassen

Ihr Plan

1. 1

   Sofort (2)

   Hohe Wirkung, günstig zu beheben. Nehmen Sie es in diesen Sprint.

   • S1 Im Bezahlschritt erscheint die Fehlermeldung nicht neben dem Feld, sondern ganz oben auf der Seite.
   • S5 Das für eine Aktion eingefügte Banner lässt sich nicht schließen und liegt über dem Menü.
2. 2

   Planen (2)

   Hohe Wirkung, aber viel Arbeit. Schreiben Sie es mit Datum in die Roadmap.

   • S3 Der alte Registrierungsablauf ist noch live. Der neue ist gestaltet, aber nicht programmiert.
   • S7 Die Retourenscreens aus einem zugekauften Produkt nutzen eine andere Menüstruktur.
3. 3

   Bei Gelegenheit (2)

   Beheben Sie es, wenn Sie den Screen ohnehin anfassen.

   • S2 Warenkorb, Kasse und Profil haben drei verschiedene Stile für den primären Button.
   • S6 Die Seite mit Suchergebnissen nutzt die alte Schrift und die alten Abstände.
4. 4

   Liegen lassen (2)

   Vorerst liegen lassen, aber im Verzeichnis behalten. Alle drei Monate erneut prüfen.

   • S4 Für die Datumsauswahl gibt es zwei Komponenten: einen Kalender und Auswahllisten.
   • S8 Den alten Berichts-Screen im Admin-Bereich öffnen wenige. Ihn neu zu schreiben, ist viel Arbeit.

Sofort: 2 · Planen: 2 · Bei Gelegenheit: 2 · Liegen lassen: 2

Die acht Einträge sind Beispiele aus einer erfundenen E-Commerce-App. Ihre Auswahl wird nirgendwohin gesendet und nicht gespeichert.

Verzeichnis der Schulden: Jeder Eintrag wandert nach Wirkung und Aufwand der Behebung in eine von vier Listen. Hohe Wirkung bei günstiger Behebung steht ganz vorn.

Die vier Listen sind ein Anfang. Die Liste „Liegen lassen“ wird nicht gelöscht, sie bleibt im Verzeichnis. Wird ein Screen neu gestaltet, wandern ihre Einträge oft in die Liste „Bei Gelegenheit“.

Abbauplan: Anteil im Sprint und Designsystem

Schulden werden nicht auf einmal bezahlt. Kaley beschreibt drei Wege.

• Ein Anteil in jedem Sprint. Reservieren Sie in jedem oder jedem zweiten Sprint Story Points für Schulden. Ziel ist, mindestens ein oder zwei Einträge zu schließen.
• Alle drei Monate ein Aufräum-Sprint. Technische und UX-Schulden werden zusammen angegangen.
• Ein Aufräumtag. Können Sie keinen ganzen Sprint freimachen, widmet das Team einen Tag nur den Schulden. Kaley nennt das „cheese day“.

Kaley empfiehlt, den Fortschritt gegenüber Stakeholdern über Nutzerwert und Geschäftswert zu erzählen. Sagen Sie statt „Wir haben fünf Einträge geschlossen“ lieber „Die Fehlermeldung im Bezahlschritt steht jetzt neben dem Feld“.

Mit dem Designsystem abbauen

Der dauerhafteste Abbau von Schulden durch inkonsistente Komponenten ist ein Designsystem. Therese Fessenden von NN/g definiert ein Designsystem als vollständigen Satz von Standards aus wiederverwendbaren Komponenten und Mustern, um Design im großen Maßstab zu steuern. Laut Fessenden senkt die Wiederverwendung standardisierter Elemente das Risiko ungewollter Inkonsistenz.

In der Praxis läuft es so. Statt drei verschiedener Buttons definieren Sie einen einzigen in der Komponentenbibliothek. Entscheidungen zu Farbe und Abstand stehen als Design Tokens an einer Stelle. Dann ziehen Sie die Screens einzeln um, jeweils in dem Sprint, in dem Sie den Screen ohnehin anfassen.

Kaley und Budiu zeigen dieselbe Richtung für Teams, die mit KI produzieren. Geben Sie dem Werkzeug Ihr Designsystem und freigegebene Interaktionsmuster mit. So startet neuer Output von einer solideren Grundlage.

Meine Notiz

Der häufigste Fehler bei Designschulden ist, sie gar nicht aufzuschreiben. Das Team kennt das Problem, spricht in Slack darüber, aber niemand bringt es in eine Zeile. Was nicht aufgeschrieben ist, lässt sich nicht planen.

Deshalb empfehle ich als ersten Schritt ein einstündiges Treffen für das Verzeichnis. Alle schreiben die Einträge auf, die sie kennen, dann ordnen Sie sie mit den zwei Fragen oben. Stehen Einträge in der Liste „Sofort“, nehmen Sie sie in diesen Sprint.

In einem kleinen Team braucht es keinen Aufräum-Sprint. Schon ein oder zwei geschlossene Einträge pro Sprint bremsen das Wachstum der Schulden.