Prototyping mit KI.

Es entsteht ein bedienbares Stück Software, in dem zwei bis drei Abläufe von Anfang bis Ende funktionieren — nicht ein Bild, nicht eine Präsentation, sondern etwas, das man einer fremden Person in die Hand geben kann. Genau das unterscheidet einen KI-gestützten Prototyp von einem Klickdummy: Es gibt echte Eingaben, echte Reaktionen und echte Fehlermeldungen, wenn man etwas Unerwartetes tut.

Konkret heisst das zum Beispiel: ein Buchungsablauf, in dem man tatsächlich Datum, Leistung und Kontaktdaten eingibt und eine Bestätigung sieht. Ein Konfigurator, der aus Eingaben einen Richtpreis rechnet. Ein internes Werkzeug, das eine Liste filtert, sortiert und exportiert. Ein Portal, in dem zwei unterschiedliche Rollen unterschiedliche Dinge sehen. In allen Fällen mit Testdaten, nie mit echten Personendaten.

Was nicht entsteht, ist Vollständigkeit. Der Prototyp kann genau die Wege, für die er gebaut wurde. Verlässt man sie, wird es unschön — und das ist beabsichtigt. Jeder zusätzlich abgedeckte Nebenweg kostet Zeit, die für die eigentliche Frage nichts beiträgt. Wie das Ergebnis gestalterisch aussieht, richtet sich nach demselben Prinzip: erkennbar genug, um beurteilt zu werden, nicht ausgearbeitet genug, um verteidigt zu werden. Die vollständige Gestaltungsarbeit gehört in UI/UX-Design, nicht in den Prototyp.

Der Ablauf folgt immer derselben Reihenfolge: erst die Annahme schärfen, dann bauen, dann mit echten Menschen testen, dann entscheiden. Die Reihenfolge ist wichtiger als die Werkzeuge — wer sie umdreht und zuerst baut, testet am Ende nur noch, ob das Gebaute gefällt.

• Tag 1 — Annahme und Abbruchkriterium. Wir formulieren einen einzigen Satz, der geprüft werden soll, und einen zweiten, der beschreibt, woran wir das Scheitern erkennen würden. Dazu die Aufgabe, die Testpersonen später lösen sollen. Ohne diese beiden Sätze beginnen wir nicht.
• Tag 1–2 — Zuschnitt. Welche zwei bis drei Abläufe tragen die Annahme? Alles andere wird schriftlich als «nicht enthalten» markiert. Ein grober Wireframe reicht als Vorlage; Feinschliff wäre hier verschwendete Zeit.
• Tag 2–5 — Bauen. Hier wirken die KI-Werkzeuge am stärksten, weil neu gebaut wird und keine Altlast im Weg steht. Wir arbeiten in kurzen Runden: bauen, ausprobieren, nachschärfen. Sie sehen den ersten bedienbaren Stand in der Regel am zweiten oder dritten Tag.
• Tag 5–7 — Testen. Fünf bis acht Personen aus der Zielgruppe, je 30 bis 45 Minuten, Aufgabe statt Meinung. Wir schauen zu und helfen nicht, auch wenn es weh tut.
• Tag 7–10 — Auswerten und entscheiden. Beobachtungen, Zahlen und eine schriftliche Empfehlung: weiterbauen, Zuschnitt ändern oder lassen. Inklusive der Frage, was ein Produktivsystem zusätzlich bräuchte.

Der Rhythmus funktioniert auch remote. Für die Region Zürich, Zollikon und Küsnacht sind wir bei den Testterminen gern vor Ort, weil man beim Zuschauen mehr sieht als in einer Bildschirmfreigabe. In der übrigen Schweiz führen wir dieselben Sitzungen per Video durch; der Erkenntnisgewinn ist geringfügig kleiner, der Aufwand deutlich.

Weggelassen wird alles, was den Betrieb betrifft und nichts zur Erkenntnis beiträgt. Das ist in Ordnung, weil ein Prototyp keine Software ist, die laufen soll, sondern ein Experiment, das eine Frage beantworten soll. Wir schreiben die Auslassungen vor dem Start auf, damit die Grenze später nicht zur Verhandlungssache wird.

• Keine belastbare Zugriffskontrolle. Rollen werden angedeutet, nicht abgesichert. Der Prototyp läuft in einer geschlossenen Umgebung.
• Keine echten Personendaten. Testdaten sehen echt aus, sind aber erfunden. Das erspart die ganze Datenschutzdiskussion in der Erkenntnisphase.
• Keine Skalierung, keine Betriebsüberwachung. Acht Testpersonen sind keine achttausend Nutzer, und das muss der Prototyp auch nicht aushalten.
• Keine vollständige Fehlerbehandlung. Der vorgesehene Weg funktioniert, daneben darf es stolpern. Randfälle kosten viel Zeit und beantworten selten die gestellte Frage.
• Keine automatisierten Tests jenseits des Hauptpfads. Ein Wegwerfstück braucht kein Sicherheitsnetz für Änderungen, die es nie geben wird.
• Keine Barrierefreiheitsprüfung, keine Rechtstexte, keine Mehrsprachigkeit. Alles notwendig für ein Produkt, alles irrelevant für die Frage «will das jemand benutzen?».

Diese Liste ist der eigentliche Grund, warum die Methode wirtschaftlich aufgeht. Sie senkt den Preis der Erkenntnis so weit, dass man sich einen Irrtum leisten kann — und ein Irrtum, den man in der zweiten Woche bemerkt, kostet einen Bruchteil desselben Irrtums im achten Monat. Für den betriebenen Auftritt gilt danach wieder der volle Massstab, wie bei jeder Premium-Website.

Belastbar wird ein Prototyptest nur, wenn Menschen eine Aufgabe lösen sollen statt eine Meinung abzugeben — und wenn niemand ihnen dabei hilft. Die Frage «wie finden Sie das?» erzeugt Höflichkeit, die Aufgabe «buchen Sie einen Termin für nächsten Dienstag» erzeugt Beobachtungen.

Wir laden fünf bis acht Personen aus der tatsächlichen Zielgruppe ein, je 30 bis 45 Minuten. Jede erhält dieselben zwei bis drei Aufgaben, arbeitet allein und denkt dabei laut. Wir schweigen. Protokolliert werden vier Dinge: Wie viele lösen die Aufgabe ohne Hilfe, an welchen Stellen entsteht Zögern oder Rückschritt, welche Wörter benutzen die Personen für das, was sie suchen, und was sagen sie unaufgefordert über den Nutzen. Das dritte Protokollfeld ist unterschätzt: Es liefert die Begriffe, die später auf der Website stehen sollten.

Fünf Personen wirken wenig, decken aber erfahrungsgemäss den grössten Teil der gravierenden Bedienprobleme auf — dieselben Hürden wiederholen sich schnell. Was fünf Personen nicht beantworten, sind Fragen nach Zahlungsbereitschaft oder Marktgrösse; dafür braucht es andere Methoden, und wir sagen das, statt eine Beobachtung zu einer Statistik zu erklären. Der methodische Hintergrund steht im Glossar unter Usability-Testing.

Ein Hinweis zur Nachfrage: In unserer Google Search Console erscheint die Anfrage «ux prototyping services» mit 110 Impressionen auf Position 5.8 — Menschen suchen also bereits nach genau dieser Leistung, ohne dass es dafür bisher eine passende Seite bei uns gab. Das ist einer der Gründe, warum diese Seite existiert.

Ein Prototyp zur Ideenvalidierung beginnt bei CHF 10'000 exklusive Mehrwertsteuer und rechnet sich immer dann, wenn die Alternative eine Investition mit unbekanntem Ausgang ist. Die Rechnung ist einfacher, als sie klingt: Was kostet es, die falsche Software ein halbes Jahr lang zu bauen — und was kostet es, das vorher zu wissen?

Enthalten sind vier Dinge: das Schärfen der Annahme samt Abbruchkriterium, ein bedienbarer Prototyp der zwei bis drei tragenden Abläufe, ein Testdurchlauf mit fünf bis acht Personen aus der Zielgruppe und eine schriftliche Empfehlung mit Begründung. Nicht enthalten sind Betrieb, Zugriffskontrolle, Skalierung, Wartung und alles andere aus der Auslassungsliste weiter oben. Der Preis steigt, wenn echte Fremdsysteme angebunden werden müssen oder mehrere Rollen mit unterschiedlichen Rechten zu testen sind.

Zum Vergleich der Grössenordnungen: Eine vollständige Website liegt bei uns zwischen CHF 3'000 und CHF 25'000, laufendes SEO beginnt bei CHF 800 pro Monat, Local SEO bei CHF 300 pro Monat. Ein Prototyp ist also keine kleine Ausgabe — er ist eine Ausgabe, die eine grössere Ausgabe absichert. Eine erste Einordnung für Ihr Vorhaben gibt unser Projektrechner; wie sich Website-Budgets in der Schweiz zusammensetzen, steht unter Webdesign-Preise.

Nicht rechnen tut sich ein Prototyp, wenn die Antwort schon feststeht. Wenn Sie und Ihr Team sich einig sind, was gebaut werden soll, und es dafür bereits Nachfrage gibt, ist der Prototyp ein Umweg. Dann gehört das Geld in die Umsetzung. Auch das sagen wir im Erstgespräch.

Der tragfähige Teil wird neu gebaut, nicht fertiggestellt — mit entschiedener Architektur, Review und Tests. Das klingt nach Verschwendung und ist das Gegenteil: Der Prototyp hat seine Aufgabe erfüllt, sobald die offenen Fragen beantwortet sind, und ein Neubau mit bekannten Antworten geht deutlich schneller als der erste Anlauf.

Was im Neubau dazukommt, ist genau die Liste, die vorher fehlte: Rechteverwaltung und Anmeldung, Umgang mit Personendaten nach dem revidierten Datenschutzgesetz, automatisierte Tests über die kritischen Pfade, Fehlerbehandlung, Protokollierung, Betriebsüberwachung, Barrierefreiheit, Rechtstexte und die Messung von Ladezeit und Core Web Vitals unter echten Bedingungen. Wie dieser Prozess aussieht und welche Rolle KI-Werkzeuge darin behalten, beschreibt KI-gestützte Entwicklung.

Übernommen wird aus dem Prototyp fast nie der Code, aber fast immer das Wertvollere: der bewährte Ablauf, die Wortwahl aus den Tests, die Erkenntnis, welche Funktion niemand benutzt hat. Grössere Systeme setzen wir anschliessend als komplexe Weblösungen um; wenn aus der Idee ein Rechner oder Konfigurator wird, sehen Sie unter Konfigurator & Preisrechner, wie so etwas fertig aussieht.

Prototyping mit KI ist die falsche Wahl, wenn es keine offene Frage gibt, wenn die Frage nicht durch Beobachtung beantwortbar ist, oder wenn das Ergebnis produktiv gehen soll. Diese drei Fälle sind der Grund für die meisten unglücklichen Prototyp-Projekte.

• Keine offene Frage. Steht fest, was gebaut werden soll, und gibt es dafür Nachfrage, ist der Prototyp ein teurer Umweg. Dann ist der direkte Bau der schnellere Weg.
• Nicht beobachtbare Fragen. Marktgrösse, Zahlungsbereitschaft, rechtliche Zulässigkeit oder regulatorische Machbarkeit beantwortet kein Prototyp. Dafür braucht es Marktrecherche, Gespräche oder eine juristische Abklärung — Themen für die Startup-Beratung, nicht für ein Repository.
• Produktivabsicht von Anfang an. Wenn von Beginn weg echte Kundendaten fliessen sollen, sparen Sie mit einem Prototyp nichts. Dann gehört von Anfang an ordentlich gebaut.
• Kein Zugang zur Zielgruppe. Ohne fünf bis acht Testpersonen bleibt der Prototyp eine Demo für den eigenen Bildschirm. Wir klären vor dem Start, wer testet — das ist Teil der Vorbereitung, nicht ein Nebenpunkt.
• Keine Bereitschaft, die Idee zu verwerfen. Ein Test, dessen Ergebnis schon feststeht, ist keine Prüfung, sondern eine Bestätigungsübung. Dann sparen Sie sich das Geld und bauen gleich.

Und die unbequemste Einschränkung: Ein Prototyp beantwortet «funktioniert die Bedienung» und «verstehen es Menschen» sehr gut — «wird jemand dafür bezahlen» nur indirekt. Wer das verwechselt, hält ein Bedienbarkeitsergebnis für einen Marktbeleg. Wir trennen das im Bericht sauber und schreiben hin, welche Frage nach dem Test noch offen ist. Was wir bisher umgesetzt haben, steht in den Referenzen.