Agile Produktentwicklung: Design Sprint für das Mobility-Start-up Movacar

This case study is also available in English

TL;DR

Die Challenge

Movacar wollte das Feedback und die Ideen der Nutzer in die Entwicklung einer neuen Geschäftsidee einbinden, um sicherzustellen, dass das Endprodukt den Kundenbedürfnissen entspricht.

Unser Lösungsansatz

INNOQ führte einen vier Tage dauernden Design Sprint durch, der es ermöglichte, innerhalb kurzer Zeit von der Idee bis zum Prototypen zu kommen und echtes Nutzerfeedback zu sammeln.

Das Ergebnis

Der Sprint lieferte wertvolle Erkenntnisse und führte zu einem nutzerzentrierten Produktansatz, der Movacar hilft, ihre Dienstleistungen effektiv auf die Bedürfnisse der Zielgruppe abzustimmen.

Mietwagen müssen nicht teuer sein! Einen Mietwagen für 1€ buchen? Das klingt zu schön, um wahr zu sein. Eustach von Wulffen und Karl Markiewicz möchten mit ihrem Startup Movacar genau das schaffen. Aber wie soll das funktionieren?

Mietwagenfirmen müssen oftmals ihre Fahrzeuge aufgrund zukünftiger Kundenreservierungen von einem Standort zu einem anderen transportieren. Zum Beispiel könnte ein Kunde in fünf Tagen einen Mietwagen zur Abholung in einer Hamburger Filiale reserviert haben. Wenn der Anbieter nun aufgrund seiner Planung weiß, dass dort zu diesem Zeitpunkt kein Fahrzeug verfügbar sein wird, muss er einen passenden Wagen von einem anderen Standort nach Hamburg transportieren. Im Idealfall findet sich ein zahlender Kunde, welcher im Rahmen einer ganz normalen Leihe ein Auto dorthin fährt.

Was aber, wenn keine passende Fahrt ansteht? In diesem Fall muss der Mietwagenanbieter den Transport auf eigene Kosten durchführen. Normalerweise wird hierfür eine externe Firma beauftragt, welche eine entsprechende Gebühr erhält. Und genau hier setzt Movacar an: Anstatt den “Leertransport” zu Lasten der Mietwagenfirma durchführen zu lassen, möchte Movacar solche Fahrten einer preisbewussten Nutzergruppe als “Last-Minute-Angebote” verfügbar machen und die Ersparnis der Mietwagenfirma an den Kunden weitergeben.

Vom ersten Gespräch zum gemeinsamen Design Sprint

Der Kontakt zwischen Movacar und INNOQ kam über das Netzwerk der Factory Berlin zustande. Nach einem ersten Telefonat und einem persönlichen Treffen, in denen uns Eustach und Karl Movacar vorstellten, merkten wir, dass uns nicht nur die Idee an sich gefällt, sondern auch die Gründer dahinter. Beide hatten zuvor für einen großen Mietwagenanbieter in leitenden Positionen gearbeitet, sie kennen die Materie in- und auswendig. Sie wissen um die logistischen Probleme, die gelöst werden wollen. Und sie wissen, wen sie auf Seiten der Mietwagenanbieter wie ansprechen müssen. Alles in allem also beste vertriebliche Voraussetzungen für das junge Startup. Was fehlte war Technologie.

Im Rahmen unseres “Tech4Equity”-Programms möchten wir Startups, die uns gefallen, technologisch unterstützen. Im Gegenzug erhält INNOQ einen Anteil an der neuen Firma. Um uns einerseits ein Bild über die umzusetzende Idee und ihr geschäftliches Potenzial zu machen, andererseits aber auch einen besseren Eindruck von den möglichen Partnern zu verschaffen, haben wir für uns den Design Sprint-Prozess von Google Ventures entdeckt.

Während bei einer “klassischen” Produktentwicklung unter Umständen viele Monate von der Idee bis zum ersten realen Nutzerfeedback nach dem Launch vergehen können, hilft der Design Sprint mit seinem definierten Prozess, diese Zeit auf wenige Tage zu verkürzen. Das Grundprinzip ist, alle wesentlichen Entscheider und Wissensträger zusammen an einem gemeinsam definierten Problem kreativ arbeiten zu lassen. Dabei kommt es darauf an, dass aus möglichst vielen Bereichen des Unternehmens Wissen in den Sprint hineingetragen wird. Auf der anderen Seite darf eine solche Arbeitsgruppe aber auch nicht zu groß werden. Unserer Erfahrung nach nimmt der Koordinierungsaufwand bereits bei mehr als acht Personen überproportional zu. Um aber am letzten Tag einen vorführbaren Prototyp vorliegen zu haben, mit dem echtes Nutzerfeedback eingeholt werden kann, muss ein straffer, aber nicht stressiger, Zeitplan eingehalten werden.

Nachdem wir das Formale geklärt, die Teamzusammensetzung besprochen und alle eine Woche “freigeschaufelt” hatten, konnte es losgehen. Wie sieht nun ein Design Sprint konkret aus?

Tag 1: Verstehen

Am ersten Tag wird das Sprint-Ziel festgelegt. Dieses wird aber nicht einfach vorgegeben. Vielmehr geht es darum, eine gemeinsame Entscheidung transparent und von allen nachvollziehbar zu treffen. (Natürlich gibt es auch die Rolle des Entscheiders, der im Zweifel “gegen das Team” stimmen kann. Allerdings kommt dies eben aufgrund der sehr hohen Transparenz eher selten bis gar nicht vor.)

Um Inhalt und Umfang des Prototyps zu definieren, helfen folgende Fragen und Schritte:

Long term goals

Was sind die mittel- und langfristigen Ziele des Unternehmens?

Sprint questions

Was sind mögliche Probleme, die das Unternehmen davon abhalten, diese Ziele zu erreichen?

Ask the experts & How might we

Hier geht es darum, bisher unbeteiligte Personen fragen, wie Dinge bislang funktionieren und warum sie so sind, wie sie sind. Man hakt nach, wo es Probleme gibt, und notiert “How might we”-Fragen in Form von Post-its. Diese Fragen helfen dabei, in Lösungen statt in Problemen zu denken.

User Experience Map

In der User Experience Map (UX Map) werden zunächst alle Beteiligten eines Geschäftsprozesses identifiziert. Dies können sowohl interne als auch externe Personen oder Personengruppen sein. Anschließend werden alle notwendigen Aktionen der Beteiligten und ihre Abhängigkeiten erarbeitet.

Nun werden die zuvor gewichteten “How might we”-Fragen an die UX Map gehängt. Auf diese Weise wird recht deutlich, auf welche Teile des Prozesses sich das Team konzentrieren sollte. Dies kann entweder ein ganz neuer, ein noch nicht vorhandener oder ein bereits existierender Teilprozess sein.

Lightning Demos

Basierend auf dem identifizierten Teilprozess, der im Design Sprint betrachtet werden soll, sucht jedes Teammitglied Beispiele, die den Prozess nach eigener Auffassung besonders gut umsetzen oder einen neuen Aspekt einbringen.

Four Step Sketch

Zum Ende des ersten Tages erarbeitet jedes Teammitglied mit den bisherigen Eindrücken eine erste Lösung für den Prototyp auf Papier. Dies kann zum Beispiel ein überarbeiteter Checkout-Prozess eines Online-Shops sein. Die Lösung muss dabei weitestgehend selbsterklärend sein, so dass alle anderen am nächsten Tag die besten Ideen zusammentragen können.

Tag 2: Konzipieren

Nachdem jedes Teammitglied eine eigene Idee auf Papier entwickelt hat, wird per Voting die beste ausgewählt. Diese Wahl bestimmt hauptsächlich, in welche Grundrichtung das Team weitergehen soll. Sind sehr ähnliche Ansätze entstanden, können auch Teilaspekte anderer Vorschläge weiterverfolgt werden.

Um nun die zu erstellenden Screens des Prototyps zu finden, erarbeitet jeder einen “User Experience Flow” (UX Flow) bestehend aus sechs Schritten. Auch hier werden wieder die besten Ansätze per Voting identifiziert und in Reihenfolge gebracht. Der UX Flow ist somit Basis für das etwa acht Screens umfassende Storyboard, welches bis zum Ende des Tages erstellt wird. Mit diesem Storyboard ist der Umfang des Prototyps klar definiert.

Tag 3: Erstellen des Prototyps

Zu Beginn des Tages werden die verschiedenen Rollen zur Erstellung des Prototyps verteilt (Designer, Texter, etc.) sowie ein passendes Tool gewählt. Wir haben bisher sehr gute Erfahrungen mit Figma gesammelt. Figma ermöglicht als webbasiertes Tool ein kollaboratives Arbeiten aller Beteiligten.

Tag 4: Testen

Dies ist der Tag, auf den alle hingearbeitet und dem alle entgegen gefiebert haben! Wie wird die Idee ankommen? Verstehen die Nutzer, was wir uns überlegt haben? Was haben wir in unserem Entwurf nicht bedacht?

Während ein Teil des Teams am Vortag den Prototyp gebaut hat, wurde parallel der Nutzertest vorbereitet. Neben einem Interviewleitfaden für die Nutzer wurde ein Feedbackbogen erarbeitet, der hilft, die subjektiven Eindrücke der Beobachter in einer einheitlichen Form aufzunehmen, am besten direkt digital. Mehr zu unseren Erfahrungen und Empfehlungen bezüglich der Technik finden Sie hier.

Es ist immer wieder interessant, zu sehen, wie die einzelnen Nutzer auf den erstellten Prototyp reagieren. Oftmals gibt es sehr unterschiedliche Erwartungen und Prioritäten, die teilweise vom Team vorab überhaupt nicht gesehen wurden. In der abschließenden teaminternen Diskussion werden nicht selten bereits Fragen und Themen für den nächsten Design Sprint identifiziert. Dies ist für uns das schönste Feedback und zeigt, dass das Vorgehen effektiv ist, zu wertvollen Ergebnissen führt und dabei Spaß macht.

Lessons learned

Wie immer gibt es natürlich auch Dinge, die man noch besser machen kann. So ist es stets ratsam, mehr Personen für den Test anzufragen, als tatsächlich benötigt werden. Gerade wenn sich jemand nicht rechtzeitig zurückmeldet, kann man davon ausgehen, dass der Termin vergessen wurde und “Ersatz” benötigt wird.

Für die Gestaltung des Prototyps sollten bewusst ausgesparte Screens dennoch als Platzhalter eingebaut werden. So ist es zum Beispiel immer wieder störend, wenn ein Nutzer in einem Buchungsprozess die Eingabe seiner Zahlungsdaten erwartet, diese aber nicht abgefragt werden. Um den gesamten Prozess aber dennoch klar zu machen, sollten solche vom Nutzer erwarteten Schritte mit einer kurzen Erklärung, jedoch ohne Funktionalität, eingebaut werden.

Ebenso sollte sich das Team den Testern gegenüber erkenntlich zeigen. Die von Eustach und Karl im Anschluß an die Tests verteilten Aufmerksamkeiten in Form von Movacar-Tassen, Schokolade und Amazon-Gutscheinen sorgten bei allen für eine sehr positive Resonanz.

Und zu guter Letzt braucht es für den Sprint-Erfolg natürlich engagierte und motivierte Leute, die interessiert sind, etwas Neues zu lernen und somit sich und ihr Produkt zu verbessern.