UI Design im KI-Zeitalter – Die unendliche Leinwand

Im letzten Artikel habe ich beschrieben, wie KI die Arbeit im UX-Bereich verändert – weg vom Pixel-Perfektionismus, hin zur strategischen Begleitung. Heute möchte ich einen Schritt weitergehen und eine Frage stellen, die viele in der Branche umtreibt: Braucht es UI Designer überhaupt noch?

Spoiler: Ja. Aber anders als bisher.

Die große Umkehrung

Vierzig Jahre lang funktionierte UI Design nach dem gleichen Prinzip: Man startet mit nichts und baut Stück für Stück auf. Leere Leinwand, erste Komponente, zweite Komponente, irgendwann ein fertiger Screen. Additive Logik. Der Designer als Schöpfer.

Mit generativer KI kehrt sich das um.

Wer ein LLM bittet, ein Dashboard zu bauen, bekommt innerhalb von Sekunden etwas. Nicht nichts – etwas. Oft sogar etwas Brauchbares. Das Problem ist nicht mehr die leere Leinwand. Das Problem ist die unendliche Leinwand.

Ein Sprachmodell kann alles generieren. Jeden Stil, jede Farbe, jede Struktur. Ohne Einschränkungen produziert es beliebige Interfaces – technisch funktional, aber ohne Identität, ohne Haltung, ohne System.

Design bedeutet plötzlich nicht mehr: Was erschaffe ich? Design bedeutet: Was schließe ich aus?

Das erinnert an Michelangelos angebliches Zitat über den David: “Ich habe nur weggenommen, was nicht David war.” Bei KI-gestütztem Design ist es ähnlich. Das Modell kann alles formen. Die Aufgabe des Designers ist es, zu definieren, was es nicht tun soll.

Ein Design-System für KI-generierte Interfaces funktioniert genau so: Diese Farben, diese Schriften, dieser Ton – das sind keine Einschränkungen im negativen Sinn. Es sind Leitplanken, die aus beliebigem Output gestalteten Output machen.

Das ist ein fundamentaler Mindset-Shift. Vom Aufbauen zum Kuratieren. Vom Erschaffen zum Einschränken.

Das Interface wird durchlässig

Der klassische Designprozess ging von klaren Grenzen aus: Hier ist die App, hier ist der Nutzer, dazwischen das Interface als Vermittler. Screens, Flows, Interaktionen – alles fein säuberlich getrennt.

Diese Grenzen lösen sich gerade auf.

Moderne KI-Assistenten sind keine isolierten Chat-Fenster mehr. Sie haben Zugriff auf Dateisysteme, navigieren in Browsern, verbinden sich mit APIs und Datenbanken, deployen Code auf Servern. Die KI bewohnt die Arbeitsumgebung des Nutzers.

Man könnte von einem “permeablen Interface” sprechen. Die Grenze zwischen Gespräch und Aktion verschwimmt. Eine Antwort ist nicht mehr nur Text – sie kann eine echte Zustandsänderung in realen Systemen sein.

Das hat massive Design-Implikationen.

Traditionelle Interfaces haben klare Zuständigkeiten: Button X macht Aktion Y, Screen A führt zu Screen B, der Nutzer kontrolliert den Flow. Bei durchlässigen KI-Interfaces weiß der Nutzer oft nicht, was das System gerade tut. Die KI agiert in Bereichen, die er nicht sieht. Vertrauen muss aktiv designed werden.

Neue Fragen entstehen: Wie zeigt man, dass das System gerade 47 Dateien durchsucht – ohne zu überfluten? Wie macht man Undo möglich, wenn die KI etwas im System verändert hat? Wie kommuniziert man, wo das System Zugriff hat und wo nicht?

Das sind keine Fragen, die sich mit klassischem Screen-Design beantworten lassen. Hier entsteht ein neues Designfeld.

Vertrauen als Gestaltungsaufgabe

Es gibt eine Dimension, die in den meisten technischen Analysen zu kurz kommt: die emotionale.

Viele Menschen haben ein diffuses Unbehagen bei KI. Nicht wegen konkreter Fehler, sondern weil sie nicht verstehen, was passiert. Die Black Box macht Angst. Und diese Angst lässt sich nicht durch mehr Erklärungen auflösen – das überfordert nur.

Was hilft, ist Gefühl von Kontrolle. Konsistenz. Vorhersehbarkeit.

Wenn eine KI-Anwendung jedes Mal anders “aussieht” – mal formell, mal locker, mal mit Visualisierungen, mal ohne – entsteht kein Vertrauen. Design-Systeme für KI sind deshalb auch Persönlichkeits-Systeme. Sie definieren nicht nur Farben und Abstände, sondern Ton, Verhalten, Grenzen.

Eine weitere offene Frage: Wie gestaltet man Unsicherheit? LLMs sind probabilistisch, sie können sich irren. Aktuell drücken sie das durch Text aus: “Ich bin nicht sicher, aber…” Das funktioniert, ist aber nicht besonders elegant.

Wie könnte man Unsicherheit visuell gestalten? Weichere Kanten bei vagen Aussagen? Andere Farben? Subtile Animationen? Hier gibt es noch viel zu erforschen.

Die Branche bewegt sich bereits

Was abstrakt klingt, ist seit gestern Realität. Während ich diesen Artikel schreibe, hat sich die Landschaft fundamental verändert.

Gestern – am 26. Januar 2026 – ging MCP Apps offiziell live. Die erste offizielle Erweiterung des Model Context Protocol ermöglicht es, interaktive UI-Komponenten direkt in KI-Konversationen einzubetten. Das Besondere: Es ist ein branchenweiter Standard. Claude, ChatGPT, Visual Studio Code, Goose – alle unterstützen ihn. JetBrains, AWS und Google DeepMind haben angekündigt, zu folgen.

Das ist bemerkenswert. Anthropic und OpenAI – normalerweise Konkurrenten – haben zusammen mit dem MCP-UI-Team und der Community an einem gemeinsamen Standard gearbeitet. Microsoft, Google, Amazon ziehen mit. Wann hat es das zuletzt gegeben?

Und es bleibt nicht bei der Theorie. In Claude sind ab sofort interaktive Tools live: Asana für Projektmanagement, Figma für Diagramme, Hex für Datenvisualisierung, Slack für Nachrichtenentwürfe. Keine Chat-Antworten mehr, die man kopieren muss – echte, eingebettete Interfaces.

Block (das Unternehmen hinter Square) formuliert es treffend: “MCP inverts this by making apps pluggable components within agents.” Apps werden zu Bausteinen innerhalb von Agenten, nicht umgekehrt.

Parallel dazu hat Google im Dezember 2025 A2UI veröffentlicht – ein offenes Protokoll mit einem anderen Ansatz. Hier pflegt der Client einen “Katalog” vertrauenswürdiger Komponenten. Der Agent kann nur aus diesem Katalog wählen. Das ist Design durch Einschränkung, technisch umgesetzt.

Daneben existiert AG-UI von CopilotKit – ein Protokoll für die Interaktion zwischen Agent und Frontend, das Events, Lifecycle und Synchronisation standardisiert. Und MCP-UI, eine Community-Initiative, die den Weg für MCP Apps bereitet hat und nun in den offiziellen Standard aufgegangen ist.

Ergänzt wird das Ökosystem durch Googles A2A (Agent-to-Agent Protocol), das die Kommunikation zwischen verschiedenen Agenten regelt. Zusammen ergibt sich ein Bild: MCP verbindet Agenten mit Tools und Daten, A2UI definiert UI-Beschreibungen, AG-UI transportiert die Interaktion, A2A orchestriert Multi-Agent-Systeme. Die Standards sind komplementär, nicht konkurrierend.

Die technischen Ansätze unterscheiden sich – A2UI setzt auf native Komponenten, MCP Apps auf iframe-Sandboxing – aber die Richtung ist eindeutig: Die Industrie hat entschieden, dass Agents UI-Komponenten brauchen.

Die Frage ist nicht mehr ob KI-Systeme interaktive Interfaces nutzen werden. Die Frage ist, wer diese Komponenten-Kataloge gestaltet.

Context Design: Design-Intuition maschinenlesbar machen

Hier wird es praktisch. Denn es gibt eine konkrete Aufgabe, die direkt aus diesen Entwicklungen folgt.

LLMs können Text, Code, Tabellen, Charts generieren. Was sie nicht haben, ist Intuition dafür, wann welches Format angemessen ist. Diese Intuition steckt im Kopf erfahrener Designer: “Diese Art von Daten → dieses Format.”

Die Frage ist: Wie macht man dieses Wissen maschinenlesbar?

Man könnte es “Context Design” nennen. Es geht nicht um die Darstellung selbst, sondern um die Bedingungen, unter denen eine bestimmte Darstellung gewählt wird.

Ein praktisches Beispiel: Ein MCP-Server, der Sensordaten einer Photovoltaik-Anlage liefert. In der einfachen Version gibt der Server nur Rohdaten zurück:

{
  "solar_production": 4.2,
  "unit": "kWh"
}

Das Sprachmodell muss dann raten, wie diese Daten am besten dargestellt werden. Manchmal trifft es, manchmal nicht.

Mit Context Design würde der Server zusätzliche Hinweise mitliefern:

{
  "solar_production": 4.2,
  "unit": "kWh",
  "display": {
    "format": "gauge",
    "thresholds": { "low": 2, "medium": 5, "high": 8 },
    "comparison": "yesterday_same_time"
  }
}

Jetzt weiß das Modell nicht nur was, sondern auch wie. Das Ergebnis wird konsistent und durchdacht – nicht geraten.

Das ist kodifizierte Design-Intuition. Und genau hier liegt eine zentrale Aufgabe für UI Designer der Zukunft: Nicht mehr einzelne Screens gestalten, sondern Regeln definieren. Wann Balkendiagramm, wann Linie? Wann Tabelle, wann Fließtext? Wann detailliert, wann zusammengefasst?

Dieses Wissen in Systeme zu übersetzen – das ist die neue Kernkompetenz.

Vom Endprodukt zum Baukasten

Eine wichtige Klarstellung: UI-Elemente verschwinden nicht. Buttons, Cards, Formulare, Dashboards – all das wird es weiterhin geben. Und ja, man kann sie nach wie vor in Figma gestalten, wenn man möchte. Die Werkzeuge bleiben die gleichen.

Was sich ändert, ist der Anspruch.

Bisher lieferte ein UI Designer das fertige Endergebnis. Der Screen, wie er aussehen soll. Für alle Nutzer gleich, bis auf kleine Anpassungen. Das Ziel war Kontrolle über das Resultat.

In einer Welt mit generativen Interfaces verschiebt sich das. Der Designer gestaltet nicht mehr das finale Produkt, sondern den Baukasten, aus dem das LLM sich bedient. Die einzelne Komponente – sorgfältig gestaltet, mit allen Zuständen durchdacht – wird zum Baustein. Aber wie diese Bausteine kombiniert werden, entscheidet das System im Kontext des jeweiligen Nutzers.

Das klingt nach Kontrollverlust. Ist es aber nicht.

Es ist ein Perspektivwechsel. Der Designer tritt einen Schritt zurück, verliert die direkte Nähe zum fertigen Screen – und gewinnt dafür den Überblick über das Gesamtsystem. Statt einen Flow für alle zu gestalten, definiert man die Regeln, nach denen unzählige individuelle Flows entstehen können.

Das ist im Grunde, was gute Design-Systeme schon immer versucht haben: Konsistenz ohne Starrheit. Nur dass jetzt nicht mehr menschliche Entwickler die Komponenten zusammensetzen, sondern ein Sprachmodell – in Echtzeit, angepasst an den Kontext des Nutzers.

Der individuelle Mehrwert für den Nutzer steigt. Die Marke bleibt konsistent. Und der Designer wird zum Kurator eines Systems, nicht zum Autor jedes einzelnen Screens.

Was bedeutet das konkret?

Die Rolle verändert sich grundlegend. Aber sie verschwindet nicht – sie verschiebt sich.

Was weniger wird:

• Pixel-genaue Ausarbeitung einzelner Screens
• Statische Mockups für jeden erdenklichen Zustand
• Manuelle Übergabe-Dokumente an Entwickler
• Die Illusion, dass alle Nutzer das Gleiche sehen

Was mehr wird:

• Definition von Design-Systemen, die semantisch robust sind
• Entwicklung von Regeln für dynamische Darstellung
• Gestaltung von Vertrauen, Transparenz und Kontrolle
• Zusammenarbeit mit Entwicklern an APIs und Datenstrukturen
• Denken in Baukästen statt in fertigen Screens

Der UI Designer wandelt sich vom Gestalter statischer Oberflächen zum Architekten von Regelsystemen. Das erfordert neue Skills: ein Grundverständnis für Datenstrukturen, die Fähigkeit, in Bedingungen zu denken, vielleicht sogar ein wenig Code.

Aber es bedeutet auch: mehr Einfluss auf das Gesamtsystem. Weniger Nähe zum einzelnen Pixel, dafür ein größerer Überblick. Weniger Kontrolle über das Ergebnis, dafür mehr Gestaltungsmacht über die Regeln, die unzählige Ergebnisse formen.

Das kann bedrohlich wirken. Oder als Chance begriffen werden.

Ein Aufruf

An alle UI Designer: Eure Arbeit geht nicht weg. Sie wird sich verändern.

Informiert euch, was gerade passiert. Schaut euch an, wie die Asana-Integration in Claude funktioniert. Versteht, was MCP Apps sind, wie A2UI Komponenten-Kataloge definiert, was semantische Design-Tokens bedeuten. Nicht, weil ihr Entwickler werden sollt – sondern weil ihr verstehen müsst, in welchen Systemen eure Design-Entscheidungen zukünftig leben.

Die Interfaces der Zukunft werden nicht mehr gezeichnet. Sie werden beschrieben, eingeschränkt und kuratiert.

Das ist keine Bedrohung. Das ist eine Einladung, die Disziplin neu zu definieren – mit mehr Einfluss auf das Gesamtsystem als je zuvor.