Designprozess im Wandel: Wie KI-Coding-Tools die Rolle von UX/UI-Design neu definieren

Ein Entwickler baut die erste lauffähige Version einer Funktion in unter einer Stunde. Sie funktioniert, sie ist navigierbar, sie lässt sich live ausprobieren. In derselben Zeit hätte ein klassischer Designprozess gerade einmal die Wireframe-Phase abgeschlossen. Wer heute in der digitalen Produktentwicklung arbeitet, kennt diese neue Geschwindigkeitsrealität. Sie verändert nicht nur das Tempo der Auslieferung, sondern die Rollenverteilung im Team und damit die Stellung von Design.

Wir bei mindtwo erleben diesen Wandel in der täglichen Projektarbeit: von der Konzeption skalierbarer Webanwendungen bis zur Modernisierung bestehender Plattformen. Wer in den kommenden Monaten anspruchsvolle digitale Produkte entwickelt, trifft auf eine Designdisziplin, die in vielen Punkten anders aussieht als noch vor zwei Jahren. Worauf es jetzt ankommt, welche Rollen sich verschieben und wie ein zeitgemäßer Design- und Entwicklungsprozess aufgesetzt sein muss, ist das Thema dieses Beitrags.

Warum der klassische Designprozess seine Selbstverständlichkeit verliert

Über Jahre galt ein bestimmtes Modell als Goldstandard: Recherche und Discovery, Divergenz mit vielen Ideen, Konvergenz auf einen Lösungsweg, sorgfältige Mockups, klickbare Prototypen, Tests, dann die Übergabe an Engineering. „Trust the process" war die Maxime, und sie hatte ihren Grund, solange das Implementieren der eigentliche Engpass war.

Dieser Engpass hat sich deutlich verschoben. Mit modernen KI-gestützten Coding-Assistenten lassen sich Ideen in vielen Fällen innerhalb von Minuten in lauffähigen Code überführen. Eine Entwicklerin baut parallel mehrere Varianten einer Funktion, probiert sie aus, verwirft sie, setzt neu auf. Alles in der Zeit, in der früher ein einziger Mockup-Zyklus stattfand. Das hat eine unmittelbare Konsequenz für Design: Wer in derselben Zeit weiterhin acht ausgearbeitete Mockups produziert, blockiert das Tempo des Teams, statt es zu führen.

Das bedeutet nicht, dass Designkompetenz an Bedeutung verliert. Im Gegenteil. Es bedeutet, dass die Verteilung der Aufmerksamkeit innerhalb der Disziplin sich verschiebt. UX- und UI-Design wird zu einer Disziplin, die enger an der Umsetzung arbeitet und gleichzeitig mehr Verantwortung für die strategische Richtung trägt.

Zwei Arten von Designarbeit, die heute zählen

In modernen Produktteams kristallisieren sich zwei klar unterscheidbare Modi heraus, in denen Design wirksam wird.

Modus 1: Execution-Support und Feinschliff in der Umsetzung

Wenn Engineering schnell Prototypen baut, ist die wertvollste Designleistung oft nicht das Erstellen eines weiteren Mockups, sondern die direkte Mitarbeit an der Implementierung. Konkret heißt das: Eine Entwicklerin baut eine erste, grobe Version einer Funktion. Sie funktioniert, sie zeigt das Konzept, aber sie ist nicht ausgearbeitet. Genau hier setzt Design heute an: Spacing, Typografie, Mikro-Interaktionen, Konsistenz mit dem Designsystem, Tonalität von Texten und Hinweisen, Reihenfolgen, Hierarchien.

Designerinnen und Designer, die diesen Feinschliff liefern können, brauchen ein anderes Werkzeug als reines Figma. Sie arbeiten zunehmend direkt im Code, in der IDE oder im Browser, und ändern dort gezielt die letzten 20 Prozent, die ein Produkt von „funktioniert" zu „fühlt sich richtig an" überführen. Das ist keine technische Spielerei, sondern eine pragmatische Antwort auf die Frage: Wo ist der Designbeitrag am wirkungsvollsten?

Modus 2: Vision und Richtung

Der zweite Modus betrifft das, was viele Teams im Tempo der Umsetzung verlieren: einen geteilten Zielzustand. Wenn beliebig viele Features in beliebig viele Richtungen entstehen können, wird Kohärenz zur knappen Ressource. Hier braucht es Designarbeit, die nach vorne denkt, aber anders als früher.

Visionen, die fünf bis zehn Jahre in die Zukunft reichen und auf 30 Folien ausformuliert werden, haben in diesem Umfeld kaum noch Berechtigung. Die Technologielandschaft verändert sich zu schnell, als dass sich ein präziser Zustand in zwei Jahren seriös beschreiben ließe. Stattdessen entstehen Richtungsbilder, die drei bis sechs Monate in die Zukunft reichen und häufig nicht als Deck, sondern als interaktiver Prototyp formuliert sind. Ihr Zweck ist nicht, eine endgültige Wahrheit zu behaupten, sondern dem Team eine gemeinsame Zielmarke zu geben, an der sich parallele Umsetzungsstränge orientieren können. Langfristige Designprinzipien (etwa zu Marke, Tonalität oder Architektur) bleiben weiterhin wichtig, sie laufen jedoch in einer separaten Ebene mit.

Wie sich die Zeitanteile in Designteams verschieben

Wer noch vor zwei Jahren in Designteams arbeitete, kannte typischerweise diese Verteilung: ungefähr 60 bis 70 Prozent der Zeit für Mockups und klickbare Prototypen, 20 Prozent für Abstimmungen mit Engineering, der Rest für Koordination. In den Teams, mit denen wir arbeiten, sieht das heute anders aus.

Mocking macht in vielen Projekten noch 30 bis 40 Prozent der Designarbeit aus, und wir kommen gleich darauf zurück, warum dieser Anteil nicht auf null fällt. Etwa der gleiche Anteil entfällt auf direktes Jamming und Pairing mit Engineering: gemeinsam Lösungen entwickeln, an Whiteboards skizzieren, gebaute Versionen kommentieren, Varianten bewerten. Ein wachsender Anteil, je nach Senioritätsgrad und Spezialisierung, entfällt auf die eigene Implementierung im Code.

Diese Verschiebung ist keine Modeerscheinung, sondern eine Antwort auf die Frage, wo Design im neuen Tempo den größten Hebel hat. Wer als Auftraggeber heute eine Webagentur sucht oder ein bestehendes Designteam weiterentwickelt, sollte diese Verteilung kennen. Sie hat unmittelbare Konsequenzen für Kompetenzprofile, Tooling und Zusammenarbeit.

Warum Figma trotzdem nicht verschwindet

Ein häufiges Missverständnis lautet: Wenn Designerinnen und Designer jetzt im Code arbeiten, brauchen sie kein Figma mehr. Das stimmt nicht. Figma bleibt aus zwei Gründen ein zentrales Werkzeug.

Erstens ist Designarbeit oft Variantenarbeit. Acht bis zehn Richtungen für dasselbe Element nebeneinander zu sehen, sie zu kuratieren, zu verwerfen, zu kombinieren: Das ist auf einer Designfläche schneller und übersichtlicher als in einer Code-Iteration mit einem KI-Assistenten, die in der Natur der Sache linear verläuft. Wer eine Variante in Code baut, investiert in diese eine Richtung. Wer in Figma denkt, kann den Raum der Möglichkeiten gleichzeitig aufspannen.

Zweitens gibt es einen Bereich, in dem Fläche und Vergleich unverzichtbar bleiben: die Mikroebene des Visuellen. Typografie-Stufen, Iconfamilien, Farbskalen, Spacing-Tokens, Komponentensysteme: Solche Detailentscheidungen profitieren von einer Canvas, auf der alle Varianten sichtbar sind. Diese Arbeit ist nicht weniger geworden, sie ist nur deutlich präziser fokussiert.

Was sich ändert, ist die Funktion von Mockups insgesamt. Sie sind nicht mehr die Hauptauslieferung an Engineering, sondern ein Denkwerkzeug, eine Skizze, ein Diskussionsangebot. Und sie konkurrieren in vielen Phasen mit dem schnellen Prototyping in echtem Code, das durch KI-Tools heute auch für nicht-technische Disziplinen erreichbar geworden ist.

Der neue Werkzeugkasten: KI-Stack im Designalltag

Der Werkzeugkasten im Designalltag ist deutlich heterogener geworden. Neben Figma und den klassischen Design-Apps treten Coding-Assistenten in der IDE, chatbasierte Modelle für Recherche, Konzeption und Texte sowie agentenfähige Werkzeuge, die im Hintergrund längere Aufgaben übernehmen.

Ein typischer Tag kann so aussehen: Morgens wird in einem chatbasierten Modell ein Konzept geschärft, Texte werden in verschiedenen Tonalitäten erprobt, bestehende Inhalte analysiert. Vormittags entstehen in Figma einige Variantenflächen für eine neue Funktion. Mittags findet ein Pairing mit einem Entwickler statt, der einen ersten Prototypen gebaut hat, und Feedback fließt direkt in den Code. Nachmittags ergänzt die Designerin selbst noch Feinschliff im Frontend. Über Slack reagiert dabei ein KI-Agent auf kleine, klar umrissene Tickets („Icon Y ist falsch ausgerichtet"), schlägt eine Korrektur vor, die ein Mensch prüft und in den Hauptbranch übernimmt.

Das ist keine Zukunftsmusik, sondern Alltag in Teams, die früh auf agentenbasierte Softwareentwicklung gesetzt haben. Entscheidend ist, dass die Werkzeuge nicht in Konkurrenz zueinander stehen, sondern sich ergänzen, je nach Aufgabe, Detailgrad und Geschwindigkeitsanforderung.

Vertrauen durch Geschwindigkeit: Ein neues Qualitätsverständnis

Ein Punkt erscheint vielen Auftraggebern zunächst paradox: Wenn alles schneller geht, muss dann nicht zwangsläufig die Qualität leiden? Die Antwort ist differenzierter. Es entsteht ein neues Qualitätsverständnis, das wir als „Vertrauen durch Geschwindigkeit" beschreiben.

In der alten Logik baute ein Team monatelang an einer Funktion, bis sie als perfekt galt, und veröffentlichte sie dann mit einem großen Launch. In der neuen Logik wird früher und expliziter veröffentlicht, oft mit einem klaren Hinweis darauf, dass eine Funktion noch jung ist und sich rasch weiterentwickelt. Der Vertrauensgewinn entsteht dann nicht über die abgeschlossene Perfektion, sondern über zwei Dinge: das frühe Sichtbarwerden von Nutzwert und die nachweisbar schnelle Reaktion auf Rückmeldungen.

Damit dieses Modell funktioniert, müssen drei Bedingungen erfüllt sein:

• Klarheit über den Status. Was ist eine reife Produktoberfläche, was ist explizit eine frühe Version? Diese Unterscheidung muss für Nutzerinnen und Nutzer erkennbar sein.
• Sichtbare Reaktion auf Feedback. Rückmeldungen werden nicht nur entgegengenommen, sondern sichtbar in Verbesserungen überführt, idealerweise innerhalb weniger Tage.
• Stete Iteration. Die Veröffentlichungstaktung muss hoch genug sein, dass Nutzer Fortschritt wahrnehmen. Eine frühe Version, an der ein halbes Jahr nichts passiert, beschädigt Vertrauen, statt es aufzubauen.

Dieses Modell setzt voraus, dass die zugrundeliegende Engineering-Maschinerie tatsächlich schnell genug ist, um Korrekturen innerhalb von Stunden statt Wochen zu liefern. Genau hier zahlt die Investition in moderne Coding-Werkzeuge doppelt ein: Sie ermöglicht das schnelle Veröffentlichen und das schnelle Nachbessern.

Welche Profile in modernen Designteams gebraucht werden

Wer Designteams heute aufbaut oder erweitert, sollte sich von einigen klassischen Suchmustern lösen.

Der starke Generalist (Block-Profil)

Lange wurde das T-Profil propagiert: eine breite Basis an Fähigkeiten und eine vertiefte Spezialisierung. Diese Form bleibt sinnvoll, sie reicht für viele Aufgaben jedoch nicht mehr aus. Wertvoll ist heute, wer in mehreren Disziplinen (UX, Visual Design, Frontend-Implementierung, Produkt- und Markenverständnis) jeweils zu den oberen 20 Prozent gehört. Das ist selten und schwer zu finden. Dort, wo es zusammenkommt, entsteht jedoch eine Beweglichkeit, die in fluiden Teams enorm wirksam ist. Solche Profile können je nach Projektphase die Rolle wechseln, ohne dass das Team eine Übergabe verliert.

Die tiefen Spezialisten

Das Gegenstück sind Profile mit einer außergewöhnlich tiefen Spezialisierung. Das kann ein Designer sein, der technisch so versiert ist, dass er nahezu auf dem Niveau eines Frontend-Entwicklers arbeitet. Diese Profile sind entscheidend, wenn Modelle, APIs und Komponentenarchitekturen direkt mitgestaltet werden müssen. Oder eine Spezialistin für visuelle Identität, die den Unterschied zwischen einem austauschbaren und einem unverwechselbaren Produkt macht. Genau dieser visuelle und ikonografische Feinschliff wird in der KI-Ära wertvoller, nicht weniger wertvoll, weil generische Standardlösungen jederzeit auf Knopfdruck verfügbar sind.

Talentierte Berufseinsteiger mit Macher-Mentalität

Das dritte Profil wird vielfach übersehen: junge Designerinnen und Designer früh in der Karriere, die zwei Eigenschaften mitbringen, nämlich ehrliche Neugier und die Gewohnheit, Dinge tatsächlich zu bauen, statt nur zu konzipieren. Sie tragen keinen Ballast aus überholten Prozessen mit sich. Sie greifen unbefangen zu neuen Werkzeugen. Sie veröffentlichen kleine Projekte, probieren absurde Ideen aus, lernen schnell. In einer Branche, deren Prozesse sich im Halbjahresrhythmus ändern, ist diese Lernoffenheit ein strategischer Vorteil und ein Profil, das gerade von kleineren, fokussierten Teams unterschätzt wird.

Wer Profile dieser Art aufbauen möchte, sollte in seiner Personalstrategie nicht ausschließlich auf Senior-Erfahrung mit klassischen Methoden setzen. Die Kombination aus erfahrenen Spezialisten, generalistisch starken Senioren und neugierigen Talenten ist robuster gegenüber den Veränderungen, die in den kommenden Monaten weitergehen werden.

Was sich für Management und Führungsrollen ändert

Auch Designleitung verändert sich. Klassische Designmanagement-Rollen, die fast ausschließlich aus People-Management und Prozessführung bestanden, werden ausgedünnt. An ihrer Stelle entsteht eine hybride Rolle: jemand, der Richtung gibt, fachlich nah am Produkt ist, gleichzeitig die Entwicklung der Mitarbeiterinnen und Mitarbeiter verantwortet und im Zweifel selbst mit anpackt.

Praktisch heißt das, dass viele erfahrene Designleitungen sich zumindest temporär wieder in die operative Arbeit zurückbegeben sollten, nicht aus Misstrauen gegenüber ihren Teams, sondern um die Veränderungen am eigenen Werkstück zu verstehen. Wer die neuen Coding-Werkzeuge nicht selbst benutzt hat und nicht selbst erlebt hat, wie ein Engineer mit Agenten arbeitet, wird Schwierigkeiten haben, Teams in dieser Realität glaubwürdig anzuführen.

Ein zweiter, oft unterschätzter Punkt: Die klassische Unterscheidung zwischen „hoch hebelnden" und „niedrig hebelnden" Aufgaben gerät in Bewegung. Wenn eine Geschäftsführerin selbst Fehlerberichte einreicht, einen Bug reproduziert oder einen Pull Request prüft, erscheint das auf den ersten Blick als Tätigkeit mit geringer Hebelwirkung. Auf den zweiten Blick wirkt sie stark, weil sie Produktnähe demonstriert, Standards prägt und Teamkultur formt. Führung wird damit weniger über Hierarchie und mehr über sichtbares Mitwirken definiert.

Psychologische Sicherheit und hohe Standards: Kein Widerspruch

Eine Beobachtung zur Teamkultur: In den produktivsten Designteams herrscht eine Mischung aus zwei Dingen, die oft als Gegensatz beschrieben werden, nämlich psychologische Sicherheit und unbedingte Ergebnisorientierung.

Psychologische Sicherheit zeigt sich in scheinbar nebensächlichen Details: Teammitglieder ziehen sich gegenseitig liebevoll auf, Führungskräfte werden für ihre Tics und Phrasen sanft parodiert, kritisches Feedback wird ohne Statusangst gegeben. Das Gegenteil, eine Atmosphäre, in der jede Äußerung als potenzielles Karriererisiko geprüft wird, verlangsamt nicht nur Entscheidungen, sondern senkt die Qualität der Ergebnisse.

Gleichzeitig liegen die Maßstäbe an die Arbeit hoch. Es wird ehrlich kritisiert, ohne dabei zu verletzen. Es wird nachgehakt, ohne zu demütigen. Beide Pole tragen einander: Wer sich sicher fühlt, kann hohe Standards aushalten. Wer hohe Standards akzeptiert hat, schöpft Vertrauen daraus, dass das Team gemeinsam ein gutes Produkt baut. Diese Kultur lässt sich nicht in einem Workshop erzeugen. Sie wächst aus dem Verhalten der Beteiligten, insbesondere derer, die führen.

Wo menschliches Urteil weiterhin entscheidet

Bei aller Geschwindigkeit, bei aller Automatisierung und bei allem Feinschliff durch KI-Werkzeuge bleibt eine Frage, die nicht automatisierbar ist: Was sollte überhaupt gebaut werden? Welche der vielen möglichen Funktionen, welche der vielen denkbaren Richtungen, welche Variante einer Lösung verdient den nächsten Sprint?

Die schwierigsten Momente in der Produktentwicklung sind nicht technischer Natur, sondern menschlich. Zwei Personen sind sich uneins, welche Funktion in eine Version gehört. Eine Stakeholder-Gruppe sieht das Produkt anders als eine andere. Daten widersprechen einander, und jemand muss entscheiden, welcher Lesart gefolgt wird. Hier sind KI-Werkzeuge wertvolle Sparringspartner, aber sie nehmen die Verantwortung nicht ab. Jemand muss am Ende sagen: „Das bauen wir, das nicht, das verschieben wir." Diese Entscheidung trägt eine Person persönlich und verantwortet sie.

Für Designteams heißt das: Geschmack, Urteilsvermögen und Strategie behalten ihren Wert. Möglicherweise gewinnen sie sogar an Wert, weil das Bauen so günstig geworden ist, dass die Frage „Was lohnt sich überhaupt zu bauen?" zur eigentlich knappen Ressource wird. Wer hier klare Antworten geben kann, ist als Designerin oder Designer wichtiger denn je.

Was das für Projekte und Auftraggeber bedeutet

Für Unternehmen, die anspruchsvolle digitale Produkte entwickeln lassen, lassen sich aus diesen Beobachtungen einige praktische Konsequenzen ableiten:

• Erwartungshaltung an Mockup-Phasen anpassen. Eine ausführliche Mockup-Phase mit dreißig fertig ausgearbeiteten Screens, bevor die erste Zeile Code geschrieben wird, ist in vielen Projekten nicht mehr das beste Vorgehen. Frühe, lauffähige Prototypen, an denen sich Entscheidungen prüfen lassen, sind oft wertvoller.
• Geschwindigkeit der Iteration zur Vertragsgrundlage machen. Nicht der einzelne Launch ist die Qualitätsgarantie, sondern die Fähigkeit eines Teams, in kurzen Zyklen sichtbar zu verbessern. Diese Fähigkeit lässt sich vorab prüfen, etwa anhand der Werkzeuge, der Architekturentscheidungen und der Teamzusammensetzung.
• Designkompetenz nicht nur in der Konzeptphase einkaufen. Wer Design nur am Anfang eines Projekts einbindet und es dann an Engineering „übergibt", verschenkt einen Großteil des Wertes. Die Mitarbeit in Implementierung und Feinschliff ist heute der Ort, an dem Design erheblich wirkt.
• Auf crossfunktionale Teamzusammensetzung achten. Strikte Disziplintrennungen (hier Design, dort Frontend, dort Backend) sind in agentenfähigen Umfeldern hinderlich. Erfolgreiche Teams haben Profile, die sich überlappen und die Werkzeuge der Nachbardisziplinen mitbeherrschen.

Wir bauen Webanwendungen und Plattformen für anspruchsvolle Anwendungsfälle, von der initialen Konzeption bis zur langfristigen Weiterentwicklung. In aktuellen Projekten zeigt sich deutlich, wie sehr das Zusammenspiel aus Design, Engineering und KI-gestützten Werkzeugen die Ergebnisqualität prägt. Wer heute eine Plattform aufsetzt oder ein bestehendes Produkt modernisiert, profitiert davon, dieses Zusammenspiel von Anfang an einzuplanen, statt später nachzusteuern, wenn das eigene Team merkt, dass die alten Prozesse nicht mehr greifen.

Ein Zwischenfazit, kein Endpunkt

Die Disziplin Design steht nicht vor ihrem Ende, sondern vor einer ihrer interessantesten Verschiebungen. Mockups behalten ihren Platz, sie verlieren jedoch ihre Alleinstellung. Designerinnen und Designer arbeiten näher am Code, ohne dabei zu Entwicklern zu werden. Die Geschwindigkeit nimmt zu, und Qualität bleibt verteidigbar, wenn sie auf andere Weise gesichert wird als früher.

Wie es weitergeht, ist offen. Die Werkzeuge der Disziplin werden sich in den kommenden Monaten weiter verändern, die Verhältnisse zwischen Mensch und Agent werden neu austariert, die Profile in den Teams werden weiter geschärft. Klar zeichnet sich jedoch ab: Die Teams, die in der nächsten Welle erfolgreich digitale Produkte bauen, sind nicht jene, die am stärksten am alten Prozess festhalten. Es sind die, die ihren Designbeitrag dort platzieren, wo er heute am meisten zählt, nämlich an der Schnittstelle zur Umsetzung, in der strategischen Richtungsfrage und in der Verteidigung des Urteilsvermögens, das auch das beste Werkzeug nicht ersetzt.

Wenn Sie für ein anstehendes Projekt oder eine Plattformmodernisierung über die richtige Aufstellung von Design und Engineering nachdenken, sprechen Sie uns gern an. Wir teilen, was wir aus der täglichen Arbeit mit modernen Designprozessen und KI-gestützten Werkzeugen gelernt haben.