Product Design Sprint 4: Den Prototyp ausarbeiten

Die Ausarbeitung eines Prototyps kann abhilfe schaffen. Fast täglich fliegen sie ein und lassen den Entwicklern nicht selten einen kalten Schauer den Rücken hinunterlaufen. Schwerwiegende Bugs, die vor allem über einen längeren Zeitraum nicht behoben werden, können das Vertrauen des Kunden gegenüber einer Anwendung in seinen Grundfesten erschüttern.

Wenn es also einer schnellen und darüber hinaus auch noch effektiven Lösung bedarf, geht es in den Sprint – genauer gesagt den Product Design Sprint. Ziel ist es, innerhalb eines Zeitfensters von möglichst einer Woche gemeinsam mit dem Team Brainstorming zu betreiben und Ansätze zur Produktoptimierung zu entwickeln. Im Rahmen der ersten drei Tage wurden bereits Ideen gesammelt, diskutiert und skizzenhaft zu Papier gebracht.

Von analog zu digital – vom Papier zum Endgerät

Das Prototyping erweist sich nun in diesem Spiel als essentielle Methode, zentrale Pain Points zu einem geringen Kostenaufwand zu bearbeiten. Besonders die Vorarbeit aus den vorangegangenen Etappen kommen dabei dem finalen Ziel zugute. Mittels der angefertigten Skizzen kann so an Tag 4 des Sprints ein erster High-Fidelity-Prototype erstellt werden. Der Begriff High Fidelity umfasst dabei sämtliche Prototypes, die in ihren Mechanismen bereits so weit ausgearbeitet sind, dass sie das Konzept gegenüber Außenstehenden greifbar und verständlich darstellen können.

Welcher Prototyp darf’s sein?

Ähnlich einer jeden Weiterentwicklung oder Implementierung steht natürlich die Zielgruppe im Vordergrund – schließlich ist sie, ganz nebenbei bemerkt, die Ursache für die Durchführung dieses Sprints. Es sollte sich dementsprechend schon zu Beginn vor Augen gehalten werden, welche Erkenntnisse aus den anschließenden User Testings herausgezogen werden sollen.

Mittlerweile liegt, basierend auf den Sketches vom Vortag, bestenfalls eine brillante Idee für ein adäquates Interface vor. Für die Umsetzung essentielle Design Principles geben außerdem die wichtigsten Rahmenbedingungen vor, nach diesen die Anwendung ver- oder bearbeitet wird. Selbstverständlich ist diese Vorgehensweise kein Muss, denn auch dem Designer kann freie Hand in Sachen Styleguide gelassen werden. Hauptsache ist, dass grundlegende Elemente wie Schrift, Formen und Farben einen einheitlichen Charakter besitzen. Schließlich wirken wirre Designs auf den Betrachter nicht nur unschön, sondern schlichtweg unseriös.

Codieren ist kein Muss – Tools wie Sketch können Abhilfe verschaffen

High Fidelity vs. Low Fidelity

Warum muss gleich High Fidelity sein? Reicht denn nicht eine ganz einfache Darstellung im Low-Fidelity-Format? Leider nein, denn die Ausarbeitung eines möglichst produktnahen Entwurfs legt die ausschlaggebende Basis für die interaktive Präsentation der Anwendung im Rahmen der User Testings. Low-Fidelity-Prototypes sparen zwar enorm an Zeit ein, lassen aber auch kein repräsentatives Feedback seitens der potentiellen Nutzer zu. Komplexe Benutzeroberflächen können so nicht detailliert abgebildet werden und verfehlen im Endeffekt vielleicht sogar das Ziel dieser Woche.

Ein Glück, dass in Sachen Prototyping das Rad nicht neu erfunden werden muss. Bereits Design-Tools wie Sketch ermöglichen das Erstellen mobiler Anwendungen – und das obendrein ganz ohne Code-Kenntnisse. Die Orientierung des Interfaces an gängigen Design-Tools bietet außerdem auch für Teammitglieder, die nicht unbedingt aus der Entwicklung stammen, einen reibungslosen Einstieg.

Und nun entscheiden die User

Im Endeffekt ist mit Abschluss des Tages die größte Hürde des Product Design Sprints überwunden. Die in ihren Ideen ausgereifte Anwendung in Form des High-Fidelity-Prototyps kann also in den Ring geworfen werden. Für die Zielgruppe repräsentative Probanden werden so an Tag 5 des Sprints den Prototyp erstmals unter die Lupe nehmen, die Mängel prüfen und die Anwendung auf ihre Usability testen – all das selbstverständlich aus der Perspektive des „Otto Normalverbrauchers“.