Der perfekte Product Design Sprint – die besten Methoden für kompakte 5 Tage

In dieser Artikelreihe führen wir euch durch jeden Tag des aus unserer Sicht idealen Product Design Sprints. Mit dieser kompakten Variante eines Design Prozesses könnt ihr in kürzester Zeit gemeinsam und interdisziplinär Konzepte entwickeln, die konkrete Probleme eurer Nutzer lösen. Ein Product Design Sprint eignet sich perfekt für StartUps, die ihre Ideen nutzerzentriert und schnell entwickeln wollen. Aber auch bereits etablierte Produkte, die einfach frischen Wind oder neuen Fokus brauchen, profitieren von einem Design Sprint. Neben der Generierung von neuen Ideen könnt ihr die 5 Tage aber auch nutzen, um gemeinsam UX Tools zu entwickeln, die euch nachhaltig eine nutzerzentrierte Produktentwicklung ermöglichen.

Was ist denn ein Product Design Sprint?

Wenn ihr beim Blick auf die Übersicht von dem Product Design Sprint denkt “Das kommt mir bekannt vor”, dann habt ihr Recht. Das Vorgehen basiert auf dem Design Thinking Ansatz, der von der Stanford d.school ins Leben gerufen worden ist. Mit dem Product Discovery Ansatz haben Marty Cagan und aber auch Jeff Patton die Idee von Design Thinking bereits erfolgreich in die agile Produktentwicklung integriert. Auch Rainer hat über das Thema Product Discovery hier bei produktbezogen schon einen Artikel geschrieben. Wir haben auf Basis unser Erfahrungen der letzten Jahre kleine Abwandlungen am Vorgehen vorgenommen, die unser Meinung nach ideal für die Lösung von größeren und komplexeren User Experience Herausforderungen im Produkt sind. Ihr könnt den Product Design Sprint aber auch nutzen eure eigenen User Experience Tools zu entwickeln, die euch in der nutzerzentrierten Produktentwicklung unterstützen. Das Ergebnis nennen wir den (agile) Product Design Sprint und er bündelt all unsere Lieblings-Methoden in kompakten und aufregenden 5 Tagen. Wir haben uns übrigens bewußt dazu entschieden unseren kleinen Product Design-Methoden-Koffer nicht Product Discovery zu nennen, da wir uns in einigen Punkten unterscheiden.

So liegt der Fokus beim Product Design Sprint auf der ganzheitlichen Nutzersicht und den großen Veränderungen. Bei Product Discoveries, die im Rahmen von Dedicated Standing Teams durchgeführt werden, verschiebt sich der Fokus dagegen schnell auf kleine und kontinuierliche Verbesserungen. Das ist in einem bestimmten Rahmen gut, aber ihr könnt den Product Design Sprint dann gezielt für das “Big Picture” einsetzen. Damit es im agilen Sinne bleibt, setzen wir schlankere Varianten von bekannten User Experience Methoden wie zum Beispiel der Customer Journey ein. Und wir nehmen uns auch die Zeit, gemeinsam Design Principles zu definieren, da dies unserer Meinung nach die Design Qualität deutlich steigern kann. Welche Methoden wir an welchem Tag einsetzen, erfahrt ihr in den folgenden Artikeln dieser Artikelreihe. Wir haben euch aber auch schon eine kurze Übersicht zusammengestellt.

Die 5 Tage des Product Design Sprints

Vorbereitung

Um die einzelnen Tage des Product Design Sprints gut durchführen zu können, ist gute Vorbereitung alles. Vor Allem das Sammeln und Aufbereiten der vorhandenen Informationen ist wichtig. Dabei kann man unterschiedlich vorgehen. Bei größeren Unternehmen haben wir zum Beispiel schon mit kurzen Online-Umfragen gearbeitet, bei StartUps eher persönliche Gespräche geführt und Notizen gemacht. In beiden Fällen gilt aber, dass man sich nicht im Detail verlieren sollte. Da die 5 Tage sehr kompakt und dynamisch sind, sollten aber auch Räume und Material bereits vorbereitet sein, denn dafür werdet ihr zwischendurch einfach keine Zeit haben. Auch die Teilnehmer des Product Design Sprints sollten gut ausgewählt werden, weil der Erfolg der 5 Tage auch davon abhängt die richtigen Personen und die richtigen Skills im Sprint Team zu haben.

Je nach Problemstellung kann es auch notwendig sein, dass im Vorfeld des Product Design Sprints noch Research gemacht wird. Welcher Research das sein kann, hängt ganz von dem individuellen Fall ab. Wir haben zum Beispiel schon mal über 20 Tiefeninterviews mit Nutzern vorab durchgeführt, weil sehr wenig Erkenntnisse über die jeweiligen Nutzerbedürfnisse da waren.

Tag 1: Experience Mapping

Am ersten Tag des Design Sprints versuchen wir, in die Köpfe und die Welt der Nutzer einzutauchen, um ihre Probleme wirklich verstehen und nachvollziehen zu können. Experience Maps sind kompakte Steckbriefe für das Nutzererlebnis mit dem Produkt oder dem Service und sind so der ideale Einstieg. Sie zeigen, wie der Nutzer idealerweise mit dem neuen Produkt umgehen soll oder welches Erlebnis er mit dem aktuellen Produkt hat.
Zum Artikel →

Tag 2: Storyboarding

Den zweiten Tag nutzen wir zur Generierung von so vielen Ideen wie möglich. Storyboarding hilft uns hier, die in der Experience Map gesammelten Erkenntnisse über das Nutzererlebnis in konkrete Stories zu verwandeln. Dafür kombinieren wir Ansätze aus dem Storytelling mit dem Sketching von ersten Papier Prototypen. Geschichten sind eng mit unseren Emotionen und Handlungen verbunden und helfen uns, Problemstellungen aus ganz neuen Perspektiven zu sehen. So können innovative Konzepte entstehen.
Zum Artikel →

Tag 3: Principles & Paper Prototyping

Design Prinzipien helfen uns am dritten Tag zu entscheiden, welche der entstandenen Konzepte am Besten zur Marke oder der Product Vision passen. Wenn noch keine Design Prinzipien vorhanden sind, beginnt der dritte Tag damit, diese von Vision und Value Proposition herzuleiten. Auf Basis der Prinzipien werden visuelle Ideen gesammelt und die Konzepte mit Papier Prototypen verfeinert und geschärft. Papier Prototypen nutzen wir hier deshalb, weil sie am schnellsten zu erstellen sind und am wenigsten vorgeben.
Zum Artikel →

Tag 4: Vision Prototyping

Am vierten Tag erstellen wir sogenannte Vision Prototypes. Ein Vision Prototype zeigt einen einfachen Screenflow, der Konzept und Idee des Produktes optimal vermitteln kann. Der Vision Prototype ist dem Click Dummy recht ähnlich, aber der Fokus des meist komplexeren Click Dummys liegt mehr auf Usability Testing. Vision Prototypes sind besser für das Testing des Nutzwertes geeignet.
Zum Artikel →

Tag 5: User Feedback Talks & Bewertung

Am letzten Tag werden die Vision Prototypes dann validiert. Hier setzen wir bewußt sehr agile und pragmatische Methoden ein und verzichten soweit es geht auf starre Testing Situationen im Lab. Wenn möglich testen wir gerne an Orten, wo die Nutzer das Produkt oder den Service auch selber nutzen würden beziehungsweise sich in ähnlichen Situationen befinden. Auch das persönliche Gespräch mit den Nutzern ist uns hier wichtig, auch wenn es nur kurz ist. Das gesammelte Feedback nutzen wir dann abschließend zur gemeinsamen Bewertung der Ergebnisse unseres Product Design Sprints.
Zum Artikel →

Mehr Details über die einzelnen Tage und praktische und konkrete Tipps zur Durchführung bekommt ihr in den folgenden Wochen. Wer sich grundlegend über das Thema Design Methoden informieren möchte, dem empfehlen wir das Buch 101 Design Methods von Vijay Kumar, dass einen guten und strukturierten Überblick gibt. Und wir freuen uns natürlich auch, wenn ihr eure Erfahrungen und Meinungen zum Thema mit uns teilt.

Zum ersten Tag →

Alle Artikel aus dieser Serie:

Über Inken Petersen

Inken Petersen ist freiberuflicher Product Design Lead aus dem schönen Hamburg. Vor ihrer Selbstständigkeit hat sie das UX Team bei XING aufgebaut. Seit 2012 hilft sie Produkt-Teams dabei ihre UX Kompetenzen gezielt aufzubauen und nutzerzentrierte und erfolgreiche Produkte zu entwickeln. Dabei arbeitet sie je nach Projektfokus als Coach oder auch als hands-on Product Designer.

Über Wiebke Kudernatsch

Wiebke Kudernatsch ist passionierte Product Design Expertin, die seit über einem Jahrzehnt Unternehmen und Produktmarken für nutzerzentrierte Lösungen begeistert. Ihre agile Arbeitsweise ist geprägt durch designgetriebene Vorgehensmodelle sowie starke UX Methoden. Wiebke Kudernatsch ist Gründerin von Ubercreative.

5 Kommentare

  1. Aaron Sanders

    Entschuldigung, aber mein Deutsch ist schrecklich. Darf ich auf English schriben?

    Have you tried this yet? How often? What were the results? We sometimes do this with our clients, and then work with them to incorporate all the ideas into their “regular” Sprints. Like so: http://comakewith.us/how-start-discovery-your-scrum-team/ And sometimes, it’s good to do this before a release planning session. A “design challenge” for the upcoming release, if that is going to take longer than one Sprint.


  2. Bernhard

    Danke für die kompakte Übersicht. Macht für mich Sinn, allerdings tauchen da noch einige Fragen auf:
    1. Um Experience Mapping machen zu können, brauche ich irgendwelche Research-Daten zu den potentiellen Benutzern, sonst macht das für mich keinen Sinn.
    2. Man kann diesen Product Design Sprint nicht von weiteren Sprints losgelöst sehen, denn was passiert, wenn das Benutzer-Feedback auf die Prototypen etliche Verbesserungspotentiale aufzeigt – geht man dann damit in den nächsten Sprint? Und wie sieht der aus? Man wird ja nicht jedesmal Experience Maps + Storyboards bauen – oder doch?
    3. Was genau ist (dann) der Endzweck eines solchen Product Design Sprints? Die Generierung von ersten Ideen? …?
    4. Wie wird ein Vision Prototype erstellt? Noch mit Papier oder schon digital mit einem Prototypingtool wie Balsamiq oder Axure?

    Es sollte vielleicht noch ein wenig mehr rauskommen, wo dieser Sprint kontextuell aufgehängt ist- als Teil einer Kette von anderen Sprints, oder als erster Sprint, der zu einem finalen Produkt führt und dafür die Grundlage liefert oder eventuell als Innovationstool zur Generierung neuer Ideen?

    Gute finde ich den Ansatz trotz den knappen Zeit “Design Principles” zu definieren – das ist immer ein gutes Framing fürs UX Design.

    Auf jeden Fall ein guter Ansatz…
    LG aus Wien
    Bernhard


  3. Inken Petersen Artikelautor

    @Aaron: thanks for your comment and the link. And english is totally fine, no problem.

    And yes, we’ve did such design sprints and the results were good. In our experience doing such a design challenge is great for the ideation of new products and for complex ux challenges of existing products. However, as the context is always different, the methods we use during the sprint could vary. If the product team already has an experience map, you don’t need to do another one. If the usage scenarios are straightforward, you don’t necessarily need intensive storyboarding.

    If you practice something like continuous discovery, doing such a design sprint from time to time could help to get the best of both. Design Sprints are good to avoid that the team gets too focused on micro improvements of the existing. It’s dependent on the context, but I think twice a year is a good number for bigger design sprints.

    But planning such things and integrating the output in the daily work is complicated. So I like your approach of doing it before a release planning session and including discovery more in the existing scrum ceremonies.

    You suggest using discovery backlog items in the sprint planning sessions in your article… often there’s so much work to do, that the team members prefer to get the work done over e.g. talking to users. Do you have any idea how to encourage people to really request time for such activities?


  4. Wiebke

    @Bernhard: Vielen Dank für dein Feedback.

    Zu deiner Frage was denn der Zweck eines solchen Design Sprints ist: Zum Einen setzen wir ihn zur schnellen Generierung von Konzepten ein, wie Inken das schon im letzten Kommentar beschrieben hat. Zum Anderen kann er zur Generierung von agilen UX Methoden genutzt werden, die für eine nutzerzentrische Entwicklung sinnvoll sind und langfristig dem Team helfen, Produkte und Services am Nutzer und seinen Bedürfnissen auszurichten. Aus unserer Erfahrung heraus werden häufig zu wenig methodische Hilfsmittel in den Teams verwendet, die helfen, die Produktentwicklung an den Bedürfnissen der Nutzer zu reflektieren und das auch frühzeitig, um damit ein Bewusstsein und einen ganzheitlichen Blick für den Nutzer und den späteren Anwendungskontext zu schaffen. Was häufig passiert ist, dass zwar Nutzertests und quantitative Tests gemacht werden, aber erst nachgelagert und diese häufig nicht den Effekt erzielen, den man erwartet oder sich gewünscht hat. Um dies zu Umgehen bzw. das Risiko zu reduzieren, dass agile Teams Lösungen für einen falschen Problemraum entwickeln, kann so ein Design Sprint durchgeführt werden. Das macht besonders Sinn, wenn größere Projektvorhaben und Discoveries anstehen oder auch in diesem Kontext für neue Themenbereiche zukunftsweisende Ideen generiert werden sollen. Und man benötigt dafür auch Research-Daten, das ist richtig. Ein Product Design Sprint kann nicht ohne Vorbereitung eingeschoben werden, sondern muss auch im Vorfeld geplant sein. Inken und ich haben hier die Erfahrung gemacht, dass dieser Aufwand sich lohnt, da die erarbeiteten UX Methoden dann auch für Folge-Discoveries genutzt werden können und nicht ad-acta gelegt werden.

    Ein Product Design Sprint kann damit auch als kompakte Variante eingesetzt werden, Erkenntnisse vom Nutzer und dem Anwendungskontext zu bündeln und intelligent mit den strategischen Zielen eines Unternehmens zu verknüpfen.

    Du stellst viele richtige Fragen, wie z.B. zum Vision Prototyping, die wenn ich darauf jetzt einzeln eingehen würde, sicherlich die Kommentarfunktion hier sprengen würde :-) Deine gestellten Fragen haben wir im Hinterkopf und würden sie dann in unserer nachfolgenden Artikelreihe mit beantworten.


  5. Detlev Petersen

    Liebe Schwester, hallo Wiebke,

    spontan fiel mir die Unterteilung in 5 Teilschritte auf, um zu einem Produktdesign zu kommen. Das entspricht den mir bekannten 5 Meilensteinen bei der Entwicklung eingebetteter Systeme, welche über die Machbarkeit, das Konzept, den Prototypen, die Nullserie zur Fertigungsüberleitung führen. Das erstreckt sich dann in Folge über den gesamten Entwicklungszeitraum eines eingebetteten Produkts, welcher sich über einen Zeitraum von 3 Monaten bis 3 Jahren erstreckt je nach Neuheitsgrad.

    Gut und richtig finde ich den Ansatz, es im Team kompakt innerhalb von 5 Tagen durchzuführen. Ich halte es aus meinen Erfahrungen für richtig das gesamte Team in den Prozess einzubinden und das auch bei jeglicher Art von Projekt so zu tun. Die Realität sieht bei mir im Gegensatz dazu anders aus. Selbst wenn das gesamte Team beim Erarbeiten einer Spezifikation dabei war, so gab es stets Altlasten abzuarbeiten. Die Handlungsprioritäten sind so gesetzt worden, dass mehrere Aufgaben parallel bewältigt werden. Das mindert jedoch den Fokus auf die jeweilige Aufgabe und zieht das Erreichen eines Ergebnisses in die Länge. Noch extremer ist es, wenn viele Projekte pro Person parallel bearbeitet werden und dann aus Ressourcenmangel solche Spezifikationsarbeiten durch Einzelpersonen erledigt werden. Was in der konkreten Situation als nachteilige aber notwendige Entscheidung sinnvoll ist, schafft im Team langfristig unterschiedliche Wissenslevel über das Produkt im Projekt. Siehe bekannte Bahnprojekte, will der Kunde einen neuen Zug mit Neigungstechnik innerhalb von 6 Monaten und zu einen sehr günstigen Preis. Das kürzt Zeitstrecken für die Entwicklung extrem und nötigt dazu, auf Lücke zu gehen, wenn jemand später in das Projekt einsteigt. Von daher finde ich die Einbindung des gesamten Teams extrem gut als auch notwendig, um dies zu vermeiden. Mehr besser informiert ist, kann sich besser beteiligen und fühlt sich so auch verantwortlicher, dabei zu unterstützen und zu helfen, das Ergebnis zu erreichen. Ich denke, durch diese Einbindung der Mitarbeiter steigert sich deren Kompetenzwahrnehmung, auch wirklich etwas beitragen zu können.

    Weiterhin finde ich den Ansatz spannend, so ein Produkt zu entwerfen. Allerdings denke ich, dass je nach Komplexität und Vorbereitungen mehrere solcher Sprints erforderlich sind, um das Wunschprodukt definiert zu haben. Schwierig ist es, von einem Einzelprojekt auf potentielle Neuprojekte zu schliessen und so ein Produkt zu definieren, was ohne Neuentwicklungsaufwand in ausreichendem Umfang verkauft wird, damit die Firma so viel Geld damit verdient, um seine eigene Zukunft aus eigenen Kräften gestalten zu können.

    Es bedarf mit Sicherheit einer guten Kenntnis des Markts und der Kunden, um das genial passende Produkt zu definieren und zu entwickeln. Was ich erlebt habe in all meinen Berufsjahren ist schon das Auffinden entsprechender Kunden, aber auch Anpassungen an den Systemen von Kunde zu Kunde. Daher war es kaum möglich, sich fürs eigene Handeln und Verbesserungen mehr Luft zu verschaffen, die gut getan hätte und uns sicherlich schneller weitergebracht hätte. Es scheint einfacher zu sein, jedem Kunden etwas Spezielles zu versprechen, aber auch stets etwas mit Mehraufwand anpassen zu müssen, als den einen Standard an Produkt zu finden, der über genügend lange Zeit verkauft werden kann. Eine entsprechende Masse an verkauften Produkten oder zahlenden Kunden für das Gleiche ist einfach notwendig, um das auch finanzieren zu können, was aus Idealsicht für die Entwicklung eines guten Produkts zu tun ist.

    So wie ich es sehe, würde ein fundiertes Wissen über den Markt und den Kunden wirklich helfen, um aus Sicht eines Entwicklers das richtige Produkt sich dazu ausdenken zu können. Zudem hilft es darüber hinaus, zwischen unwichtigen und sehr wichtigen Features besser unterscheiden zu können. Speziell unter Termindruck und bei iterativem Vorgehen ist es hilfreich, dieses Wissen zu haben, statt auf Fehlannahmen darüber spekulieren zu müssen.

    Im Umfeld von Internetseiten stelle ich es mir einfacher vor, eine gut durchdachte Produktidee, schnell verifizieren zu können. Ebenso mag ein Webauftritt in der Experimentierphase schnell anpassbar sein, um dies oder jenes ausprobieren zu können. Bei Systemen, die irgendwo verbaut werden, dann gar nicht mehr so zugreifbar sind, weil die in Zügen herumfahren, wird sich beim Versprechen der Funktionalitäten zwangsweise aus dem Fenster gelehnt. Nach erheblichen Materialeinsatz und Entwicklungseinsatz kommt die Masse an Erprobung erst beim Kundeneinsatz auf einen zu. Ein Webportal kann ich aus meiner Sicht mit weniger Materialeinsatz gut testen und erproben, denn dazu ist keine Bahn von ca. 2 Millionen EUR und kein System von mehreren tausend EUR zu kaufen erforderlich. Potentielle Kunden in einem Raum zu versammeln und dafür auch Studenten nehmen zu können, vereinfacht sicher die Produktanalyse eines Internetauftritts. Sitzen die Kunden jedoch in ganz Deutschland verteilt und in der ganzen Welt, ist das zumindest schwieriger zu bewerkstelligen, zu fundierten Erkenntnissen zu kommen.

    Wie kann ich euren Ansatz in einem Umfeld umsetzen, welches von den Randbedingungen her einem viel mehr Hürden in den Weg legt? Ich denke, dass hier nicht auf Sicht von 5 Tagen so ein Produktdesign umgesetzt ist, sondern dass dieser Prozess über einen längeren Zeitraum und mehrere Kunden verfolgt werden muss, um ein Produkt zu erschaffen, was dann in Masse auch gekauft und angenommen wird.

    Schnell ist ein eiserner Wille und die Vision dazu erforderlich, um zu einem Produkt kommen, was sich gut verkauft.

    Viele Grüße
    Detlev


Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mit Absenden des Kommentars stimmst Du der Speicherung deiner persönlichen Daten (Name, eMail-Adresse, Webseite und Nachricht) durch uns bis auf Widerruf zu. Zur Vermeidung von Spam und zur rechtlichen Absicherung wird deine IP für 2 Monate gespeichert. Ebenfalls zur Vermeidung von Spam werden diese Daten einmalig an Server der Firma Automattic inc. geschickt. Zur Darstellung eines Nutzerbildes wird die eMail-Adresse im pseudonymisierter Form an Automattic inc. übermittelt. Wenn du einen oder beide Haken für die eMail-Benachrichtigungen setzt, wird deine eMail-Adresse bei Automattic inc. gespeichert. (Datenschutzerklärung)

Du hast noch viel mehr zu erzählen?

Dann schreib doch einen eigenen Artikel auf produktbezogen.

Artikel vorschlagen →