In traditioneller Software sendet ein Button entweder das Formular oder nicht. Das Verhalten ist spezifiziert, implementiert und verifiziert. Design kann mit statischen Screens vorauseilen, weil die zugrundeliegende Logik vorhersehbar ist – man entscheidet hauptsächlich, wie Dinge aussehen und wie sie angeordnet sind.

KI-Features brechen diese Annahme. Die Ausgabe wird generiert, nicht spezifiziert. Derselbe Input kann unterschiedliche Ergebnisse produzieren. Das System kann selbstsicher falsch liegen. Es kann langsam sein. Es kann ablehnen. Und der Nutzer ist nun ein Teilnehmer, der beurteilen, korrigieren und manchmal übersteuern muss, was das Produkt produziert hat.

Nichts davon ist in einem statischen Mockup sichtbar. Man kann sich keine Sicherheit über eine Erfahrung annotieren, deren Kernverhalten ungewiss ist. Man muss es spüren.

Die Unsicherheit liegt an Orten, die Mockups nicht zeigen können

Wenn man ein KI-Produkt gestaltet, sind die schwierigsten Fragen selten über Layout. Sie betreffen das, was in der unübersichtlichen Mitte passiert:

  • Probabilistische Ausgabe. Das Ergebnis variiert von Durchlauf zu Durchlauf. Das Interface muss also eine Bandbreite von Ausgaben elegant halten, nicht nur ein perfektes Beispiel.
  • Grenzfälle und Fehler. Leere Ergebnisse, Teilergebnisse, Ergebnisse mit geringer Konfidenz, Verweigerungen, Timeouts. Für KI sind das keine Ausnahmen, sondern der Alltag, und sie brauchen echtes Design.
  • Vertrauen und Korrektur. Nutzer müssen verstehen, woher die Ausgabe stammt, wie sicher das System ist und wie sie es korrigieren können, wenn es falsch liegt.
  • Latenz. Eine Wartezeit von zwei Sekunden verändert das gesamte Gefühl einer Interaktion. Das merkt man nur durch Erleben.
  • Menschliche Überprüfung. Die meisten nützlichen KI-Produkte halten einen Menschen in der Schleife. Das Übergabe-Design, genehmigen, bearbeiten, ablehnen, eskalieren, ist das eigentliche Produkt.

Man kann sich keine gute KI-Erfahrung zusammenreviewen. Man muss etwas Funktionierendes vor eine Person stellen und beobachten, was bricht.

Prototyping bewegt Unsicherheit vorwärts, wo sie günstig ist

Jedes Produkt hat eine feste Menge an Unsicherheit, die vor der Auslieferung abgebaut werden muss. Die einzige Frage ist, wann man dafür zahlt. Eine fehlerhafte Vertrauensarchitektur im Prototyp zu entdecken kostet eine Woche. Sie nach dem Aufbau der Pipeline in der Entwicklung zu entdecken, kostet ein Quartal.

Ein realistischer Prototyp – auch ein gefälschter oder geskripteter – ermöglicht es, die teuren Fragen früh zu beantworten:

  1. Macht das Interaktionsmodell die KI tatsächlich kontrollierbar?
  2. Vertrauen Nutzer der Ausgabe genug, um zu handeln – und misstrauen sie ihr genug, um zu überprüfen?
  3. Wie fühlt sich die Erfahrung an, wenn das Modell falsch, langsam oder leer ist?
  4. Ist der menschliche Überprüfungsschritt eine Erleichterung oder eine Aufgabe?

Man braucht kein funktionierendes Modell, um diese Fragen zu beantworten. Man braucht etwas, das überzeugend genug funktioniert, um eine echte Reaktion zu provozieren. Dafür ist ein Prototyp da.

Wie das in der Praxis aussieht

Für KI-Arbeit prototypiere ich das Verhalten vor den Pixeln: die Zustände, die Konfidenzsignale, die Korrekturpfade, die Fehlermodi. Oft mit vorbereiteten oder Wizard-of-Oz-Antworten als Platzhalter für das echte Modell. Das Ziel ist kein Demo, das immer funktioniert, sondern ein Demo, das zeigt, wo die Erfahrung auseinanderfällt, solange die Änderung noch günstig ist.

Traditionelle Software lässt einen vorwärts gestalten und am Ende validieren. KI-Produkte kehren das um. Je früher man das Verhalten greifbar macht, desto weniger zahlt man für die Unsicherheit, der man sich sowieso stellen musste.