Design Sprints und die Vorteile gegenüber klassischem UX Design

Was sind überhaupt Design Sprints? Ein Design Sprint ist ein Prozess mit unterschiedlichen Schritten, der innerhalb von 5 Tagen (seit Design Sprint 2.0 in 4 Tagen) Lösungen für große Probleme erarbeitet und diese validiert. Erfunden wurde das ganze ursprünglich von Jake Knapp für Google Ventures, was er dann auch direkt in einem Buch verewigt hat. Der Prozess ist ein Workshop mit 6-8 Personen, die fokussiert daran arbeiten, Problemstellung zu erarbeiten und die für den Design Sprint relevante einzugrenzen. Man kann im Sprint nicht alle Probleme auf einmal lösen. Deshalb ist es notwendig, sich auf eine Problemstellung zu fokussieren. Nachdem man aus diversen Lösungsansätzen einen bestimmt hat (ggf. auch mal zwei), wird dieser als Prototyp umgesetzt, damit dieser dann an echten Nutzern getestet werden kann – beides an jeweils einem Tag.

Es handelt sich also um einen sehr schnellen Prozess, um Lösungsansätze für eingegrenzte Problemstellungen zu erarbeiten, als Prototyp umzusetzen und zu testen. Design Sprints beschränken sich übrigens nicht nur auf digitale Produkte.

Vorteile gegenüber klassischen UX Design Methoden.

Design Sprints sind schnell. Sehr schnell. In gerade mal einer Woche lässt sich herausfinden, ob eine Lösungsidee grundsätzlich funktioniert oder nicht. Gegebenenfalls macht man noch einen Iterationssprint, um eine Idee aufgrund der Testergebnisse zu verfeinern. Danach kann man dann aber in die Umsetzung gehen. Klassisches UX Design würde da wesentlich länger dauern. Ja, Design Sprints ersetzen UX Design nicht, da der Fokus ein anderer ist. Es stellt sich nur die Frage, ob Personas, Empathie- und Situationalmapping und langwierige Researchphasen ein besseres Ergebnis erzielen als Design Sprints. Schließlich entwickeln hier diejenigen Personen, die am meisten vom Produkt und den Nutzern verstehen, gemeinsam die richtige Fragestellung und die unterschiedlichen Lösungsansätzen. Essenziell notwendig ist dafür natürlich, dass man Produkt und Nutzer auch wirklich versteht und sich nicht am ersten Tag des Design Sprints das erste Mal damit beschäftigt. Aus diesem Grund nehmen bestenfalls aber auch nur Experten am Design Sprint teil.

Der kurze Zeitraum vom Lösungsansatz zum Testing, das geballte Wissen der Experten in einem Raum und die kurze Iterationszeit sind die Vorteile des Design Sprints. Der Fokus geht weg von der Theorie, hin zur praktischen Umsetzung und echtem Feedback von echten Nutzern. Das Problem ist ja immer, dass man sich viel Ausdenken kann, letztendlich aber erst der Nutzer entscheidet, ob das Produkt einen Nutzen hat oder nicht, wenn er/sie es auch wirklich benutzen kann – selbst wenn es sich erstmal „nur“ um einen Prototypen handelt.

Wann setzt man Design Sprints ein?

Ich hatte es ja schon erwähnt: Design Sprints ersetzen nicht UX Design Methoden, ob nun Lean UX oder nicht. Man sollte auch aufpassen, dass man nicht versucht jedes Problem damit zu lösen, nur weil man den Prozess so toll findet. Das wird nicht funktionieren und auch beim Kunden nicht unbedingt gut ankommen, wenn man einen Design Sprint verkauft und sich danach herausstellt, dass man in die falsche Richtung gearbeitet hat.

Wann setzt man nun also Design Sprints ein? Es sollte sich nicht um Probleme handeln, die eine einzelne oder zwei Personen alleine mal schnell umsetzen oder testen können. Es wäre beispielsweise unsinnig, einen Design Sprint anzusetzen um die Farbe oder Position eines Buttons zu diskutieren. Es geht vielmehr um größere Teile eines Produkts oder vielleicht sogar ein ganz neues Produkt. Falls die komplette Entscheidungsgewalt oder das gesamte Wissen bei einer einzigen Person liegt und es keinen Sinn ergibt, andere Personen oder Abteilungen mit in den Entscheidungsprozess einzubeziehen, würde man sich ebenfalls nicht für einen Design Sprint entscheiden.

Eine Abonnement-Struktur einem Produkt hinzufügen? Design Sprint. Die Nutzerinteraktion mit dem Produkt soll gesteigert werden? Design Sprint. Die Navigationsstruktur einer Webseite soll geändert werden? Kein Design Sprint. Das Problem muss so groß sein, dass es die Kosten eines Design Sprints rechtfertigt. Wenn man keinen Design Sprint einsetzt um eine Lösung für ein Problem zu erarbeiten, was würde es für das Produkt bedeuten? Wären die Kosten vernachlässigbar oder wäre es wirklich wichtig, dieses Problem zu lösen? Bedarf es zur Lösung des Problems mehrerer Personen aus unterschiedlichen Abteilungen?

Ich hoffe, ich konnte einen ersten kleinen Einblick in Design Sprints geben. „Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days“ von Jake Knapp (gibt’s auch auf Deutsch) ist nicht umsonst auf Platz 2 meiner Literaturliste. Das Buch ist super geschrieben und hat mich in die Welt der Design Sprints eingeführt und damit meinen Horizont in der UX Welt um ein vielfaches erweitert. Mittlerweile gibt es ja auch schon den Design Sprint 2.0 (weiterentwickelt von AJ & Smart zusammen mit Jake Knapp), der den Sprint auf vier Tage verkürzt. Aber als Einstieg kann ich das Buch nur empfehlen. Ich denke, ich werde auch noch ein Buchreview schreiben. Darüber hinaus werde ich vielleicht auch noch eine mehrteilige Artikelreihe erstellen, die Design Sprints detaillierter beschreibt.

(Alle meine Artikel werden von mir persönlich geschrieben. Da schaut niemand mehr drüber, was manchmal vielleicht besser wäre. Aber dadurch bekommt man eben auch genau das zu lesen, was ich so denke und recherchiert und gelernt habe. Da bleiben ein paar Rechtschreibfehler nicht aus. Das tut mir auch echt leid, aber damit muss man dann auch einfach mal klar kommen.)