Warum KI-Prototypen schneller zu brauchbarem Feedback führen
Viele Digitalprojekte beginnen mit Workshops, Prozesslandkarten und detaillierten Designs. Das ist verständlich: Niemand möchte ein System bauen, das am Geschäft vorbeigeht. Trotzdem entsteht in dieser Phase oft ein trügerisches Gefühl von Sicherheit. Auf einem Diagramm wirkt fast jeder Prozess logisch. Erst wenn Menschen mit einer konkreten Anwendung arbeiten, werden die fehlenden Felder, unklaren Zustände, Sonderfälle und Medienbrüche sichtbar.
KI-gestützte Entwicklung verändert deshalb die Reihenfolge guter Produktarbeit. Statt wochenlang zu modellieren, kann ein Team früh einen einfachen Prototyp bauen. Er kann echte Formulare, Listen, erste Rollen, Beispielreports und sogar eine grobe Integration zu vorhandenen Daten enthalten. Der Prototyp darf unfertig aussehen und muss noch nicht produktionsreif sein. Er muss nur konkret genug sein, damit Benutzer reagieren können.
Eine empirische Modellstudie zum Software-Prototyping fasst 33 Primärstudien, eine Fokusgruppe und Interviews aus zwölf Unternehmen zusammen. Sie trennt fünf Entscheidungen: Zweck, Umfang, Medium, Verwendung und Art der Erkundung. Prototypen können Anforderungen, Machbarkeit und Bedienbarkeit klären. Die Autoren warnen aber auch, dass sie einen falschen Eindruck vom Fertigstellungsgrad erzeugen können. Die Studie belegt nicht, dass KI jeden Prototyp schneller macht; sie stützt, dass der Prototyp auf eine konkrete Lernfrage zugeschnitten sein sollte.
Ein Beispiel: Bestand einem Projekt zuordnen
Bei MAFU-SHERPA lief die Bestandsverwaltung über eine ausgeklügelte Excel-Datei, und vom Shopfloor aus wurde die Inventur damit zunehmend fehleranfällig. Auf einem Ablaufdiagramm steht in so einem Fall ein einziger Kasten, „Bestand einem Projekt zuordnen“, und er wirkt vollständig. Am Regal entscheidet sich dann, ob dafür der Artikel, der Lagerplatz oder der Auftrag gescannt wird, was bei einer falschen Zuordnung passiert und wer den Fehler bemerkt. Diese Fragen beantwortet erst die Benutzung. Die erste Version war deshalb eine schmale Barcode-App, die Artikel am Regal las, Bestand einem Projekt zuordnete und die Änderung in die vorhandenen Tabellen zurückschrieb. In den Wochen danach kam weitere Funktionalität dazu, während die App bereits im Einsatz war. Die Fallstudie zur Bestandsverwaltung mit Power Apps hält den Weg fest, und wie sich eine solche Wahl zwischen Standard, Eigenentwicklung und Tabelle einordnet, zeigt Individualsoftware vs. Standardsoftware.
Warum abstraktes Feedback schwach ist
Wenn Benutzer ein Prozessmodell sehen, kommentieren sie meist das, was sie bereits kennen. Sie sagen, ob die Kästchen grundsätzlich richtig angeordnet sind und ob ein Schritt fehlt. Das hilft, aber es bleibt abstrakt. Niemand spürt, ob ein Formular zu lang ist oder ob die Suche im Alltag funktioniert. Auch missverständliche Statusnamen und häufige Systemwechsel bleiben auf dem Diagramm unsichtbar.
Ein Prototyp erzeugt anderes Feedback. Benutzer klicken durch einen Auftrag, erfassen eine Reklamation, prüfen einen Lagerbestand oder genehmigen eine Bestellung. Sie merken sofort, wo die Software den Arbeitsfluss unterstützt und wo sie im Weg steht. Dieses Feedback ist präziser, weil es aus Nutzung entsteht, nicht aus Vorstellungskraft.
KI senkt die Kosten der ersten Version
Früher war ein Prototyp oft teuer genug, dass Teams ihn ebenfalls stark planen mussten. KI verschiebt diese Kostenkurve. Layouts, Datenmodelle, einfache Abläufe, Validierungen und erste Testdaten lassen sich schneller erstellen. Dadurch wird es wirtschaftlich sinnvoll, mehrere Varianten auszuprobieren, bevor große Entscheidungen getroffen werden.
Das bedeutet nicht, dass Architektur, Sicherheit und Prozessverständnis unwichtig werden. Im Gegenteil: Gerade weil KI schnell viel Code erzeugen kann, braucht das Team klare technische Leitplanken. Der Unterschied liegt im Zeitpunkt. Anstatt den gesamten Prozess vorab perfekt zu beschreiben, baut man eine schmale Version, testet sie mit echten Nutzern und modelliert danach mit besseren Informationen weiter.
Prototyp und MVP liegen auf einer Kostenkurve
Ein Lernprototyp darf Lücken haben. Vielleicht zeigt er nur den kritischen Statuswechsel mit realistischen Beispieldaten. Ein MVP (Minimum Viable Product) ist hier die kleinste produktive Version, mit der echte Benutzer echte Arbeit erledigen können. Die MAFU-SHERPA-App gehört in diesem Vergleich zur produktiven Seite, auch wenn die Fallstudie sie nicht als MVP bezeichnet. Je näher der Test an produktiver Nutzung liegt, desto mehr Aufwand wandert in Berechtigungen, Fehlerbehandlung, Betrieb, Datenübernahme und Tests. Dieser zusätzliche Aufwand kann ein MVP teurer machen als einen Lernprototyp, ohne dass es schon die spätere Anwendung im Kleinen enthalten muss.
Ein guter Prototyp beantwortet konkrete Fragen
Ein Prototyp ist kein Selbstzweck. Er sollte auf wenige Entscheidungen ausgerichtet sein. Zum Beispiel: Reicht eine einfache Aufgabenliste oder braucht der Prozess Statuswechsel mit Verantwortlichkeiten? Kann ein Standardformular die Daten erfassen oder sind mehrere Rollen beteiligt? Muss eine Integration sofort gebaut werden oder genügt für die erste Version ein Import?
- Bauen Sie nur den kleinsten Ablauf, der eine echte Entscheidung ermöglicht.
- Nutzen Sie realistische Beispieldaten, damit Fachbereiche typische Fälle erkennen.
- Beobachten Sie Benutzer beim Klicken, statt nur Meinungen einzusammeln.
- Trennen Sie Feedback zu Fachlogik von Feedback zu Oberfläche und Bedienung.
- Entscheiden Sie nach jeder Feedbackrunde, was entfernt, vereinfacht oder vertieft wird.
Prozessmodellierung bleibt wichtig
Schnelles Prototyping ersetzt keine saubere Prozessarbeit. Es macht sie besser. Nach zwei oder drei Feedbackrunden ist klarer, welche Prozessschritte wirklich relevant sind. Ebenso wird sichtbar, welche Sonderfälle selten genug für manuelle Behandlung bleiben und welche Regeln im System verbindlich abgebildet werden müssen. Das spätere Prozessmodell basiert dann auf beobachtetem Verhalten statt allein auf Workshop-Erinnerungen.
Bei der Inventur-App war das genau so. Das vollständige ERP folgte später als eigener Schritt; die App wurde in den Wochen nach der Einführung um weitere funktionale Anforderungen erweitert.
Gerade bei ERP-, CRM- und internen Business-Apps ist das entscheidend. Der Nutzen entsteht nicht dadurch, dass ein Prozess besonders detailliert dokumentiert wurde. Der Nutzen entsteht, wenn Mitarbeiter schneller entscheiden, weniger doppelt erfassen und Management verlässliche Informationen erhält.
Schreiben Sie vor dem Bau einen vollständigen Prüfbrief
Halten Sie diese fünf Punkte zusammen fest, bevor Sie den Prototyp für die nächste Lernrunde bauen. So ist klar, was der Prototyp beantworten soll und wer über das Ergebnis entscheidet.
- Die Entscheidung: Was soll nach dieser Runde klarer sein?
- Der echte Fall: Welcher konkrete Vorgang und welche Beispieldaten werden geprüft?
- Die Grenze: Was gehört ausdrücklich noch nicht in diese Version?
- Die Prüfer: Wer arbeitet mit dem Ergebnis und welche Sicht braucht diese Person?
- Der Termin: Wann wird geprüft und wer entscheidet über Bauen, Ändern oder Stoppen?
Eine Regel für den Start
Bei der MAFU-SHERPA-App hat sich eine Regel bewährt, die wir seither jedem Prototyp mitgeben: Benennen Sie vor dem Bau genau eine Entscheidung, die der Prototyp ermöglichen soll, und beenden Sie die Lernrunde, sobald diese Frage beantwortet ist. Alles, was diese Frage nicht beantwortet, gehört in eine spätere Runde; woran ein Ergebnis später erkennbar sein muss, steht in Akzeptanzkriterien für KI-Aufgaben.
Mit dem Tempo der Entwicklung verschiebt sich außerdem der Engpass innerhalb der Lernrunde. Wenn die erste funktionierende Version in Tagen entsteht, ist selten der Code der langsamste Teil, sondern die Entscheidung darüber. Feedback, das drei Wochen liegen bleibt, macht den schnellsten Prototyp wieder langsam; dann entsteht nur schneller mehr Oberfläche, ohne dass der Ablauf besser wird. Planen Sie deshalb die Entscheiderrunde gleich mit: Wer sieht den Prototyp wann an, und wer entscheidet innerhalb weniger Tage über die nächste Runde?
Erst mit benannter Lernfrage und fester Entscheiderrunde lohnt sich das Tempo der KI-Entwicklung.
Was muss ein erster Prototyp enthalten?
Nur genug, um eine konkrete Entscheidung zu treffen: einen echten Vorgang, die wichtigsten Rollen, passende Beispieldaten und den Teil der Oberfläche, an dem die Unsicherheit liegt. Login, vollständiges Design und jede Integration sind nur nötig, wenn genau sie geprüft werden sollen.
Kann der Prototyp direkt produktiv genutzt werden?
Nicht automatisch. Ein Lernprototyp darf Abkürzungen bei Daten, Sicherheit und Fehlerbehandlung enthalten und muss deshalb klar von einer produktionsreifen Anwendung getrennt bleiben. Erst nach der Lernrunde werden Architektur, Berechtigungen, Tests, Betrieb und Datenübernahme bewusst festgelegt.
Wann ist die Prototyping-Phase abgeschlossen?
Wenn die zuvor benannte Lernfrage beantwortet ist und das Team eine belastbare Entscheidung treffen kann. Das kann nach einer Variante oder nach mehreren Feedbackrunden der Fall sein. Ein Prototyp sollte nicht weiterwachsen, nur weil weitere Funktionen leicht hinzuzufügen wären.
Reicht Figma für Software-Prototyping?
Figma reicht, wenn Sie Oberfläche, Reihenfolge und Verständlichkeit prüfen. Für Geschäftslogik, Datenqualität, Rollen oder Integrationen brauchen Sie einen funktionierenden Prototyp. Wählen Sie das Medium nach der offenen Entscheidung. Ein technischer Prototyp ist kein Qualitätszeichen, wenn ein Klickmodell dieselbe Frage günstiger beantwortet.
Was kostet es, ein MVP entwickeln zu lassen?
Der Preis hängt davon ab, welche Daten, Berechtigungen und Integrationen die echte Nutzung braucht und wie viel Fehlerbehandlung, Tests und Betrieb sie verlangt. Ein Lernprototyp kann günstiger sein, weil er diese Produktionspflichten nur für die geprüfte Frage abbildet. Lassen Sie sich daher den Umfang und ausdrücklich ausgeschlossene Punkte gemeinsam erklären, statt nur Funktionslisten zu vergleichen.
Wenn Sie für einen Ihrer Abläufe einen ersten Prototyp mit einer benannten Lernfrage bauen lassen wollen, besprechen wir die Entwicklung.