Kampf gegen Windmühlen: Warum UX kein KI-Prompting ist

Key Takeaways

• KI-Tools können in Minuten klickbare Prototypen erzeugen, aber nicht automatisch gute Produkte.
• Viele KI-generierte Entwürfe wirken professionell, bleiben aber generisch und austauschbar.
• Funktionierender Code ist nicht automatisch sicher, wartbar oder sinnvoll strukturiert.
• Der erste KI-Prototyp kann Erwartungen prägen, bevor Research oder Validierung stattgefunden haben.
• UX bleibt Facharbeit: KI kann unterstützen, ersetzt aber nicht Verständnis, Verantwortung und Erfahrung.

Wenn aus ein paar Sätzen ein Prototyp wird

Lovable. Bolt. v0 – diese Tools versprechen alle dasselbe: Aus ein paar Sätzen wird in Minuten ein klickbarer Prototyp. Und das stimmt sogar. Wer noch nie erlebt hat, wie ein Kunde mit leuchtenden Augen auf einen KI-generierten Entwurf zeigt und sagt „genau so wollen wir das haben“, der hat einfach noch nicht lange genug in dieser Branche gearbeitet, oder er hat bisher Glück gehabt – beides kommt vor.

Das Ergebnis sieht auf jeden Fall aus wie ein Produkt: Es hat Farben, es hat Buttons, man kann draufklicken und irgendwas passiert. Es ist, kurz gesagt, beeindruckend genug, um in einem Meeting nicht kritisch hinterfragt zu werden. Was es aber ist, wenn man genauer hinschaut: der statistische Durchschnitt von allem, was das KI-Modell je an Webdesign gesehen hat.

Forscher der University of Washington haben das ziemlich nüchtern beschrieben. LLMs werden auf einem Web trainiert, das von denselben Frameworks, denselben Komponentenbibliotheken und denselben Layoutkonventionen dominiert wird. Das Ergebnis ist schlicht vorhersehbar: generische Layouts, Standard-Komponenten, ein sauberer, aber völlig austauschbarer Look. Unter Zeitdruck – und wann ist man heute mal nicht unter Zeitdruck – nimmt man dann einfach diesen Output. Ungeachtet dessen, dass die eigene Markenidentität dabei geopfert wird, ersetzt durch das, was das Modell „halt so macht“.

Wenn es funktioniert, heißt das noch nicht, dass es gut ist

Und dann ist da noch das, was man nicht sieht, weil es unter der Oberfläche sitzt. KI-generierter Code läuft. Er sieht korrekt aus. Er besteht oberflächliche Tests. Das ist erst einmal kein Argument gegen KI-Code, sondern ein Argument dafür, wer ihn reviewt. Denn genau da liegt das eigentliche Problem: nicht im Tool, sondern in der Annahme, dass kein Fachwissen mehr nötig ist, um es zu benutzen.

KI-Code, der von erfahrenen Entwicklern geprüft, verstanden und verantwortet wird, hat durchaus seinen Platz. KI-Code, der von jemandem in Produktion gebracht wird, der nicht weiß, wonach er schauen müsste, ist eine Einladung. Was funktioniert, wird nicht mehr angefasst. Bis es jemand anfasst, der es nicht gut mit dir und deiner Organisation meint.

Ähnlich sieht es im Designprozess aus. Wer versucht, einen KI-generierten Prototyp in ein bearbeitbares Figma-Dokument zu überführen, landet schnell in einem Zustand, der sich anfühlt wie der Keller einer Person, die nie etwas wegwirft: unnötig verschachtelte Ebenen, generische Bezeichnungen, keinerlei Komponenten-Logik, kein erkennbares Designsystem, keine Konsistenz. Für einen UX-Designer, der in Figma ein konsistentes Produkt weiterentwickeln will, ist das kein echter Ausgangspunkt, sondern eine Menge Mehrarbeit fürs Aufräumen.

Der erste Prototyp wird zum Anker

Die Sicherheitslücken, das generische Aussehen und die Inkonsistenzen sind aber noch nicht das eigentliche Problem. Das wirkliche Problem passiert früher, nämlich in dem Moment, in dem der Kunde den Prototyp zum ersten Mal sieht. Ab diesem Zeitpunkt wird alles schwieriger, und zwar nicht nur ein bisschen.

Die Kognitionspsychologie nennt das den Anchoring-Effekt. Was man zuerst sieht, wird zum Referenzrahmen für alles danach. Eine Idee, die früh auftaucht, noch ohne User Research, noch ohne irgendeine Validierung, gewinnt Momentum allein dadurch, dass sie zuerst da war. Auf KI-Prototypen angewendet heißt das: Der Kunde hat etwas Klickbares gesehen. Er hat es angefasst. Er hat es wahrscheinlich schon drei Leuten weitergeleitet und jetzt kommt der UX-Designer und sagt, man sollte das eigentlich nochmal grundlegend überdenken, nur als „Basis“ verwenden.

Das ist dann kein Designgespräch mehr, das ist Therapie. Für einen Anker, den man selbst nicht gesetzt hat, und der trotzdem jetzt das gesamte Projekt definiert. Man beißt sich am ersten plausiblen Output fest, und das divergente Denken, das für gute Entscheidungen notwendig wäre, findet schlicht nicht mehr statt. Man kann es schwer jemandem erklären, der gerade sehr stolz auf seinen Zwei-Stunden-Prototypen ist.

Schnell sichtbar ist nicht nachhaltig gut

Das Versprechen lautet: schneller. Für Projektmanager und Gründer stimmt das kurzfristig sogar, und kurzfristig ist bekanntermaßen der Lieblingszeitraum von Projektmanagern und Gründern. Etwas ist da, etwas ist sichtbar, irgendjemand kann auf irgendetwas zeigen. Was sich nicht so gut zeigen lässt: der Aufwand, der danach entsteht.

Die Inkonsistenzen, das Priming, das man erst mühsam aufbrechen muss, die technische Schuld, die irgendwann so groß ist, dass niemand mehr weiß, was das Ding eigentlich tut. UX-Designer verbringen am Ende mehr Zeit damit, Fehler auszubügeln und Kunden umzustimmen, als wenn sie von Anfang an Teil des Prozesses gewesen wären. Die Effizienzgewinne landen irgendwo, nur nicht dort, wo man sie haben wollte.

UX ist mehr als Prompting

Die KI-Modelle werden immer besser darin, Kompetenz zu simulieren. Das ist das eigentliche Problem. Nicht, weil sie gut sind, sondern weil sie gut genug aussehen, um die unbequeme Folgefrage zu unterdrücken.

Kann man was dagegen tun? Ja, tatsächlich. Es braucht Designer, die früh unbequeme Wahrheiten aussprechen, Kunden davon überzeugen, dass ein Zwei-Stunden-Prototyp und ein durchdachtes Produkt zwei verschiedene Dinge sind, und trotzdem irgendwie alle bei Laune halten. Die wissen, wann ein KI-Tool sinnvoll eingesetzt den Prozess beschleunigt, und wann es mehr Schaden anrichtet, als es spart.

Genau das ist die Arbeit, die wir machen. Mit KI, wo es Sinn ergibt, ohne, wo es keinen macht, und immer mit dem Anspruch, UX und UI so zu entwickeln, wie es das jeweilige Projekt verdient – nicht wie es sich am schnellsten prompten lässt. Es gibt einen Unterschied zwischen einem Tool, das einem Fachmann Zeit spart, und einem Tool, das einen Fachmann ersetzt. Den ersten Fall begrüßen wir. Den zweiten erleben wir täglich in den Projekten, die danach zu uns kommen.