Start / Seminare / Feste UI, Chat oder Generative UI
Modul
Sieben Entscheidungskriterien
Modul 1 von 1 aus dem Seminar Feste UI, Chat oder Generative UI
5 Kapitel in diesem Modul-Video · Laufzeit
Für Teams
Die Videos zeigen, wie es geht. Die Schulung sorgt dafür, dass Ihr Team es danach tut.
Ein Video kann niemanden fragen, warum es ausgerechnet in Ihrem Repository nicht funktioniert. Es kann kein Team auf eine gemeinsame Konvention bringen. Und es setzt sich niemand freiwillig drei Tage hin. In der Schulung sind am Ende alle auf demselben Stand, gearbeitet wurde am eigenen Code, und die offenen Fragen sind entschieden — in ein paar Tagen statt irgendwann nebenbei.
Vorgespräch am Telefon · Programm nach Maß · ab 1 Tag (8 Unterrichtseinheiten) · Teilnahmezertifikat
Transkript
Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.
Feste UI, Chat oder Generative UI
0:00 Jahrzehntelang war die Sache klar: Entwickler bauen eine Oberfläche, und Nutzer bedienen sie. Dann kam der Chat, und plötzlich sollte man mit Software reden. Jetzt kommt der nächste Schritt. Die KI liefert nicht mehr nur Text, sondern stellt die Oberfläche selbst zusammen, passend zur Aufgabe: hier ein Kalender, dort ein Vergleich, am Ende eine Freigabe.
0:21 Das klingt nach Zukunft, und manches davon läuft schon. Die eigentliche Frage ist aber eine andere: Wann hilft das wirklich, und wann ist ein gutes altes Formular die bessere Wahl? Genau darum geht es in den nächsten Minuten, entlang von sieben Kriterien.
Feste UI, Chat oder Generative UI
0:37 Zuerst sortieren wir die Begriffe. Unter Generative UI wird inzwischen fast alles verstanden, was sich irgendwie bewegt, vom ausklappbaren Formularfeld bis zum Agenten, der selbstständig Termine reserviert. Wer so unscharf redet, kann nicht sauber entscheiden. Danach folgen die ersten beiden Kriterien: wie vorhersehbar die Aufgabe ist und ob Sprache überhaupt der richtige Einstieg ist.
1:00 Stellen Sie sich zwei Restaurants vor. Im einen gibt es eine feste Karte, im anderen fragt der Kellner, worauf Sie Lust haben, und stellt Ihnen ein Menü zusammen. Beides kann hervorragend sein, aber für ein schnelles Mittagessen ist die feste Karte meist besser. So arbeitet dieses Kurzmodul. Es empfiehlt keine Oberflächenform, sondern liefert ein Entscheidungsprofil.
1:21 Sie nehmen eine konkrete Aufgabe, gehen sieben Kriterien durch und sehen, ob ein festes Formular, ein Chat oder eine vom Modell zusammengestellte Oberfläche den Nutzen bringt. Häufig ist das Ergebnis eine Mischung, und das ist keine Schwäche, sondern der Normalfall. Die Tabelle liest sich am besten von oben nach unten, als wachsender Spielraum. Oben ist alles vorab gebaut, darunter steuern Regeln, welche Felder erscheinen.
1:46 Das ist adaptiv, aber noch nicht generativ, denn ein Entwickler hat jede Variante vorher festgelegt. Beim Chat wird Sprache zum Eingabekanal. Generativ wird es erst, wenn ein Modell entscheidet, welche Komponenten es zeigt, entweder aus einem zugelassenen Baukasten oder als frei erzeugter Code. Ganz unten steht die AI-native Anwendung: Dort plant das Modell auch den Ablauf und bereitet Aktionen vor. Als Beispiel dient Hallenplan, ein Buchungsportal für Sporthallen.
2:14 Auf diese Unterscheidung kommen wir immer wieder zurück. Warum ist das gerade jetzt ein Thema? Am 13. Oktober 2026 hat Workday angekündigt, dass sein Assistent Sana zur neuen Startseite wird. Statt fester Menüs entsteht die Oberfläche je Aufgabe: Formulare, Kalender, Freigabekarten, Auswertungen. Das ist bemerkenswert, weil hier kein Start-up experimentiert, sondern ein etabliertes Unternehmenssystem seine Startseite umbaut.
2:40 Allerdings sagt die Mitteilung, was entstehen soll, nicht, wie Modell, Anwendungslogik und Sicherheit technisch zusammenspielen. Daraus lässt sich also keine Bauanleitung ableiten. Was sich ableiten lässt, ist die Frage, die jedes Team für sich beantworten muss: Soll die KI nur Inhalte liefern oder auch bestimmen, welche Oberfläche und welche nächste Aktion passt?
3:03 In vielen Diskussionen laufen vier Fragen durcheinander, und dieses Schaubild trennt sie. Die oberste ist die eigentliche UI-Frage: Welche Komponenten erscheinen auf dem Bildschirm? Darunter liegt eine ganz andere: Welche Daten stehen in Komponenten, die es ohnehin gibt? Ein Modell, das eine Tabelle füllt, generiert noch keine Oberfläche.
3:23 Die dritte Ebene ist die heikelste: Was passiert tatsächlich, wenn jemand auf einen Knopf drückt? Und ganz unten steht die Architekturfrage, welche Rolle das Modell in der gesamten Anwendung spielt. Behalten Sie diese Trennung im Kopf. Wer sie sauber zieht, merkt schnell, dass viele Projekte nur die zweite Frage brauchen.
3:43 Nehmen wir Hallenplan, das Buchungsportal des Sportstättenamts einer Mittelstadt. Ein Volleyballverein bucht jede Woche dieselbe Trainingszeit. Das läuft immer gleich ab, und ein festes Formular erledigt es in Sekunden, verlässlich und ohne Überraschungen. Ganz anders das Jugendturnier im Frühjahr: mehrere Felder, die Tribüne, ein Hausmeisterdienst am Wochenende und vielleicht eine Gebührenbefreiung für gemeinnützige Vereine.
4:08 Hier ändern sich Informationen, Reihenfolge und nächste Schritte mit jedem Fall. Genau dort wird eine generierte Oberfläche interessant. Das erste Kriterium ist deshalb nüchtern: Wiederkehrende, stabile Abläufe brauchen meist keine KI, die eine Oberfläche entwirft. Chat hat einen echten Vorteil: Man kann eine offene Absicht einfach hinschreiben. Wir brauchen am 14. März zwei Felder für ein Turnier, das versteht jeder sofort.
4:33 Sobald es aber um Details geht, wird Sprache mühsam. Versuchen Sie einmal, drei Termine per Text zu verschieben oder zwei Hallen nach Größe und Preis zu vergleichen. Spätestens dann wünscht man sich den Kalender zurück. Für Datumswahl, Vergleich, Mehrfachauswahl und Freigabe sind sichtbare Komponenten präziser und schneller.
4:53 Die gute Lösung ist deshalb selten reiner Chat. Sie nutzt Sprache für die Absicht und Komponenten für alles, was genau sein muss.
Gestaltungsraum, Aktionen und Kontrolle
5:01 Steht fest, dass eine Aufgabe von einer variablen Oberfläche profitiert, kommt die nächste Frage: Wie viel darf das Modell gestalten, und was darf es auslösen? Die Kriterien drei bis fünf drehen sich um Spielraum, Berechtigungen und darum, dass Nutzer jederzeit verstehen, was gerade passiert. Der Gestaltungsraum des Modells lässt sich in drei Stufen beschreiben, und der Pfeil zeigt wachsende Freiheit.
5:25 Auf der ersten Stufe wählt das Modell eine fertige Komponente aus, etwa über einen Werkzeugaufruf, der genau einen Kalender öffnet. Auf der zweiten kombiniert es mehrere zugelassene Komponenten aus einem Katalog zu einer Oberfläche. Auf der dritten schreibt es selbst Code, also HTML, CSS oder JavaScript. Mit jeder Stufe gewinnt man Flexibilität und verliert Kontrolle.
5:47 Die Entscheidung ist also keine technische Spielerei, sondern eine Abwägung, wie viel Unvorhersehbarkeit eine Anwendung verträgt. Für Unternehmensanwendungen ist die mittlere Stufe meist die interessanteste, und Googles offenes Format A2UI zeigt, warum. Dort beschreibt das Modell eine Oberfläche als Daten, nicht als ausführbaren Code.
6:08 Die Anwendung hält einen Katalog vertrauenswürdiger Komponenten, und das Modell darf nur anfordern, was darin steht. Weil die Beschreibung eine flache Liste mit Kennungen ist, lässt sie sich Stück für Stück übertragen, anzeigen und prüfen. Das Ergebnis ist flexibel genug für den Einzelfall und trotzdem berechenbar. Frei erzeugter Code dagegen braucht eine abgeschottete Umgebung und verliert unterwegs, was mühsam aufgebaut wurde: Designsystem, Barrierefreiheit und Verlässlichkeit.
6:36 Hier passiert der folgenreichste Denkfehler. Eine generierte Oberfläche zeigt einen Knopf, Gebühr erlassen, und alle gehen stillschweigend davon aus, dass der Knopf auch wirken darf. Darf er aber nicht automatisch. Was sichtbar ist, ist noch lange nicht erlaubt. Anzeige, Eingabe und geschäftliche Aktion gehören getrennt behandelt.
6:56 Bei Hallenplan wird die Befreiung erst wirksam, wenn Identität, Rolle, Vereinsstatus und eine Freigabe geprüft sind, und zwar von der Anwendung, nicht vom Modell. Die Sicherheitsorganisation OWASP hat für das Gegenteil einen eigenen Namen: Excessive Agency, also einem Modell mehr Handlungsspielraum zu geben, als die Aufgabe braucht.
7:16 Eine Oberfläche, die sich ständig neu zusammensetzt, kann verunsichern. Deshalb muss sie mehr erklären als ein festes Formular. Der Nutzer sollte sehen, was das System verstanden hat und welche Daten es dafür verwendet. Er sollte erkennen, welche Aktion vorbereitet ist und was eine Bestätigung auslöst. Und er braucht jederzeit einen Weg zurück: korrigieren, abbrechen, und die beruhigende Antwort auf die Frage, ob schon etwas passiert ist.
7:41 AI-native bedeutet nicht, dass Navigation verschwindet und durch Entscheidungen ersetzt wird, die niemand nachvollziehen kann. Gute Anwendungen machen die Arbeit des Modells sichtbar, statt sie zu verstecken.
Prüfbarkeit, Aufwand und Entscheidungsmatrix
7:54 Zwei Kriterien fehlen noch, und sie entscheiden oft über Erfolg oder Misserfolg im Betrieb: Lässt sich das Ganze überhaupt prüfen, und rechtfertigt der Nutzen den Aufwand? Danach fassen wir alle sieben Kriterien in einer kompakten Matrix zusammen. Ein festes Formular lässt sich Bildschirm für Bildschirm testen. Bei einer generierten Oberfläche gibt es diese Bildschirme nicht im Voraus, es gibt nur Varianten.
8:17 Getestet werden deshalb unvollständige und widersprüchliche Eingaben, unerwartete Kombinationen von Komponenten und der Abbruch mitten im Ablauf. Jede Variante muss sich per Tastatur bedienen lassen und mit einem Screenreader funktionieren, Statusmeldungen eingeschlossen. Dazu kommt die Sicherheit: Manipulierte Daten können das Modell umsteuern, und ungeprüfte Ausgaben landen sonst ungefiltert auf dem Bildschirm.
8:41 Beides steht in den Top Ten von OWASP. Die Qualitätssicherung wandert also von Seiten zu Komponenten, Schemas, Regeln und erlaubten Zustandswechseln. Generative UI ist kein Schalter, den man umlegt. Sie bringt Bauteile mit, die eine feste Oberfläche nicht braucht: Modellaufrufe, Streaming, eine Zustandsverwaltung, Kataloge für Komponenten und Aktionen.
9:03 Dazu kommen Schemaprüfung, Telemetrie, Sicherheitsprüfungen, eine Ausweichoberfläche für den Fall, dass etwas schiefgeht, und Regressionstests für das Modellverhalten. Jede Anfrage kostet außerdem Zeit und Geld. Die Beratungsfirma Thoughtworks formuliert es für MCP Apps sehr nüchtern: Man solle prüfen, ob die zusätzliche Komplexität gegenüber einer reinen Textantwort gerechtfertigt ist.
9:27 Dieser Satz gilt für Generative UI insgesamt. Diese Tabelle fasst zusammen, wohin die sieben Kriterien in typischen Situationen zeigen. Auffällig ist, wie oft die feste Oberfläche gewinnt: beim stabilen Standardprozess und überall dort, wo Vorhersagbarkeit selbst das Ziel ist, etwa beim Bezahlen. Generative UI spielt ihre Stärke aus, wenn eine offene Absicht auf Details trifft, die Auswahl und Vergleich brauchen.
9:51 Die eingebettete Variante lohnt vor allem, wenn ein Werkzeug in fremden KI-Anwendungen erscheinen soll. Und die letzte Zeile ist eine Warnung: Wo eine wirksame Aktion ohne prüfbare Freigabe ausgelöst würde, wird nichts generiert, sondern zuerst die Berechtigung geklärt. Lesen Sie die Matrix als Tendenz, nicht als Regelwerk.
A2UI, AG-UI und MCP Apps einordnen
10:11 Wer sich mit dem Thema beschäftigt, stößt schnell auf ein Dickicht aus Abkürzungen. A2UI, AG-UI, MCP Apps, dazu eine Handvoll Frameworks. Das wirkt unübersichtlicher, als es ist. Jede dieser Spezifikationen löst ein anderes Problem, und wenn man die Schichten auseinanderhält, ordnet sich das Bild fast von selbst. Das Schaubild zeigt den Stapel von oben nach unten. Ganz oben steht der Renderer in Ihrer Anwendung, er zeichnet die Komponenten aus Ihrem eigenen Designsystem.
10:43 Darunter liegt die Beschreibung der Oberfläche, also das Format, in dem ein Modell sagt, was erscheinen soll. Hier stehen A2UI von Google und Open-JSON-UI von OpenAI. Eine Ebene tiefer regelt AG-UI, wie Agent und Oberfläche in Echtzeit miteinander reden. Und ganz unten verbindet MCP den Agenten mit Werkzeugen und Daten.
11:03 Wichtig ist die Reihenfolge: Die Komponenten gehören Ihnen. Die Standards regeln nur, wie man sich darüber verständigt. Die Namen laden zu Verwechslungen ein, deshalb lohnt ein genauer Blick. AG-UI ist ausdrücklich keine Spezifikation für Oberflächen, sondern das Protokoll für Ereignisse, gemeinsamen Zustand und Rückfragen an den Menschen.
11:26 Es transportiert die anderen Formate nur. A2UI liegt seit April 2026 in Version 0.9 vor und bringt Renderer für React, Angular, Lit und Flutter mit. Open-JSON-UI ist die offene Fassung des Schemas, das OpenAI intern verwendet, und A2UI konzeptionell sehr ähnlich. Frameworks wie das AI SDK von Vercel verbinden Werkzeugergebnisse mit Komponenten. Die Entscheidung, wie viel Spielraum das Modell bekommt, nehmen sie Ihnen allerdings nicht ab.
11:55 MCP Apps dreht die Perspektive um. Hier liefert nicht Ihre Anwendung die Komponenten, sondern das Werkzeug bringt seine eigene Oberfläche mit. Seit Januar 2026 ist das die erste offizielle Erweiterung des Model Context Protocol. Ein Werkzeug verweist auf eine Oberfläche, die der Host abgeschottet in einem eigenen Rahmen anzeigt, und unterstützt wird das unter anderem von Claude, ChatGPT und Visual Studio Code.
12:19 Das ist ideal, wenn Ihr Produkt innerhalb fremder KI-Anwendungen bedienbar sein soll. Für die eigene Anwendung ist es dagegen meist ein Umweg, denn dort haben Sie mit einem eigenen Komponentenkatalog mehr Kontrolle über Aussehen und Verhalten. Diese Tabelle ist vielleicht die wichtigste des ganzen Moduls, denn sie verteilt die Verantwortung.
12:39 Das Modell versteht die Absicht und wählt passende Komponenten, aber nur aus dem Katalog. Die freien Hallenzeiten holt ein kontrolliertes Werkzeug, nicht das Modell aus seinem Gedächtnis. Eingaben prüft der Anwendungscode, Belegungs- und Gebührenregeln prüft eine deterministische Geschäftslogik, die bei gleicher Eingabe immer gleich entscheidet.
12:59 Die Reservierung gibt ein Mensch frei, der Hallenwart oder der Vereinsvorstand. Und das Backend protokolliert alles. Das Prinzip dahinter ist einfach: Das Modell darf vorschlagen und zusammenstellen. Wirksam wird nur, was Regeln und Menschen freigeben.
Übung
13:15 Jetzt sind Sie dran. Die sieben Kriterien entfalten ihren Wert erst, wenn man sie auf einen echten Fall anwendet. Am besten auf eine Aufgabe aus Ihrem eigenen Produkt, bei der gerade jemand vorgeschlagen hat, man könne das doch mit KI lösen. Zur Orientierung noch einmal Hallenplan. Vereine sollen Hallenzeiten künftig auch per Chat anfragen können, und im Team liegen drei Vorschläge auf dem Tisch.
13:39 Der erste: Das bestehende Formular bleibt, weil es funktioniert. Der zweite: Man setzt einen Chat davor, der die Anfrage aufnimmt. Der dritte: Die Oberfläche wird je Anfrage zusammengestellt, aus Kalender, Feldauswahl, Gebührenübersicht und Freigabekarte. Jeder Vorschlag hat Fürsprecher und gute Argumente. Genau das macht die Übung lehrreich. Es geht nicht darum, den einen richtigen Vorschlag zu finden, sondern zu begründen, welcher Teil der Aufgabe welche Form verdient.
14:09 Die Schritte führen vom Beschreiben zum Entscheiden. Zuerst halten Sie den Fall in fünf Sätzen fest: die Aufgabe, ihre Varianten, die Daten, die Aktionen und wer damit arbeitet. Danach trennen Sie feste und variable Teile. Meist ist der variable Teil kleiner, als man anfangs denkt. Dann legen Sie fest, welche Komponenten und Werkzeuge das Modell überhaupt verwenden darf.
14:31 Im vierten Schritt markieren Sie jede Aktion, die eine Freigabe braucht, und überlegen, was passiert, wenn das Modell nicht weiterkommt. Zum Schluss notieren Sie, welche Qualitäts- und Barrierefreiheitskriterien jede denkbare Variante erfüllen muss. Das Ziel der Übung ist eine Fähigkeit, keine Folie: Sie sollen für eine konkrete Aufgabe begründet zwischen fester Oberfläche, Chat und Generative UI wählen und genau abgrenzen können, wie viel Spielraum das Modell bekommt.
14:59 Geschafft ist es, wenn zu jedem der sieben Kriterien eine Antwort steht und dazu drei handfeste Ergebnisse: ein Katalog zugelassener Komponenten, die Liste der freigabepflichtigen Aktionen und eine Ausweichoberfläche. Lassen Sie sich nicht entmutigen, wenn am Ende kein eindeutiger Sieger steht. Oft ist die beste Antwort eine Mischung aus festem Kern, Chat als Einstieg und generierten Teilen nur für die Varianten.
Und jetzt?
15:22 Was bleibt? Generative UI ist weder Spielerei noch Allheilmittel. Sie ist eine Architekturentscheidung, die sich für jede Aufgabe einzeln begründen lässt, mit sieben Kriterien von der Vorhersehbarkeit bis zu den Kosten. Wenn diese Entscheidung steht, beginnt die eigentliche Arbeit: Werkzeuge anbinden, Freigaben absichern, die Qualität des Modells messbar machen.
15:44 Genau darum geht es im Seminar KI-Features im eigenen Produkt. Es lohnt sich besonders dann, wenn bei Ihnen noch offen ist, wie ein Modell sicher handeln darf und woran Sie merken, dass es gute Arbeit leistet. Alle Inhalte und Termine finden Sie auf learning-master.de.
Weiter geht es im Seminar KI-Features im eigenen Produkt
Dieses Kurzmodul ordnet ein und hilft bei der Entscheidung — es ersetzt keine Schulung. Wer danach in die Umsetzung will, findet sie im Seminar KI-Features im eigenen Produkt: 11 Module, 74 Video-Kapitel, kostenlos ansehbar — und als Schulung für Ihr Team buchbar.
3 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung
Schulung zu KI-Features im eigenen Produkt anfragenZum Seminar KI-Features im eigenen Produkt →