v.zero - Exploring Generative UI as a Scalable System

KI verändert die Art und Weise, wie unsere Geräte denken und arbeiten. Unser Zugang dazu steckt noch in überholten Interfaces. Inhalte liegen in Dateien, Dateien öffnen sich in Apps, Funktionen bleiben darin eingeschlossen. Eine Ordnung, die nicht mehr zu dem passt, was die Technik darunter längst kann.

Generative UI bietet einen möglichen Paradigmenwechsel. Dabei werden Interfaces nicht mehr vorab gestaltet, sondern von einer KI im Moment der Nutzung erzeugt. Das Ziel dieses Projekts ist es, zu untersuchen, wie ein zukünftiges Betriebssystem aussehen könnte, das im Kern auf Generativer UI aufbaut. Dabei haben uns zwei Fragen geleitet: Welche gestalterischen Grundlagen braucht ein GenUI-System, damit es funktioniert und benutzbar ist? Und wie muss ein System drumherum aufgebaut sein, damit generierte Interfaces wirklich navigierbar und sinnvoll sind?

zeroOS

zeroOS denkt das Betriebssystem von seinem Kern her neu. Nicht als Sammlung von Apps, sondern als Spaces, die sich aus Themen und Workflows zusammensetzen. Im Zentrum steht ein Vektor-Embedding: Sämtliche Daten einer Person liegen als Vektoren in einem gemeinsamen Raum, sortiert nach Bedeutung statt nach Herkunft. Was zusammengehört, rückt von selbst zusammen. So weiß das System schon aus seinem Aufbau heraus, was gerade relevant ist, ohne feste Regel und ohne dass jemand danach fragt. Funktionen sind nicht länger in Apps eingeschlossen, sie setzen sich je nach Situation neu zusammen.

Core Spaces

Core Spaces bilden die verlässliche Grundlage von zeroOS. Sechs Bereiche, die abdecken, wofür wir unser Smartphone jeden Tag in die Hand nehmen. Jeder Core Space bündelt Funktionen aus dem ganzen System, unabhängig davon, aus welchem Dienst sie stammen. Conversation etwa bringt Nachrichten, Anrufe und Threads zusammen, egal über welchen Kanal, semantisch neu geordnet statt nach Herkunft getrennt.

Ihre Grundstruktur bleibt fest, denn Core Spaces fungieren als verlässliche Ankerpunkte im Interface. Über eine 2x2-Matrix können Nutzer*innen aber anpassen, wie die Clusterung innerhalb eines Core Space funktioniert.

Emerging Spaces

Emerging Spaces sind das bewegliche Gegenstück. Sie entstehen von selbst, sobald sich genug Daten um eine Situation verdichten, und bündeln, was dazugehört: Gespräche, Dateien, nächste Schritte, über App-Grenzen hinweg. Kommen keine neuen Datenpunkte mehr hinzu, lösen sie sich wieder auf und bleiben über die Historie auffindbar.

Gesten

Das System erlaubt es, Daten aus unterschiedlichen Perspektiven zu betrachten. Skaliert man ein Objekt auf öffnet sich sein Umfeld, der ganze Cluster semantisch verwandter Daten, zu dem es gehört. Zieht man es wieder zu, schließt sich der Kontext.

Visual Design

Ein System, das sich ständig neu zusammensetzt, muss lesbar bleiben. Jede gestalterische Entscheidung in zeroOS folgt darum einem Ziel: das System nachvollziehbar zu machen, statt es als Black Box wirken zu lassen. Wir arbeiten dafür mit den zwei Ebenen. Der Application Layer, die vertraute Oberfläche, liegt immer oben. Darunter der Operating Layer, die Logik, auf der alles aufsetzt. So wird sichtbar, was fest ist und was in Bewegung bleibt.

Sichtbar wird dort eine Punktgrafik, eine abstrakte Darstellung dessen, was im Embedding gerade geschieht. Nähe und Bewegung der Punkte zeigen, wie das System Zusammenhänge liest.

v.zero

Während zeroOS zeigt, wie ein generatives Betriebssystem aussehen kann, beschreibt Version Zero, wie man es aufsetzen könnte. Dafür haben wir untersucht, wie ein solches System aufgebaut sein muss und welche Vorgaben es braucht, damit das Generierte sinnvoll wird. Generative UI ist dabei immer ein Spiel mit Freiraum und Constraints. Zu viel Freiheit, und der Output ist unnutzbar. Zu wenig, und der Mehrwert geht verloren. ZeroOS hält fest, wo aus unserer Erfahrung im Prototyping diese Balance liegt.

Prototyping

Um das zu testen, haben wir Prototypen gebaut. Dabei werden Simulierte Daten aus dem Betriebssystem, Nachrichten, Termine, Kontakte und geteilte Medien, mit pgvector in einer Supabase-Datenbank als Vektoren abgelegt. Trifft ein Auslöser ein, in unserem Prototyp etwa eine neue Nachricht, wird er in denselben Vektorraum eingebettet, und über eine Vector Search werden die semantisch nächsten Objekte abgerufen. Das Ergebnis ist ein Context Blob, ein strukturiertes Paket aus Auslöser und allem, was das System als verbunden einstuft. Im nächsten Schritt werden zwei Dinge abgefragt. Der System Prompt und das Design System.

Der System Prompt ist in vier Layer und insgesamt zwölf Blocks aufgebaut. Der erste legt die Operating Conditions fest, bevor das Modell zu denken beginnt: Rolle, Umgebung und das Schema des Context Blob. Der zweite führt es durch eine feste Reasoning Chain, der dritte bestimmt die Design Principles, der vierte das Output-Format und die harten Constraints. Ein Teil dieser Blocks bleibt für jedes System gleich, ein anderer wird je nach Anwendung neu gefüllt.

Das Design System liefert die Bausteine, aus denen das Modell die Oberfläche zusammensetzt. Die Grundlage bildet ein Layer aus Design Tokens, der Farben, Typografie, Spacing und Border Radius etc. definiert. Darauf bauen die Components auf, jede mit festen Composition Rules, die vorgeben, welche Child-Elemente in welcher Menge und unter welchen Bedingungen erlaubt sind. Wrapper bestimmen schließlich, welche Components in einem Abschnitt erscheinen dürfen und wie sie angeordnet werden.

Damit ist das Design System kein Style Guide, sondern die gestaltete Schicht zwischen der generativen Fähigkeit des Modells und dem Interface, das die Person am Ende sieht. Das Component-Vokabular wird dabei zur Laufzeit dynamisch aus dem Design System geladen, nie fest in den Prompt geschrieben. So bleibt alles, was das Modell erzeugt, in einem Raum, der bewusst gestaltet wurde.

Résumé

Mit der Entwicklung dieses Projekts sind wir der Meinung, dass Generative UI verändern wird, wie Designer*innen in Zukunft arbeiten. Nicht mehr einzelne Screens, User Flows und Personas werden entworfen, sondern die Regeln und Constraints, innerhalb derer Interfaces von selbst entstehen.

Bis ein System, wie wir es hier entworfen haben, tatsächlich integriert werden sollte, sind aus unserer Sicht aber noch einige Fragen zu lösen. Generative Systeme tragen die Schwächen ihrer Modelle in sich. Vor allem aber werfen sie Fragen zum Datenschutz auf. Gerade der Umgang mit persönlichen Daten ist eine Voraussetzung und keine Randnotiz, denn ein System, das Kontext lesen soll, muss tief in die Daten einer Person blicken.

Wir verstehen diesen Bachelor deswegen als Version 0, einen Vorschlag, wie ein solches System aussehen könnte, wenn die Voraussetzungen dafür stimmen.