7 Hacks für euren Google Design Sprint

Nachdem wir in den vergangenen Jahren Design Sprints zu den verschiedensten Themen mit Kollegen aus den unterschiedlichen Abteilungen veranstaltet haben, haben wir sieben Dinge in der Art und Weise geändert, wie wir unsere Design Sprints durchführen. Und es hat die Methodik für uns viel besser gemacht.

Mit der Methodik des Design Sprint hat Google Ventures uns einen Weg gezeigt, in die Zukunft unserer Produkte zu schauen. Fünf strukturierte Tage reichen aus, um „vorzuspulen” und ein echtes Produkt vor sich zu haben, zu dem bereits die ersten Nutzer Feedback gegeben haben. Wir sehen im Design Sprint die stärkste UX-Methodik der letzten Jahre. (Danke, Jake Knapp!)

Trotzdem kann jede Technik angepasst werden, um noch besser zum eigenen Team und der eigenen Art der Arbeit zu passen. Hier sind die sieben Dinge, die wir im Ablauf unserer Design Sprints geändert haben, um diese noch besser zu machen.

Tauche tiefer in die Problematik ein

Der Montag in der Sprint-Woche steht ganz im Zeichen der Beleuchtung des Problems, welches ihr in eurem Sprint angehen werdet. Laut dem Buch wird dies mithilfe der „Start at the end“-Übung gemacht. Einfach gesagt stellt man sich dabei eine Zukunft vor, in der der Sprint bereits geschehen ist, und hält fest, welche Fragen bisher beantwortet wurden und was sich seither verändert hat. Das ist eine gute Technik, um ein klares Bild vom Sprint-Ziel zu bekommen, aber nach unserer Erfahrung reicht es nicht aus, um ein geteiltes Verständnis des zu lösenden Problems zu schaffen.

Wir haben diesen Schritt um zwei Übungen ergänzt, die uns helfen, dieses geteilte Verständnis zu erzeugen.

Best Practice or Bust (intern Karibik oder Chorweiler 😁)

Wir nutzen grundsätzlich die „Start at the end“-Technik, aber wir schauen uns dabei auch die Kehrseite an. Nehmt euch einen Block Post-It-Notes und schreibt all die Dinge auf, die sich in den kommenden 6 bis 12 Monaten zum Schlechten verändert haben werden oder schief gelaufen sein werden. An einem eurer Whiteboards befinden sich dann zwei Seiten. Auf der einen Seite sind alle Notizen, die sich eine Zukunft ausmalen, in der alles nach dem Sprint perfekt verlaufen sein wird. Die andere Seite des Boards gehört der schlechten Aussicht. Geht hier davon aus, dass alles, was ihr ab sofort macht, schiefläuft. Was wird sich im kommenden Jahr verändert haben oder eben gerade nicht? Was wird passiert sein und wie wirkt sich das auf euer Business aus?

Einen Blick auf eine solche Dystopie zu werfen ist ehrlich gesagt nicht sonderlich aufheiternd am Anfang eines Design Sprints, aber glaubt mir, es rüttelt jeden im Raum wach. Die Tatsache, dass das Best-Case-Szenario direkt daneben steht, tut dann ihr Übriges, um die Wogen direkt wieder zu glätten.

Schrei uns an

Für den Erfolg des Sprints ist es entscheidend, ein gemeinschaftliches Verständnis des Problems zu haben. Wie sich zeigt, gibt es in jedem Sprint-Team Experten, die mehr über das Problem wissen und Experten, die eben nicht so tief in der Problematik sind. Mit einer Übung, die wir „Schrei uns an“ nennen, geben wir jedem Teilnehmer und jeder Teilnehmerin die Möglichkeit, alles rauszulassen und das Problem aus ihrer bzw. seiner Sicht zu schildern, um so viele Erfahrungswerte wie möglich zu dem Thema auf den Tisch zu bekommen.

Nebenbei sei erwähnt, dass man bei dieser Übung nicht zwangsläufig schreien und weinen muss, aber es hilft ungemein weiter, seinen Emotionen freien Lauf zu lassen, damit der Rest des Teams die Schmerzpunkte wirklich versteht.

Diskutiert nicht – versteht

Es ist wichtig, zu versuchen, das Problem nicht zu sehr zu diskutieren. Diskussionen nehmen zu viel Zeit in Anspruch und führen selten zu wirklich guten Ergebnissen. Versucht das geteilte Verständnis zu erlangen und hebt euch die großen Fragen und eure Meinung dazu für später im Sprint auf.

Benennt eure Experten

Das ist nur ein kleiner Trick, den wir nutzen, damit sich unser Sprint-Team besser und mehr wertgeschätzt fühlt. Sprecht nicht durchweg von Team-Mitgliedern odder Teilnehmer/innen. Stellt sicher, dass ihr die Personen, die eurer Meinung nach bei dieser Wagnis helfen können, Experten nennt. Denn genau das sind sie. Das sind die Experten, die eine entscheidende Rolle in der Lösung eurer großen Problemstellung spielen werden.

Verlasst eurer Büro

Im Sprint-Buch beschreibt Google den „War Room“. Dabei handelt es sich um einen Raum, der ganz speziell für Veranstaltungen wie einen Design-Sprint vorgesehen und ausgestattet ist. Ohne große Überraschung zeigt sich allerdings, dass nicht jedes Büro über ausreichend Platz für einen solchen Raum verfügt. Das ist bei uns nicht anders. Wir haben in unserem Kölner Büro sechs kleinere Meeting-Räume und sogar einen riesigen, der auch gut für ein Meeting mit 30 Personen funktioniert. Aber keiner dieser Räume erfüllt die Anforderungen an einen „War Room“. Außerdem zeigt sich aus unserer Erfahrung, dass es eine schlechte Idee ist, den Sprint im eigenen Büro zu veranstalten. Dabei besteht immer die Gefahr, dass man doch vom Tagesgeschäft abgelenkt wird.

Daher buchen wir uns für unsere Design Sprints in einen geeigneten Raum in einem der vielen tollen Coworking-Spaces in Köln ein. Das funktioniert perfekt. Der Raum hat dann die richtige Größe und Ausstattung. Außerdem gibt es zumeist eine Kaffee- und Snack-Flatrate.

Denkt also lieber zweimal nach, ob ihr euren nächsten Sprint in eurem Büro veranstaltet oder ob ihr nicht doch das Budget findet, um das Büro zu verlassen.

Verbessert den Sketching-Prozess

Ich liebe den Dienstag in der Sprint-Woche! Mit meinem Background als Grafik- und Interfacedesigner ist es einfach immer wieder toll, den Kollegen aus anderen Abteilungen dabei zuzusehen, wie sie ihre kreative Seite rauslassen. Und es überrascht mich immer wieder, wie kreativ und „out of the box“-denkend meine Kollegen aus den anderen Abteilungen werden, wenn man sie nur ein kleines bisschen in die richtige Richtung schubst.

Trotzdem funktioniert der im Buch beschriebene Sketching-Prozess nicht perfekt für uns.

Schauen wir uns kurz an, wie das Buch es vorgibt:

1. Notizen machen, 20 Minuten

   • Schlüssel-Informationen niederschreiben

2. Ideen aufschreiben, 20 Minuten

   • Rohe Ideenentwürfe runter skribbeln

3. Crazy 8s, 8 Minuten

   • Verschiedene Variationen von Ideen unter Zeitdruck

4. Lösungs-Sketches, 30+ Minuten

   • Details erarbeiten

An diesem Prozess ist eigentlich gar nichts falsch. Allerdings stellte sich in unseren vergangenen Sprints heraus, dass das Team die Unterscheidung von Notizen und Ideen nicht so recht verstanden hat. Außerdem fanden sie es sehr schwierig, ihre Crazy 8s in Lösungs-Sketches umzuwandeln.

Daher haben wir den Prozess für uns ein wenig verändert.

1. Macht Notizen

   20+ Minuten

   • Der erste Schritt ist ganz einfach. Ihr stellt den Timer auf 20 Minuten und lasst das Team ihre Ideen und Notizen zu Papier bringen. Erklärt dem Team dabei, dass es darum geht, alles aufzuschreiben, was ihnen zur Problemlösung in den Sinn kommt. Diese Übung ist mehr oder weniger eine Mischung aus den Übungen „Notizen machen“ und „Ideen aufschreiben“, so wie sie im Buch beschrieben sind. Sie gibt dem Team jedoch die Freiheit, während dieser Phase so viel oder wenig zu sketchen, wie sie es für richtig halten. Wenn das Team nach den 20 Minuten noch Zeit benötigt, dann hängt einfach noch 10 Minuten hinten an und noch einmal 10 Minuten, wenn es nötig ist.

1. Crazy 8s 

   8 Minuten

   • Hier gibt es keine Änderungen zum Buch. Ihr nehmt das Papier, faltet es und skizziert Variationen eurer Ideen unter Zeitdruck. Immer wieder ein Spaß! Bei einem unserer letzten Design Sprints waren die Kollegen von Digitale Leute dabei und haben dazu ein ausführliches Interview mit viel Video- und Bildmaterial veröffentlicht. Pro-Tipp: Ich empfehle die Nutzung der App Bit Timer als Timer.

1. Feature Storyboards

   30+ Minuten

   • Diesen Schritt haben wir von den originalen „Lösungs-Sketches“ adaptiert. Eigentlich ist es tatsächlich eine umbenannte Kopie mit kleineren Änderungen. Das Problem mit den Lösungs-Sketches ist, dass das Team nicht verstanden hat, was genau in dieser Übung gefordert wurde, selbst als ich gute Sketches aus den vergangenen Sprints gezeigt habe. In deren Köpfen ist ein „Sketch“ ein Blatt-Papier mit einer Zeichnung. Warum auch 3 Post-its? Also haben wir die finalen Blätter in „Feature Storyboards“ umbenannt und erklärt, dass das gewünschte Ergebnis eine skizzierte Erklärung eines einzelnen Prototypen-Features ist. Mit einer Einleitung, der Feature-Aktion an sich und einem Abschluss. Genau wie in einem kleinen Storyboard aus einem Comic. „Du gelangst über eine E-Mail auf die Seite, dann klickst du den Call-To-Action-Button und der Download beginnt.“ Einleitung, Aktion, Abschluss. So einfach kann das sein.

Kritiker werden jetzt sagen, dass das ziemlich genau das ist, was Jake Knapp mit den Lösungs-Sketches meinte und ich möchte gar nicht gegenargumentieren. Es zeigt sich nur bei uns, dass es für die Sprint-Experten einfacher zu verstehen ist, wenn es anders heißt und eine andere Story erklärt wird.

Nutzt einen neuen Ansatz zum Storyboarden: Den Proto-Flow

Die finale Übung am Mittwoch während der Sprint-Woche ist das Storyboard. Das Ziel ist ein mehr oder weniger detailliertes Storyboard, das den Ablauf des gewünschten Prototypen aufzeigt.

Dabei gibt es allerdings ein Problem, das wir in einigen unserer Sprints erkannt haben: Am Mittwochnachmittag ist das Team meist recht erschöpft, wenn es Zeit für das Storyboarden ist. In dieser Konstitution ein gutes Storyboard an die Wand zu bringen, stellt immer eine große Herausforderung dar.

Nun war es aber so, dass wir meistens damit begonnen haben, ein Flow-Diagramm der verschiedenen Schritte aufzumalen, die die Tester/innen im Prototypen durchlaufen werden.

In unserem letzten Design-Sprint habe ich diese Situation erstmalig in einen Vorteil gewandelt. Dabei habe ich das Team etwas tiefer in die Ausarbeitung des Flow-Diagramms mitgenommen und auf das anschließende Storyboard einfach verzichtet. Wir nennen diese Übung den „Proto-Flow“.

Wenn ihr euren Sprint-Mittwoch mit dem Proto-Flow beendet, habt ihr als Resultat ein Flow-Diagramm, das ein gemeinschaftliches Verständnis darüber vermittelt, was am Donnerstag umgesetzt wird, ohne zu tief in die Details zu gehen und jedes kleine Stückchen aufzuschreiben.

Nutzt kein Keynote!

Der folgende Tipp ist mehr ein Best-Practice aus unseren Sprints als ein genereller Tipp für alle anderen Sprint-Teams.

Wie im Buch empfohlen, haben auch wir anfänglich Keynote und Keynotopia genutzt, um unsere ersten Sprint-Prototypen zu bauen. Wir glauben bei jobvalley aber auch daran, dass jede_r immer das tun sollte, womit er_sie den meisten Mehrwert schafft. Und da unser Sprint von einem unserer UX-Designer moderiert wird, haben wir recht früh entschieden, dass die Prototypen auch maßgeblich von diesem UX-Designer erstellt werden soll.

Weiterhin zeigte sich bei uns, dass Keynote unseren Prototypen-Prozess nicht beschleunigt, sondern sogar verlangsamt. Der Grund ist, dass wir durchgehend alle Arten von Prototypen in Tools wie Sketch oder Adobe xD bauen. Es ist also logisch, dass wir das im Design Sprint genau so machen. Normalerweise teilen wir das Sprint-Team am Donnerstag in drei Gruppen auf, die den Prototypen anhand des Proto-Flows bauen, den Inhalt für den Prototypen erstellen und das anstehende Interview am Freitag planen.

Veranstalte ein öffentliches Wrap-Up

Bei jobvalley streben wir die vollständige Transparenz unserer Arbeit an. Und wenn deine Firma ähnlich tickt wie unsere, dann ist es wichtig, das gesamte Team über die Ergebnisse der Design-Sprints zu informieren. Bei uns fordern unsere großartigen Kollegen diese Informationen mittlerweile sogar direkt ein.

Nach jedem Design-Sprint veranstalten wir also ein öffentliches Wrap-Up für die gesamte Firma. Normalerweise nutzen wir hierfür eine der nächsten regelmäßigen Scrum-Sprint-Review-Meetings und beenden diese Veranstaltung mit dem Wrap-Up. Dieses wiederum startet immer mit einer kurzen Erklärung der Design-Sprint-Methodik für all die Teilnehmer, die diese Informationen zum ersten mal hören. Dann zeigen wir den Prototypen und geben Einsicht in das User-Feedback vom Freitag. Außerdem nutzen wir die Chance, um über weitere Schritte nach dem Design-Sprint zu sprechen und internes Feedback zu sammeln.

Als Resultat zeigt sich, dass die verschiedenen Abteilungen die Methodik immer mehr befürworten und sich mittlerweile freiwillig melden, um als Experte an einem der nächsten Sprints teilzunehmen.

Im Original veröffentlicht auf UX and the City.