Der Druck ist real: Produktteams und insbesondere Produktmanager*innen sind gefordert, KI nicht nur zu beobachten, sondern aktiv einzusetzen. Tools werden eingeführt, Pilotprojekte gestartet, Budgets freigegeben.
Und trotzdem haben viele Teams das Gefühl, dass sich in der täglichen Produktentwicklung weniger verändert hat als erwartet. Nicht weil KI nichts kann, sondern weil noch zu wenig darüber gesprochen wird, wo sie wirklich etwas bewegt, und was dafür stimmen muss.
Was KI im Produktentwicklungsprozess bereits leistet
KI ist kein einzelnes Tool, sondern eine Querschnittstechnologie, die an verschiedenen Stellen im Produktentwicklungsprozess ansetzt. Ein kurzer Überblick:
Auf der Entwicklungsseite
Der am weitesten entwickelte Bereich: KI kann Code generieren, bestehenden Code analysieren und verbessern, Dokumentation aus Code erzeugen und Testfälle erstellen. Entwicklungsteams arbeiten bereits produktiv damit, besonders bei wiederkehrenden, strukturierten Aufgaben.
Auf der Produktseite
KI unterstützt unter anderem beim Verfeinern von Anforderungen, beim Auswerten von User-Research-Daten und beim Verdichten von Nutzer-Feedback zu verwertbaren Erkenntnissen. Es gilt: Je strukturierter der Input, desto nützlicher der Output.
An der Schnittstelle von Design und Entwicklung
Einer der vielversprechendsten Bereiche ist die Umsetzung von Designs in Code. KI kann aus fertigen Design-Dateien direkt Frontend-Code generieren und damit den aufwändigsten Teil der Übergabe zwischen Design- und Entwicklungsteam automatisieren.
Genau hier setzen gerade viele Teams ihre größten Erwartungen. Doch die erhoffte Beschleunigung bleibt häufig aus.
Warum es noch hakt
Die Hoffnungen sind nachvollziehbar: Die Übergabe von fertigen Designs in die Entwicklung kostet viel Zeit, produziert Rückfragen und bringt Sprints oft genug zum Rutschen. Und weil sich der Prozess theoretisch gut automatisieren lässt, klingt KI hier nach einer besonders naheliegenden Lösung: Die Aufgabe ist repetitiv, der Input wirkt strukturiert, das gewünschte Ergebnis ist klar definiert. Genau die Bedingungen, unter denen KI gut funktioniert.
Kein Wunder also, dass viele Teams hier viel erwarten. Was wir bei unseren Kund*innen immer wieder erleben: Das Design ist abgenommen, das Team lädt die Datei in ein KI-Tool, und wenige Minuten später liegt Code vor. Erstmal sind alle happy. Nur dass die Entwickler*innen diesen Code kaum verwenden können. Buttons sehen auf verschiedenen Screens unterschiedlich aus. Abstände stimmen nicht. Komponenten wurden mehrfach generiert, obwohl sie eigentlich dieselben sein sollten. Und der generierte Code passt oft nicht zur bestehenden Architektur des Entwicklungsteams, er muss erst übersetzt werden, bevor er in die Codebasis integrierbar ist. Was als Zeitersparnis gedacht war, wird zur Nacharbeit. Der Sprint ist nicht kürzer geworden, er hat sich nur anders verteilt.
Teams reagieren mit Toolwechseln, anderen Einstellungen, neuen Anbietern. Ein Quartal später wiederholt sich dasselbe Muster. Der Aufwand für Evaluierung, Migration und Onboarding kommt obendrauf und das Grundproblem bleibt. Es liegt nicht am Tool.
Was in diesen Situationen fast nie gefragt wird: Was haben wir diesem Tool eigentlich gegeben?
Was fast immer übersehen wird
KI schafft keine Ordnung. Sie arbeitet mit der Ordnung, die bereits vorhanden ist, oder eben nicht.
Der Gedanke, eine Design-Datei hochzuladen und daraus Code zu generieren, klingt einfach. Doch KI liest die Design-Datei so, wie sie aufgebaut ist. Sie erkennt Muster, wenn Muster da sind, und erzeugt konsistenten Code, wenn der Input konsistent ist. Ist er das nicht, spiegelt der Output genau das wider.
KI verstärkt, was sie vorfindet.
„Wir sehen das gerade in vielen Projekten: Unternehmen haben ein Designsystem, das für Menschen gut funktioniert, aber nicht für Maschinen. Die Lücken fallen im Designalltag oft nicht auf. Spätestens im generierten Code werden sie sichtbar.“
Bernd Feldmayer
Senior Frontend Engineer, UX&I
KI braucht nicht nur das fertige Design als Input, sie braucht die Struktur dahinter: ein Designsystem, das so aufgebaut ist, dass eine Maschine damit arbeiten kann. Genau das fehlt in den meisten Prozessen.
Die Design-Datei selbst ist nie neutral. Sie spiegelt wider, wie systematisch oder unsystematisch die Designs dahinter aufgebaut sind. Das Designsystem, oder sein Fehlen, steckt bereits drin, bevor KI auch nur eine Zeile generiert.
Ein Designsystem zu haben reicht nicht
Die meisten Unternehmen haben heute ein Designsystem. Das ist die gute Nachricht. Weniger gut: Oft ist dieses noch nicht maschinenlesbar.
Viele Designsysteme funktionieren gut als gemeinsame Referenz für Design- und Entwicklungsteams, als Kommunikationsmittel, als visuelle Sprache. Aber sie sind nicht so strukturiert, dass eine KI daraus zuverlässig produktionsreifen Code erzeugen kann. Der Maßstab hat sich verändert.
„Ein Designsystem, das für KI funktioniert, ist kein anderes System. Es ist nur konsequenter. Oft sind es Details, die uns als Menschen gar nicht auffallen: Benennung, Struktur, fehlende Zustände. Für eine Maschine sind das die entscheidenden Stellen.“
Flora Maxwell
Senior UI-Designerin, UX&I
Reifegrad, nicht Vorhandensein
Ein Designsystem, das für KI funktioniert, ist kein anderes Werkzeug, es hat einen höheren Reifegrad. Die entscheidende Frage ist, ob eine Maschine es versteht. Das zu beurteilen ist nicht trivial, da es weder eine reine Design- noch eine reine Entwicklungsfrage ist. Wer verstehen will, auf welcher Stufe das eigene Designsystem steht, findet im Designsystem-Reifegradmodell einen guten Ausgangspunkt. Die eigentliche Arbeit beginnt aber mit den richtigen Fragen.
Drei Signale, dass euer Designsystem KI noch ausbremst
Ob KI mit eurem Designsystem gut arbeiten kann, ist nicht immer sofort offensichtlich. Oft zeigt es sich erst, wenn ein Pilotprojekt nicht die erhofften Ergebnisse liefert. Drei Signale, die wir dabei immer wieder beobachten:
Der generierte Code braucht mehr Zeit als selbst geschriebener
KI hat zwar Code erzeugt, aber die Entwickler*innen verbringen viel Zeit damit, ihn zu sichten, verstehen, korrigieren und anzupassen. Oft ist der Output so weit von einer brauchbaren Basis entfernt, dass sich nicht einmal eine Korrektur lohnt, und das Team wieder bei null anfängt. Das Tückische: Wann das passiert, ist kaum vorhersagbar. Produktmanager*innen merken das meist indirekt: Der Sprint wird nicht kürzer, obwohl das Tool läuft. Aufwandsschätzungen werden unzuverlässiger, weil niemand vorher weiß, ob der generierte Code brauchbar sein wird. Der Engpass hat sich nur verschoben: vom Schreiben zum Sichten und Korrigieren.
Gleiche Elemente, unterschiedliche Ergebnisse
Ein Button, der in zehn verschiedenen Screens auftaucht, wird von KI zehn Mal unterschiedlich interpretiert und generiert. Das eigentliche Problem: Der Button existiert als Komponente, aber Instanzen wurden irgendwo manuell überschrieben, Varianten haben leicht abweichende Namen, Zustände fehlen. Für Menschen sieht alles gleich aus – KI sieht verschiedene Objekte. Das Ergebnis: Eine inkonsistente UI, die im QA auffällt, Nutzer*innen irritiert und Nacharbeitsschleifen produziert, die niemand eingeplant hatte. Besonders tückisch: Das Problem ist im Design selbst nicht sichtbar. Es zeigt sich erst, wenn KI daraus Code macht.
Vor jedem KI-Einsatz muss jemand die Design-Datei aufbereiten
Bevor KI eingesetzt werden kann, bereinigt häufig jemand aus dem Team die Design-Datei: Benennung vereinheitlichen, fehlende Zustände ergänzen, Inkonsistenzen beheben. Das ist kein KI-spezifisches Problem, denn dieselben Lücken existieren auch bei der Übergabe an menschliche Entwickler*innen. Der Unterschied: Erfahrene Entwickler*innen kennen das Projekt, die Komponenten, die Konventionen. Sie kompensieren Informationslücken aus ihrem spezifischen Erfahrungsschatz. KI kann das nicht, sie arbeitet nur mit dem, was in der Datei steht.
Was Produktmanager*innen jetzt konkret tun können
PMs können das Team unterstützen, indem sie die richtigen Fragen stellen, Prioritäten setzen und Gespräche anders führen: Das ist dein Hebel. Drei Denkverschiebungen helfen dabei.
Nicht: Welches Tool ist das richtige? Sondern: Was ist der Input?
Wenn die Antwort auf diese Frage lautet „unsere Figma-Datei“, ist die nächste Frage: Ist die so aufgebaut, dass eine Maschine damit arbeiten kann? Oft ist das der Moment, in dem klar wird, wo die Investition wirklich hingehört. Nicht ins nächste Tool-Abo, sondern in die Grundlage, die jedes Tool erst zum Funktionieren bringt.
Nicht: Haben wir ein Designsystem? Sondern: Kann eine Maschine damit arbeiten?
Die meisten Teams haben die erste Frage beantwortet, die zweite stellen noch wenige. Ein Designsystem kann für Menschen gut funktionieren, als Referenz, als Kommunikationsmittel, als gemeinsame Sprache zwischen Design und Entwicklung, und trotzdem für KI unbrauchbar sein. Wenn du diese Frage in dein Design-Team trägst, startest du einen wichtigen Prozess.
Nicht: Designsystem als Designthema. Sondern: Designsystem als Infrastruktur.
Wenn du das Designsystem so denkst wie eine API oder eine Datenbankstruktur, stellst du automatisch andere Anforderungen daran und kannst es anders priorisieren. Infrastruktur gehört nicht einem Team, sie dient dem ganzen Prozess. Mit diesem Framing wird aus einem internen Design-Projekt eine strategische Entscheidung mit eigenem Budget, eigener/m Owner*in und einem Platz auf der Roadmap, statt einem dauerhaften Nebenprojekt, das nie ganz fertig wird. Die Frage „Wer ist verantwortlich für das Designsystem?“ bekommt plötzlich eine andere Dringlichkeit. Und die Antwort „das Design-Team irgendwie“ reicht nicht mehr.
Die Frage, die den Unterschied macht
KI verändert die Art, wie Produktteams arbeiten, grundlegend. Aber nicht gleichmäßig und nicht automatisch. Teams, die die richtige Grundlage haben, werden davon profitieren.
Der Unterschied liegt selten am Tool. Er liegt daran, ob der Designinput so aufgebaut ist, dass KI damit arbeiten kann. Die entscheidende Frage betrifft nicht nur das Designteam, sie muss höher aufgehangen und strukturell beantwortet werden: Könnte eine Maschine unsere Designs verstehen?
Wenn ihr wissen wollt, wie weit euer Designsystem wirklich ist: Wir haben dafür einen strukturierten Einstieg entwickelt. Der AI-Readiness-Check gibt euch eine klare Standortbestimmung: mit konkreten Empfehlungen, was als nächstes sinnvoll ist.
