Validieren Sie Ihre Produktideen professionell in nur 5 Tagen mit
Innovationen realisieren.
Product Design Sprints
Teile dieses E-Book iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii
iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii
iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii
iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii
iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiI
© Trueffelpix / fotolia.com
Inhalt
Einleitung
3
Vorbereitung
6
Tag1: Problem verstehen
15
Tag2: Lösungsansätze entwicklen
24
Tag3: Entscheiden
34
Tag4: Prototypen bauen
41
Tag5: Interviews
46
Autoren
54
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!2
Einleitung
Neue Trends und Ideenfelder entstehen heutzutage mit rasender Geschwindigkeit in fast allen Branchen. Ideen, wie sich diese für das eigene Unternehmen nutzen lassen, sind meist schnell gefunden - die Frage lautet häufig vielmehr: Wie lassen sich unterschiedliche Ideen bewerten und möglichst schnell, kostengünstig und aussagekräftig (d. h. durch “echtes” Feedback der Zielgruppe) validieren? Stehen Sie selbst vor diesen Herausforderungen? Dann werden Ihnen Product Design Sprints als Werkzeug für schlanke und schnelle Innovationsprozesse eine große Hilfe sein!
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!3
Einleitung
Dieser einfache Prozess, welcher von Google Ventures für das schnelle Validieren von Ideen und Produkten bei StartUps des eigenen Portfolios entwickelt wurde, ermöglicht Ihnen eine Produktidee in nur 5 Tagen zu konzipieren, einen funktionalen Prototypen zu entwickeln und mit diesem echtes Nutzerfeedback zu erhalten. Dieses E-Book führt Sie durch einen vollständigen Product Design Sprint. Sie können es zur Lektüre verwenden, wenn Sie den Prozess genauer kennen lernen möchten oder als Schritt-für-Schritt Anleitung, wenn Sie Product Design Sprints selbst einsetzen möchten.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!4
Product Design Sprint Roadmap
Vorbereitung
Tag 1: Problem verstehen
Tag 2: Lösungsansätze entwickeln
Tag 3: Entscheiden
Tag 4: Prototypen bauen
Tag 5: Interviews
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!5
Vorbereitung
“Der Zufall begünstigt nur den vorbereiteten Geist.” - Louis Pasteur
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!6
Vorbereitung
Product Design Sprints können zur Validierung von gänzlich neuen Ideen oder Erweiterungen von Bestandsprodukten genutzt werden. Nehmen wir einmal an, Sie wären in einem Verlag tätig. Die Nachrichtenwebseite einer Tageszeitung soll grundlegend überarbeitet und modernisiert werden. Die aktuelle Version ist knapp 7 Jahre alt und wirkt optisch wie technisch nicht mehr zeitgemäß. Vor dem eigentlichen Relaunch Projekt möchte der Verlag zunächst die Eckpfeiler der Webseite wie die ideale Navigations-struktur, die optimale Darstellung einzelner Inhaltsmodule und die beliebtesten Funktionen aus Nutzerperspektive ermitteln.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!7
Vorbereitung
Product Design Sprints eignen sich ideal als Vorbereitung für größere Projekte. Anhand von Beobachtungen bei der Verwendung von kleinen Prototypen und Interviews mit Personen aus der Kernzielgruppe können in sehr kurzer Zeit viele, unterschiedliche Realisierungsansätze validiert werden. Das ist eine Riesenchance um die Erfolgswahrscheinlichkeit im nachgelagerten, großen Projekt deutlich zu steigern und schneller ans Ziel zu kommen.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!8
Vorbereitung
Bevor der Product Design Sprint nun beginnt, wird zunächst eine Marktrecherche durchgeführt: Gibt es bereits Konkurrenten? Auf welche Art und Weise wird das Problem dort gelöst? Welche Verbreitung hat das Produkt und welche Kunden spricht es an? Konkret auf die Ziele des Relaunch Projektes der Nachrichtenwebseite ausgerichtet:
- Navigation: Welche Konzepte existieren bereits? In welchen
- Product Design Sprints sollten immer -
vorbereitet werden möglichst viele Informationen über das Problemfeld vorab sammeln Inspiration von Konkurrenten erhalten
Kontexten werden diese erfolgreich eingesetzt? - Analytics Daten: Welche Bereiche, Funktionen und Inhalte der Webseite werden aktuell stark genutzt? - Konkurrenzanalyse: Wie setzen andere Webseiten Navigation, Inhaltsdarstellung und Funktionen für deren jeweilige Zielgruppe um? © 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!9
Vorbereitung
Wer nimmt an einem Design Sprint teil?
Ein Sprint profitiert enorm von möglichst unterschiedlichen Sichtweisen und Expertisen der Teilnehmer. Daher sollten folgende Personen unbedingt anwesend sein: Geschäftsführer bzw. Entscheider, Produktmanager, Designer, Kunden-Support oder die Stelle mit dem meisten Endkundenkontakt. Personen aus dem Marketing und der Technik können ebenfalls gerne mit dazu genommen werden. Das Team besteht im Idealfall aus 6 bis maximal 8 Personen.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!10
Vorbereitung
Welche Umgebung eignet sich idealerweise? Der Design Sprint sollte außerhalb der gewohnten Büroumgebung stattfinden - am besten in einem Tagungsraum. In einigen Firmen ist dies nicht möglich. Weichen Sie in ein ruhiges Büro mit großer Wandfläche und zwei Whiteboards oder einen Konferenzraum aus.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!11
Vorbereitung
Wie erfolgt die Moderation des Sprints? Während des gesamten Sprints ist eine Person erforderlich, welche den generellen Überblick sowie Ziel und Zeit im Auge behält. Zudem sollte sie mit den Methoden des Product Design Sprints vertraut sein. Da Sie dieses E-Book lesen, haben Sie vielleicht Interesse daran diese Rolle zu übernehmen. Es soll nicht verschwiegen werden, dass die Leitung eines 5 tägigen Workshops einige Kraft kosten kann.
Sehen Sie es als Herausforderung ;)
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!12
Vorbereitung
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!13
Vorbereitung
Welche Materialien sind notwendig? Zur Durchführung werden lediglich die folgenden Materialien benötigt:
• • • • • • • •
Klebezettel Zeichenstifte Stattys Whiteboards, verschiedenfarbige Marker Kleine Aufkleber (grün, rot, schwarz) für die Punktevergabe Papier Eine Stoppuhr bzw. ein Smartphone mit Timer-Funktion Klebeband um Zettel und Papier am Storyboard oder an den Wänden des Raumes zu befestigen • Ausreichend Snacks und Getränke für die grauen Zellen und schnelle Energie
Tipp: Ein handelsüblicher Moderationskoffer enthält alle diese Dinge.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!14
Tag 1 - Problem verstehen
“Hätte ich sechs Stunden Zeit um einen Baum zu fällen, würde ich die ersten vier auf das Schärfen der Axt verwenden.”
- Abraham Lincoln
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!15
Tag 1 Problem verstehen
Es geht los! Zunächst ist es wichtig, in dem interdisziplinären Product Design Sprint Team die Problemstellung (Navigation, optimale Darstellung der Inhaltsmodule, einfache Nutzung der Funktionen der Webseite) aus möglichst unterschiedlichen Perspektiven zu betrachten: Der Produktmanager erläutert die Nutzung der gegenwärtigen Version der Webseite und stützt seine Aussagen mit Analytics Daten. Drei Hauptnavigationsbereiche sind gut auffindbar. Auf den “versteckteren” Bereichen landen mehr Nutzer einer Web-Maschine als Nutzer der Nachrichtenwebseite.
- Problemstellung aus unterschiedlichen Perspektiven betrachten
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!16
Tag 1 Problem verstehen
Eine Vorab-Befragung einiger Nutzer im Rahmen eines Gewinnspiels hat zudem ergeben, dass einige Navigationspunkte sich so ähnlich sind, dass Nutzer zwischen diesen kaum differenzieren können. Ferner ist die optische Darstellung der Inhalte stark veraltet und nicht an Smartphones angepasst. Nutzer verwenden vorwiegend Funktionen und Inhalte, die sie bereits kennen. Das stöbern in anderen Bereichen wird als lästig und unintuitiv wahrgenommen. Der Designer weist auf die geringe Schriftgröße hin und zeigt zum Vergleich Screenshots zweier anderer Webportale, welche eine optisch sehr ansprechende und klare Navigation einsetzen. Zudem nutzen die Webseitenelemente, welche Bildund Textinhalte darstellen, mehr Bildschirmfläche.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!17
Tag 1 Problem verstehen
Der Mitarbeiter aus dem Callcenter erhält zudem häufig Nutzeranfragen zu der Verwendung der Suche (welche sich aktuell ebenfalls in der Navigation befindet). Die Sortierung der Ergebnisse erfolgt nach Alphabet und nicht in chronologischer Reihenfolge. Der Softwareentwickler des Teams gibt zu bedenken, dass die derzeitige Darstellung auf PC Monitore im Jahr 2008 optimiert wurde. Inzwischen ist die durchschnittliche Auflösung stark gestiegen und Mobilgeräte wie Smartphones und Tablets werden häufig zur Darstellung der Webseite genutzt. Technisch sollte die überarbeitete Webseite in jedem Fall “responsive” gestaltet werden um diverse Auflösungen und Geräte zu unterstützen. Abschließend zeigt sich der Entscheider überzeugt: Es gibt großes Optimierungspotential an dem Produkt und garantiert Zeit und Mittel für die Durchführung eines vollständigen Product Design Sprints.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!18
Tag 1 Problem verstehen
Je genauer das Ziel des Sprints im Zuge der Vorbereitung eingegrenzt werden konnte, desto einfacher lassen sich nun die Erfolgsmetriken für den Sprint ermitteln. Dabei muss das Team konkrete Ziele beschreiben. Wir schlägt sich das Erreichen oder Nicht-Erreichen der Ziele im Nutzerverhalten wieder? Welche Signale gibt hier? Signale wiederum lassen sich durch konkrete Metriken messen um etwa durch einen A/B Vergleich von zwei Designvorschlägen den geeigneten auszuwählen.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!19
Tag 1 Problem verstehen
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!20
Tag 1 Problem verstehen
Am 5. Tag des Sprints werden Nutzerinterviews mit 5 Testpersonen fest angesetzt. Diese Personen werden die “neue Webseite” anhand eines echt wirkenden Prototypen testen und Feedback geben. Im Laufe des Product Design Sprints wird es gelegentlich zu längeren Diskussionen kommen. Der Moderator achtet darauf diese nicht ausufern zu lassen und hat immer die Nutzerinterviews im Blick. Diese Deadline in 5 Tagen hilft dem Team während des Sprints den Fokus zu halten! Entscheidungen können daher nicht lange aufgeschoben werden. Nun folgt die wichtigste Aufgabe des Tages: Gemeinsam entwickelt und zeichnet das Team die wichtigste User-Story ein Nutzer gelangt auf die Webseite wegen eines Artikels über seine Stadt, danach informiert er sich über ein sportliches Großereignis und sucht nach Nachrichten zu seinem lokalen Fussballverein.
- Gemeinsam wichtigste User-Story für diesen Sprint zeichnen
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!21
Tag 1 Problem verstehen
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!22
Tag 1 Problem verstehen
Die User-Stories der Nachrichtenseite haben exemplarisch folgende Form: Als Leser möchte ich Neuigkeiten über meine Stadt erfahren, um mich informiert zu fühlen. Als Leser möchte ich weitere, relevanten Informationen zum aktuellen Tagesgeschehen in den Bereichen, Politik, Wirtschaft und Sport erhalten. Als Leser möchte ich spontan nach relevanten Informationen zu diversen Stichworten suchen können, um passende Artikel zu erhalten.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!23
Tag 2 - Lösungsansätze entwickeln
“Es gibt kein Problem auf der Welt, bei dem es keine Lösung gibt.”
- Yan Rabenstein
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!24
Tag 2 Lösungsansätze entwickeln
Nachdem das Problemfeld abgesteckt sowie die User-Story an Tag 1 gezeichnet wurde, versucht das Team an Tag 2 so viele Lösungsansätze und -ideen wie möglich zu skizzieren. Die Zeichnung dieser Ideen erfolgt mit einfachsten Mitteln: Stift und Papier. Teams welche direkt mit Mockup Tools loslegen laufen Gefahr, sich in die Ideen zu “verlieben” weil diese schon eine hohe ästhetische Qualität aufweisen. Die User-Story aus Tag 1 wird in Blöcke mit jeweils maximal 2 Teilschritten aufgeteilt:
- möglichst viele Skizzen und Lösungsansätze entwickeln
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!25
Tag 2 Lösungsansätze entwickeln
Das Team kann sich nun teilen und den nachfolgenden 7stufigen Prozess jeweils für die Einzelblöcke durchführen oder das gesamte Team durchläuft die einzelnen Abschnitte. Die Arbeit ist sehr intensiv - wird aber viele gute Lösungsansätze ermöglichen. Freuen Sie sich darauf! 1. Warmup (5 Minuten): Alle Teilnehmer erhalten 5 Minuten um sich nochmal in das Problem “reinzudenken” und können zusätzlich Notizen mit eigenen Ideen und Fragen aufschreiben. Oft hilft es Notizzettel mit der Frage “Wie können wir…” einzuleiten. z. B.: “Wie können wir die wichtigsten Navigationspunkte für den Nutzer ermitteln?” “Wie können wir die Darstellung der Inhaltselemente auf unterschiedlichen Bildschirmgrößen logisch und einheitlich gestalten?”
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!26
Tag 2 Lösungsansätze entwickeln
2. Mind-Map (10-15 Minuten): Alle Teilnehmer strukturieren für sich nun ihre eigenen Ideen und Konzepte optisch in Form einer Mind-Map auf einem Papierbogen. Diese wird nachfolgend als Ideenpool verwendet wenn User Interface Skizzen gezeichnet werden.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!27
Tag 2 Lösungsansätze entwickeln
3. 8 Ideen (5 Minuten): Jeder Teilnehmer faltet ein Blatt Papier vier mal zur Hälfte und erhält so ein Blatt mit 8 Quadranten. Diese 8 sollen nun innerhalb von fünf Minuten vollständig mit Designskizzen gefüllt werden! Die Zeit ist so knapp bemessen, damit die Kreativität des Gehirns nicht von unbewusster Eigenkritik zurück gehalten wird. Die Besten Ergebnisse erhält man, wenn man die Übung zwei mal hintereinander durchführt.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!28
Tag 2 Lösungsansätze entwickeln
4. Storyboard (10-20 Minuten): Auf ein leeres DIN-A4 Blatt werden 3 Klebezettel aufgebracht. Jeder Teilnehmer für sich verkettet nun die besten Ideen aus der Mind-Map sowie den “8 Ideen” Skizzen zu User-Stories bzw. zu Abläufen. Jeder Klebezettel symbolisiert ein Bild des Storyboards in der Reihenfolge: zuerst dies (1), dann das (2), dann das (3).
- Ideen zu Abläufen zusammen fassen - Abläufe werden anonym von der Gruppe bewertet
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!29
Tag 2 Lösungsansätze entwickeln
Wichtig bei der Storyboard-Erstellung sind zudem drei Regeln: Eigenständigkeit - Die Skizze muss so aussagekräftig sein, dass sie für sich selbst stehen kann und keinerlei Erklärung vom Autor benötigt um verstanden zu werden. Anonym - allen Ideen soll das gleiche Gewicht zukommen können. Daher bitte keinen Namen drauf schreiben. Benennen - Die Idee sollte einen einprägsamen Namen haben damit sich leicht darüber diskutieren lässt.
- Anonymität sichert allen Ideen idealerweise gleiche Chancen zu
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!30
Tag 2 Lösungsansätze entwickeln
5. stille Kritik (5-10 Minuten): Jedes Teammitglied erhält eine Anzahl von Punktaufklebern (z. B. 10). Ohne zu sprechen verteilen die Personen nun die Punkte auf Ideen die ihnen gefallen. Es können auch die eigenen sein und es gibt kein Limit wie viele Punkte pro Person auf eine Idee geklebt werden können. Nach Abschluss der Übung entsteht eine Heatmap - die besten Ideen stechen bereits optisch heraus.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!31
Tag 2 Lösungsansätze entwickeln
6. Drei-Minuten-Kritik (3 Minuten pro Idee): Zunächst sprechen die Teammitglieder über Ideen die viel Zuspruch gefunden haben - Was gefällt an der Idee? Erst danach bekommt der “Zeichner” der Idee die Möglichkeit etwas zu der Idee zu sagen, falls Aspekte der Idee bisher nicht berücksichtigt wurden.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!32
Tag 2 Lösungsansätze entwickeln
7. Abstimmung (5 Minuten): In diesem letzten Schritt bekommen die Teilnehmer ein oder zwei Super-Punkte. Mit diesen kann jeder die allerbesten Ideen markieren. Entscheider erhalten ggf. ein oder zwei Stimmen mehr als alle anderen Teilnehmer - so ehrlich sollte man schon sein. Ohne deren Unterstützung würden später im Prozess Probleme entstehen.
Falls die User-Story im ersten Schritt in mehrere kleine aufgespalten wurde, kann der große Prozess nun für alle nachfolgenden Teile wiederholt werden. Keine Bange - mit der Zeit wird es immer einfacher. Dieser gesamte Zyklus kann pro Tag 2-3 mal durchlaufen werden. Danach haben sich alle Mitglieder des Sprints eine Pause redlich verdient!
Ziel: - möglichst viele Skizzen und Lösungsansätze entwickeln
Tools: - Papier - Stifte - Stoppuhr (ggf. als App)
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!33
Tag 3 - Entscheiden
“Die schlimmste Entscheidung ist Unentschlossenheit.”
- Benjamin Franklin
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!34
Tag 3 Entscheiden
Der vergangene 2. Tag stand ganz im Dienste der Generierung von Lösungsideen und Einzelkonzepten. An Tag 3 werden nun die besten Ideen zu einem Gesamtwerk zusammen gefügt. Zunächst sollten die Storyboards des Vortages auf Konflikte geprüft werden. “Konflikt” bedeutet in diesem Falle schlicht, dass mehr als eine mögliche Lösung zu einem Problem gefunden wurde. Konflikte sind sehr hilfreich weil sie unterschiedliche Lösungen für ein Problem darstellen. In unserem Sprint identifizieren wir viele unterschiedliche Ideen zum generellen Aufbau der Nachrichtenwebseite: die klassische Navigation am oberen Bildrand, ein Menü am linken Bildrand, sowie vorgeschlagene weitere Kategorien unter jedem Artikel. Zudem sind unterschiedliche Skizzen zur Darstellung einzelner Inhalte entstanden!
- Konflikte stellen lediglich mehrere Möglichkeiten zur Lösung von einem Problem dar
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!35
Tag 3 Entscheiden
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!36
Tag 3 Entscheiden
Nicht vergessen: Wir haben an Tag 5 die Nutzer eingeladen und müssen uns entscheiden, welche Ideen wir in einem oder mehreren Prototypen umsetzen wollen. Für die Neugestaltung der Webseite hat sich durch die Punkte-Bewertungen bereits ein Sieger-Design herauskristallisiert, welches als Prototyp umgesetzt werden soll. Eventuell gibt es auch mehrere unterschiedliche Ansätze die durch die Nutzerbefragung gegeneinander getestet werden sollen. Beides ist möglich: ein gut ausgebauter Prototyp oder mehrere unterschiedliche und entsprechend reduzierte.
- es kann ein vollständiger oder mehrere kleinere Prototypen entwickelt werden um verschiedene Annahmen zu testen
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!37
Tag 3 Entscheiden
“Welche Annahmen wurden getroffen und sollen durch die Nutzerevaluation des Prototypen validiert werden?” ist die ganz zentrale Frage. Viele Unternehmen entwickeln ein Produkt zunächst vollständig und stellen erst bei Markteintritt fest, dass Kunden andere Wünsche haben, der Markt viel kleiner als angenommen oder die Technologie noch nicht ausgereift ist. Nicht alle Annahmen lassen sich durch den Einsatz eines Prototypen testen - zu vielen jedoch liefern die Nutzer in den Interviews wertvolle Hinweise.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!38
Tag 3 Entscheiden
Die letzte Gruppenaktivität vor dem Bau des Prototypen besteht in der Zeichnung der User-Story, welche den exakten Ablauf des Prototypen darstellen wird. Zunächst wird ein Whiteboard in einzelne Zellen aufgeteilt, jede ca. 2 Blatt Papier groß. In jede Zelle wird nun eine Aktion, wie der Klick eines Buttons, eine Texteingabe oder eine offline durchgeführte Aktion des Nutzers (Paket abholen) skizziert. Die visuelle Qualität ist nicht so wichtig, aber alle möglichen Handlungsstränge der Nutzung sollten bedacht werden.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!39
Tag 3 Entscheiden
Nach und nach entsteht eine Art Comic-Zeichnung, welche die Geschichte des Nutzers erzählt, der mit der NachrichtenWebseite interagiert und deren Funktionen vollständig nutzt.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!40
Tag 4 - Prototypen bauen
“Der Schlüssel liegt im Handeln, nicht in Worten.”
- Georg Christoph Lichtenberg
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!41
Tag 4 Prototypen bauen
Es geht los! Der Prototyp soll so real wie möglich wirken. Alle Texte sollten so echt wie möglich sein - kein Lorem Ipsum - damit die Nutzer des Prototypen sich zurecht finden. Die UserStory des Vortages dient als Bauplan des Prototypen. Der Aufwand für die Erstellung des Prototypen darf nur minimal sein. Wir haben schließlich nur einen Tag! Es existiert eine endlose Vielzahl an Prototyping-Werkzeugen. Eine wirklich einfache aber effektive Methode ist die Verwendung von Apple Keynote bzw. Microsoft PowerPoint in Kombination mit den “keynotopia.com” Vorlagen. Diese enthalten die meisten Bedienelemente gängiger Apple- / PC- sowie MobilBetriebssysteme, Webseiten und Social Media Integrationen.
- User Story ist Bauplan des Prototypen - Mit möglichst einfachen Werkzeugen einen möglichst echt wirkenden Prototypen schaffen
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!42
Tag 4 Prototypen bauen
Es sind keine Programmierkenntnisse erforderlich. Apps oder Webseiten werden einfach per Drag & Drop auf Vorlageschablonen zusammengebaut. Die Folienübergänge von Keynote bzw. PowerPoint reichen in den meisten Fällen aus, ein minimales aber funktionales Produkt zu simulieren. Durch die Verwendung dieser einfachen und bekannten Werkzeuge ist kein Spezialwissen notwendig und jedes Teammitglied kann an der Erstellung des Prototypen mitwirken. Die Nachrichtenwebseite inkl. Navigation, Inhaltemodule für Artikel und Bilderstrecken sowie eine Suchfunktion inkl. Ergebnissdarstellung muss unser Team nun erstellen.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!43
Tag 4 Prototypen bauen
Die User-Story aus Tag 3 wird von der ganzen Gruppe bearbeitet, wobei immer 2 Personen gemeinsam an einem Rechner arbeiten. Buttons, Texte, Navigationsebenen etc. werden auf einzelnen Folien zusammen gesetzt. Die Masken der Einzelgruppen werden dann (idealerweise von einem Designer) nochmals zum endgültigen Prototypen mit einer gemeinsamen Stilsprache zusammen geführt.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!44
Tag 4 Prototypen bauen
Während der Designerstellung sollte man sich immer vor Augen halten, welche Annahmen und Konzepte an Tag 5 mit dem Prototypen validiert werden sollen. Perfekte Optik ist nicht so wichtig, jedoch sollte für Nutzer in unserem Projekt der Eindruck einer möglichst echten Nachrichten-Webseite mit echten Inhalten entstehen. Eine Browserzeile am oberen Bildrand und klickbare Elementen welche zu Folien mit entsprechend dahinterliegenden (mit Folienübergängen) Inhalten führen, sollten enthalten sein.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!45
Tag 5 - Interviews
“Man muss viel gelernt haben, um über das, was man nicht weiß, fragen zu können.”
- Jean-Jacques Rousseau
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!46
Tag 5 Kundeninterviews
Heute wird es richtig spannend! Der Prototyp bzw. die Prototypen werden echten Nutzern vorgelegt. In nur 5 Tagen hat das Team mehrere, unterschiedliche Funktionen der neuen Nachrichtenwebseite konzipiert und prototypisch umgesetzt. Respekt! Vor der Nutzerbefragung sollten die Schlüsselfragen nochmals herausgestellt werden: Welche Konflikte und Annahmen von Tag 3 sollen validiert werden? Versteht der Interviewer (kann Person aus dem Team oder extern sein) die Unterschiede der einzelnen Konzepte? Welche Dinge möchten wir noch durch die Augen des Nutzers sehen?: Aktuell verwendete Konkurrenzprodukte, die Wichtigkeit des Problems, die Bereitschaft für Funktionen zu zahlen? etc.
- Nutzerfeedback zur Validierung bzw. Falsifizierung der Annahmen und der Prototypen
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!47
Tag 5 Kundeninterviews
Eine Person, führt die Interviews mit den Nutzern durch, während alle anderen Mitglieder des Sprint Teams in einem Nebenraum per Videoübertragung virtuell die Nutzung der eigenen Designentwürfe verfolgen. Verwenden Sie einfach 2 Laptops, welche über Skype, Google Hangouts oder Apple AirPlay Kamerabild und Ton übertragen. Ganz wichtig: Nicht der Nutzer wird getestet sondern die Designentwürfe des Sprint Teams! Versteht ein Nutzer ein Konzept nicht, weist dies auf eine Schwachstelle im Design hin und stellt keine Fehlleistung des Nutzers dar.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!48
Tag 5 Kundeninterviews
Während des Interviews, erfasst das Team im Beobachtungsraum Notizen auf Papier (jeder für sich) in drei Kategorien - gut, schlecht, sonstige Beobachtungen Eine Person darf einen Laptop verwenden, hat allerdings die Aufgabe das Interview Wort für Wort mitzuschreiben. Diese Notizen erlauben es bei der späteren Auswertung genau nachzuschlagen, was der Nutzer an Stelle X im Prototypen geäußert hat. Auf ein großes Whiteboard wird nach Ende jedes einzelnen Interviews eine Spalte angelegt in denen die markantesten Beobachtungen eingetragen werden. Dinge, welche gut funktioniert haben werden grün markiert, Probleme rot und alles sonst noch interessante schwarz. Diese Markierungen machen es leichter Muster zu erkennen.
- während des Interviews sind alle Äußerungen der Testperson wichtig und sollten festgehalten werden
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!49
Tag 5 Kundeninterviews
Es kann ziemlich anstrengend sein, den Nutzern bei der Bedienung der Prototypen zuzusehen. Jedoch liegt genau darin die Chance Schwachstellen zu erkennen und zu verbessern. Nach der Durchführung aller 5 Interviews zeichnen sich in den meisten Fällen bereits Cluster ab: Was funktioniert? Welche Probleme bestehen? Wichtig hierbei ist insbesondere, dass der Entscheider die einzelnen Punkte versteht und deren Lösung unterstützt.
- innerhalb von nur 5 Tagen konnte das Problemwissen um ein vielfaches gesteigert werden
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!50
Tag 5 Kundeninterviews
Diese Liste verdeutlicht direkt die Punkte, an denen das Team noch arbeiten muss. Grün markierte Dinge können im nächsten Prototypen weiter verbessert werden (Methodik von Tag 3), rote Probleme sollten genauer analysiert werden. Dies kann nun jedoch mit dem Wissen aus den Nutzerfeedbacks wesentlich besser geschehen (Methodik von Tag 2). Gratulation! Das Team hat den Sprint durchlaufen - es war eine sehr intensive Woche! Das Team weiß nun viel mehr über das Problemfeld und mögliche Lösungen! Zudem vermittelt die Auswertung der Interviews auf dem Whiteboard eine ziemlich genaue Vorstellung von den nun notwendigen, weiteren Aktivitäten.
- innerhalb von nur 5 Tagen konnte das Problemwissen um ein vielfaches gesteigert werden
In jedem Fall ist das Problemwissen im Team nun um einige Größenordnungen gewachsen.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!51
Tag 5 Kundeninterviews
Die meisten Teams nutzen das Momentum und wenden sich direkt den Schwachstellen der User-Story und / oder dem Prototypen zu und überarbeiten diese(n) für einen weiteren, verkürzten Product Design Sprint.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!52
Next Steps
In jedem Fall sollte eine klare Empfehlung für die nächsten Schritte abgegeben werden. Häufig wird ein 2-3 seitiges Management Review Dokument mit Handlungsempfehlungen erstellt. Bei dem Beispiel der Nachrichtenseite würden die gelernten Lektionen zu Navigation, Inhaltsmodulen und Suchfunktion verdichtet und dokumentiert. Diese Erkenntnisse dienen fortan als Leitlinien für das Hauptprojekt “Webseiten Relaunch”, könnten aber auch in einem zweiten, verkürzten Design Sprint noch genauer untersucht werden.
- ein Design Sprint sollte unbedingt mit der Dokumentation von Handlungsempfehlungen abgeschlossen werden
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!53
Die Autoren
Maurice Knopp ist Softwareentwickler, freiberuflicher Technologie-Berater und Mitgründer von JoinMyGift.com - der Online Plattform für die Organisation von Gemeinschaftsgeschenken. Er beschäftigt sich leidenschaftlich seit über 10 Jahren mit Softwareentwicklung mit Schwerpunkt im Enterprise- und Web-Umfeld und liebt es ausgeklügelte Softwarelösungen unter dem Einsatz verschiedener Technologien zu entwickeln. Er gewann 2010 den Opitz Consulting Innovationspreis für Informatik und erreichte den 1. Platz beim FERCHAU Preis 2007 (Fachbereich Informatik). Er arbeitet und lebt mit seiner Familie in Köln.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!54
Die Autoren
Andreas Pihan hat langjährige Erfahrungen in den Bereichen Asset Management, Privatbanken und in der Verlagsbranche. Ganz besonders interessiert er sich für den Aufbau, die Validierung und die Realisierung von neuen digitalen Geschäftsmodellen sowie für neuartige Content-MarketingStrategien. Zudem gibt er Produkt-Positionierungs-Trainings und ist Autor von verschiedensten Publikationen zu Themen wie z.B. iBeacon, IoT und User Stories. Seit Oktober 2014 verantwortet er bei Safari den Bereich Business Modeling.
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!55
Wir helfen Ihnen bei Innovationsprojekten!
Kontaktieren Sie uns!
Bildhinweis: © Trueffelpix / fotolia.com
© 2015
Teile dieses E-Book
iiiiiii
iiiiii
iiiiiii
iiiiiii
!56
