App-Idee mit einem Prototyp validieren: Schritt für Schritt
Ein App-Prototyp zeigt vor der ersten Codezeile, ob eine Idee bei echten Nutzern funktioniert: Prototyp-Arten, Testablauf und Messkriterien.
rabbitclip-TeamVeröffentlicht: 6 Min. Lesezeit
Kurz gesagt
Eine App-Idee mit einem Prototyp zu validieren heißt, Bildschirme und Ablauf vor der ersten Codezeile als klickbaren Entwurf aufzubauen und echten Nutzern vorzulegen. Das Ziel ist kein hübsches Mock-up, sondern die Antwort auf eine einzige Frage: Möchte diese Person diese Aufgabe mit dieser App erledigen, und kann sie es? Ein Prototyp ist in wenigen Tagen fertig, einige Gespräche zeigen, ob die Idee trägt, und eine falsche Annahme tritt vor dem Entwicklungsstart zutage, also zum niedrigsten Preis.
Die Validierung wird oft übersprungen, weil der Ideengeber das Ergebnis schon zu kennen glaubt. Doch die Zustimmung des eigenen Teams oder des engen Umfelds ist kein Beweis. Stellen Sie sich eine Terminbuchungs-App vor: Für ihren Besitzer ist der Ablauf offensichtlich, aber ein Kunde, der ihn zum ersten Mal sieht, bleibt vielleicht schon auf dem zweiten Bildschirm hängen. Das erst nach der Entwicklung zu erfahren, kostet Monate an Aufwand und Budget. Am Prototyp kostet es einen Nachmittag.
Worin unterscheiden sich Prototyp und MVP?
Ein Prototyp ist ein Modell, das nicht funktioniert, aber so aussieht, als täte es das. Die Bildschirme sind verknüpft, die Schaltflächen führen zum nächsten Bildschirm, doch dahinter gibt es weder einen echten Server noch eine Datenbank oder ein Zahlungssystem. Sein Zweck ist es, eine Hypothese zu prüfen, und er wird gebaut, um weggeworfen zu werden.
Ein MVP dagegen ist ein echtes Produkt, nur kleiner. Echte Nutzer geben echte Daten ein, das System läuft tatsächlich, und es kann in die Stores gelangen. Die übliche Reihenfolge lautet: erst der Prototyp, danach bei Bedarf das MVP. Eine Idee, die im Prototypstadium verworfen wird, verursacht nie MVP-Kosten, und eine Idee, die es übersteht, schärft zugleich den Umfang des MVP.
Welcher Prototyp beantwortet welche Frage?
Es gibt nicht die eine Prototyp-Art; die Wahl hängt von der Frage ab, die Sie beantwortet haben möchten. Schreiben Sie zuerst die Frage auf und wählen Sie dann das günstigste Werkzeug, das sie beantworten kann.
Wenn Sie prüfen, ob das Problem selbst real ist, genügen eine Papierskizze und ein Gespräch. Wenn Sie prüfen, ob der Ablauf verstanden wird, brauchen Sie klickbare Bildschirme aus einem Design-Werkzeug. Wenn Sie prüfen, ob etwas technisch machbar ist, schreiben Sie ein kleines Stück Code, das nur den riskanten Teil abdeckt.
- Papier- oder Handskizze: Stimmen Problem und Grundablauf? In wenigen Stunden testbar
- Klickbares Bildschirmmodell: Werden Ablauf und Texte verstanden? Auf einem echten Telefon ausprobiert
- Manuell betriebener Dienst: Im Hintergrund erledigt ein Mensch die Arbeit, während der Nutzer eine automatische App sieht; so lässt sich messen, ob die Nachfrage echt ist
- Technischer Spike: Geprüft wird nur, ob die riskanteste Anbindung oder Funktion funktioniert
Wer soll den Prototyp testen, und wie?
Die Testpersonen sollten aus der Zielgruppe stammen. Freunde und Familie sind meist freundlich und verbergen ihre echte Reaktion. Eine kleine Gruppe von fünf bis acht Personen reicht oft, um zu sehen, dass sich dieselben Probleme zu wiederholen beginnen; wichtiger als die Zahl ist, dass die Personen wirklich zur Zielgruppe gehören.
Erklären Sie die App während des Gesprächs nicht. Geben Sie dem Nutzer eine Aufgabe, etwa «Buchen Sie einen Termin für morgen», und schweigen Sie dann und beobachten Sie. Wo er zögert, was er falsch versteht und welche Schaltfläche er sucht, das sind die echten Lücken Ihres Produkts.
Zeichnen Sie das Gespräch auf oder machen Sie Notizen, halten Sie aber fest, was geschehen ist, ohne Deutung. Sagt ein Nutzer «sieht gut aus», werten Sie das nicht als wertvoll. Sätze, die Verhalten beschreiben, wie «ich würde das wöchentlich nutzen» oder «so mache ich das heute», sind die eigentlichen Daten.
Woran erkennt man, dass die Idee funktioniert hat?
Legen Sie die Erfolgskriterien vor dem Test fest, nicht danach. Sonst lässt sich jedes Ergebnis als gutes lesen. Die Kriterien sind, ob der Nutzer die Aufgabe ohne Hilfe abgeschlossen hat, welches Problem er beim Erzählen benannt hat und ob er einen nächsten Schritt gehen würde, etwa sich auf eine Warteliste setzen zu lassen oder vorzubestellen.
Legen Sie auch die Schwelle im Voraus fest. Wenn Sie erwarten, dass die meisten Personen mit der Aufgabe den Ablauf ohne Hilfe schaffen, schreiben Sie das auf. Die Schwelle dürfen Sie selbst wählen, aber sie muss vor Testbeginn feststehen.
- Hat der Nutzer die Aufgabe abgeschlossen, ohne um Hilfe zu bitten?
- Sind mehrere Personen an derselben Stelle hängen geblieben?
- Wie löst der Nutzer das Problem heute, und ist er damit zufrieden?
- Wäre er zu einem konkreten Schritt bereit, etwa Warteliste, Vorregistrierung oder Vorbestellung?
Welche Fehler passieren bei der Prototyp-Validierung häufig?
Der häufigste Fehler ist, den Prototyp zu stark zu polieren. Ein Modell mit jedem fertigen Pixel bringt Nutzer dazu, über Ästhetik zu sprechen statt über den Ablauf, und weil Aufwand investiert wurde, wird das Team bei Kritik defensiv. Ein Prototyp sollte gut genug sein, um eine Hypothese zu prüfen, und nicht besser.
Der zweite Fehler sind Suggestivfragen. Die Antwort auf «Gefällt Ihnen diese Funktion?» lautet fast immer ja. Der dritte Fehler ist, negatives Feedback auf Nutzer zu schieben, die etwas missverstanden hätten; bleiben drei Personen an derselben Stelle hängen, liegt das Problem im Bildschirm und nicht bei den Menschen.
- Den Prototyp zu stark polieren und das Ergebnis in eine Debatte über das Aussehen verwandeln
- Suggestivfragen stellen, die ein Ja nahelegen
- Nur mit bekannten Personen testen und ihre Freundlichkeit als Beweis zählen
- Die Erfolgskriterien erst nach dem Test festlegen
Wann ist ein Prototyp überflüssig oder die falsche Wahl?
Liegt das Problem, das Sie lösen, in einem gut bekannten Feld mit ähnlichen Produkten und einem etablierten Ablauf, kann ein langer Prototypzyklus überflüssig sein. Dann ist der direkte Weg zu einem kleinen MVP und echten Nutzungsdaten lehrreicher. Ein Prototyp ist wertvoll, wenn die Unsicherheit hoch ist, und Zeitverschwendung, wenn sie niedrig ist.
Ein Prototyp ist außerdem das falsche Werkzeug, um hardwareabhängiges Verhalten zu testen, etwa Kameraqualität, Sensoren oder die Offline-Tauglichkeit der App. Solche Risiken zeigen sich nur in einem kleinen technischen Versuch. Klären Sie, ob Ihr Zweifel den Markt und das Verhalten betrifft oder die Technik; ein Werkzeug bedient nicht beides.
Ein Prototyp ist kein Hindernis für die Idee, sondern ein Gefallen an ihrem Besitzer: Er fängt eine falsche Annahme günstig ab und stärkt eine richtige. Schreiben Sie die eine Frage auf, die beantwortet werden soll, bauen Sie den günstigsten Prototyp, der sie beantworten kann, testen Sie ihn mit einigen Personen aus der Zielgruppe und legen Sie die Kriterien vorher fest. Wenn Sie gemeinsam überlegen möchten, wie sich Ihre Idee testen lässt, können Sie mit rabbitclip ein Erstgespräch vereinbaren.
Häufige Fragen
Wie lange dauert es, einen Prototyp zu erstellen?
Das hängt vom Umfang der Idee und der gewählten Art ab. Eine Papierskizze dauert einige Stunden, ein klickbares Bildschirmmodell meist einige Tage. Je mehr Sie aufnehmen, desto länger dauert es; bilden Sie deshalb nur den Hauptablauf ab, den Sie testen müssen.
Kann ich einen Prototyp ohne Programmierkenntnisse erstellen?
Ja. Papierskizzen und klickbare Bildschirmmodelle in Design-Werkzeugen brauchen keinen Code, ebenso wenig ein manuell betriebener Dienst. Code ist nur nötig, wenn Sie die technische Machbarkeit testen.
Mit wie vielen Personen sollte ich den Prototyp testen?
Fünf bis acht Personen aus der Zielgruppe genügen oft, um zu sehen, dass sich dieselben Probleme zu wiederholen beginnen. Wichtiger als die Zahl ist, dass sie wirklich zur Zielgruppe gehören; die Meinung von Freunden und Familie ist kein verlässlicher Maßstab.
Was ist der nächste Schritt, wenn der Prototyp überzeugt?
Sie nehmen den Hauptablauf, der sich bewährt hat, und definieren darum ein kleines MVP. Sie bauen nur diesen Ablauf wirklich und messen ihn dann mit echten Nutzern. Die Entscheidungen zu Texten und Ablauf, die Sie am Prototyp gelernt haben, fließen direkt in die Entwicklung ein.
