Ein Prototyp verleiht einem Designvorschlag etwas, das eine Präsentation nicht bieten kann: Konsequenzen. Jemand wählt eine Option, gelangt zum nächsten Screen und erlebt direkt, ob das Ergebnis den eigenen Erwartungen entspricht. Beim Prototyp-Testing werden genau diese Momente genutzt, um ein Design zu prüfen, bevor das Team Zeit und Ressourcen in die finale Entwicklung steckt.
Ob der Prototyp eine Papierskizze ist, ein Klickdummy aus verknüpften Screens oder schon funktionierender Code, ist zweitrangig. Entscheidend ist, ob Testpersonen die Aufgabe wirklich so ausprobieren können, wie es die Forschungsfrage verlangt. Ein schicker Screen, der sich nur für eine Demo eignet, kann zwar spannende Diskussionen anstoßen – verrät einem aber nicht, wie sich Nutzer:innen eigenständig durch das Produkt bewegen würden.
Am Anfang steht die Frage, die der Prototyp beantworten soll
Nehmen wir als Beispiel einen fiktiven Bike-Sharing-Dienst, der den Ablauf beim Beenden einer Fahrt überarbeitet. Die Unklarheit könnte sich darum drehen, wo das Parken erlaubt ist, ob das Schloss wirklich verriegelt ist oder warum Zusatzgebühren anfallen. Für jede dieser Fragen müssen andere Teile des Erlebnisses glaubwürdig umgesetzt sein.
Eine Karte und realistische Parkhinweise reichen oft schon aus, um das Verständnis der Regeln zu prüfen. Um zu testen, ob jemand das erfolgreiche Abschließen erkennt, braucht es das passende Feedback und den richtigen Ablauf. Will man herausfinden, wie Gebühren wahrgenommen werden, sind plausible Beträge und Erklärungen nötig. Jede einzelne Kontoeinstellung nachzubauen, macht hingegen nur Arbeit, ohne die Tests wirklich voranzubringen.
Genau darum geht es bei der Detailtiefe (Fidelity) von Prototypen: gezielt zu entscheiden, welche Details sich wie das spätere Produkt verhalten oder anfühlen müssen. Die Detailtiefe sollte sich nach den offenen Fragen richten – nicht nach der starren Regel, dass jedes Projekt zwingend dieselbe Abfolge von Wireframes bis hin zu Hochglanz-Screens durchlaufen muss.
Genug Freiraum für echte Interaktionen schaffen
Der offensichtliche Weg durch einen Prototyp ist oft der, den das Design-Team klickbar gemacht hat. Führt jede andere Abzweigung ins Leere, lernen Testpersonen schnell, einfach den verfügbaren Hotspots zu folgen statt den Inhalten auf der Seite. So wirkt ein unfertiges Design plötzlich viel einfacher zu bedienen, als es in Wirklichkeit ist.
Bauen Sie plausible Handlungsoptionen rund um die Aufgabe ein – inklusive der Screens, die nötig sind, um Erfolge zu bestätigen oder Fehler zu korrigieren. Die Betrachtung der Nielsen Norman Group zu Breite und Tiefe von Prototypen veranschaulicht gut, warum der abgedeckte Funktionsumfang für den Test so wichtig ist. Für Teams bedeutet das: auch die Wege mitzudenken, die Testpersonen sinnvollerweise ausprobieren könnten, nicht nur den Idealpfad (Happy Path).
Nutzen Sie realistische Inhalte, sobald Text und Daten Entscheidungen beeinflussen. Ein Platzhalter-Kontostand, generische Fehlermeldungen oder leere Suchergebnisse verändern das Verhalten von Nutzer:innen spürbar. Testdaten sollten sicher teilbar sein und für die Aufgabe glaubwürdig wirken – ohne dass Teilnehmende private Daten preisgeben müssen.
Testpersonen das Design unvoreingenommen entdecken lassen
Geben Sie Testpersonen ein Aufgabenszenario an die Hand, das das Ziel beschreibt, ohne sie Schritt für Schritt durch das Interface zu leiten. Klären Sie technische Grenzen des Prototyps gleich zu Beginn, aber verzichten Sie auf eine Einführungstour, die genau das Wissen vorwegnimmt, das die Studie eigentlich untersuchen soll.
Im moderierten Testing können Sie als Testleitung fehlende Funktionen einfach kurz ansprechen und festhalten, was die Person an der Stelle erwartet hätte. In unmoderierten Sessions braucht es dafür eine klare Möglichkeit im Test-Setup, solche Hürden zurückzumelden. Wichtig ist in beiden Fällen: Unterscheiden Sie zwischen reinen Grenzen des Prototyps und echten Problemen im Designkonzept. Beides ist relevant, verlangt aber völlig unterschiedliche Maßnahmen.
Wenn Ihr Team mit Figma arbeitet, bietet Ballparks Prototype-Testing einen einfachen Weg, diese Entwürfe direkt in Studien einzubinden. Testen Sie das genaue Setup der Teilnehmenden vor dem Start: Ein Prototyp, der im Browser des Design-Teams perfekt läuft, kann auf anderen Geräten schnell an fehlenden Berechtigungen oder unpassenden Skalierungen scheitern.
Aus den Erkenntnissen die nächste Iteration ableiten
Bleiben wir beim Bike-Sharing-Beispiel: Vielleicht parkt eine Testperson das Rad völlig richtig, bleibt aber unsicher, ob die Fahrt wirklich beendet ist. Ein klarerer Bestätigungstext kann diese Unsicherheit sofort auflösen; eine allgemeine Onboarding-Tour würde diesen kritischen Moment hingegen kaum abfangen.
Halten Sie fest, was genau passiert ist, wie Sie das Feedback interpretieren und was der nächste Test klären soll. Sorgen Sie für eine saubere Versionierung, wenn sich der Prototyp zwischen einzelnen Sessions ändert – nur so lassen sich Erkenntnisse verlässlich dem Design zuordnen, das die Testpersonen auch tatsächlich vor sich hatten.
Ein gelungener Prototyp-Test räumt Unklarheiten rund um ein Design aus. Er belegt jedoch weder technische Stabilität noch Marktpotenzial oder Barrierefreiheit der fertigen Umsetzung. Für diese Fragen braucht es eigene Belege im weiteren Verlauf der Entwicklung – inklusive weiterer Tests, sobald die Funktionen im echten System laufen.