Zombie-UI: Wie man verhindert, dass KI das gleiche Interface baut wie alle anderen

Dreiköpfige Teams können heute leisten, wofür früher 30 Personen nötig waren. Dieser Artikel vermittelt die vier Schritte, um gegen die negativen Folgen dieser Entwicklung anzusteuern: eine klare Haltung (Point of View), in die Maschine einprogrammierte Standards, ein Editor, der "fertig" nicht mit "gut" verwechselt, und ein Budget für das Ungewöhnliche.

Der zweite Bauboom und wie ein Stil zu Zombies wird

Direkt nach dem Zweiten Weltkrieg erlebte die Welt einen Bauboom, laut dem Vortrag den größten der Geschichte. Die Baumeister griffen auf den Modernismus der 1920er Jahre zurück: einfache Geometrien, saubere, kahle Oberflächen, monochrome Farbpaletten, keinerlei Verzierungen. Angetrieben von der Dringlichkeit zu bauen und neuen Konstruktionsmethoden, wurde dieser Stil immer wieder ohne echte Intention kopiert. Der Vortrag bezeichnet das Resultat als Zombie-Gebäude – Bauwerke, die zwar stehen und funktionieren, sich aber durch absolut nichts voneinander unterscheiden.

Ein Stil ist eine Reihe von Antworten auf spezifische Probleme, und wer ihn kopiert, ohne diese Probleme zu haben, übernimmt nur die Oberfläche. Auf diese Weise kopiert, passten die Muster bald nicht mehr zu den Orten und Menschen, für die sie gebaut wurden.

Das berühmteste Opfer dieser Ära zeigt, warum man mit dieser Lektion vorsichtig umgehen muss. Pruitt-Igoe in St. Louis wurde 1951 vom Architectural Forum als das beste Hochhaus-Apartment-Projekt des Jahres gefeiert, 1972 begann sein Abriss, und es wird bis heute oft als Paradebeispiel für das Scheitern modernistischen Designs zitiert. Charles Jencks ging sogar so weit, den Tod der modernen Architektur auf die Sprengung dieser Wohnblöcke am 15. Juli 1972 zu datieren. Historiker haben seitdem argumentiert, dass Bau und Verwaltung von tief verwurzelten wirtschaftlichen und politischen Bedingungen geprägt waren und dass es die Aufmerksamkeit von diesen institutionellen Ursachen ablenkt, wenn man den Designern die Schuld gibt.

Die zentrale These des Vortrags lautet, dass wir uns jetzt in einem weiteren Bauboom befinden: dem KI-Bauboom. Ein Unternehmen kann heute 20 Ideen in einer Woche umsetzen. Die Zombie-UI ist der digitale Zwilling des Zombie-Gebäudes: ein Interface, das aus den wahrscheinlichsten Mustern zusammengesetzt wird, an der Oberfläche kompetent wirkt und mit jedem anderen Produkt austauschbar ist, das auf dieselbe Weise entwickelt wurde. Forschungen zu KI-generierten Interfaces zeigen bereits deren Konturen: Tools, die grundlegende Barrierefreiheits-Standards (Accessibility) erreichen, sich dabei aber auf stark homogenisierte Designmuster stützen.

Der Drang zum Durchschnitt: Language Models sind extrem gut darin, die wahrscheinlichste Antwort zu liefern – und das wahrscheinlichste Interface ist eben der Durchschnitt. Der Drang zum "Fertig"-Zustand: KI lässt Dinge sehr schnell fertig aussehen, allzu oft jedoch verfrüht. Der Drang zum Wegwerfprodukt: Die Arbeit geht so schnell, dass sie sich entbehrlich anfühlt und, schlimmer noch, auch so behandelt wird.

Jeder dieser Tendenzen benötigt ein eigenes Gegengewicht. Der Vortrag rahmt das Ergebnis als bewusste Entscheidung: Dieser Boom kann die digitalen Zombies überspringen und zu einer kreativen Renaissance werden.

Warum KI-Output zum Durchschnitt tendiert – und warum bessere Prompts das nicht beheben

Abbildung 1. Die drei strukturellen Tendenzen, die KI-Output in Richtung Zombie-UI drücken. Jede erfordert ein eigenes Gegengewicht.

Ein Large Language Model, oder LLM, ist darauf trainiert, vorherzusagen, was als Nächstes kommt. Es lernt also, den Fortsetzungen, die es am häufigsten gesehen hat, eine hohe Wahrscheinlichkeit zuzuweisen. Genau in diesem Sinne sind LLMs wirklich gut darin, die wahrscheinlichste Antwort zu geben.

Forscher nennen diese Verengung generative Monokultur: ein signifikanter Rückgang der Output-Diversität im Vergleich zu den Trainingsdaten, wie beispielsweise die ausschließliche Produktion positiver Rezensionen für Bücher, die eigentlich gemischt aufgenommen wurden. Eine andere Forschungsrichtung führt einen Teil der Ursache auf den Typicality Bias zurück: Menschen, die Modellausgaben bewerten, bevorzugen systematisch vertraute Texte. Formatvorlagen erzeugen zusätzlichen Druck, und eine Studie ergab, dass der daraus resultierende Kollaps der Diversität selbst bei High-Temperature Sampling bestehen bleibt. Bei 14 Language Models stellte ein weiteres Team fest, dass sich die Wahrscheinlichkeitsmasse (Probability Mass) übermäßig auf wenige gültige Fortsetzungen konzentriert.

Eine systematische Überprüfung von LLMs im UI- und UX-Design stellt die Abhängigkeit von generischen oder konservativen Mustern fest und warnt davor, dass Designer sich zu früh an KI-Vorschlägen verankern (Anchoring), was ihre Ideenfindung einschränkt. Eine Evaluierung KI-generierter Screens fand einen attraktiven visuellen Feinschliff – direkt neben falschen Wörtern, unleserlichen Labels und fehlendem interaktivem Feedback. Praktiker, die ein Tool für generative UIs testeten, berichteten, dass es Schwierigkeiten hatte, das Bindegewebe zwischen den Screens aufrechtzuerhalten: konsistente Stile, gemeinsames Layout, ein kohärenter Flow.

Der zweite Mechanismus ist die Lücke zwischen dem, was man meint, und dem, was man tippt. Das Design-Team von Stripe hat dies direkt beobachtet: Drei verschiedene Personen gaben denselben Prompt ein und erhielten drei völlig unterschiedliche Ergebnisse.

Der dritte Mechanismus liegt beim Reviewer, nicht beim Modell. Das Bild des Vortrags hierfür ist der Mikrowellen-Burrito: 90 Sekunden von "hungrig" bis "Mittagessen" – und diese Geschwindigkeit macht einen bereit, darüber hinwegzusehen, dass er eigentlich kaum genießbar ist. Das ist der Drang zum "Fertig"-Zustand im Kleinen.

Was funktioniert, ist Struktur an drei Punkten: eine klare Haltung (Point of View) im Vorfeld (upstream), in die Tools einprogrammierte Standards, die das Modell zwingend durchlaufen muss, und ein verantwortlicher Editor im Nachgang (downstream). Der Ablauf unten skizziert die Methode, die im Rest dieses Artikels vermittelt wird.

Schritt eins: Eine klare Haltung durch genaues Beobachten aufbauen

Der erste Schritt passiert, bevor überhaupt ein Modell geöffnet wird: Definieren Sie Ihre Marke, was sie für Sie und was sie für Ihre User ist.

Die Haltung von Stripe ist Optimismus, und das Team lässt diese in alle Details einfließen, im Großen wie im Kleinen. Im Vortrag zieht sich dieser Wert durch Farben, Texte, Themen und die Produkte, die verschifft werden, um Unternehmer zu unterstützen.

Eine solche Haltung (Point of View) wird nicht in einem Workshop erfunden; sie wird durch genaues Beobachten aufgebaut. Achten Sie darauf, was Ihre User brauchen und was sie wollen – nicht nur darauf, was sie sagen. Beobachten Sie auch die Welt im Allgemeinen, da Produkte, Kunst und Wissenschaft signalisieren, was als gut, großartig oder mittelmäßig wahrgenommen wird.

Abbildung 2. Die dreistufige Token-Architektur, die sicherstellt, dass KI-Agenten absichtsbasierte Standards befolgen, anstatt anhand von Aussehens-Bezeichnungen zu raten.

Vorlage zum Anpassen: Wir sind [was Sie sind] für [wen]. Wir glauben an [die Überzeugung]. Deshalb tun wir immer [sichtbares Verhalten] und niemals [den wahrscheinlichen Standard, den wir ablehnen].

Schritt zwei: Die eigenen Standards in die Maschine codieren

Die folgenreichste These des Vortrags ist, dass das Designobjekt nicht mehr der Screen ist, sondern das System selbst. Daraus folgt der zweite Schritt: Codieren Sie Ihre Standards fest in die Maschine.

Zunächst lasen die KI-Agenten bei Stripe einfach die Design-Dokumentation, was nicht spezifisch genug war: Drei Personen mit demselben Prompt erhielten noch immer drei unterschiedliche Ergebnisse. Also baute das Team eine CLI (Command-Line Interface) auf Basis seines Designsystems, die als Framework (Harness) fungiert und die KI deutlich gehorsamer macht.

Ein Leitfaden zur Governance von Designsystemen formuliert das Prinzip drastisch: Ein Agent kann keine Wiki-Seite lesen und dann entscheiden, der Namenskonvention zu folgen. Er benötigt Regeln, die als strukturierte Daten mit expliziten Bedingungen, Constraints und Konsequenzen formuliert sind.

Komposition ist genau der Punkt, an dem generative Tools am schwächsten sind. Das stellten auch Praktiker fest, als ein Tool Schwierigkeiten hatte, Stile und Flows über verschiedene Screens hinweg konsistent zu halten.

Aktuelle Best Practices unterteilen dies in Ebenen: Primitives enthalten die Rohwerte, Semantics tragen die Bedeutung, und Components (Komponenten) konsumieren diese semantische Ebene. Benennen Sie nach Absicht (Intent), nicht nach Aussehen: color.blue.500 zwingt zu einem Raten zwischen verschiedenen Blautönen, während color.action.primary die Absicht klar benennt. Im W3C-Design-Tokens-Format ist es das $description-Feld, das einem Agenten sagt, wann er einen bestimmten Token anstelle eines ähnlich aussehenden verwenden soll. Ein agentisches Open-Source-Designsystem formuliert seine absolute Regel so: Primitives werden niemals direkt in Komponenten verwendet.

Wenn Ihre Design-Quelle Figma ist, empfiehlt der offizielle Leitfaden, Komponenten über Code Connect mit Code zu verknüpfen. Das ist der effektivste Weg, um einen Agenten dazu zu bringen, Ihre echten Komponenten wiederzuverwenden; ohne dies muss der Agent raten. Derselbe Leitfaden fordert Variablen für Spacing, Farbe, Eckenradius und Typografie, Ebenennamen, die den Zweck beschreiben, sowie Auto Layout anstelle von absoluter Positionierung.

Eine Umsetzung bietet einen Compliance-Check, der ein Code-Snippet gegen die Design-Regeln validiert und Verstöße zurückmeldet. Eine andere pflegt ein Contract-File neben jeder Komponente und blockiert einen "Design-System-Drift" in der Continuous Integration (CI). Der Erfahrungsbericht eines Entwicklers über einen Designsystem-Agenten machte die CLI zum einzigen Einstiegspunkt und verankerte harte Leitplanken darin: eine Write-Allowlist, keine Shell-Befehle, keine neuen Dependencies.

Doch dieses Codieren hat eine Grenze. Der Vortrag benennt sie mit einem Zitat von Christopher Alexander: Ein System kann jede Regel erfüllen und trotzdem tot sein. Forschungen zu Design-Organisationen teilen diese Sorge: Führungskräfte befürchten, dass Systeme, die Design als das Zusammenbauen vordefinierter Komponenten strukturieren, das Spektrum an "Skills" einschränken könnten, das sie bei Neueinstellungen sehen. Praktiker in einer anderen Studie bewerteten solche Kritik oft als aus dem Kontext gerissen, bekräftigten den Wert von Designsystemen und forderten eine bessere Zusammenarbeit rund um diese.

Schritt drei: Rigoros redigieren und "fertig" nicht mit "gut" verwechseln

Der dritte Schritt hat einen Slogan, den man sich an die Wand hängen sollte: Verwechseln Sie "fertig" nicht mit "gut". Dahinter verbergen sich zwei Gewohnheiten, die sich jedes Team abtrainieren muss: dass "gebaut" gleichbedeutend mit "fertig" ist, und dass "fertig" gleichbedeutend mit "gut" ist.

Die Rolle, die den alten Filter ersetzt, ist die des Editors. Ein Editor übernimmt die Verantwortung für jede Entscheidung, was in vielerlei Hinsicht jeden Pixel einschließt. Der Editor bewertet das End-to-End-Ergebnis so, wie es ein User erlebt, und nicht Screen für Screen, wie es generiert wurde.

Bei Stripe endete ein Crit (Design-Kritik) einer KI-gestützten Anzeige mit 17 Stichpunkten an Verbesserungen.

Gehen Sie den Flow wie ein User durch, vom ersten Einstiegspunkt bis zur letzten Bestätigung. Notieren Sie sich, wo die Reise bricht, anstatt nur, wo ein Screen etwas seltsam aussieht. Öffnen Sie jeden Zustand (State), den Modelle selten gut zeichnen: leere Zustände (Empty States), Ladebildschirme, Fehlermeldungen, unvollständige Daten, den längsten Namen, den kleinsten Screen. Lesen Sie jedes Wort, denn Auswertungen von KI-generierten Screens finden immer wieder falsche Wörter und unleserliche Labels hinter attraktiven Layouts. Halten Sie dann das Ergebnis gegen Ihre Haltung (Point of View): Würde jemand, der die Marke kennt, sie als die Ihre erkennen, wenn das Logo entfernt wäre?

Vorlage zum Anpassen: Bei [Ort] sehe ich [Beobachtung], was gegen [Prinzip] verstößt, also ändern Sie es in [spezifische Anweisung].

Das Redigieren funktioniert nur, wenn der Editor Arbeiten stoppen kann, die bereits gebaut sind. Ernennen Sie einen Editor pro Bereich, geben Sie dieser Person das ausdrückliche Recht, einen Release zu blockieren, und machen Sie das Blockieren zur Routine, damit es als normale Praxis und nicht als persönliches Veto verstanden wird.

Der Schritt, den die meisten Teams überspringen, ist das Schließen des Kreises zwischen Redigieren und Codieren. Jede Anmerkung, die in zwei Crits auftaucht, ist eine Regel, die nur darauf wartet, ins System geschrieben zu werden. So summiert sich das Urteilsvermögen des Editors (Compounding Effect), anstatt bei jedem Screen neu aufgewendet werden zu müssen. Leitfäden zur Governance vollziehen denselben Schritt von der anderen Seite: Inventarisieren Sie die Regeln, die bereits in Contribution Guidelines, Linter-Configs, Review-Checklisten und Decision Records existieren, und drücken Sie dann jede als maschinell überprüfbaren Constraint aus. Im Laufe der Zeit absorbiert das Framework die Routineentscheidungen und gibt den Editor frei für die Dinge, die nur Geschmack und Urteilsvermögen entscheiden können.

🛠 Anleitung — Wie man einen Design-Standard baut, dem ein KI-Agent gehorcht, und ein Edit-Gate, das "Fertig-aber-nicht-gut" blockiert

1. Inventarisieren Sie die Regeln, die bereits existieren und wo sie leben: Contribution Guidelines, Linter-Configs, Figma-Namenskonventionen, Hinweise zur Token-Nutzung, Pull-Request-Checklisten und Decision Records.
2. Strukturieren Sie Tokens in eine Primitive-Ebene mit Rohwerten und eine semantische Ebene, die nach Absicht (Intent) benannt ist. Richten Sie jede Komponente auf die semantische Ebene aus und geben Sie jedem semantischen Token eine einzeilige Beschreibung, wann er zu verwenden ist.
3. Verbinden Sie Ihre Figma-Komponenten über Code Connect mit Code, damit der Agent echte Komponenten wiederverwendet anstatt zu raten.
4. Wenn Sie eine vorgefertigte Contract-Ebene einsetzen, initialisieren Sie diese in Ihrem Repository; Fragments z. B. erkennt Ihr Framework und schreibt den Contract mit einem einzigen Befehl. npx @usefragments/cli init
5. Blockieren Sie Design-System-Drift in der Continuous Integration (CI), sodass systemabweichender Output fehlschlägt, bevor er das Review erreicht. fragments check --changed --ci

Schritt vier: Die Ersparnisse in das Ungewöhnliche investieren

Wie der Vortrag es formuliert: KI kann uns helfen, Monotonie herzustellen, aber sie ist auch der größte kreative Katalysator, den wir je hatten. Das Motto lautet: Schützt das Ungewöhnliche. KI senkt die Kreationskosten, also sollte ein Teil der Ersparnisse in ungewöhnliche Arbeit fließen.

Wenn jeder Versuch teuer ist, streichen Teams rationalerweise die merkwürdigen Ideen zuerst, da deren Ertrag ungewiss und die Kosten gewiss sind. Wenn Versuche billig werden, kehrt sich diese Logik um: Varianz wird erschwinglich, und die ungewöhnliche Option verdient sich in jeder Runde einen Platz.

Das Beispiel des Vortrags dafür ist die Eröffnungsanimation eines Events.

Das Hindernis für Ungewöhnliches ist nicht nur das Modell, sondern die Fixierung der Menschen, die es nutzen – ein Phänomen, das Forscher in der generativen KI noch immer als untererforscht bezeichnen.

Bitten Sie das Modell also um eine Bandbreite, nicht um eine Antwort. Verbalized Sampling, eine trainingsfreie Prompting-Strategie, bittet das Modell um mehrere Antworten samt ihrer Wahrscheinlichkeiten. Das nimmt den Druck, die eine, typische Antwort produzieren zu müssen. Im kreativen Schreiben erhöhte dies die Diversität im Vergleich zu direktem Prompting um das 1,6- bis 2,1-Fache.

Vorlage zum Anpassen: Gib mir fünf Richtungen für diesen Onboarding-Screen. Gib für jede an, wie wahrscheinlich es wäre, dass ein typisches Produkt-Team sie veröffentlicht, und sorge dafür, dass mindestens zwei davon Richtungen sind, die ein typisches Team niemals wählen würde.

Abbildung 3. Gutenbergs 290 Letternvarianten und Ruskins sich nicht wiederholende Säulen teilen dasselbe Prinzip: Sinnvolle Variation wird in das System integriert, nicht dem Zufall überlassen.

Die Spannung mit Schritt zwei ist real: Ein Framework, das KI gehorsam machen soll, zieht in die exakt entgegengesetzte Richtung wie eine Spur, die darauf ausgelegt ist, KI ungewöhnlich zu machen. Nennen wir die Lösung "zwei Spuren": Eine System-Spur (System Lane), in der das Framework Navigation, Formulare, Einstellungen und jeden Flow regelt, den User berechenbar brauchen. Und eine Ausdrucks-Spur (Expression Lane), in der die Marke spricht – gebunden an die Haltung (Point of View) und den Maßstab des Editors, anstatt an Templates. Eine Studie über Designsysteme merkt an, dass deren Einschränkungen der Kreativität auch ein Vorteil sein können, da sie Designern erlauben, bei Problemen, die das System nicht löst, umso kreativer zu werden.

Handwerkslektionen von Gutenberg und Ruskin: Wo Variation lebt

Die Geschichte des Buchdrucks wird oft als eine Geschichte der Geschwindigkeit erzählt, aber für jeden, der mit KI baut, ist der nützlichere Teil das System, das Gutenberg rund um seine Maschine aufbaute. Seine Skalierungsmaschine war ein Handgießinstrument, mit dem Hunderte oder Tausende von Lettern aus einer einzigen Matrize gegossen werden konnten.

Für seine Bibel schuf Gutenberg 290 einzigartige Zeichen, darunter verschiedene Breiten, Abkürzungen und Ligaturen. Etwa 60 Zeichen hätten ausgereicht, um den Text zu setzen, wenn die Vermeidung breiter Wortabstände nicht das Ziel gewesen wäre. Der Schriftgestalter Hermann Zapf identifizierte das Geheimnis später als die gleichmäßige Grauwirkung der Spalten, ohne störend große Löcher zwischen den Wörtern.

Das Detail ist entscheidend: Die meisten dieser zusätzlichen Zeichen waren Ligaturen und Abkürzungen, während die Anzahl der Einzelzeichen mit unterschiedlichen Breiten gering war. Selbst für denselben Buchstaben goss er mehrere Lettern, jede mit einem leicht unterschiedlichen Design.

John Ruskin ging dasselbe Problem von der entgegengesetzten Seite an, als er 1850 über Qualität und Handwerk schrieb und die gotische Architektur als Inbegriff des Großartigen hervorhob. Er bemerkte, dass kein gotisches Gebäude dem anderen glich und dass nicht einmal eine Säule mit einer anderen übereinstimmte. Auf die Frage, ob man Gotik bauen könne, indem man Gebäude mit Dreipässen (Trefoils) überzieht, antwortete er mit Nein – genauso wenig, wie ein Kind Latein schreiben könne, indem es zufällig Wörter aus Cicero kopiert.

In The Nature of Gothic ordnete Ruskin die moralischen Elemente des Stils als Wildheit (Savageness), Veränderlichkeit (Changefulness), Naturalismus, Groteskheit, Starrheit (Rigidity) und Überfluss (Redundance) ein. Aus der Sicht des Baumeisters betrachtet, formulierte er sie um als Grobheit, Liebe zur Veränderung, Liebe zur Natur, gestörte Vorstellungskraft, Eigensinn und Großzügigkeit.

Fehler, die ein gutes System in eine Zombie-Fabrik verwandeln

Der erste Fehler ist ein separater, niedrigerer Maßstab für KI-generierte Arbeit. Ein funktionsübergreifender Partner, der schnell "shippen" wollte, fragte einmal treffend: Was ist eigentlich der Qualitätsstandard für etwas, das mit KI gemacht wurde? Die einzige Antwort, die Bestand hat, ist, dass am Ende des Tages der Output zählt: Usern ist wichtig, ob es gut ist – und das sollte den Entwicklern auch wichtig sein.

Der zweite Fehler ist es, Regelkonformität mit Qualität gleichzusetzen, wovor Christopher Alexander warnte, als er sagte, ein System könne jede Regel erfüllen und trotzdem tot sein. Eine Studie über neunzig Interfaces, die von zwei KI-Tools in drei Anwendungsbereichen generiert wurden, zeigt diese Falle in der Praxis. Die Tools erreichten konsequent grundlegende Accessibility-Standards, stützten sich jedoch auf homogenisierte Designmuster, die einschränkten, wie gut sie spezialisierte Nutzerbedürfnisse erfüllten.

Die Forscher zählten 178 Instanzen, in denen Teilnehmer Anforderungen ohne Fragen akzeptierten, und 41 Fälle, in denen Paare neue Ideen ablehnten, weil sie von den anfänglichen abwichen.

Praktiker, die zu dieser Kritik befragt wurden, empfanden sie oft als fehlgeleitet oder aus dem Kontext gerissen und bekräftigten den Wert von Designsystemen. Eine andere Studie merkt an, dass diese Einschränkung ein Vorteil sein kann, weil sie Designer befreit, bei Problemen, die das System nicht löst, kreativer zu werden. Design-Führungskräfte beschreiben dennoch ein echtes Spannungsfeld: Sie sind angewiesen auf Menschen, die innerhalb der Systemgrenzen arbeiten, schätzen aber bei Neueinstellungen diejenigen, die Annahmen hinterfragen und unerwartete Lösungen vorschlagen.

Abbildung 4. Die zwei möglichen Enden des KI-Baubooms und die vier sichtbaren Gewohnheiten, die ein Renaissance-Team von einer Zombie-Fabrik unterscheiden.

Pruitt-Igoe, das Wohnprojekt in St. Louis, das oft als das Scheitern von modernistischem Design zitiert wird, wurde vom Architectural Forum als bestes Hochhausprojekt 1951 gefeiert, sein Abriss begann 1972. Historiker argumentieren, dass es primär kein Designfehler war: Wirtschaftliche und politische Bedingungen, öffentliche Politik und der Niedergang der Stadt bestimmten sein Schicksal.

Vorlage zum Anpassen: Bevor etwas veröffentlicht wird, beantwortet der Editor schriftlich drei Fragen: Würde ein User dies der am besten gestalteten Alternative vorziehen? Was genau hierbei könnte nur von uns stammen? Und wem gehört es in sechs Monaten? Wenn auch nur eine Antwort leer bleibt, ist die Arbeit vielleicht gebaut, aber noch nicht fertig.

Die Wahl einer kreativen Renaissance statt Zombie-UI

Wir befinden uns in einem weiteren Bauboom, dem KI-Bauboom, und die Wahl, vor der wir stehen, ist, ob wir das digitale Äquivalent von Zombie-Gebäuden erschaffen oder eine kreative Renaissance auslösen. Die Geschichte hält beide Ausgänge bereit, was die Entscheidung sehr real und nicht nur rhetorisch macht.

Das Designobjekt ist nicht mehr der Screen, sondern das System selbst. Deshalb wird die Entscheidung "upstream" (im Vorfeld) getroffen: in der Haltung (Point of View) und den codierten Standards, lange bevor jemand einen einzigen Screen überprüft.

Die Leitplanke am anderen Ende ist ein einziger Satz: Verwechsle "fertig" nicht mit "gut". Er funktioniert, weil er einem Editor die Erlaubnis gibt, Arbeit zu stoppen, die bereits fertig aussieht – genau der Moment, in dem die KI es einem am verlockendsten macht, Dinge durchzuwinken.

Ein Team, das sich für die Renaissance entscheidet, hat vier sichtbare Gewohnheiten: eine schriftlich fixierte Haltung, ein System, das Templates und Flows statt Einzelteilen ausliefert, einen Editor mit der Autorität, "noch nicht" zu sagen, und ein geschütztes Budget für ungewöhnliche Arbeit. Gutenberg gab seine Ersparnisse für Lettern aus, die maschinengeschriebene Seiten dem Handwerk würdig machten, und Ruskin lobte Baumeister, deren Säulen sich schlicht weigerten, sich zu wiederholen.

Kernaussagen

• Der KI-Bauboom wiederholt das Muster der Nachkriegszeit: Ohne Intention kopierte Formen produzieren Zombie-UI.
• Definieren Sie eine Haltung (Point of View), aufgebaut durch das Beobachten von Verhalten, bevor auch nur ein Modell die Arbeit berührt.
• Designen Sie das System, nicht den Screen: Codieren Sie Tokens, Templates und Flows in ein Framework (Harness), das die KI passieren muss.
• "Gebaut" ist nicht "fertig" und "fertig" ist nicht "gut": Ein Editor verantwortet jede Entscheidung, bis auf den Pixel genau.
• Investieren Sie einen Teil dessen, was die KI einspart, in ungewöhnliche Arbeit, auf einer eigenen Spur, aber gemessen am selben redaktionellen Maßstab.

Aktionsplan

1. Machen Sie den Konsistenztest: drei Personen, ein Prompt, Ihr aktuelles KI-Setup, und vergleichen Sie die Ergebnisse Seite an Seite.
2. Wählen Sie eine schriftliche Regel aus Ihren Guidelines und codieren Sie sie als maschinell überprüfbaren Constraint, den Ihre CI oder Ihr Agent ausführt.
3. Benennen Sie Ihre semantischen Tokens nach Absicht (Intent) um und geben Sie jedem eine einzeilige Beschreibung, wann er zu nutzen ist.
4. Ernennen Sie einen Editor für Ihren nächsten KI-gestützten Release, geben Sie ihm das Recht, ihn zu blockieren, und führen Sie ein Crit (Design-Review) durch, das in schriftlichen Anweisungen endet.

Testen Sie sich selbst

F. Warum kann man generischen KI-Output nicht einfach dadurch beheben, indem man die "Temperature" erhöht oder den Prompt umformuliert?
A. Forschungen zeigen, dass der Diversitäts-Kollaps selbst bei High-Temperature Sampling bestehen bleibt und einfache Änderungen am Sampling oder Prompting nicht ausreichen, da die Verengung wahrscheinlich im Alignment verwurzelt ist.

F. Was ist der Unterschied zwischen der Dokumentation einer Designregel und ihrer Codierung?
A. Dokumentation erklärt die Absicht in Worten, denen ein Agent eventuell nicht folgt. Eine Codierung drückt die Regel als strukturierte Daten mit Bedingungen, Constraints und Konsequenzen aus, die Agenten, Linter und CI automatisiert prüfen können.

F. Warum sollte man einen Token color.action.primary nennen anstatt color.blue.500?
A. Ein Agent liest den Namen, bevor er einen Token wählt: Ein Intent-Name gibt an, wofür der Token gedacht ist, während ein Aussehens-Name zu einem Raten zwischen ähnlich aussehenden Tokens zwingt.

F. Wovor warnt die Geschichte von Pruitt-Igoe Produktteams?
A. Davor, der Form allein die Schuld zu geben: Historiker argumentieren, dass das Scheitern von wirtschaftlichen, politischen und institutionellen Bedingungen geprägt war und das modernistische Design nur ein Faktor unter vielen war.

Offene Fragen

• Wer sollte in einer Organisation die Rolle des Editors übernehmen, und mit welcher Befugnis, bereits gebaute Arbeit zu stoppen?
• Wie können dreiköpfige Teams Zeit für akribisches Handwerk finden, wenn Geschwindigkeit genau der Grund ist, warum sie überhaupt konkurrenzfähig sind?
• Wer wartet langfristig das große Volumen an schnell gebauten, KI-generierten Produkten?
• Wie lässt sich das Schützen des Ungewöhnlichen mit der Markenkonsistenz vereinbaren, die das Framework eines Designsystems erzwingt?
• Wenn die Verengung des Modell-Outputs im Alignment verwurzelt ist, werden dann Fine-Tuning-Methoden kommen, die Diversität erhalten, und was werden sie für die Design-Arbeit ändern?
• Schränken Designsysteme die kreativen Skills ein, die in der Design-Profession entwickelt werden, wie einige Design-Leiter befürchten?

Vertiefende Informationen

1. Good Accessibility, Handcuffed Creativity: AI-Generated UIs Between Accessibility Guidelines and Practitioners’ Expectations | Proceedings of the 2025 ACM Designing Interactive Systems Conference — Eine Studie über neunzig KI-generierte Interfaces, die grundlegende Accessibility-Konformität neben homogenisierten Designmustern zeigt.
2. Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity — Das Paper zum Verbalized Sampling: Warum ausgerichtete Modelle (Aligned Models) zu typischen Antworten kollabieren, und ein trainingsfreier Prompt, der Diversität wiederherstellt.
3. skills/governance-encoder/SKILL.md — Ein Schritt-für-Schritt-Skill, um Governance-Regeln von Designsystemen in maschinell überprüfbare Constraints für KI-Agenten zu verwandeln.
4. How to structure your design system for AI: tokens, naming, LLM-readable docs | DesignSystems.one — Konkrete Leitlinien zur Schichtung von Tokens, Intent-basierter Benennung und zum Schreiben von Beschreibungen, nach denen ein Agent handeln kann.
5. MCP server best practices – Figma Learn - Help Center — Figmas Best Practices für die Strukturierung von Dateien, damit ein Agent echte Komponenten und Variablen wiederverwendet.
6. InDesign, the hz-program and Gutenberg's secret — Wie Gutenberg 290 Zeichen, hauptsächlich Ligaturen und Abkürzungen, nutzte, um seinen gleichmäßigen Blocksatz zu erreichen.
7. The Nature of Gothic and Modern Oblivion | Church Life Journal | University of Notre Dame — Ruskins eigene Liste der charakteristischen Elemente der Gotik, von Wildheit bis Überfluss.
8. Why Did Pruitt-Igoe Fail? — Ein kurzer Bericht darüber, warum Pruitt-Igoe scheiterte, jenseits der populären Erzählung, die seiner modernistischen Architektur die Schuld gibt.