Ich bin Jackie undUser Resea ist voll mein Ding.

Es gibt Studien mit Durchschnittswerten dazu, die geben aber nur eine grobe Richtung vor. Wie hoch die tatsächliche Ersparnis ausfällt, hängt stark vom einzelnen Unternehmen ab – eine feste Prozentzahl möchte ich deshalb ungern versprechen. UX-Design wirkt vor allem als Risikominimierung, die konkrete Einsparung bleibt dabei immer unternehmensspezifisch.

Ein weiterer, oft unterschätzter Effekt liegt in der Entwicklung selbst: Arbeitet sie nach einer bereits mit den Stakeholdern abgestimmten Designvorgabe, beschleunigt das die Umsetzung spürbar. Konzeptionelle Fragen sind zu diesem Zeitpunkt bereits geklärt, wodurch während der Entwicklung deutlich weniger Rückfragen und Abstimmungsrunden nötig sind.

Genau das ist der eigentliche Wert: UX-Design verhindert Fehlinvestitionen, beschleunigt die Umsetzung und macht gleichzeitig sichtbar, wo tatsächlich Potenzial liegt – das lässt sich nicht in eine einzelne Jahreszahl pressen.

Ich fange nicht mit einem Relaunch an, sondern mit der Frage, wo der größte Schmerzpunkt sitzt und wo sich das am schnellsten beheben lässt. Beides zusammen ergibt die Reihenfolge, nicht der Schmerzpunkt allein – ein Problem, das drei Sprints Vorlaufzeit braucht, bringt kurzfristig nichts, auch wenn es das größte ist.

Ist absehbar, dass die Anwendung langfristig auf ein skalierbares System umgestellt wird, verknüpfe ich Fixes mit dem Aufbau von Atomic Design: Jedes Feature oder jeder Pull Request bringt eine wiederverwendbare Komponente mit, statt eine Einzellösung. Kleine Schritte nach der 1%-Methode, die sich langfristig zu echter Skalierbarkeit summieren, ohne dass ein einzelner Schritt den laufenden Betrieb gefährdet.

Diese Strategie hat aber eine Grenze, die ich offen benenne: Irgendwann behebt man nur noch Symptome. Wenn ein UI-Element immer wieder angepasst werden muss, ist oft nicht die Komponente das Problem, sondern eine strukturelle Frage dahinter – etwa ob das Nutzerproblem, das ursprünglich gelöst wurde, überhaupt noch existiert. Diesen Punkt zu erkennen und dann für eine tiefere Ursachenanalyse zu argumentieren, statt endlos weiterzuflicken, gehört genauso zur Aufgabe wie das Flicken selbst.

Der größte Risikofaktor sind Sicherheitslücken, die unentdeckt bleiben. Wer nicht versteht, was die KI im Backend tatsächlich umsetzt, kann nicht erkennen, wo eine Schwachstelle entsteht.

Der zweite Risikofaktor ist strukturell: Wird Code größtenteils inline statt in Komponenten geschrieben, wächst das Inkonsistenz-Risiko mit jeder neuen Seite. Das schlägt sich später doppelt in Kosten nieder – einmal für die eigentliche Behebung, einmal für das Review davor. Bevor überhaupt etwas optimiert werden kann, muss der gesamte generierte Code erst gesichtet und eingeordnet werden: Was lässt sich auslagern, was überhaupt vereinfachen?

Der dritte Punkt wird oft unterschätzt: wie schnell ungenutzte Features entstehen.

Ein Feature, das kaum genutzt wird, verursacht ähnliche laufende Wartungskosten wie eines, das der Großteil der Nutzer:innen verwendet – Updates, Bugfixes, Testaufwand. Wird das nicht regelmäßig geprüft, sammeln sich über die Zeit Funktionen an, die mehr kosten als sie an Mehrwert bringen. Ungenutzte Features konsequent wieder zu entfernen hält die Anwendung schlank und spart genau diese Folgekosten.

Arbeite ich als UX-Designerin direkt im Code statt nur in Figma zu prototypen, entsteht dabei bereits ein eigenes Designsystem im Frontend – kein zusätzlicher Übersetzungsschritt von Prototyp zu Produktivcode nötig. Das macht mich spürbar schneller unterwegs als ein Team, das erst in Figma iteriert und die Umsetzung danach separat beauftragt.

Der zweite Punkt betrifft die generierte Codequalität selbst. Tools wie Figma Make oder Lovable schreiben Styling in meiner Erfahrung meist inline direkt in die Komponente, statt es in wiederverwendbare Bausteine auszulagern. Das bläht den Code auf und bringt mit wachsendem Projekt zunehmend Inkonsistenzen mit sich – jede neue Seite bekommt im Zweifel ihre eigene, leicht abweichende Variante desselben Elements.

Baseline-Programmierkenntnisse sind dabei die Voraussetzung, nicht optional: Nur wer erkennt, wann Code unübersichtlich oder schlecht strukturiert wird, kann eine KI gezielt und ressourcensparend in die richtige Richtung lenken. Dazu kommt: Ich verstehe direkt die Technik, mit der ein Entwicklungsteam tatsächlich arbeitet, egal ob React oder ein anderes Framework, statt auf den einen Stack festgelegt zu sein, den ein bestimmtes KI-Tool erzeugt.

Ja, und zwar ohne dass man dafür erst alles umbauen muss. Der Umstieg passiert schrittweise: Mit jedem neuen Feature oder Pull Request entsteht eine wiederverwendbare, atomare Komponente statt einer Einzellösung – wahlweise mehrere auf einmal oder eine nach der anderen, je nach Kapazität. Nach der 1%-Methode wächst das System mit jedem Release ein Stück weiter, ohne dass ein einzelner Schritt den laufenden Betrieb gefährdet.

Der Unterschied zur Budget-Frage oben: Dort ging es darum, WAS zuerst behoben wird, wenn das Budget knapp ist. Hier geht es um reine Machbarkeit – die Antwort ist unabhängig vom Budget dieselbe, weil sich Atomic Design in praktisch jedes bestehende Projekt einbauen lässt, sobald ohnehin neue Features entstehen.

Mehrere, die sich gegenseitig verstärken. Entwickler:innen arbeiten in einem konsistenten System spürbar motivierter, was sich direkt auf die Geschwindigkeit neuer Features auswirkt. Änderungen an einer Komponente ziehen sich automatisch durch die ganze Anwendung, statt an jeder Stelle einzeln nachgezogen werden zu müssen.

Der Effekt verstärkt sich noch mit KI-Unterstützung wie Claude: Kennt die KI das Regelwerk eines atomaren Designsystems, hält sie sich beim Generieren neuer Komponenten daran, Ergebnisse bleiben konsistent statt bei jedem Prompt neu erfunden. Ohne dieses Regelwerk arbeitet die KI zwar trotzdem, aber unstrukturierter, und braucht entsprechend mehr manuelle Nacharbeit.

Eine Einschränkung gehört aber dazu: KI-Unterstützung ersetzt kein Review. Ohne klare Anweisungen und regelmäßige Prüfung dessen, was die KI tatsächlich umsetzt, kippt das System schnell ins Chaos statt sauber zu bleiben – das habe ich selbst schon erlebt.