Von der Idee zum klickbaren Prototyp in fünf Tagen: ein realistischer Ablauf

Fünf Arbeitstage reichen, um aus einer Idee einen klickbaren Prototyp zu machen und ihn von fünf Personen aus der Zielgruppe testen zu lassen. Der Grund, warum es fünf und nicht ein Tag sind, hat nichts mit der Bauzeit zu tun: Das Bauen ist mit heutigen KI-Werkzeugen der kürzeste Teil der Woche, die Zeit geht für den Zuschnitt der Frage, für echte Inhalte, für die Testrunde und für die Auswertung drauf.

Das Format ist nicht neu. Jake Knapp beschrieb 2016 mit dem Design Sprint eine fünftägige Struktur, in der ein Team von der Frage über die Skizze und den Prototyp bis zum Nutzertest kommt — damals gebaut aus Klickattrappen und Präsentationsfolien. Was sich seither geändert hat, ist die Mitte: Der Prototyp muss nicht mehr vorgetäuscht werden, er kann echt sein. Damit verschiebt sich die knappe Ressource vom Bauen zum Entscheiden.

Warum fünf Tage und nicht einer

Ein Tag reicht, um zu bauen; fünf Tage braucht es, um zu wissen, ob das Gebaute etwas taugt. Wir haben an anderer Stelle beschrieben, wie ein Prototyp an einem einzigen Tag entsteht — dieser Artikel ist die Fortsetzung für den Fall, dass am Ende eine Entscheidung stehen soll und nicht nur eine Demo.

Der Unterschied lässt sich an einem Beispiel zeigen. Ein Treuhandbüro will wissen, ob Kundinnen ihre Belege künftig selbst hochladen würden statt sie im Couvert zu bringen. Nach einem Tag Bauzeit existiert eine Upload-Maske, die funktioniert. Sie beantwortet die Frage aber nicht, weil die Frage nie technischer Natur war. Erst wenn fünf echte Kundinnen es versucht haben und dabei drei von ihnen an derselben Stelle abbrechen, weiss man etwas.

Deshalb sind die fünf Tage nicht fünfmal so viel Bauzeit, sondern eine andere Verteilung: ein Tag Denken, ein Tag Bauen, ein Tag Füllen, ein Tag Testen, ein halber Tag Entscheiden.

Tag 1: Die Frage schärfen, bevor irgendetwas gebaut wird

Der erste Tag gehört nicht dem Werkzeug, sondern der Frage — und zwar so lange, bis sie in einem Satz steht, der eine falsifizierbare Annahme enthält. «Wir bauen ein Kundenportal» ist keine Frage. «Laden Kundinnen ihre Belege selbst hoch, wenn der Weg drei Klicks hat und sie eine Bestätigung sehen?» ist eine.

Aus diesem Satz folgt der Zuschnitt automatisch. Alles, was nicht nötig ist, um diese eine Annahme zu prüfen, fällt weg: keine Registrierung, keine Rechnungsübersicht, keine Einstellungen, kein Design-System. Praktisch bleiben zwei bis drei Bildschirme übrig.

Der zweite Teil des Tages gehört den Menschen. Wer testet am Donnerstag? Fünf Namen, fünf Termine, fünf Zusagen — schriftlich. Dieser Schritt wird fast immer aufgeschoben und ist fast immer der Grund, warum eine Prototyp-Woche im Sand verläuft. Am Montag ist es leicht, fünf Termine für Donnerstag zu bekommen; am Mittwochabend ist es unmöglich.

Tag 2: Das Grundgerüst bauen

Am zweiten Tag entsteht der lauffähige Kern, und zwar in einem Zug statt in Etappen: ein durchgehender Ablauf vom ersten Bildschirm bis zur Bestätigung, ohne Sonderfälle, ohne Fehlerbehandlung, ohne Feinschliff. Werkzeuge wie Lovable, v0 oder Bolt erzeugen aus einer Beschreibung eine anklickbare Oberfläche; welches davon passt, hängt vom Schwerpunkt ab — wir haben die Unterschiede im Vergleich der App-Baukästen auseinandergenommen.

Wichtiger als die Werkzeugwahl ist die Arbeitsweise: kleine Schritte, nach jedem Schritt anklicken. Wer fünf Änderungen auf einmal beschreibt und das Ergebnis nicht prüft, verbringt den Nachmittag damit, herauszufinden, welche der fünf den Bruch verursacht hat.

Ob am zweiten Tag schon eine Datenbank dazukommt, entscheidet die Frage vom Montag. Für «wird der Ablauf verstanden?» genügt eine Ansicht, die so tut als ob. Für «funktioniert der Upload überhaupt?» braucht es echte Speicherung — dann kommt ein Dienst wie Supabase dazu, was die Werkzeugkosten für den Monat erhöht, aber nicht den Zeitplan sprengt. Wie weit man dabei gehen sollte, hängt daran, wo für euch die Grenze zwischen Prototyp und Produktionssystem verläuft.

Tag 3: Echte Inhalte statt Blindtext

Der dritte Tag ist der am häufigsten übersprungene und der mit dem grössten Einfluss auf die Testergebnisse, weil Menschen an echten Inhalten scheitern und an Blindtext nicht. «Lorem ipsum» in einer Belegliste verdeckt genau das Problem, das man sucht: dass niemand weiss, ob «Beleg», «Dokument» oder «Quittung» gemeint ist.

Konkret heisst das: echte Beispieldaten mit realistischen Längen, echte Beschriftungen auf Knöpfen, echte Fehlermeldungen im richtigen Ton. Wer Kundendaten verwendet, nimmt anonymisierte oder erfundene Datensätze — echte Personendaten haben in einem Prototyp nichts verloren.

Der zweite Teil des Tages gehört dem Testleitfaden. Er besteht aus einer Aufgabe («Bitte reichen Sie die Quittung von letzter Woche ein») und drei Fragen für danach. Kein Skript, keine Erklärung, keine Tour durch die Oberfläche. Wer beim Test erklärt, testet die eigene Erklärung.

Tag 4: Fünf Menschen testen lassen

Am vierten Tag testen fünf Personen aus der Zielgruppe je zwanzig Minuten — das ist die Runde, die nach Jakob Nielsens klassischer Auswertung aus dem Jahr 2000 rund 85 Prozent der Usability-Probleme sichtbar macht, weil sich die Beobachtungen ab der fünften Person zu wiederholen beginnen. Fünf mal zwanzig Minuten plus Pausen ergeben einen halben Tag; die andere Hälfte gehört dem Notieren.

Der Ablauf pro Person ist immer gleich: Aufgabe nennen, Mund halten, zuschauen, mitschreiben. Notiert wird, wo jemand zögert, wo jemand etwas anderes anklickt als erwartet und wo jemand eine Frage stellt. Nicht notiert wird, was die Person über das Produkt sagt — Meinungen sind höflich, Verhalten ist ehrlich. Für eine sauber geführte Runde lohnt ein Blick auf die Grundlagen des Usability-Testings.

Nach jeder Person wird nichts geändert. Das ist die schwerste Regel des Tages: Wer nach Person zwei umbaut, hat am Abend fünf Tests von fünf verschiedenen Prototypen und kann nichts vergleichen.

Tag 5: Auswerten und entscheiden

Der fünfte Tag endet mit genau einer von drei Entscheidungen: weiterbauen, umbauen oder verwerfen — und ohne diesen Punkt war die Woche eine teure Bastelübung. Die Auswertung selbst dauert selten länger als zwei Stunden: Alle Beobachtungen kommen auf eine Liste, gleiche Beobachtungen werden zusammengefasst, und alles, was bei drei von fünf Personen auftrat, gilt als Muster.

Dann wird die Frage vom Montag beantwortet, wörtlich und ohne Ausweichen. Hat der Prototyp die Annahme bestätigt, widerlegt oder nichts gezeigt? Das dritte Ergebnis ist häufiger als gedacht und ebenfalls brauchbar, weil es meist bedeutet, dass die Frage falsch geschnitten war.

Der Wochenplan mit Stundenbudget

Diese 25 Stunden lassen sich durchrechnen. Bei einem internen Stundensatz von CHF 120 sind das CHF 3'000 an gebundener Arbeitszeit. Dazu kommen die Werkzeuge: ein Monat eines App-Baukastens ab rund $25, bei Bedarf ein Backend-Dienst ab rund $25 und ein Hosting-Zugang ab rund $20 — realistisch also 50 bis 70 Franken, sofern man die Abos nach der Woche wieder kündigt. Zusammen etwa CHF 3'060.

Diese Rechnung ist nur dann ehrlich, wenn die 25 Stunden tatsächlich freigeräumt sind. In der Praxis scheitert die Woche fast nie am Können und fast immer daran, dass Tagesgeschäft dazwischenkommt und aus fünf Tagen fünf Wochen werden. Wer das kennt, verlagert die Woche nach aussen: Ein begleiteter Prototyp zur Ideenvalidierung beginnt bei CHF 10'000 und enthält den Zuschnitt, den Bau, die Testrunde und eine dokumentierte Empfehlung. Der Unterschied zur Eigenleistung liegt weniger im Bauen als in der Verbindlichkeit des Freitags. Wie sich das in grössere Vorhaben einordnet, zeigt die Übersicht zu Softwarekosten in der Schweiz.

Was in fünf Tagen bewusst nicht entsteht

Ein Fünf-Tage-Prototyp enthält keine Rechteverwaltung, keine geprüfte Datensicherung, keine Fehlerbehandlung für Sonderfälle und keine echten Personendaten — und diese Lücken sind Absicht, nicht Nachlässigkeit. Jede dieser Eigenschaften kostet mehr Zeit als der ganze Kernablauf und beantwortet keine einzige offene Frage.

Ebenso wenig entsteht ein Design im engeren Sinn. Der Prototyp soll benutzbar aussehen, nicht fertig. Ein zu poliertes Ergebnis ist sogar schädlich, weil Testpersonen dann über Farben reden statt über den Ablauf.

Und schliesslich entsteht keine Codebasis, auf der man ohne Prüfung weiterbaut. Wenn die Entscheidung am Freitag «weiterbauen» lautet, folgt ein eigener Schritt mit Datenmodell, Rechten und Betrieb — planbar als KI-gestützte Entwicklung oder als klassische Individualsoftware, je nach Umfang.

Fazit: fünf Tage kaufen eine Entscheidung

Die Woche liefert nicht Software, sondern Gewissheit. Am Freitagabend weisst du, ob deine Annahme trägt, und du hast diese Antwort für rund 25 Arbeitsstunden bekommen statt für ein halbes Projektbudget. Genau darin liegt der Wert: nicht im Prototyp, sondern in dem, was er verhindert.

Wer die Woche zum ersten Mal macht, sollte klein anfangen — eine Annahme, drei Bildschirme, fünf Testpersonen. Die Versuchung, gleich zwei Fragen zu prüfen, kostet zuverlässig beide Antworten.