Das kennst du bestimmt: Ein Projektbeteiligter (Kunde?) kommt nicht mit einer Anforderung, sondern mit einem fertigen Designvorschlag auf dich zu. In Claude Design oder einem ähnlichen Tool erstellt. Vor zwei Jahren wäre das undenkbar gewesen, heute ist es Alltag. Es verändert die Arbeit von UX-Professionals und UX-Verantwortlichen von Grund auf.
Ich beschäftige mich seit Monaten intensiv mit diesen Werkzeugen. Unter anderem, indem ich jeden Artikel lese, der mir unter die Finger kommt. Aber hauptsächlich, indem ich damit arbeite. Ich erstelle Prototypen, nutze Figma-Plugins, baue Design-zu-Code-Strecken und entwickle die Tools, die ich für die Arbeit benötige, selbst. Was ich dabei gelernt habe, deckt sich nur teilweise mit dem, was man in Artikeln liest und auf YouTube sieht.
Kurz gesagt: Es funktioniert. Besser als die meisten Skeptiker glauben. Aber die Stelle, an der es schwierig wird, ist nicht die, die alle erwarten.
Was tatsächlich gut funktioniert
Fangen wir mit dem an, was überrascht – im positiven Sinne.
Das Prototyping mit Claude Code hat meine Vorstellung davon verändert, wie schnell man von einer Idee zu einem greifbaren Ergebnis kommt (das lässt mich auch den Double Diamond hinterfragen … aber das ist ein anderes Thema). Es entsteht nicht nur ein Klickdummy, der so tut als ob, sondern funktionierender Code, an dem sich eine Annahme tatsächlich prüfen und Interaktion wirklich erleben lässt. Das ist ein Unterschied. Ein Wireframe diskutiert man. Einen laufenden Prototyp benutzt man – und merkt schnell, ob die Idee trägt. Und die Strecke vom Designsystem ins Frontend, also der Übergang, an dem in Projekten traditionell die meiste Reibung und Übersetzungsarbeit entsteht, lässt sich mit KI deutlich enger führen als früher.
All das ist keine Zukunftsvision mehr. Das geht heute. Die Erfahrung zeigt: Die Produktivitätsgewinne sind real und größer als bei einer einzelnen Tool-Demo angenommen.
An dieser Stelle endet normalerweise der Artikel… aber hier fängt der interessante Teil erst an 🙂
Der Bruch kommt nicht bei der Technik
Alles, was ich oben beschrieben habe, funktioniert für mich. Allein, an meinem Rechner, in meinem Prozess. Genau das ist der Haken.
Die meisten beeindruckenden KI-Demos sind Soloshows. Eine Person, ein Tool, ein in sich geschlossener Ablauf. Unter diesen Bedingungen ist der Gewinn enorm und leicht zu zeigen. Was selten jemand zeigt, ist, was passiert, wenn aus der einen Person ein Team wird – damit meine ich nicht nur das UX-Team. Und auch auf Kundenseite beschränkt sich nicht auf eine Person. Denn dann verschiebt sich das Problem. Es geht nicht mehr um die Frage „Kann KI gute Designs erzeugen?” – die Antwort darauf ist längst ja – sondern: Die Frage wird zu: „Wie arbeiten fünf Menschen mit diesen Werkzeugen so zusammen, dass am Ende nicht fünf Inseln entstehen, sondern ein konsistentes Ergebnis?”
Das ist keine technische Frage mehr. Es geht um Prozesse, Rollen und Standards. Und sie ist alles andere als trivial.
Was im Team plötzlich Arbeit macht
Sobald mehr als eine Person mit KI im selben Projekt arbeitet, tauchen Fragen auf, die in der Solo-Variante schlicht nicht relevant sind.
- Wann ist etwas fertig?
Wenn jeder innerhalb von Minuten drei Designvarianten erzeugen kann, ist die alte Definition von „fertig” wertlos. Die Menge war nie das Problem. Die Frage, welche Variante warum die richtige ist, wird durch KI nicht beantwortet – sie wird vielmehr dringlicher. - Wer entscheidet über Qualität?
Ein KI-generierter Entwurf sieht auf den ersten Blick oft gut aus (je nach Input nicht einmal das …). Ob er tragfähig ist, ob er zum echten Nutzungskontext passt und ob er das eigentliche Kundenproblem trifft, sieht man ihm nicht an. Im Team braucht es jemanden, der das beurteilen kann und darf. Diese Bewertungskompetenz wird nicht weniger, sondern mehr wichtig. - Wie übergibt man sauber?
Wenn ein Plug-in oder ein Prototyp im Alleingang entstanden ist, weiß nur eine Person, wie er gedacht ist. Im Team muss dies nachvollziehbar, dokumentiert und anschlussfähig sein. Andernfalls hat man die Übersetzungsarbeit, die KI an einer Stelle einspart, an anderer Stelle wieder hereingeholt.
Und dann ist da noch das veränderte Verhalten aller anderen. Der eingangs erwähnte Projektbeteiligte mit dem fertigen Designvorschlag ist genau das: ein Symptom dieses Bruchs. Stakeholder kommen nicht mehr mit Wünschen, sondern mit Lösungen. Kunden erwarten Ergebnisse schneller, weil sie gesehen haben, was „über Nacht“ möglich ist – und unterscheiden dabei oft nicht zwischen „sieht fertig aus“ und „ist fertig/richtig“ oder „passt in unser System“.
Wer hier nur die Technik im Griff hat, aber nicht die Zusammenarbeit, bekommt ein neues Problem: viel mehr Material, viel schneller, bei gleichbleibend offener Frage, was davon eigentlich stimmt.
Die Steuerungsfrage hat sich geändert
Ich war über 25 Jahre lang in zwei Agenturen sowohl Agenturinhaber als auch UX-Lead. Ich kenne die Steuerungsfragen von beiden Seiten. Und gerade verschieben sie sich erheblich.
Früher bedeutete Steuern im UX-Bereich vor allem, Kapazitäten zu planen, die Qualität zu sichern und Prozesse zu standardisieren. Die Engstelle war meistens die Zeit. Gute Arbeit dauerte lange, und die knappe Zeit der knappen Fachleute wurde nicht immer optimal verteilt, sondern oftmals danach, wer gerade noch Zeit hatte.
KI verschiebt diese Engstelle. Das Erzeugen wird günstiger und schneller. Was teuer bleibt und teurer wird, ist das Urteil: Welche der vielen schnell erzeugten Optionen ist die richtige und warum? Wer das im Team nicht organisiert, automatisiert nicht seinen Prozess, sondern seine Beliebigkeit.
Für jemanden, der ein Team oder eine Agentur leitet, bedeutet das konkret, dass sich die Investition verlagert. Sie investiert weniger in reine Ausführungskapazität und mehr in die Fähigkeit, aus einer Flut von Vorschlägen das Tragfähige zu erkennen und den Prozess so aufzustellen, dass dies verlässlich passiert. Das ist Operationsarbeit, keine Toolarbeit. Und sie lässt sich nicht einfach durch den Abschluss eines Abos erledigen.
Warum Lesen nicht reicht
Hier komme ich zu dem Punkt, der für mich am wichtigsten ist.
Nichts von dem, was ich oben beschrieben habe, hätte ich durch Lesen verstanden. Ich habe die Artikel auch gelesen. Ich war auf den Konferenzen. Ich habe mir die YouTube-Videos angesehen. All das gibt dir eine Landkarte. Aber sie gibt dir nicht das Gelände.
Den Unterschied zwischen „Claude Design erzeugt schöne Screens” und „mein Team produziert mit Claude Design konsistente Ergebnisse” merkst du erst, wenn du es selbst ausprobierst. Die Reibung, von der ich spreche, taucht in keiner Demo auf, weil Demos Soloshows sind. Sie taucht auf, sobald du selbst baust, mit echten Leuten in einem echten Projekt – und dann scheiterst du genau an den Stellen, die vorher unsichtbar waren.
Deshalb ist mein Rat an jeden, der UX-Arbeit verantwortet, unspektakulär: Mach es einfach. Baue einen Prototyp, verwende Vibecodeing, erstelle ein kleines Plugin, das dir wirklich etwas abnimmt, und setze es in Projekten ein. Du wirst in einer Woche des Herumprobierens mehr lernen als in einem Quartal des Lesens.
Es geht nicht um Talent oder um Zeit, die man nicht hat. Es ist eine Frage der Haltung: Werkzeuge versteht man nicht, indem man über sie spricht. Man versteht sie, indem man mit ihnen arbeitet.
Ein Austausch auf Augenhöhe
Auf diese Fragen habe ich keine fertigen Antworten. Ich habe jedoch Erfahrungen und eine ziemlich klare Vorstellung davon, wo die schwierigen Stellen liegen. Aber das Team-Problem, das Standard-Problem und die neue Steuerungsfrage: Daran arbeite ich selbst noch.
Wenn du in einer UX-Abteilung oder Agentur arbeitest und dir dieselben Fragen begegnen, zum Beispiel: Wie verändert sich euer Prozess gerade, was funktioniert bei euch, woran hakt es, dann tausche ich mich gern darüber aus. Als Gespräch unter Leuten, die dasselbe gerade praktisch durchdenken. Genau dort, im Konkreten, wird es ohnehin interessant.
