Warum AI die Pipelines im Produktdesign beeinträchtigt – und wie Teams das Problem lösen

Schwächen eure AI-Tools unbemerkt die UX oder Servicequalität eures Produkts? Wenn ihr AI in eure Produkt-Workflows integriert, besteht das größte Risiko nicht darin, dass AI euer Design zerstört. Sie könnte es jedoch langsam dem Durchschnitt annähern.

Ich habe vier führenden Modellen ein Beispiel für Google Labs' DESIGN.md gegeben und sie gebeten, einen „Weiter“-Pfeil in 44×44 und 88×88 px zu erstellen. Alle vier hielten sich an jedes Token der Spezifikation: Farbe, Strichstärke, Linienenden, Linienverbindungen, Zeichenfläche, keine Füllung. Bei zwei Punkten, die in der Spezifikation nie erwähnt wurden, waren sie sich ebenfalls einig: beim Winkel der Pfeilspitze und bei der Gestaltung der Linienenden.

Siehe DESIGN.md, das von Google als Open Source veröffentlichte Format für Designregeln.

Dies ist kein Benchmark, aber es zeigt ein Problem: Eine Spezifikation kann vollständig genug sein, um Compliance-Tests zu bestehen, und dem Modell dennoch Lücken überlassen, die es selbst füllt. Und was Modelle dafür verwenden, ist der Durchschnitt aus allem, worauf sie trainiert wurden.

Warum AI-bedingte UX-Abweichungen schwer zu erkennen sind

Das Icon-Experiment war Teil meines eigenen Projekts, in dem ich die Erstellung und den Umgang mit eigenem UX-Material getestet habe. Ich habe mir strikte Ziele für UX und Service Design gesetzt, die ich nicht wegdesignen durfte – so wie man die zentralen Anforderungen eines Kunden nicht wegdesignen kann. Ich habe bewusst ungewöhnliche Interaktionsmuster eingebaut: drei überlappende Navigationsmodelle, Bedienelemente, die nur nach bestimmten Ereignissen erscheinen, sowie ein Zurück- und Vorwärtsverhalten, das sich je nach Kontext ändert – Dinge, die meiner Einschätzung nach in den Trainingsdaten kaum vertreten sind.

Ich ging davon aus, dass sich diese ungewöhnlichen Muster mit AI nur schwer umsetzen ließen. Das war nicht der Fall, aber sie beizubehalten war nahezu unmöglich.

Über einige Wochen wurden die ungewöhnlichen Muster unbemerkt zu konventionellen. Formulierungen, die ich bewusst gewählt hatte, wurden während einer nicht damit zusammenhängenden Fehlerbehebung „verbessert“. Ein Kollege erlebte dasselbe aus der entgegengesetzten Richtung: Das erneute Anwenden eines zuvor funktionierenden Designsystems führte plötzlich zu Pixelabweichungen, merkwürdigen Positionierungen und subtilen Veränderungen im Tone of Voice. 

Nichts davon war in Tests sichtbar, denn nichts war kaputt. Alles bewegte sich ein paar Grad in Richtung Durchschnitt.

Der Mechanismus ist nicht rätselhaft. AI wird mit normalen Dingen trainiert, die im Trainingsmaterial reichlich vorhanden sind. In der technischen Arbeit ist das meist ein Geschenk – im Produktdesign kommt es jedoch dem Gegenteil nahe. Das meiste, was ein Produkt förderungswürdig macht, ist der Teil, der noch nicht normal ist und in Trainingsdaten ganz sicher nicht in großem Umfang verfügbar ist.

Warum menschliche Reviews AI-Abweichungen nicht erkennen

Jetzt kommt der Teil, den ich lieber nicht schreiben würde. Das geschah nicht hinter meinem Rücken. Das Tool zeigte mir für jede Änderung einen Diff und fragte um Erlaubnis. Ich habe sie gelesen. Ich habe sie alle freigegeben.

Darüber sollte man nachdenken, denn die Standardantwort auf all das oben lautet: „Kein Problem, ein Mensch prüft das Ergebnis und übernimmt die Verantwortung.“ Ich war dieser Mensch, ich kannte meine Ziele, ich habe geprüft – sollte ich mich vielleicht selbst aus meinem Testprojekt entlassen? Oder gibt es andere Perspektiven?

Ein Diff ist ein hervorragendes Werkzeug und verdient Besseres, als hier beschuldigt zu werden. Diffs funktionieren am besten, wenn der Umfang einer Änderung eng oder klar definiert ist: Die Auswirkungen sind überwiegend lokal, und die nicht lokalen werden durch eine Coding Convention oder einen fehlschlagenden Test sichtbar gemacht. Auch der Arbeitskreislauf rund um Code und Softwareentwicklung ist sehr eng verzahnt. Diese Faktoren erklären, warum Entwickler AI-Unterstützung so schnell angenommen haben.

Eine Änderung an einer Produktannahme ist nicht auf diese Weise lokal. Ändert einen Satz am Anfang eines Positionierungsdokuments, und die Bedeutung von allem darunter kann sich verändern, obwohl der Text gleich bleibt. Ändert eine Regel in einem Service-Workflow, und die Folge zeigt sich drei Schritte später – in der Journey einer anderen Person. Uns fehlen die Tools und Konventionen, um diese Art von Änderungen zu erkennen, wenn sie von AI vorgenommen werden.

Vielleicht habe ich also nicht unachtsam gelesen. Ich suchte nach dem richtigen Objekt, aber in der falschen Form. Ich las die Worte und übersah die Bedeutung. Die Menge erledigt den Rest. 

Dieses Experiment haben wir außerhalb von AI schon mehrfach durchgeführt, und wir wissen, wie es endet. Frühe Virenscanner meldeten alles, was sie taten, weil Nutzer „wissen mussten, dass Sicherheit stattfindet“. Stattdessen lernten die Nutzer den Reflex, die Dialoge wegzuklicken – einschließlich des ungewöhnlichen Dialogs, der wichtig gewesen wäre. Webwerbung vermittelte dieselbe Lektion umgekehrt: Gebt etwas die Form eines Banners, und Menschen sehen es nicht mehr. Die Forschung zu menschlichen Faktoren sagt das seit Jahren über Automatisierung: Parasuraman und Manzey stellten fest, dass Automatisierungsbias und Selbstzufriedenheit von der Person, der Situation und dem System abhängen und dass Anweisungen und Schulungen allein sie nicht beseitigen. Die AI-Risikoleitlinien von NIST fordern Teams daher auf, zu untersuchen, wie Ergebnisse *präsentiert* werden, und Expertise zu menschlichen Faktoren einzubeziehen.

Quellen:

Parasuraman & Manzey: Selbstzufriedenheit und Bias bei der menschlichen Nutzung von Automatisierung: Eine aufmerksamkeitstheoretische Integration

NISTs Leitlinien zu AI-Risiken

All das bedeutet nicht, dass Menschen unachtsam sind oder das Review fehlgeschlagen ist und sie neu geschult werden müssen. Vielmehr wurde die Aufgabe für andere Inhalte und einen anderen Beruf konzipiert.

Wie Designagenturen mit AI arbeiten

Meine Erfahrung ist kein Einzelfall. Die großen Designfirmen diskutieren längst nicht mehr darüber, ob Generierung im Produktdesign und bei Aufgaben von Wissensarbeitern nützlich ist. Sie haben sich genau diesem neuen Terrain zugewandt. Designit hat für Repsol ein gemeinsames Framework für AI-Erlebnisse entwickelt, das Interaktionsprinzipien in wiederverwendbare Mensch-AI-Muster überführt, damit „Teams nicht mehr bei null anfangen“. Der Leitfaden für agentische AI von frog schreibt Leitplanken, Verifizierungspunkte, Eskalationsregeln, Agenten mit „der minimalen Autorität, die zur Erledigung der Aufgabe erforderlich ist“, sowie eine kontinuierliche statt einmalige Evaluierung vor. Und IDEO hat „The case against AI-generated users“ veröffentlicht und warnt davor, dass oberflächliche, generische und emotionslose „Daten“ in das Kundenverständnis einfließen.

Also: Kodiert euren Kontext, steuert den Kreislauf und hört auf, Prompts zu zählen. Ich stimme ihnen zu, sehe aber eine fehlende Perspektive: die tägliche Arbeit und die Änderungen im Workflow, die nötig sind, um die gewünschte Richtung beizubehalten.

Referenzen: Designit entwickelte Repsol und frogs Playbook für agentische AI

Quellen: IDEO: Argumente gegen AI-generierte Nutzer

Für Designer: Dokumentiert für AI, was unverändert bleiben muss

Die sinnvolle Ausgangsbasis ist klein: Die Design- und Produktregeln, einschließlich der Bereiche, in denen sie *nicht* gelten, sollten dem Agenten, der an der Aufgabe arbeitet, immer zur Verfügung stehen. Annahmen hinter einer Journey sollten mit den Screens und Verhaltensweisen verknüpft sein, die von ihnen abhängen – ebenso wie Beispiele für akzeptable und nicht akzeptable Ergebnisse und all die wichtigen Details, die früher zwischen den Swimlanes verloren gingen. 

Das ist keine Aufgabe für einen „einzigen Prompt“. Ein Agent folgt veralteten Absichten mit genau derselben Sicherheit wie aktuellen. Eine große Datei ist der falsche Ansatz, denn Marke, Produktvision, Service Journeys, Content und Interaktionsmuster haben unterschiedliche Verantwortliche und ändern sich unterschiedlich schnell. All das bei jedem LLM-Aufruf mitzusenden, kostet Tokens und begräbt die relevante Anweisung. 

Stattdessen experimentiere ich mit einem Index – etwas, das den Agenten bei Bedarf zu „Widgets → Buttons → Switch“ führt und nicht früher. Die Struktur ist weniger wichtig als das Prinzip: die kleinste relevante Absicht genau dann, wenn sie gilt. Einschränkungen? Das muss gepflegt werden. Ihr müsst euch also in Confluence und Jira an der Planung beteiligen und während der Entwicklungsphase die entsprechenden Änderungen in GitHub vornehmen.

Für Manager: Gestaltet die Arbeit der Menschen genauso sorgfältig wie den Prompt

Produktabsichten zu dokumentieren, reduziert Abweichungen, und die Wirkung dieser Absichten zu überwachen, hilft dabei, Ziele beizubehalten. Doch Abweichungen brauchen eine Prüfoberfläche, die auf die Fachdisziplin der prüfenden Person zugeschnitten ist.

Der Designer muss Teil des Produktteams sein. Er muss Veränderungen am visuellen Modell und am Service-Modell in seinem eigenen Kontext sehen können. Zeigt einem Service Designer die veränderte Annahme und die davon abhängigen Journeys. Zeigt einem Product Owner das Ziel, die Evidenz und den Zielkonflikt. 

Lasst die Umgebung die üblichen technischen Grenzen selbst durchsetzen – einen Designer zu bitten, einen unbekannten Shell-Befehl zu genehmigen, macht ihn nicht zum Security Reviewer. Das ist Rauschen, das ermüdet und ablenkt. Einen Product Manager zu bitten, einen Text-Diff zu genehmigen, bedeutet nicht, dass er die Änderung am Produkt genehmigt hat.

Das ist eine gemeinsame Aufgabe für Design-, Entwicklungs- und Platform Engineering-Teams. Und sie erfordert eines von den Verantwortlichen für die Pipeline: Personen in anderen Rollen als Entwickler brauchen Zugang zum tatsächlichen AI-gestützten Workflow, nicht nur zu dessen Endergebnis – und die Befugnis, ihn anzupassen, anzuhalten oder abzulehnen.

Wählt einen Workflow aus, in dem Menschen häufig AI-Ergebnisse genehmigen, nachvollziehen oder korrigieren müssen. Fragt jeden Reviewer, was er tatsächlich verstehen muss, um zustimmen zu können. Richtet die Prüfung an dieser Antwort aus und messt, ob sie tatsächlich etwas erkennt.

AI wird bei der Erstellung von Arbeitsergebnissen immer besser werden. Die Tools jeder Rolle auf dem aktuellen Stand zu halten, ist kein Designer-Problem, sondern ein Pipeline-Problem. Um AI-Abweichungen zu beheben, müssen [Platform Engineering-Teams](https://www.eficode.com/software-tooling/platform-engineering) Prüfoberflächen entwickeln, die Product Ownern ermöglichen, AI-Änderungen im Kontext zu sehen – nicht nur in Text-Diffs.