Design Sprints – Sinn und Unsinn der Google-Methode

Design Sprints erfreuen sich nach wie vor einer großen Beliebtheit. Verglichen mit ihrem „großen Bruder“, dem inzwischen populären Design Thinking, erreichen die Sprints zwar ein geringeres Suchvolumen (Das zeigt etwa dieser Einblick in Google Trends) – dennoch ist die Nachfrage ungebrochen und unsere (Online-) Seminare hierzu sind weiterhin sehr gut besucht.

Dies hängt vor allem mit der Leistung eines Design Sprints zusammen: Innerhalb von wenigen Tagen erhalten wir für vergleichsweise geringe Kosten ein neuartiges doch zugleich begründetes Produktkonzept inklusive eines authentischen Prototypens, valides Nutzerfeedback und Antworten auf essenzielle Fragen, die den Weg in die Zukunft ebnen. Design Sprints haben sich daher unter den Kreativ- und Innovationsworkshops ihren Platz merklich verdient. (Vielleicht auch interessant: Wie funktioniert ein Design Sprint? Und: Geht das auch Remote?)

Design Sprints sind aber kein Allheilmittel. Es gibt durchaus Fälle, in denen zwar der Wunsch nach Innovation besteht, aber ein Sprint nicht die geeignete Methode darstellt. Manchmal wäre der Sprint vielleicht auch ideal, aber das, was die Verantwortlichen damit vorhaben, macht die möglichen Vorteile zunichte. Und bisweilen ist alles perfekt geplant, doch ein fehlendes Detail führt dazu, dass das gesamte Fundament wackelt.

Wann macht ein Design Sprint keinen Sinn?

Worauf gilt es also zu achten, wenn wir einen Design Sprint organisieren wollen? Wann ist es vielleicht sogar besser auf einen Design Sprint zu verzichten und stattdessen eine andere Vorgehensweise zu erwägen?

Ein Design Sprint macht keinen Sinn, wenn…

…er zu schnell wieder vorbei ist:

Klar, es kostet (gerade in Sprint-unerfahrenen Unternehmen) viel Zeit und Überzeugungskraft die notwendigen Ressourcen und Mitarbeiter für bis zu fünf Tage von ihrer täglichen Arbeit weitgehend zu lösen. Da ist ein viertägiger Design Sprint, welcher bestimmte Abschnitte komprimiert und Diskussionen adäquat verkürzt, schon kompatibler. Das ist immer noch zu viel? Wenn wir nur tief genug googeln, finden wir exotische Vorschläge für Varianten, die einen Sprint in nur drei Tagen versprechen oder gar innerhalb einiger Stunden. Auf dem ersten Blick lässt sich mit einem „Design Sprint Light“ evtl. leichter argumentieren: „Wir fangen erst mal klein an und wenn es uns gefällt, machen wir vielleicht auch die vollständige Variante.“ Obgleich sicherlich auch solche Abwandlungen ihre Stärken haben werden (schließlich bleibt die wesentliche Vorgehensweise der fünf Designphasen immer erhalten) – das Ergebnis ist nicht gleichzusetzen mit einem solchen, welches ein längerer Sprint bieten würde. Das Einsatzgebiet ist grundverschieden. Absprachen und Erörterungen müssen abgekürzt werden, Kreativphasen drastisch reduziert und der Prototyp minimiert werden – Wenn am Ende dasselbe Produkt entstehen soll, müssten die entscheidenden Fragen vorher schon beantwortet sein. Daher beschreiben diese Design-Sprint-Intermezzos zumeist doch vielmehr Vorgehensweisen für andere Ausgangssituationen, für ein ganz spezifisches Problem oder für kleine interne Teams, um sich einer bestehenden Fragestellung kreativ zu widmen.

…die Herausforderung oder das Team nicht für einen Sprint geeignet sind:

Dies ist in etwa die umgekehrte Situation. Denn selbst, wenn wir alle Ressourcen organisiert bekommen, so muss unsere Herausforderung auch innerhalb dieser vier oder fünf Tage fachgerecht gelöst werden können. „Fachgerecht“ meint hier vor allem, dass es Problemstellungen gibt, die sich durch eine kleine Gruppe von Experten besser bearbeiten ließen. „Wie machen wir unser Produkt nutzerfreundlicher?“, „Wie verbessern wir unsere Navigation?“ oder „Wie sollte unsere nächste Werbekampagne aussehen?“ sind Fragen, mit denen sich speziell dafür ausgebildetes Personal beschäftigen sollte – sicherlich gern auch unter Beihilfe von Außen. Aber nicht ein gänzlich gemischtes, womöglich sogar fachfremdes, Team.
Und dann kann es auch noch die Herausforderung selbst sein, die nicht passen will. „Wie erschaffen wir das neue Facebook?“ ist doch deutlich zu ambitioniert. Es darf aber gerne noch etwas unspezifisch klingen: „Wir wollen für unsere Reihe XYZ ein innovatives Erlebnis durch ‚Sprache‘, für Kinder im Alter zwischen 6–8 Jahren, erschaffen.“ Das klappt. Man wird im Sprint auf Situationen stoßen, an denen viele Fragen und Möglichkeiten offenstehen – hier ist es wichtig, dass wir uns für einen Weg entscheiden und bewusst machen, dass alle übrigen Optionen auch nach dem Sprint nicht verloren gehen und noch nachträglich untersucht werden können.

Generell lässt sich festhalten, dass für sehr komplexe und breite Problemstellungen Design Thinking die bessere Methode darstellt. (Was ist der Unterschied zwischen Design Sprint, Design Thinking und Product Discovery?)

…wenn an wichtigen Ecken gespart wird:

Ein Design Sprint ist kein Jour Fixe. Natürlich könnten wir uns den typischen Raum in unserem Konzern reservieren, in dem wir sowieso jedes Mal unsere Meetings abhalten und wo alles seine Ordnung hat. Theoretisch könnten wir sogar zwischendurch umziehen, weil dummerweise unser Raum ausgerechnet immer mittwochs belegt ist. Aber ist dies ein Raum, wo großartige Ideen entstehen sollen wollen?
Auch für Design Sprints machen Räume und Einrichtungen Sinn, die viel Freiheit, Freude und Ungezwungenheit begünstigen. Die „Design Thinking Line“ von System 180 etwa oder auch die typischen Konferenzräume von Google zeigen Arbeitsumgebungen, in denen man sich sicherlich gern mit komplexeren Problemen auseinandersetzen möchte und die ihre Ansässigen – fast von ganz allein – zu dem verwandelt, für das unser alltäglicher Meeting-Ort keine Kräfte zu besitzen vermag: zu einem gleichgestellten Team, das gemeinsam, motiviert und ungezwungen an ein und demselben Problem arbeitet. Nicht nur UX-Legende Donald A. Norman weiß, dass wir in einer Umgebung und mit Dingen, mit denen wir uns wohl fühlen, beträchtlich effektiver und effizienter zu Lösungen gelangen („Joy of Use“).
Das trifft auch auf die reichhaltige Verpflegung zu (viele unterschiedliche Snacks, leichte Speisen und Obst) oder bei einem Remote Design Sprint auf die technische Ausstattung aller Teilnehmer. (Sozusagen der virtuelle Raum – wer verbleibt in Zoom, Skype und Co. schon gern viele Stunden und Tage unter stetigen Mikrofonrückkopplungen, dumpfen Stimmen und stotternder Bildübertragung?) Und zum Wohlfühlen gehört auch dazu, dass wir unsere wichtigen übrigen Aufgaben und Termine vor Sprintbeginn bereits abgearbeitet haben.

Viel Raum, mobile und modulare Möbel, Fläche für Haftnotizen etc. und jederzeit greifbare Snacks – so kann ein Design Sprint stattfinden (leider nicht im Bild: Die mobile Sofa-Ecke auf der gegenüberliegenden Seite).

…wenn zu viele Beteiligte mitmischen wollen:

Jake Knapp, der Erfinder des Design Sprints, empfahl 2016 nicht mehr als sieben Sprint-Teilnehmer (inklusive Entscheider). Wir haben bei eresult auch mit acht Teilnehmern gute Erfahrungen gemacht. Mehr sollten es aber wirklich nicht sein, denn erstens verlängert jeder zusätzliche Teilnehmer auch die Dauer der einzelnen Sprint-Methoden (z. B. mehr HMW-Notizen = mehr Aufwand beim Clustern) und zweitens müssen alle Teilnehmer auch gut durch den Sprint geleitet werden – viele Teilnehmer bedeuten unterschiedliche Ansätze und Diskussionen, die zwar durchaus gewünscht sind, aber die der Sprint-Moderator auch beherrschen und lenken können muss.
Wenn es uns schwer fällt die richtigen Teilnehmer für unseren Design Sprint auszuwählen, kann es hilfreich sein, bestimmten Personen stattdessen die Experten-Rolle zuzuweisen. So können diese das Team zwar nur anfangs und für kurze Zeit unterstützen, ihr Wissen und wertvoller Beitrag, geht aber nicht verloren.

Mehr als acht Teilnehmer sollten es bei einem Design Sprint nicht sein. Sechs oder sieben Teilnehmer sind optimal.

…wenn keine Einigkeit über die Nutzer besteht:

An wen soll sich unsere Lösung richten? Mit welcher Zielgruppe werden wir am letzten Tag unseren Test durchführen? Haben wir hier keine Antwort, werden wir nicht nur Schwierigkeiten haben, unter der Woche geeignete Probanden zu organisieren – viel schwerwiegender wird es werden, gemeinsam in der Gruppe an einem Produkt zu arbeiten, für das wir uns dessen letztlichen Benutzer nicht vorstellen können. Es ist ein wenig wie bei einer zu undefinierten Sprint-Herausforderung, die benötigt wird, um einen Design Sprint beginnen zu können: Starten wir auf einer zu großen „grünen Wiese“, droht das Vorhaben über uns hinauszuwachsen. Wir haben innerhalb des Design Sprints keine Zeit und Möglichkeiten spontan herauszufinden, wer für unsere neuartige Produktidee der typische Anwender ist. Sollten wir hier keine eindeutige Antwort haben und dennoch einen Design Sprint durchführen wollen, ist es höchstens vorstellbar, dass wir uns von Beginn an – das heißt vor dem ersten Sprint-Tag – auf eine Zielgruppe einigen, die unseren vagen Erfahrungen entspricht. So lässt sich rückblickend auch qualitativ bewerten, ob der untersuchte Personenkreis geeignet ist. Gleichzeitig bedeutet es aber auch, dass wir damit das Risiko eingehen, eine tolle Lösung zu erarbeiten, die anschließend an Strahlkraft verliert, da sie den falschen Probanden gegenübergesetzt wurde.
Aber auch wenn die Zielgruppe stimmt ist es möglicherweise wichtig, das finale Produkt auch an weiteren Zielgruppen zu erproben. Diese jedoch in die Fragestellungen der Sprint-Woche aufzunehmen, erhöht dessen Komplexität ungemein. Besser halten wir uns hier an die Regel, die uns auch in vielen anderen Situationen immer und immer wieder begegnet: Wir setzen auf die eine Lösung und behalten uns weitere Optionen oder ungeklärte Fragen für das nachträgliche Vorgehen vor. Dann können wir in Folgeuntersuchungen immer noch herausfinden, wie unser Produkt für Persona B und C aussehen sollte.

…wenn es danach direkt in die finale Umsetzung geht:

Ein Design Sprint kann verlockend wirken, wenn man dessen Geschwindigkeit mit dem Prozess eines klassischen Wasserfall-Modells vergleicht. Schließlich erhalten wir nach wenigen Tagen bereits qualitatives Nutzerfeedback und wenn wir Glück haben, fällt dies vielleicht durchaus positiv aus. Man könnte nun meinen, es genüge das Design des Prototypen fein auszuarbeiten und die gröbsten Usability-Hindernisse zu beseitigen – fertig ist das neue Produkt!
Das, was wir nach dem Sprint aber in den Händen halten, ist nur der Rohdiamant. Es gibt mit Sicherheit einige Stellen, an denen es sich lohnt weitere Untersuchungen anzuschließen. An manchen Kreuzungen wurden ggf. Entscheidungen getroffen, die noch einmal nachträglich überprüft werden sollten. Vielleicht sind auch weitere Zielgruppen und Szenarien denkbar. Das Produkt eines Design Sprints bringt also – so spannend es auch sein mag – immer auch eine gute Hand voll Hausaufgaben mit sich.

…wenn er zu sehr gestreckt wird:

Wenn es schwierig wird die gewünschten Teilnehmer für ein paar Tage am Stück von ihren üblichen Aufgaben zu lösen, ließen sich die Tage theoretisch auch separat verteilen, gar auf mehrere Wochen. Doch damit wird dem Design Sprint nicht nur dessen Geschwindigkeit genommen, sondern auch seine Kraft und Effizienz. Sich mehrere Tage am Stück, mit denselben Personen im selben Raum einzuschließen und in echter Teamarbeit an einer gemeinsamen Lösung zu arbeiten, verleiht dem Sprint ein enormes Potenzial. Dies spiegeln auch jedes Mal die Rückmeldungen unser Teilnehmer wider.
Bei Remote Design Sprints ist es gezwungenermaßen so, dass die Sprinttage etwas gestreckt werden müssen – die volle Zeit in derselben Konzentration und Dauer kann sonst sehr energieraubend werden. Auch das Vorarbeiten der Sprint-Moderatoren hat sich hier als hilfreich erwiesen. Durch die regelmäßige Kommunikation (und kleine Hausaufgaben zwischendurch) schafft das Konzept des Remote Design Sprints, den Vorteil eines Vor-Ort-Workshops weitgehend beizubehalten. Dies sähe jedoch mit Sicherheit anders aus, würden diese Zwischenphasen durch leere Tage – oder gar Wochen – gefüllt werden; allein da sich die verschiedenen Teilnehmer stetig erneut in die Fragestellung einarbeiten müssten. Wir raten daher davon ab.

…wenn das Ergebnis am Ende in einer Schublade verschwindet:

Zugegeben, das kam in unseren Design Sprints noch nie vor. Aber dies beschreibt einen Gedanken, den manche potenziellen Initiatoren haben: Was ist, wenn alles umsonst war und das Ergebnis nicht zufriedenstellend ist? Diese Sorge ist insofern unbegründet, da jedes Sprint-Ergebnis als „Leuchtturm-Projekt“ taugt. Der Prototyp basiert schließlich nicht auf Entscheidungen, die dem reinen Bauchgefühl zuzuordnen sind.
Und nehmen wir einmal an, im Nutzertest stelle sich tatsächlich heraus, dass der Untersuchungsgegenstand Frustrationen begünstigt hat und von den Probanden allesamt abgelehnt wurde. In diesem Fall könnten wir, dank der qualitativen Aussagen, gut ausmachen, woran es gelegen hat. Gab es schwerwiegende Usability-Probleme? Wurde das Konzept an einer bedeutsamen Stelle missverstanden? Gibt es bereits eine effizientere Lösung als unsere? Solche Erkenntnisse stellen niemals ein Versagen dar, sondern beschreiben ganz normale Erfahrungen, mit deren Hilfe wir unseren Rohdiamanten feinschleifen können. Und hieraus entstehen immer Antworten, die von hohem Interesse sind.
Und auch hier gilt: Wer würde nicht lieber nach einer Woche solche Antworten erhalten, als nach monatelangen Mühen und Investitionen?

Bestimmt gibt es auch noch einige weitere Punkte, die für einen erfolgreichen Design Sprint hinderlich sind. Fallen Ihnen vielleicht auch noch welche ein?

Vielleicht auch interessant: Unser kostenloses Whitepaper „Der Business Value von Design Sprints“ und die Fallstudie „Design Sprint @ MISUMI“.

Portraitfoto: Robin Nagel

Robin Nagel

UX Consultant

eresult GmbH

Bisher veröffentlichte Beiträge: 6

2 Kommentare

Schreibe einen Kommentar

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