Um die Experimente der Product Discovery schnell und effektiv durchführen zu können, werden Prototypen verwendet (Cagan M. , 2022). Diese können unterschiedlich komplex sein, doch in jedem Fall sind sie weniger aufwändig als ein Produkt. Laut Cagan (2022) testen starke Produktteams 10 bis 20 Produktideen pro Woche anhand von Prototypen.
Das klingt erst einmal aufwendig, jedoch sind auch einfache Wireframe-Zeichnungen hier als Prototyp zu verstehen und die Besprechung dieses Prototyps mit einer Userin gilt als Test dieses. Trotzdem wird hier das Testen von Prototypen in den Fokus gestellt. Eigene Annahmen und Hypothesen werden konsequent überprüft.
Es kann natürlich passieren, dass ein Experiment zu dem Ergebnis kommt, dass der Prototyp nicht weiterentwickelt wird. Besser dies passiert bei einem Prototyp, als dies erst beim fertigen Produkt herauszufinden.
Planen Sie ein, dass einer weggeworfen wird; das passiert so oder so.
Table of Contents
5 Prinzipien für Prototypen
Im nächsten Abschnitt werden unterschiedliche Arten von Prototypen beschrieben. Alle Formen von Prototypen haben jedoch folgende fünf Prinzipien gemeinsam:
- Prototypen sollten weniger Zeit und Mühe kosten als das resultierende Produkt
- Das Erstellen und Testen von Prototypen zwingt das Team, Probleme wesentlich gründlicher zu durchdenken
- Prototypen helfen, ein gemeinsames Verständnis zu entwickeln
- Prototypen sollten so schnell und günstig wie möglich zu erstellen sein. Ein aufwendiger (High-Fidelity) Prototyp sollte nur dann verwendet werden, wenn es nötig ist.
- Prototypen adressieren die vier Risiken (Value, Feasibility, Usability, Viability) und sind gleichzeitig eine ideale Vorlage für Programmierer, wenn das Produkt dann gebaut werden soll. Zusätzliche Akzeptanzkriterien können ergänzt werden – z.B. in Form von Gherkin-Szenarien.
Arten von Prototypen
Es gibt unterschiedliche Arten von Prototypen und jeder hat unterschiedliche Eigenschaften und dient zum Testen unterschiedlicher Aspekte.
Feasibility-Prototypen
- Von Programmierern geschrieben
- Technische Machbarkeit während der Discovery prüfen (neue Technologien, neuer Algorithmus, Leistungseinschätzung)
- Idee: gerade genug Code schreiben, um das Feasibility Risk zu behandeln („Können wir es mit den verfügbaren Mitteln bauen?“)
Nutzerprototypen (User-Prototyping)
- Hier wird das „Value Risk“ behandelt („Werden User:innen es kaufen/nutzen?“)
- Simulationen auf einer Spanne von-bis:
- Von Wireframes ohne Funktion (Low-Fidelity-Nutzerprototypen)
- Bis Feeling und Aussehen fast schon wie eigentliche Produkte (High-Fidelity-Prototypen)
Live-Data-Prototypen
- Ziel: Erfassen tatsächlicher Daten
- B. für die Frage „Wohin würden User im geplanten Workflow klicken?“
- Dafür braucht man:
- Den Prototypen
- Live-Traffic
Hybrid-Prototypen
- Mischformen der genannten Prototypen
- B. „Wizard-of-Oz-Prototypen“: Frontend User verwendet einen High-Fidelity-Nutzerprototyp und hinter den Kulissen steckt eine echte Person, die manuell ausführt, was dann irgendwann automatisiert ablaufen soll (z.B. für ein geplantes Chatprogramm)
Prototypen in Verbindung mit Gherkin
Aus jahrelanger Erfahrung in der Software-Produktentwicklung ist für mich die Kombination aus der Beschreibungs-Syntax Gherkin und einfachen Nutzer-Prototypen eine sehr effektive Herangehensweise, um getestete Prototypen mit dem Team für die Entwicklung vorzubereiten. Dabei achte ich auch auf einige Kleinigkeiten, die ich hier gern einmal mit euch teilen möchte.
Ich würde beispielsweise oft eine Aufgabe (z.B. eine User Story in Jira) folgendermaßen beschreiben:
Titel
Wie in Gherkin vorgesehen, braucht die Aufgabe einen sprechenden Titel. Dabei achte ich darauf, nicht zu viele Nominalisierungen zu verwenden. Nominalisierungen – also das Verpacken von Sachverhalten in einem einzigen Substantiv – sind besonders in der deutschen Sprache beliebt und werden im Business-Kontext gern verwendet. Warum? Sie haben einen „offiziellen“ Touch.
Beispiel:
Ohne Nominalisierung: „User kopiert Datei“
Nominalisierung: „Kopierfunktion“
Die „Kopierfunktion“ klingt irgendwie „amtlicher“. Warum ich trotzdem die erste Variante bevorzuge? Die Nominalisierung „friert“ die Aktion ein. Der ganzen Angelegenheit wird das Leben genommen. Der User kommt oft durch Nominalisierungen in der Formulierung gar nicht mehr vor, auch nicht implizit. Das „Wer macht Was“ wird eliminiert. Wenn ich hingegen schreibe „User kopiert Datei“ habe ich direkt ein Bild vor Augen, welches viel einfacher zum Start in eine Diskussion dient, als eine Nominalisierung. Nominalisierungen sind etwas Feststehendes. Ich bevorzuge aber lebendige Formulierungen. So kann man besser ins Gespräch einsteigen und das ist es, was ich mit Beschreibungen bezwecken will. Mehr dazu findet sich im Metamodell der Sprache aus dem NLP, welches für Produktverantwortliche meiner Ansicht nach ungeheuer nützlich ist.
User Story
Als nächstes braucht die Aufgabe eine User Story. Damit wird idealerweise in drei Zeilen der Kontext, klar: WER macht WAS und WOZU. Die User Stories formuliere ich mit dem Team und Stakeholdern so lange um, bis sie für alle passt.
Das läuft ungefähr so ab: Wenn ich über eine Aufgabe sprechen möchte, lese ich die User Story langsam vor, mache Pausen nach jeder Zeile und eine längere Pause am Ende. Ich frage dann „Was kann hier noch verbessert werden?“ und lade damit zum gemeinsamen Umformulieren ein. Wenn ich einfach Frage: „Passt das?“ wird die Hemmschwelle größer sein, die Formulierung zu kritisieren. Aber genau das möchte ich ja. Also achte ich hier auf offene Fragen (die nicht mit ja oder nein beantwortet werden können).
Nun wissen alle Beteiligten, worum es geht. Weiter geht es dann mit den Details.
Szenarien
In Gherkin gilt: Specification by Example. Und genau das ist die Schönheit dieser Beschreibungssprache. Es werden Beispiele beschrieben:
Angenommen ich bin ein neuer User, der noch nie diese Anwendung verwendet hat und sie von einem guten Freund über einen Empfehlungs-Link erreicht hat, wenn ich dann auf die Anmeldeseite komme, dann möchte ich ein gern sehen, worum es bei dieser Anwendung geht und ich möchte sehen, welche Firma dahinter steckt.
Das kann man sich vorstellen, oder? Ich mag diese Beschreibungen, weil sie nicht die Oberflächenelemente, sondern das Verhalten beschreiben. Und das auf die Art und Weise, die unser Gehirn am einfachsten versteht: Anhand eins lebendigen Beispiels. Es ist ein riesiger Unterschied, ob ich diese Art der Beschreibung verwende oder folgendes:
- Seite zum Registrieren
- Logo
- Slogan
Was genau ist der Unterschied im Arbeitsalltag? Wir sprechen mehr. Wir nehmen diese Beispiele nicht einfach hin. Wir haben das Gefühl, sie betreffen und mehr. Wir engagieren uns mehr. Das ist es, was ich mir von einem Team wünsche.
Das Verhalten wurde nun beschrieben. Als nächstes brauchen wir ein Bild, um das Ganze noch schneller und einfacher zu gestalten.
Nutzer-Prototyp
Unter ein Gherkin-Szenario platziere ich gern ein Bild, z.B. einen einfachen Wireframe. Damit wird dann klar, wie das Ganze ungefähr aussehen soll. Diese Bilder können von einer Designerin erstellt worden sein, das wäre natürlich der Idealfall. Die Designerin ist in diesem Idealfall dann auch während der Besprechung anwesend. Der Prototyp wird gemeinsam mit der Story und den Beschreibungen besprochen und muss ggf. angepasst werden. Alles zusammen sollte ein sinnvolles Ganzes ergeben.
Bei Teams, mit denen ich noch nicht lange arbeite, betone ich an diesem Punkt, dass die Gherkin-Beschreibung die erste Wahrheit für das Verhalten des neuen Features ist und das Bild zeigt, wie es aussehen soll. Ich habe es immer wieder erlebt, dass ein Nutzer-Prototyp sozusagen „abprogrammiert“ wurde und dann erst später Unstimmigkeiten im Verhalten aufgefallen sind. Besonders bei „visuellen“ Menschen besteht die Gefahr, sich an das Bild zu halten und den Text nicht so sehr zu beachten (und die meisten Menschen sind eher visuell fokussiert). Dies kann man verhindern, indem klar ist, dass zunächst das WARUM und das Verhalten des Features engagiert besprochen und verstanden wird. Das ist viel einfacher, wenn nicht nur ein Bild vorhanden ist, sondern auch ein Gherkin—Szenario. Dieses Szenario MUSS dann (als Teil der Definition of Done) erfüllt werden.