Die Lücke zwischen
Demo und Produktion
in Agentic UX

Jede Demo eines agentischen Produkts folgt demselben Skript. Die Nutzerin tippt eine klare, gut formulierte Anfrage. Der Agent versteht sie beim ersten Versuch, plant die richtigen Schritte, führt sie sauber aus und legt ein vollständiges Ergebnis vor.

Der Alltag sieht völlig anders aus. Echte Nutzer formulieren mehrdeutig. Sie ändern auf halbem Weg ihre Meinung. Der Agent bekommt drei von fünf Schritten richtig hin und bleibt beim vierten stecken. Das Ergebnis ist unvollständig, und der Mensch muss entscheiden, was er damit anfängt. Interfaces, die auf das Demo-Skript optimiert sind, scheitern genau hier, oft schon in den ersten Wochen im echten Einsatz. Denn sie wurden nie für die Situation entworfen, die in Wirklichkeit dominiert: unvollkommene Eingabe trifft auf unvollkommene Ausführung.

Diese Lücke ist kein Modellproblem. Sie ist ein Gestaltungsproblem, und sie beschreibt, worin die Arbeit an Agentic UX tatsächlich besteht.

Warum sich das Demo-Skript durchsetzt

Demo-getriebenes Design ist nichts Neues. Wir bauen seit jeher zuerst den Happy Path und zuletzt die Fehlerzustände. Bei klassischer Software deckt der Happy Path aber den größten Teil der echten Nutzung ab: Ein Formular validiert oder eben nicht, ein Button funktioniert oder nicht. Die unglücklichen Pfade lassen sich aufzählen.

Agentische Systeme kehren dieses Verhältnis um. Der Raum möglicher Absichten ist offen, die Interpretation des Agenten ist probabilistisch, und die Ausführung läuft über mehrere Schritte, von denen jeder teilweise gelingen kann. Die Randfälle sind keine Ränder mehr. Sie sind die Mitte der Verteilung. Ein Designprozess, der Mehrdeutigkeit und Teilergebnisse als Feinschliff behandelt, hat die Prioritäten verkehrt herum.

Dazu kommt ein Anreizproblem. Demos verkaufen. Intern überzeugt die Demo die Stakeholder, das Projekt zu finanzieren, extern überzeugt sie Kunden zu kaufen. Niemand finanziert einen Pitch, der mit den Worten beginnt: So elegant scheitern wir. Also werden die Fehlerzustände von denen entworfen, die am Ende noch im Raum sitzen, falls überhaupt.

Was im Alltag tatsächlich kaputtgeht

Drei Momente richten den meisten Schaden an.

Die mehrdeutige Anfrage. Jemand schreibt „Räum den Report auf“ und meint die Formatierung; der Agent löscht Zeilen, die er für überflüssig hält. Die Demo zeigt das nie, weil Demo-Anfragen vorher getestet sind. Im Alltag braucht das Interface einen Weg, die Interpretation des Agenten vor der Ausführung sichtbar zu machen: Was hat er verstanden, was will er tun, in welcher Reihenfolge. Dieses Muster heißt üblicherweise Planvorschau, und die aktuelle Musterarbeit im Enterprise-Umfeld behandelt es als eines der wenigen Muss-Elemente, unabhängig von Modell oder Framework. Es ist keine Dekoration. Es ist der einzige Punkt, an dem ein Missverständnis noch billig ist.

Das Teilergebnis. Der Agent hat vier von sechs Schritten erledigt, ist beim fünften an einer Berechtigung hängen geblieben und hat den sechsten übersprungen. Was sieht der Mensch? Viele Interfaces zeigen entweder einen Spinner oder eine fertige Antwort, dazwischen nichts. Ein Teilergebnis, das als vollständiges präsentiert wird, zerstört Vertrauen schneller als ein ehrliches Scheitern, weil der Mensch die Lücke später entdeckt, allein und ohne Kontext. Das Interface muss „das habe ich getan, das konnte ich nicht tun, deshalb“ zu einem vollwertigen Screen machen, nicht zu einem Fehler-Toast.

Der Moment der Korrektur. Etwas ist schiefgelaufen und der Mensch will es reparieren. Wenn die Antwort lautet „Fang neu an und formulier es besser“, hat man einen Agenten in eine unberechenbare Kommandozeile verwandelt. Die Systeme, die im Alltag standhalten, machen Fehler korrigierbar: ein klares Rückgängig, das einfache Nachbessern eines einzelnen Schritts, und eine Aufzeichnung des Geschehenen, die man tatsächlich lesen kann. Vertrauen entsteht genau hier neu oder gar nicht.

Vom Fehler her gestalten

Die praktische Folge: Die Reihenfolge im Design umdrehen. Bevor man gestaltet, wie der Agent aussieht, wenn er gelingt, gestaltet man, wie er aussieht, wenn er halb gelingt.

Ein konkreter Anfang ist, die drei Momente oben als Pflicht-Screens in jedem agentischen Flow zu behandeln, mit demselben Rang wie der Erfolgszustand:

1. Interpretations-Screen. Zeig, wie der Agent die Anfrage liest und welche Schritte er vorhat, bevor etwas Unumkehrbares passiert. Lass den Menschen den Plan bearbeiten, nicht nur bestätigen oder ablehnen.
2. Teilergebnis-Screen. Leg vorab fest, was sichtbar wird, wenn die Ausführung bei Schritt N von M stehen bleibt. Welche Schritte fertig sind, welche nicht, in welchem Zustand die Daten jetzt sind.
3. Korrektur-Screen. Leg fest, wie ein Mensch einen falschen Schritt repariert, ohne den Rest zu verwerfen, und wie die Nachvollziehbarkeit dieser Korrektur aussieht.

Wenn ein Flow diese drei Fragen nicht beantworten kann, ist er nicht produktionsreif, egal wie gut sich die Demo anfühlt.

Für die Forschung folgt daraus ein zweiter, leiserer Punkt. Agentische Flows mit vorformulierten, sauberen Prompts zu testen, reproduziert die Demo-Verzerrung im Labor. Usability-Tests brauchen absichtlich unterspezifizierte Aufgaben, in den Worten der Teilnehmenden, damit Interpretation und Korrektur genauso oft durchlaufen werden wie der Erfolgspfad. Die interessanten Erkenntnisse liegen dort, wo die Anfrage mehrdeutig war.

Zum Mitnehmen

• Der dominante Fall im echten Einsatz agentischer Produkte ist unvollkommene Eingabe, die auf unvollkommene Ausführung trifft. Gestalte zuerst für diesen Fall und behandle den sauberen Erfolgspfad als Sonderfall.
• Drei Screens verdienen denselben Aufwand wie der Erfolgszustand: die Interpretation des Agenten vor der Ausführung, das ehrliche Teilergebnis und die Korrektur einzelner Schritte mit nachvollziehbarer Spur.
• Teste mit mehrdeutigen Aufgaben in den Worten der Nutzer. Eine Studie auf Basis sauber formulierter Prompts ist eine Demo mit Zwischenschritten.

← Alle Texte