Öffnen Sie irgendeine Banking-App und zählen Sie die Screens, die Sie nie benutzen. Der Rechnungsteilen-Flow, der Investment-Tab, das Prämien-Karussell, das Ding, das Ihnen einen Kredit anbietet. Jemand hat das alles ausgeliefert — und für den einzelnen Nutzer ist das meiste davon Möblierung.
Generative UI ist das Argument, dass dieses Problem lösbar ist — dass der Screen für die Person zusammengebaut werden sollte, die ihn öffnet, statt einmal für alle entworfen.
Was das nicht ist
Der Begriff wird für zwei völlig verschiedene Dinge verwendet, und die Vermischung verschwendet viele Meetings.
Das erste ist Design-Tooling: einen Screen beschreiben, ein Mockup oder Code bekommen. Das ist generatives Design. Es passiert vor der Auslieferung, ein Mensch prüft das Ergebnis, und die App selbst ist so statisch wie eh und je. Genuin nützlich — nicht das Thema dieses Artikels.
Generative UI heisst: Die Oberfläche wird zur Laufzeit zusammengebaut. Die App entscheidet, während der Nutzer sie in der Hand hält, welche Komponenten sie zeigt, in welcher Reihenfolge, mit welchem Inhalt — basierend darauf, wer er ist und was er offenbar erreichen will. Kein Designer hat diese konkrete Anordnung freigegeben, denn diese konkrete Anordnung existierte vor drei Sekunden noch nicht.
Diese Unterscheidung ist der ganze Grund, warum das Thema umstritten ist.
Warum das plötzlich plausibel ist
Server-driven UI ist alt. Airbnb, Spotify und die meisten grossen E-Commerce-Apps liefern das seit Jahren aus: Der Server sendet eine Liste von Komponententypen mit Daten, der Client rendert sie, und das Layout kann sich ohne App-Store-Release ändern. Das löste das Deployment-Problem — man konnte einen Home-Screen umsortieren, ohne eine Woche auf die Review zu warten.
Was es nie löste, war das Entscheidungsproblem. Jemand musste weiterhin die Regeln schreiben. Zeig das Promo-Banner Nutzern in Segment B im Dezember. Schieb den Nachbestellen-Button hoch für Kunden mit mehr als drei Bestellungen. Jede Regel war handgeschrieben — und die Kombinatorik besiegte ab einem gewissen Punkt jeden.
Sprachmodelle ändern diese Hälfte. Mit einer Beschreibung der vorhandenen Komponenten, dessen, was der Nutzer getan hat, und dessen, was er zu wollen scheint, kann ein Modell ein Layout komponieren, ohne dass jemand die Regel schreibt. Die Rendering-Hälfte — ein Client, der jede empfangene Komponentenliste zeichnet — ist ein gelöstes Problem, das Ihr Team womöglich schon besitzt.
Abb. — Das Modell wählt aus einer Registry, die es nicht überschreiten kann. Zur Renderzeit wird nichts erfunden.
Wo es sich seinen Platz wirklich verdient
Beginnen Sie mit Suche und Discovery, denn dort ist der Nutzen offensichtlich. Eine Anfrage nach «Regenjacke unter 200 Franken» liefert heute ein Raster — weil der Screen nun mal ein Raster ist. Eine generierte Antwort könnte eine Vergleichstabelle der drei besten Treffer liefern, einen Hinweis zu den Grössen und einen Filter-Chip für die geäusserte Preisgrenze. Dieselben Daten, angeordnet für die tatsächlich gestellte Frage.
Support-Flows sind das zweite. Die meiste In-App-Hilfe ist ein Entscheidungsbaum, den jemand 2021 gezeichnet hat. Eine Oberfläche, die die konkreten Schritte für das konkrete Problem zusammenstellt — mit den Bestelldaten des Nutzers bereits eingesetzt — entfernt die Navigation komplett.
Onboarding ist das dritte und das messbarste. Ein neuer Nutzer, der über eine Anzeige zu Spesenerfassung kam, sollte nicht dieselbe Sechs-Karten-Tour sehen wie einer, der wegen Rechnungsstellung kam. Die erste Sitzung an die mitgebrachte Absicht anzupassen ist, wo sich Retention bewegt — und Retention ist, wo das Geld ist.
Was diese Fälle teilen: ein genuin breiter Raum an Nutzerabsichten, und Inhalte, die bereits strukturiert vorliegen. Generative UI schafft keine neue Fähigkeit. Sie ordnet um, was Sie haben.
Die Probleme, die die Demos überspringen
Hier die ehrliche Liste — und der Grund, warum die Verbreitung langsamer ist als der Enthusiasmus.
Testen wird probabilistisch. Ihr QA-Prozess nimmt eine endliche Menge Screens an. Wird der Screen zur Laufzeit komponiert, lassen sie sich nicht aufzählen. Teams landen dabei, die Komponenten-Registry erschöpfend zu testen und die Komposition statistisch — eine echte Veränderung im Denken über Korrektheit, und eine, die manche Organisationen zutiefst unbehaglich macht.
Barrierefreiheit bricht leicht. Ein Screenreader hängt an sinnvoller Lesereihenfolge und aussagekräftigen Labels. Ordnet ein Modell Komponenten um, ändert sich die Lesereihenfolge mit. Jede Komponente braucht ihren Accessibility-Vertrag eingebaut statt pro Screen ergänzt — ohnehin gute Praxis, jetzt aber nicht verhandelbar.
Latenz ist unbarmherzig. Nutzer tolerieren einen Spinner bei einem Netzwerkabruf. Sie tolerieren keinen, bevor die Oberfläche existiert. Praktische Deployments rendern sofort ein schnelles Standard-Layout und lassen die generierte Version es ersetzen oder verfeinern — was heisst: beide Pfade bauen.
Konsistenz erodiert leise. Ihr Designsystem existiert, damit die App sich wie ein Produkt anfühlt. Eine Kompositions-Engine, die jeden Screen lokal optimiert, produziert bereitwillig einen stimmigen Screen, der sich anfühlt wie ein anderes Produkt als der vorige. Constraints müssen kodiert werden — diese Komponente nie über jener, nie mehr als zwei Calls-to-Action — und diese Constraint-Schicht ist der Grossteil der Ingenieursarbeit.
Debugging ändert die Form. Meldet ein Nutzer, dass etwas falsch aussah, müssen Sie rekonstruieren, was er sah. Das heisst: die Kompositionsentscheidung, ihre Eingaben und das gerenderte Ergebnis für jede Sitzung loggen, die Sie erklären können müssen. Speicher- und Datenschutzfragen folgen sofort.
Wer entscheidet, was gut aussieht
Unter dem technischen Problem liegt ein organisatorisches — und es taucht ungefähr drei Wochen nach jedem ernsthaften Versuch auf.
Designer sind gewohnt, Screens zu besitzen. In einem generativen System besitzen sie Komponenten, Constraints und die Definition einer guten Komposition — ein genuin anderer Job, näher am Schreiben einer Grammatik als am Zeichnen eines Layouts. Manche Designer finden das befreiend. Andere weisen zu Recht darauf hin, dass sie nicht mehr aufs Produkt schauen und wissen können, was Nutzer sehen — was bisher die gesamte Grundlage ihres Handwerks war.
Produktmanager treffen dieselbe Wand von der anderen Seite. Abnahme hiess bisher, eine Figma-Datei zu prüfen. Jetzt heisst es, einen Raum möglicher Ausgaben zu prüfen — was durch Hinschauen nicht geht. Teams, die das gut lösen, bauen eine Galerie-Ansicht: ein Werkzeug, das hundert gesampelte Kompositionen aus echten Nutzerkontexten rendert, damit ein Mensch vor der Auslieferung nach Peinlichem scannen kann.
Bauen Sie dieses Werkzeug früh. Jedes Team, das es überspringt, baut es später — nachdem etwas rausging, das niemand je gesehen hatte.
Was es wirklich kostet
Die Komponenten-Registry ist das eigentliche Projekt. Jedes Element, das das Modell platzieren darf, muss genuin in sich geschlossen sein — keine Annahmen darüber, was darüber sitzt, kein Layout, das bei unerwarteter Breite bricht, vollständige Accessibility-Metadaten, vernünftiges Verhalten bei fehlenden Daten. Die meisten bestehenden Komponentenbibliotheken sind das nicht. Es sind Komponenten, die an den Stellen funktionieren, an denen sie gerade verwendet werden.
Budgetieren Sie auch das Constraint-System, denn dort wohnt die Qualität. Und budgetieren Sie die Inferenz: ein Modellaufruf pro Screen-Komposition ist ein Pro-Sitzung-Kostenpunkt, der mit dem Engagement skaliert — eine ungewöhnliche und leicht unbequeme Form für die Ökonomie einer Mobile-App.
Die Teams, die das erfolgreich machen, generieren Layouts für eine Handvoll hochwertiger Flächen — nicht für die ganze App. Einstellungs-Screens brauchen das nicht. Der Checkout auch nicht: Dort ist Berechenbarkeit mehr wert als Relevanz.
Anfangen, ohne die App zu verwetten
Wählen Sie eine Fläche, auf der Nutzerabsichten wirklich variieren — Suchergebnisse, der Home-Feed, der Hilfe-Flow. Bauen Sie die Komponenten-Registry für diese Fläche sauber, mit ernst genommener Barrierefreiheit und Layout-Unabhängigkeit. Liefern Sie hinter einem Flag aus, mit einem statischen Fallback, das rendert, wenn das Modell langsam, nicht erreichbar oder ungültig ist.
Und messen Sie dann das, was zählt — und das ist nicht Engagement. Engagement steigt, wenn Sie irgendetwas umsortieren. Messen Sie Aufgabenabschluss — hat die Person die Jacke gefunden, das Problem gelöst, das Setup beendet — und vergleichen Sie ehrlich gegen das statische Layout.
Ein Wort zum Fallback, denn er entscheidet, ob das den Kontakt mit der Produktion überlebt. Das statische Layout, das Sie zuerst rendern, ist keine degradierte Erfahrung — es ist die Erfahrung für jeden Nutzer, dessen Kompositionsaufruf in den Timeout läuft, jeden mit schlechter Verbindung und jeden während des unvermeidlichen Modell-Ausfalls. Ist der Fallback schlecht, haben Sie eine App gebaut, die gelegentlich schlecht ist — aus Gründen, die Nutzer nicht verstehen können. Entwerfen Sie die statische Version, als wäre sie die einzige, und lassen Sie die generierte sie verbessern.
Die meisten Apps brauchen das noch nicht. Die, die es brauchen, sind die, deren Nutzer mit völlig verschiedenen Zielen ankommen und heute an dem meisten vorbeinavigieren, was Sie gebaut haben, um das eine zu erreichen, wofür sie kamen. Beschreibt das Ihre App, kostet Sie das Möblierungsproblem bereits etwas. Es taucht nur in keinem Dashboard auf — denn niemand beschwert sich über einen Screen, an dem er vorbeigescrollt ist.
