Von einzelnen Screens zu wiederverwendbaren Systemen.
KI hat mein Produktdenken nicht verändert. Sie hat verändert, wofür ich meine Zeit einsetze — weg vom manuellen Erstellen einzelner Screens, hin zum Aufbau wiederverwendbarer Systeme, mit denen ich schneller erkunden, validieren und ausliefern kann, ohne die Messlatte bei der Evidenz zu senken.
Das hier ist keine Leistungsschau von Tools oder Prompts. Es ist ein Arbeitsprotokoll eines Wandels, den ich in meiner Art vollzogen habe, Produktdesign zu betreiben: warum es sich verändert hat, wie ich heute tatsächlich arbeite, und wohin sich das meiner Einschätzung nach als Nächstes entwickelt — weiterhin im Fluss, und verankert in echten Projekten statt in Demos.
Discovery und Recherche waren nie das Problem. Die Produktion war der teure Teil.
Klassisches Produktdesign stützt sich noch immer stark auf manuelle Produktion: Layouts neu aufbauen, Dummy-Daten einpflegen, immer wieder dieselben Patterns nachbauen und Übergabe-Artefakte vorbereiten, bevor Engineering überhaupt anfangen kann. Nichts davon ist Denkarbeit. Es ist Overhead. Beim Diagramm unten geht es nicht darum, Figma zu ersetzen, Designer zu ersetzen oder Code zu ersetzen: Es geht darum, wo das Gewicht der Arbeit liegt.
Discovery, Recherche und Produktdenken nahmen bereits die meiste Zeit ein. Produktion war schlicht der teuerste Teil des Prozesses.
↔ Wischen, um alle Phasen zu sehenDiscovery und Recherche bekommen jetzt mehr Zeit, nicht weniger — das Denken breitet sich in den Raum aus, den früher die Produktion einnahm. Produktion kostet nur noch einen Bruchteil, sodass Prototyping und Validierung wachsen, um den Rest zu füllen.
KI hat meinen Designprozess nicht verändert. Sie hat seine Ökonomie verändert.
Ein Blick darauf, wie das konkret geroutet wird:
- Problem oder Chance
- Wie viel Unsicherheit besteht? Verstehen & einschätzen
-
Hohe Unsicherheit Discovery & Recherche Unsicherheit verringern, bevor investiert wird.Geringe Unsicherheit Wiederverwendung & KI-gestützte Exploration Bewährte Patterns wiederverwenden. Mit Zuversicht beschleunigen.
- Prototyping Ideen mit wiederverwendbaren Systemen und KI-Unterstützung schnell erkunden, validieren und verfeinern.
- Validieren & verfeinern Mit Nutzern testen, Evidenz sammeln und vor der Übergabe Vertrauen aufbauen.
- Engineering Entwicklerfertige Lösungen mit Klarheit und Zuversicht liefern.
Ich wende nicht auf jedes Problem denselben Prozess an. Zuerst schätze ich immer ein, wie viel Unsicherheit besteht. Wirklich unsichere Probleme beginnen weiterhin mit Discovery, Recherche und Synthese. Gut verstandene Probleme können schneller über wiederverwendbare Patterns und KI-gestützte Exploration laufen. Beide Wege treffen im Playground wieder aufeinander, wo ich Ideen rasch prototype, validiere und verfeinere, bevor ich sie mit größerer Zuversicht an Engineering übergebe. Bei den einfachsten, risikoärmsten Korrekturen kann dieselbe Einschätzung die Arbeit direkt an Engineering weiterleiten und Design und Discovery ganz überspringen. KI hat nicht verändert, wie ich Designentscheidungen treffe. Sie hat verändert, wie schnell ich diese Entscheidungen in etwas Reales verwandeln kann.
Wiederverwendbare Komponenten wurden zu wiederverwendbarer Intelligenz.
Design System, Code-Editor, Prototyp und Dokumentation sind ein zusammenhängendes System, nicht vier separate Tools, die jedes Mal von Hand neu aufgebaut werden. Ich kuratiere ein Interface aus dem, was bereits existiert (add bar-chart-tile, kein Screenshot davon), indem ich Claude Code und OpenAI Codex in VS Code steuere, mit GitHub Copilot inline, gegen eine gemeinsame Komponentenbibliothek und ein Set an Markdown-Regeln, sodass das Ergebnis konstruktionsbedingt zum System passt. Zwei Agenten, die dieselben dokumentierten Regeln lesen, sind zugleich ein funktionierender Abgleich: Wenn sie nicht übereinstimmen, muss meist die Dokumentation geschärft werden, nicht der Code.
Design System, Code-Editor, Prototyp und Dokumentation lebten früher in getrennten Tools, für jedes Projekt von Hand neu aufgebaut. Im Playground sind sie ein zusammenhängendes System: Komponenten, Tokens, Barrierefreiheitsregeln und Interaktionsmuster existieren bereits, sodass ich ein Interface nicht von Grund auf beschreibe, sondern kuratiere — indem ich genau die gewünschte Komponente benenne (add bar-chart-tile, kein Screenshot davon), sodass das Ergebnis konstruktionsbedingt zum System passt, nicht zufällig.
Die Agenten, die das Komponieren übernehmen, sind Claude Code und OpenAI Codex, beide innerhalb von VS Code laufend und beide lesend an derselben Komponentenbibliothek und denselben Markdown-Regeln, während GitHub Copilot die Inline-Vorschläge beim Tippen übernimmt. ChatGPT steht daneben für das Denken, das außerhalb des Editors passiert: ein Problem einordnen, Daten durcharbeiten, die Dokumentation entwerfen, die die Agenten anschließend lesen. Zwei Agenten an einem dokumentierten System sind zugleich ein nützlicher Abgleich; wenn sie nicht übereinstimmen, muss meist die Dokumentation geschärft werden, nicht der Code.
Eine Veränderung wog schwerer, als ich erwartet hatte: realistische Daten. Statt Screens mit Lorem Ipsum zu füllen, habe ich wiederverwendbare, fiktive Datensätze gebaut (erfundene Händler, Produkte und Kunden, modelliert nach realen operativen Mustern), die Prototypen automatisch befüllen. Ein Promotion-Konzept, getestet gegen eine fiktive Fußball-WM-Kampagne und erfundene Produkte, fühlte sich für die Teilnehmenden genauso real an wie ein Live-Produkt — ohne dass ein einziges Stück kommerzieller Daten das Haus verließ.
Diese fiktiven Daten reichen aus, um zu designen und zu testen, nicht um auszuliefern. Der Prototyp und das Produktions-Feature teilen sich dieselben Komponenten und dieselbe Datenform; nur die Quelle ändert sich — erfundene Datensätze werden bei der Integration gegen einen echten, berechtigten Feed getauscht, sodass sich das Interface identisch verhält, sobald die dahinterliegenden Daten real sind.
Es gibt hier auch ein kommerzielles Argument, nicht nur ein handwerkliches. Ein Interface von Grund auf zu erraten kostet mehr als eines zu komponieren: mehr Generierungen, mehr Korrekturzyklen, mehr Tokens, um zum selben Ergebnis zu kommen. Die Wiederverwendung eines bewährten Systems kommt in weniger Schritten dorthin — was eine niedrigere KI-Rechnung für dasselbe Ergebnis bedeutet, nicht nur ein schnelleres.
Hygiene-Arbeit und das Aufholen zu einem Wettbewerber sind beides legitime Gründe, etwas zu bauen, aber die Version, von der ich mehr will, ist die dritte: etwas, von dem ein Nutzer nicht wusste, dass er es brauchte, bis er es benutzt hat. Ich gewichte das nach wie vor gegen Aufwand versus Nutzen, eine alte, einfache Bewertungsmethode, weil darunter immer die Frage steckt, welche Rendite eine Arbeit wert ist, in die investiert wird. Sobald es ausgeliefert ist, greift dieselbe Disziplin aus meinem CRO-Hintergrund: Qualitative und quantitative Tests entscheiden, ob es sich seinen Platz verdient hat — nicht die Tatsache, dass es ausgeliefert wurde.
- Der Auslöser Eine daten- und recherchebasierte Roadmap, die Business- und Kundenbedürfnisse in Einklang bringt.
- Was braucht das hier? Pattern, Feature oder etwas Neues — der Weg hängt von der Antwort ab.
- Bereits im Design System Direkt in die Umsetzung VS Code — Claude Code und OpenAI Codex als Agenten (die mit dem bauen, was bereits existiert), GitHub Copilot mit Inline-Vorschlägen. Kein Design-Durchlauf nötig.
-
Neu oder unsicher
Discovery & Umsetzung im Loop
In beliebiger Reihenfolge gewechselt, keine feste Abfolge:
FigJam · Lucid — zuerst Service Blueprints & Flows. Figma — ein schneller Prototyp zum Testen, oder detailliertes Design, wenn das Pattern noch nicht existiert. VS Code — Claude Code, OpenAI Codex und GitHub Copilot; die Umsetzung läuft weiter, während Discovery die Form klärt.
- Plausibilitätsprüfung UX-, Barrierefreiheits- & Content-Richtlinien — die MD-Dateien —, die vor der Auslieferung jede Überschneidung oder Folgewirkung abfangen.
-
Ausliefern
Ein GitHub-Repository, mit einer bei Bedarf angebundenen Datenbank.
Vercel-Deployment Eigene Projekte, direkt ausgeliefert.Übergabe an Engineering Brambles & Kundenteams — Repo, Frontend-Code & ein Live-Prototyp.
Der Weg hängt davon ab, was die Arbeit braucht, nicht von einer festen Abfolge: Eine kleine Änderung, die bereits im Design System vorhandene Patterns nutzt, geht direkt in die Umsetzung, ohne Design-Durchlauf. Etwas wirklich Neues oder Unsicheres tritt stattdessen in einen Discovery-und-Delivery-Loop ein — Service Blueprints, Prototypen oder detaillierte Figma-Arbeit, gewechselt zwischen VS Code und Figma in der Reihenfolge, die das Problem verlangt. Beide Wege durchlaufen vor der Auslieferung eine Plausibilitätsprüfung gegen dieselben UX-, Barrierefreiheits- und Content-Richtlinien — direkt in die Produktion für eigene Projekte, oder mit einem Live-Prototyp an Engineering übergeben für Brambles und Kundenteams.
- Im Code Komponenten Einmal gebaut, wiederverwendbar — eine bar-chart-tile, ein date-picker, bereits in der Bibliothek vorhanden.
- In MD & Tokens Regeln Varianten, Zustände & Abstände, plus UX-, Barrierefreiheits- & Content-Richtlinien, schriftlich festgehalten.
- Zusammen Claude Code, OpenAI Codex & GitHub Copilot Komponieren nur aus dem, was benannt und bereits erlaubt ist — kein leerer Prompt.
Keine der beiden Quellen reicht allein: Komponenten ohne Regeln werden falsch genutzt, Regeln ohne Komponenten bleiben theoretisch. Zusammen ist das gemeint mit “Liest: MD-Dateien” im Diagramm oben.
Ein paar Artefakte aus dem Inneren des Playgrounds selbst — mehr kommen hinzu, während sich die Praxis weiterentwickelt:
Wo das tatsächlich passiert ist.
Komplexe Daten, erkundet als etwas Reales statt als etwas Beschriebenes.
Kunden-Dashboards begannen als Skizzen und Flows und wanderten dann als interaktive, chartgetriebene Prototypen in den Playground. Wiederverwendbare Chart-Komponenten und Design Tokens sorgten dafür, dass Stakeholder auf etwas reagierten, das sie tatsächlich benutzen konnten, nicht auf ein statisches Mock-up.
Mehr erfahren →Zwei weitere Beispiele, Homepage Map und Retail Promotions, finden Sie in der vollständigen Fassung.
Ein Karten-Erlebnis skalieren, ohne es von Hand neu zu zeichnen.
Ein standortbasiertes Homepage-Erlebnis musste über mehrere Produkte und Regionen hinweg funktionieren. Die erste Exploration begann in Figma; sobald das Interaktionsmodell bewiesen war, ließ mich der Playground es als funktionierendes, wiederverwendbares Karten-Pattern neu aufbauen, sodass die Skalierung auf ein zweites Produkt bedeutete, das Pattern wiederzuverwenden, nicht neu zu designen.
Mehr erfahren →Realistisch genug zum Testen, sicher genug zum Teilen.
Ein Retail-Promotions-Konzept, fast vollständig im Playground erkundet, mit sehr wenig statischer Figma-Arbeit. Wiederverwendbare Komponenten und dynamische, fiktive Datensätze (erfundene Händler, erfundene Produkte, eine fiktive Fußball-WM-Promotion-Kampagne) sorgten dafür, dass sich der Prototyp im Usability-Test real anfühlte, ohne ein einziges Stück kommerzieller Daten offenzulegen.
Mehr erfahren →Jedes Ergebnis wird zum nächsten Input.
Nichts davon setzt sich mit jeder neuen Aufgabe zurück. Dieselben Markdown-Arbeitsdateien — Entscheidungen, Evidenz, Design-System-Regeln — werden von einer KI-gestützten Session zur nächsten weitergetragen, sodass jede weiter vorn startet als die letzte, statt denselben Kontext von Grund auf neu zu erklären. Es ist dasselbe evidenzbasierte Prinzip, das auch der Arbeit selbst zugrunde liegt: Je mehr das System aus Design Systems, Nutzererkenntnissen, UX-Patterns und Recherche erfasst, desto mehr hat es zum Schlussfolgern zur Verfügung, und desto besser wird sein Urteilsvermögen mit der Zeit.
Dasselbe Wiederverwendungsprinzip wie im Playground. Nur angewendet auf Wissen statt auf Komponenten.
Dasselbe Prinzip, in den Händen eines anderen.
Ein Designer, den ich betreue, Dmytro Ivanchenko, hat dasselbe Prinzip weitergetrieben: einen KI-Agenten direkt aus den bestehenden Komponenten und dokumentierten Nutzungsregeln unseres Design Systems komponiert, und separat ein Plugin gebaut, das ein Design automatisch zwischen Breakpoints konvertiert.
Das Komponieren aus einem bewährten System lässt sich übertragen: Andere können es aufgreifen und direkt damit weiterarbeiten.
Was ich gelernt habe
KI hat mein Urteilsvermögen nicht ersetzt. Sie hat verändert, wofür ich meine Zeit einsetze.
- Weniger Zeit für das Nachbauen von Screens, mehr Zeit für das Verstehen von Problemen.
- Wiederverwendung potenziert sich: Jede einmal gebaute Komponente zahlt sich vielfach aus.
- Realistische Daten zählen genauso viel wie realistische Interfaces.
- Prototypen, die funktionieren, provozieren schärferes Feedback als Prototypen, die nur fertig aussehen.
- Die Lücke zwischen „designt“ und „umsetzbar“ schrumpft, wenn Design und Engineering dieselben Komponenten teilen.
Das Designhandwerk ist nicht verschwunden: Es hat sich verlagert — vom Erstellen einzelner Screens hin zur Orchestrierung der Systeme, Evidenz und Wiederverwendung dahinter.
Wohin sich das als Nächstes entwickelt, und wie ich mich darauf einstelle.
Die Zahlen weiter oben auf dieser Seite — Produktion runter, Discovery und Validierung rauf — sind eine grobe Skizze von etwas, das viel breiter passiert: Nahezu 60% der mechanischen Designarbeit fallen inzwischen an KI, und die verbleibenden 40% — Feinschliff, Urteilsvermögen, das Wissen, was ein Kontext tatsächlich verlangt — sind dort, wohin sich der Wert verlagert hat, nicht dort, wo er verschwunden ist. Ich verfolge dieses Verhältnis lieber bewusst und plane, wohin es sich entwickelt, als es ein Jahr zu spät zu bemerken. Hier ist die ehrliche Version dieses Plans:
- Jetzt · 2026 ~60% KI, 40% Urteilsvermögen KI entwirft Flows, Layouts und erste Durchläufe. Ich prüfe: die MD-Dateiregeln, den Zwei-Agenten-Abgleich, die Plausibilitätsprüfung, bevor irgendetwas ausgeliefert wird.
- Nächste 12 Monate ~65% KI, 35% Urteilsvermögen Mehrere KI-Workstreams gleichzeitig steuern und beurteilen, was sie produzieren, statt es selbst zu entwerfen.
- Zwei Jahre ~70% KI, 30% Urteilsvermögen Weniger alles mit derselben Intensität prüfen. Mehr Triage: vorab entscheiden, was wirklich eine starke Prüfung braucht.
- Fünf Jahre und darüber hinaus Kompass, keine Prognose Weniger operativ mit einem einzelnen Tool. Mehr Probleme so präzise definieren, dass sich der Output eines Agenten schnell daran überprüfen lässt.
Eine ehrliche Zeitlinie, kein Verkaufsversprechen: Die näheren Stationen basieren auf dem, was sich laut den Zahlen dieser Seite bereits verschiebt; die am weitesten entfernte ist ein Kompass, keine Prognose — das sage ich lieber offen, als eine Präzision vorzutäuschen, die ich nicht habe.
Die Überlegungen hinter jeder Station, und was auch bei sich verschiebendem Verhältnis konstant bleibt, steht in der vollständigen Fassung.
Genau deshalb sind mir die Plausibilitätsprüfung, die MD-Dateien und der Zwei-Agenten-Abgleich genauso wichtig wie die Diagramme, die die Arbeit überhaupt erst erzeugen. Je mehr die mechanische Ebene abgegeben wird, desto mehr bleibt bestehen, wer dafür verantwortlich ist, dass eine folgenreiche Entscheidung richtig ist. Das ist dieselbe Disziplin, die auch UX Governance und Design QA an anderer Stelle auf dieser Website zugrunde liegt, angewendet auf schneller bewegte Ergebnisse — keine neue Fähigkeit, die ich bei null beginnend erlerne.
Über das Generieren von Interfaces hinaus interessiert mich zunehmend, wie KI validiertes Produktwissen und Forschung leichter auffindbar, wiederverwendbar und über die gesamte Produktentwicklung hinweg anwendbar machen kann.
Ein Bereich, den ich gemeinsam mit unserem Research-Team erkunde, ist, wie das Teil des Playgrounds selbst werden könnte — nicht als Ersatz für Forschung, sondern um die Zeit für die Suche nach Evidenz zu verringern, damit Teams auf dem aufbauen können, was sie bereits wissen, statt bei null anzufangen.
Dieselbe evidenzbasierte Disziplin, angewendet auf eine validierte Produktrichtung.