Design Sprints: In kürzester Zeit zu messbaren Ergebnissen

Veröffentlicht am 05. May 2020

forwerts Team

Der Faktor Zeit spielt bei der Schaffung neuer Produkte und Produktverbesserungen eine immer wesentlichere Rolle. Dabei ist der Weg von der Problem- über die Entscheidungsfindung bis hin zum Prototypen oftmals ein beschwerlicher, der durch endlose Meetings führt, die immer weitere Stolpersteine zum Vorschein bringen und schließlich in unausgereiften Kompromissen münden.

Deshalb hat sich in den vergangenen Jahren ein effizienter Prozess entwickelt, mit dem man teils monatelange Arbeit auf ein paar wenige Tage komprimieren kann: Der Design Sprint. In diesem Workshop-Verfahren finden sich crossfunktionale Teams zusammen, die sich einer klaren Challenge verschreiben, in der Ideen validiert und Lösungen direkt am Nutzer getestet werden.

“It’s what work should be about — not wasting time in endless meetings, then seeking camaraderie in a team-building event at a bowling alley — but working together to build something that matters to real people. This is the best use of your time. This is a sprint.” – Jake Knapp

Vor knapp 20 Jahren wurde eine freie Internet-Enzyklopädie ins Leben gerufen, die sich in Windeseile verbreitete und die heute jeder unter dem Namen Wikipedia kennt. Der Gedanke, dass dieses gemeinnützige Projekt in den Folgejahren nicht nur den etablierten Hauptkonkurrenten Encarta abhängen, sondern Microsofts Lexikon gänzlich zum Scheitern verurteilen könnte, wurde Anfang der 2000er als unmöglich bezeichnet und ins Reich der Fabeln verwiesen.

Doch wie so oft sind wir heute schlauer und der Untergang Encartas wurde sowohl zu einem mahnenden Beispiel als auch zum Startschuss einer neuen Methodik der Produktentwicklung und -verbesserung. Denn Jake Knapp war damals Teil des Encarta-Teams, welches den aufkommenden Konkurrenten schlicht mit einem eigenen Redesign in die Schranken weisen wollte — Sprich: Ohne Alternativen zu testen wurde alles auf eine Lösung gesetzt, deren Umsetzung ein ganzes Jahr dauerte, in dem sich Wikipedia zum Krösus entwickelte.

Jake Knapp wurde klar, dass Lösungen nicht immer so offensichtlich sind, wie man zunächst annimmt, und dass bei der Entscheidungsfindung oft halbgare Kompromisse geschlossen werden, die eher ein ‚sich im Kreis drehen’ begünstigen und Zeit kosten. Also machte er sich gemeinsam mit John Zeratsky auf den Weg einen methodischeren Ansatz zu entwickeln, der auf dem Mindset des Design Thinkings aufbaut und das Beste aus Lean Startup, User Experience Design sowie agilen Methoden vereint — Den ‚Sprint’.

Während ihrer Zeit bei Google Ventures betreuten Knapp und Zeratsky zahlreiche Startups und führten mit ihnen über 150 ‚Sprints’ durch. Ziel dabei war es, innerhalb kürzester Zeit die Komplexität eines Projektes zu verstehen und greifbare Ergebnisse zu erzielen. Es ist also kein Zufall, dass der methodische Ansatz in einem Startup-Kontext entwickelt wurde, da hiermit in einem übersehbaren Zeitrahmen erste Schritte formuliert werden können, die sowohl das eigene Team als auch mögliche Investoren im Optimalfall zu überzeugen wissen.

Die auch als ‚Google Sprint’ bekannte Urform des Sprints, die hierdurch entwickelt wurde, setzt sich aus klaren Rahmenbedingungen zusammen, um den Fokus zu wahren:

  • Dauer: Eine Arbeitswoche (Mo-Fr), also 5 Tage in denen von 10 bis 17Uhr nur gesprintet wird.
  • Raum/Material: Ein optimal ausgestatteter Raum mitsamt Materialien für den Prototyp-Bau.
  • Team: Kleine Gruppe aus 5 bis 7 Leuten, die den Product Owner miteinschließt oder zumindest eng miteinbindet.
  • Moderator: Ein sogenannter Sprint Facilitator, der durch den Sprint führt, Entscheidungen einfordert und somit den reibungslosen Ablauf gewährt.
  • Kunden/Anwender: Die nach dem Sprint zu den Ergebnissen interviewt werden und/oder den Prototyp testen.

Neben den Rahmenbedingungen sollte zuvor auch immer erst die Aufgabenstellung klar definiert und verstanden sein. Um einen Sprint also auch mit den maximalen Erfolgsaussichten zu starten, legt man zunächst dar, welche Challenge dem Sprint zugrunde liegt:

  • Was ist das Problem? Wie stellt sich die Ausgangslage dar?
  • Welche Ziele werden mit der Lösung des Problems verfolgt?
  • Wer ist der Kunde bzw. soll Kunde werden?

 

Ein Sprint ist also ein mehrtägiger Workshop, in dessen Verlauf Probleme analysiert, Lösungen entwickelt und Ideen mit Kunden getestet werden. Die klaren Rahmenbedingungen aus dem Google Sprint sind allerdings auch flexibel anwendbar. So richtet sich vor allem der Zeitaufwand an dem konkreten Anwendungsfall und Kontext aus. Wird zum Beispiel eine größere Feature-Entwicklung vorangetrieben, werden unterstützende Design Sprints projektbegleitend für längere Zeit geplant und können auch über weit mehr als die gängigen 5 Tage spannen.

Design Sprints sind somit auch immer abhängig vom jeweiligen Projektstatus. Befindet man sich noch in der PoC(Proof of Concept) oder bereits in der MVP(Minimum Viable Product) Phase? Geht es um eine losgelöste und somit kontextfreie Betrachtung oder sind wir bereits einen Schritt weiter und können ein konkretes Problem im Kontext betrachten?

Aber auch wenn das Sprintverfahren sich immer nach der Ausgangslage richtet, so ist der Ablauf eines Design Sprints in unserem UX-Kosmos klar abgesteckt und nutzt neben der Orientierung am Design Thinking Prozess auch Elemente des Customer Journey Mapping:

  • Verstehen: Hier sollte zunächst der Ablauf sowie die Rahmenbedingungen geklärt und ein kontextuelles Verständnis aufgebaut werden. Was ist überhaupt die Challenge? Dabei hilft es oft zunächst die Konkurrenz zu untersuchen und herauszufinden, wie dort mit einem bestimmten Problem umgegangen wird. Des Weiteren –sofern noch nicht im Voraus geschehen- ist es unabdingbar direkt zu evaluieren für WEN man überhaupt entwickelt. Wer sind die Nutzer? Welche Bedürfnisse haben sie? Mit Hilfe von Personas und dem Kreieren eines Key Customers können Antworten auf diese Fragen gefunden werden, bevor es an das Ausformulieren erster Lösungswege und Strategien geht.
  • Lösungsansätze finden: Da das Team nun die Challenge verstanden hat, kann an einer gemeinsamen Vision gearbeitet werden. In dieser Phase geht es um das Entwickeln von Ideen und dies bedeutet: So viele Lösungen zu erarbeiten wie nur irgend möglich. Um hier ein bisschen Abwechslung hereinzubringen, kann man auch den spielerischen Ansatz der ‚Crazy 8’-Methode einsetzen. Dabei versucht jedes Teammitglied in 5 Minuten 8 verschiedene Ideen zu skizzieren. Wenn dann eine Vielzahl von Lösungen auf dem Tisch liegen, kann sich das Team bereits aufmachen auszusieben und den Ideen Prioritäten zuzuweisen.
  • Entscheiden: Hier gilt es zunächst über die besten Ideen abzustimmen bzw. aus allen eingeworfenen Ideen ‚Die Lösung’ herauszufiltern. In dieser Phase sollte genügend Zeit zur Verfügung gestellt werden, um über die vorhandenen Ideen zu reflektieren und Meinungen darüber auszutauschen, welche am Erfolgsversprechendsten ist. Wenn es Ressourcen, Zeitplan und Budget hergeben, können hier aber auch mehrere Kandidaten mit in die nächste Phase genommen werden. Sobald man sich geeinigt hat, wird die beste Idee ausführlich mit einem Storyboard versehen.
  • Prototypen: Nun geht es darum anhand des Storyboards einen oder mehrere Prototypen zu entwickeln, deren Erstellung in der Regel nicht länger als ein Tag dauern sollte. Der Prototyp muss also weder Ansehnlich noch eine genaue Abbildung des schlussendlichen Endprodukts sein. Da er aber von tatsächlichen Benutzern getestet werden soll, muss er so ausgefeilt sein und über eine ausreichende Usability verfügen, damit er auch verwendet werden kann.
  • Überprüfen: Jetzt kommen endlich externe Nutzer ins Spiel, die mit dem/den Prototypen konfrontiert werden. Damit die Probanden auch ehrliche Antworten geben, sollte am Besten einer aus dem Team — mit dem größten Wohlfühl-Faktor — zum Interviewer ernannt werden, der die Tests mit den Nutzern individuell durchführt. Die so in jedem Durchgang ermittelten Ergebnisse geben weitere Aufschlüsse über ‚Das, was funktioniert’ und ‚Das, was (noch) nicht funktioniert’.

 

Design Sprints ersetzen das klassische UX Design natürlich nicht, aber der hands-on approach hilft den Teammitgliedern ihren Fokus zu schärfen und das direkte Feedback von echten Nutzern sorgt für eine bessere Entscheidungsfindung. Schließlich sind es immer die Nutzer, die über den Erfolg oder Misserfolg eines Produktes oder Services richten.

Als Unternehmen, das nutzerorientierte Produkte und Anwendungen entwickelt, sind wir bei forwerts stets auf der Suche nach neuen Problemen, die gelöst werden wollen. Design Sprints erlauben uns dabei in kürzester Zeit Prototypen zu entwickeln und Lösungsansätze direkt am Kunden zu testen. Dadurch können unsere Expertenteams schnell messbare Ergebnisse liefern, die uns bei der Erreichung neuer Meilensteine unterstützen.

Diese Artikel könnten Sie auch interessieren