- AI-Tools erzeugen UI direkt auf Basis von Designsystemen, wodurch sich die Rolle von Designerinnen und Designern von reiner visueller Gestaltung hin zu Strategie und Koordination verschiebt
- Die zentrale Frage ist nicht mehr „Wer nimmt wessen Arbeit weg?“, sondern wie sich der Prozess verändert
- Unsichtbare Arbeit wie Code, PRDs oder Zusammenfassungen lässt sich leicht automatisieren, doch bei sichtbarer Arbeit wie UI und Flows, die Nutzer direkt sehen und anfassen, sind Qualitätsunterschiede groß, weshalb die Design-Automatisierung beim Tempo dem Engineering noch nicht folgt
- Der größte Engpass war die Übersetzung von Figma-Mockups in Code, doch wenn Designer direkt in einer Code-Umgebung gestalten, lässt sich diese Verschwendung beim Handover vollständig beseitigen
- Der zentrale Wert von Designerinnen und Designern im AI-Zeitalter liegt nicht mehr in Pixelarbeit, sondern in der Fähigkeit zur Orchestrierung: zu entscheiden, was gebaut werden soll, AI-Outputs kritisch zu bewerten und die Arbeit zu steuern
- Unternehmen, die in kleine, handlungsfähige Teams und maschinenlesbare Designsysteme investieren, werden große Feature-Factory-Organisationen übertreffen
Der Hintergrund des Wandels im Produktdesign
- Seit der Autor 1999 seine erste Website mit Dreamweaver erstellt hat, arbeitete er mit einem Prozess, bei dem Designs in Photoshop, Sketch oder Figma erstellt und dann an Entwickler weitergegeben wurden
- Kürzlich verband er Claude Code mit dem hauseigenen Designsystem und erzeugte mit nur drei Prompts eine tatsächlich funktionierende UI, wobei der bisherige Schritt der visuellen Gestaltung übersprungen wurde
- Diese Erfahrung zeigte, dass sich der Wert von Designern von Ausführungskompetenz hin zu ‚Geschmack und strategischem Urteilsvermögen‘ verlagert
- Während AI auf Basis von Designsystemen einen Ablauf von „Prompt → Generierung → Deployment“ umsetzt, befindet sich das Produktdesign in einem grundlegenden Wandel
Die falsche Debatte: Veränderung des Prozesses statt der Anzahl von Stellen
- Die aktuelle Diskussion über AI und Produktrollen bleibt bei Revierkämpfen rund um Stellenzahlen stehen, etwa bei Fragen wie „Werden Designer ihre Jobs verlieren?“ oder „Werden Engineers ersetzt?“
- Die eigentliche Frage betrifft den Prozess: AI beseitigt diese Funktionen nicht, sondern verschiebt, wer sie ausführt, wie schnell sie erledigt werden und wo die Engpässe entstehen
- Unsichtbare Arbeit wie Coding, das Schreiben von PRDs oder Datenanalyse lässt sich leicht automatisieren, weil sich Qualitätsunterschiede hinter der UI verbergen
- Selbst wenn Code unordentlich ist, kümmert es niemanden, solange die App funktioniert, und auch ein von AI erzeugtes PRD ist in Ordnung, wenn die Problemdefinition stimmt
- Bei sichtbarer Arbeit wie Benutzeroberflächen, Flows und Erlebnissen werden Qualitätsunterschiede dagegen sofort sichtbar und von Nutzern direkt wahrgenommen
- Wenn das Bauen schneller und günstiger wird, ist nicht mehr „Wie bauen wir es?“, sondern „Was ist es überhaupt wert, gebaut zu werden?“ die schwierigste Frage
- Die Geschwindigkeitssteigerung durch AI-gestütztes Design wird zwangsläufig hinter dem Engineering zurückbleiben, und diese Asymmetrie wird den gesamten Produktentwicklungsprozess und die Teamzusammensetzung neu ordnen
Sichtbare Arbeit: Design ist nicht hinter der Wand, sondern die Wand selbst
- Engineering lässt sich mit Rohrleitungen vergleichen — es verbirgt sich hinter der Wand, und solange Wasser aus dem Hahn kommt, spielt die innere Struktur keine Rolle
- Boris Cherny betreibt 4 bis 5 Coding-Agenten gleichzeitig und erreicht damit eine Geschwindigkeitssteigerung von über 400 %; Engineers im Silicon Valley wechseln zunehmend dazu, statt selbst Code zu schreiben ein Team von Agenten zu orchestrieren
- Softwaredesign ist dagegen die Wand selbst, der Wasserhahn und der Griff, weshalb Nutzer empfindlich auf Erscheinungsbild und Bediengefühl reagieren, auch wenn AI es erzeugt hat
- AI kann zwar Standards und Muster aus Trainingsdaten befolgen, doch umfangreiche entscheidungsrelevante Nutzerforschung aus Dutzenden Interviews, Umfragen, Nutzungsanalysen oder Competitive Audits ist kontextuell zu groß und schwer zu verarbeiten
- Es gibt einen Engpass des Ingestion-Problems — selbst wenn AI riesige Mengen an Code oder Meeting-Zusammenfassungen erzeugt, müssen Menschen sie lesen, verinnerlichen und kritisch bewerten, damit intellektuelle Gespräche und fundierte Entscheidungen möglich bleiben
- Code-Review wird zum eigentlichen Engpass, und dieses Limit menschlicher Geschwindigkeit kann kein Modell umgehen
- AI ist stark bei Content-Erstellung und Zusammenfassung, aber ihre Fähigkeit, wirklich Neues zu schaffen oder Geschmack (
taste) zu besitzen, ist bislang nicht belegt
Nicht in Figma, sondern in Code gestalten
- Der größte Engpass in der Produktentwicklung ist der Handover-Prozess, bei dem Figma-Mockups in Produktionscode übersetzt werden
- Es gibt enorme Ineffizienzen: Man zeichnet Softwarebilder, feilt an Pixeln, übergibt sie an Engineers, und QA prüft anschließend den Code gegen das Mockup, wobei Pull Requests wegen Abweichungen bei Typografie oder Abständen zurückgewiesen werden
- AI kann diesen Engpass beseitigen, aber nur dann, wenn Designer direkt in einer Code-Umgebung gestalten
- Einige Designer kündigen tatsächlich ihre Figma-Abos und wechseln zu AI-Tools; das zentrale Argument ist, dass Mockups nicht das Produkt sind, sondern parallele Artefakte, die übersetzt, geprüft und abgestimmt werden müssen
- Jedes Pixel, das aus Figma herausgeschoben wird, ist ein Versprechen, das Engineers in einem völlig anderen Medium einhalten müssen; je weiter das Designtool vom Produktionscode entfernt ist, desto größer wird die Verschwendung im Handover
- Ein Experiment, bei dem mit Claude Code über drei Prompts gegen das Designsystem-Repo eine funktionierende UI erzeugt wurde, bestätigt das
- Für verlässliche Skalierung braucht es robuste Dokumentation, explizite Regeln und Agenten-Orchestrierung, aber die Grundlage ist bereits vorhanden
- Beispiel des Engineering-Teams von Monday.com: Beim ersten Versuch, einen Figma-Link in Cursor einzufügen, nutzte der erzeugte Code keine Komponenten des Designsystems, Farben waren hart codiert und Typografie überschieb die System-Defaults
- Als Lösung wurde ein Design-System-MCP (Model Context Protocol) aufgebaut — Komponenten, Tokens, Accessibility-Regeln und Nutzungsmuster wurden maschinenlesbar gemacht, und mit einem agentischen Workflow aus 11 Knoten wurde strukturierter Kontext für das Modell erzeugt
- Der Ansatz lautet „Orchestrierung, nicht Magie“: Der Agent schreibt den Code nicht direkt, sondern baut zunächst ein Verständnis dafür auf, wie der Code aussehen sollte, und übergibt dies dann an den Coding-Agenten des Entwicklers
- Designer bei Anthropic reichen mit Claude Code und dem Console-Produkt direkt Pull Requests ein und deployen in Produktion — Stand Februar 2026 ist das bereits Realität
Was dem Menschen bleibt: Orchestrierung und Urteilsvermögen
- Wenn AI Code generieren, PRDs schreiben, Research zusammenfassen und Interface-Prototypen erstellen kann, bleibt dem Menschen vor allem Orchestrierung
- Die Modelle sind kompetent genug; der Engpass ist die Person vor der Tastatur — entscheidend ist die Fähigkeit, zu wissen, was man anfragen sollte, wie man Aufgaben aufteilt und wann man die Ergebnisse des Modells zurückweisen muss
- Kyle Zantos verbringt als Designer 70 % seiner Arbeitszeit im Terminal und betont, dass selbst Empfehlungen von vor vier Monaten bereits veraltet sein können, weshalb es wichtiger ist, Philosophie und Ansatz zu lernen als konkrete Tool-Konfigurationen
- Arin Bhowmick, Chief Design Officer bei SAP: Visuell ausgefeilte Interfaces können tieferliegende Probleme wie unzuverlässige Outputs, intransparente Entscheidungsfindung und fragiles Verhalten in Edge Cases verdecken
- Design-Leads müssen Vertrauen, Klarheit und Zuverlässigkeit als erstklassige Design-Ergebnisse behandeln, nicht nur Oberflächenqualität
- Laut Vlad Derdeicea gehen etwa 80 % der Zeit eines Design-Leads für Kommunikation, Abstimmung und Rechtfertigung drauf, nur 20 % für tatsächliche praktische Designarbeit
- Hinter jeder Designentscheidung steckt eine „Justification Tax“ — die Zeit, die dafür aufgewendet wird, Entscheidungen zu erklären, zu dokumentieren und zu verteidigen, die in anderen Disziplinen in einem kurzen Gespräch erledigt wären
- AI sollte nicht auf Mockup-Arbeit zielen, sondern auf diese 80 %: Meeting-Notizen zusammenführen, Stakeholder-Kommunikation entwerfen, Research zusammenfassen und mit schnellen Prototypen Debatten anhand von Daten statt Meinungen entscheiden
- Die Einordnung von Jan Tegze: Nicht versuchen, die aktuelle Arbeit nur besser zu machen, sondern die Beschränkungen eines Fachgebiets, die aus menschlichen Grenzen entstehen, identifizieren und mit Agenten entfernen — also nicht nur bestehende Arbeit beschleunigen, sondern Dinge möglich machen, die vorher unmöglich waren
- „Nicht mit Agenten konkurrieren, sondern neue Fähigkeiten schaffen, die sowohl dich als auch Agenten benötigen“
- Junior-Designer mit weniger als fünf Jahren Berufserfahrung sind stärker gefährdet — ihnen fehlt oft das Urteilsvermögen, AI-Outputs richtig zu bewerten, und die Erfahrung, Fehler der Modelle zu erkennen; die Skill-Floor steigt
Kleine Teams, große Hebelwirkung
- Die meisten Softwareunternehmen sind heute unpassend organisiert — sie sind Feature Factories mit einem Übermaß an PMs, in denen jedem Squad ein PM zugeteilt wird, unabhängig davon, ob dedizierter Design-Support vorhanden ist
- PMs nahmen in der ZIRP-Ära stark zu, weil sie näher am Umsatz sind und ihre Zahl mit der organisatorischen Komplexität mitwächst
- Marty Cagan nennt das „Product Management Theater“ — einen Überhang an ineffektiven PMs, die sich kaum von überbezahlten Projektmanagern unterscheiden, die Roadmaps erstellen und Stand-ups leiten
- Andrew Ng prognostizierte in Davos, dass sich mit explodierender Engineering-Produktivität durch AI das Verhältnis von PMs zu Engineers von 1:8 in Richtung 1:1 drehen wird
- Wenn AI-Agenten den Großteil des Produktionscodes schreiben, schrumpft die breite Engineering-Basis, und Spezifikation und Urteilsvermögen werden zur knappen Ressource
- Airbnb hat Product Management und Product Marketing zu einer „Full-Stack“-Rolle zusammengeführt
- Brian Chesky: „Wenn man nicht weiß, wie man über ein Produkt spricht, kann man es nicht entwickeln“ — Storytelling und externe Kommunikation werden damit zu erstklassigen Bestandteilen der PM-Rolle
- Designer werden zu „Architekten“ aufgewertet, die gemeinsam mit Engineers das Produkt führen, statt nur ein nachgelagerter Service zu sein, der Tickets abarbeitet
- Koordinationsaufgaben, die zuvor PM-Headcount aufgebläht haben, wurden an dedizierte Program Manager übergeben
- Das ähnelt Apples Modell einer funktionalen Organisation: Experten führen Experten, der CEO ist der Integrationspunkt, und es gibt keine PMs als „Mini-CEOs“, die Geschäftsbereiche führen
- Das ideale Team im AI-Zeitalter ist ein kleines, handlungsfähiges Team aus 2 bis 3 Engineers, 1 PM und 1 Designer
- Das Designsystem wird zur zentralen Infrastruktur; ohne Designsystem im Code und ohne Dokumentation trifft AI schlechte Entscheidungen über UI und Implementierung
- Unternehmen, die in maschinenlesbare Designsysteme und kleine, handlungsfähige Teams investieren, werden Firmen mit 15-köpfigen Squads und Freigaben über drei Ebenen übertreffen
Der Zinseszinseffekt: die Kluft zwischen Orchestratoren und Pixel-Schiebern
- Nach dem Experiment, mit Claude Code aus dem Designsystem einen funktionierenden Screen zu erzeugen, laufen fortlaufende Verbesserungen bei Dokumentation, strengeren Komponentenregeln und klaren Kompositionsrichtlinien
- Mit jeder Runde wird es schneller und näher an Production-Ready; Modellverbesserungen, Skill-Verfeinerung und bessere Steuerungsfähigkeit akkumulieren sich wie Zinseszinsen
- Die Kluft zwischen „Designern, die AI orchestrieren“ und „Designern, die in Figma Pixel schieben“ wird in den nächsten 12 Monaten enorm werden
- Nicht weil Pixel-Schieber unfähig wären, sondern weil Orchestratoren mit grundsätzlich anderer Geschwindigkeit und Reichweite arbeiten — während andere Mockups für Handover-Meetings ausgeben, deployen sie funktionierende UI
- Der Autor bringt seinem Team diese Arbeitsweise bei, nicht weil der Beruf verschwindet, sondern weil er sich zu einem Beruf wandelt, in dem Geschmack, Urteilsvermögen und die Fähigkeit, Arbeit zu dirigieren, wichtiger werden als die Fähigkeit, Bilder zu zeichnen
Noch keine Kommentare.