Drei Tage Design Sprint bei portagon

Lesedauer: 6 Minuten

Veröffentlicht am 6. Januar 2022
Leon Stamm ist seit Juli 2021 bei portagon und ist verantwortlich für das Produkt. Als Teamlead im Product Management kümmert er sich um die Planung und Steuerung unserer Software portagon go. Als innovatives Format in der Produktentwicklung hat er einen Design Sprint entwickelt und mit einem ausgewählten Team durchgeführt. Dieser Blogartikel ergänzt die Rubrik „inside portagon“ – hier teilen wir unser Erfahrungen und Learnings als dynamisch wachsendes Unternehmen.
click here for the englisch version

Das Problem

Bei portagon helfen wir unseren Kund:innen bei der Kapitalbeschaffung durch Crowdinvesting. Wir hatten die Idee, unseren Kund:innen auf einem Software-Dashboard Echtzeiteinblicke in ihren Projektstatus zu geben. Auf dem Dashboard wollten wir auch Empfehlungen geben, um die Kampagnen unserer Kund:innen erfolgreicher zu machen. Ein Ansatz dafür war beispielsweise die Bereitstellung demografischer Daten von Anleger:innen  (z. B. Alter, Standort usw.), um so gezielte Marketingprogramme zu initiieren und weitere Anleger:innen zu gewinnen.

Problemlösung durch einen Design Sprint

Vor Kurzem haben wir einen dreitägigen Design Sprint abgehalten, um ein Konzept für ein neues Dashboard für unser Softwareprodukt zu entwickeln. Ein Design Sprint dient dazu, Herausforderungen in einem angemessenen Umfang zu lösen. Am Ende wird ein Prototyp/MVP durch Benutzertests verifiziert.

Wir haben den Design Sprint auf unübliche Weise genutzt – um ein Dashboard für ein Software-Tool zu erstellen. Dashboards sind eher statisch, während Design Sprints oft dazu verwendet werden, dynamische Produkte wie User Flows oder Prozesse zu entwerfen. Ein Dashboard hat keinen User Flow, sondern stellt einfach eine Momentaufnahme von Daten dar. Daher war es eine Herausforderung, bestimmte Werkzeuge und Methoden, die in Design Sprints verwendet werden, für die Erstellung von User Flows oder Prozessen auf unseren Anwendungsfall hin anzupassen. Wir haben den Design Sprint so eingesetzt, dass wir uns schon sehr früh auf den Nutzen konzentrieren konnten, den die Daten für den/die Benutzer:in haben sollten. Zudem haben wir schnell visuelle Werkzeuge eingesetzt, um das Endprodukt zu skizzieren.

Wie funktioniert ein Design Sprint?

Ein Design Sprint ist, wie der Name schon sagt, ein kurzer, schneller Prozess. Er dauert in der Regel nur wenige Tage und beschleunigt die Innovation durch einen komprimierten Ideenfindungsprozess. Anstatt monatelang zu warten, um ein Minimal Viable Product (MVP) zu entwickeln und zu testen, können Unternehmen Design Sprints durchführen, um innerhalb weniger Tage Feedback zu einem Prototyp zu erhalten.

Ursprünglich von Google Ventures entwickelt, haben sich Design Sprints inzwischen weit verbreitet. GV veröffentlichte 2016 ein Buch über ihre Design Sprints. Sie definieren einen Sprint als „einen fünftägigen Prozess zur Beantwortung kritischer Geschäftsfragen durch Design, Prototyping und Testen von Ideen mit Kund:innen“. Mit einem Design Sprint können Sie in die Zukunft blicken und sich vorstellen, wie Ihr fertiges Produkt aussehen könnte, einschließlich der Reaktionen der Kund:innen. Dies spart Zeit und Geld, da Sie die verschiedenen Optionen bewerten können und um zu sehen, welche die beste wäre, bevor konkrete Beschlüsse zur Produktentwicklung gefasst werden.

In einem Design Sprint skizziert das Team zunächst das zu lösende Problem. Im zweiten Schritt schlägt es Lösungen vor und wählt die beste Idee aus. Anschließend stellt das Team einen Prototyp her und testet die Idee, wobei es die Annahmen in Abstimmung mit den Zielkund:innen bewertet. Dieser Prozess wird in wenigen Tagen und nicht in mehreren Monaten abgeschlossen, was dem Team Zeit und Mühe erspart und zur Entwicklung eines besseren Produkts beiträgt. Ein großer Vorteil von Design Sprints ist, dass Produktideen vorab getestet werden können, was die Produktentwicklung beschleunigt.

Letztlich ist der Design Sprint Teil einer langfristigen Strategie innerhalb des Unternehmens. Die Festlegung von long-Term Goals innerhalb des Design Sprints trägt dazu bei, was der Sprint und das Unternehmen auf lange Sicht erreichen wollen. Wie The Familiar schreibt, ist ein long-Term Goal so etwas wie ein Northstar, „der das Design Sprint Team während des gesamten Sprints leitet“. Zu diesem Zweck sollten sich das Sprint Team Fragen stellen wie:

  • Was ist der Zweck dieses Projekts?
  • Wo wollen wir in der Zukunft stehen – ob kurzfristig (in sechs Monaten), mittelfristig (in ein oder zwei Jahren) oder langfristig (in fünf bis zehn Jahren)?

Der dreitägige Design Sprint von portagon

Unser Design Sprint war für drei Tage angesetzt. Das ist kürzer als der typische von GV entwickelte Design Sprint, der fünf Tage dauert – oder sogar der „Design Sprint 3.0“ der Design Sprint Academy, der das Ereignis auf vier Tage komprimiert. Über einen ähnlichen, verkürzten dreitägigen Sprint können Sie hier lesen. Wir haben uns für einen verkürzten Design Sprint entschieden, weil wir nicht zu viel Zeit und Ressourcen für fünf Tage blockieren wollten. Ein dreitägiger Sprint schien also perfekt.

Im Großen und Ganzen war Tag eins unseres Sprints dem Mapping und der Skizzierung des Design Sprints gewidmet – also dem Herausfinden des long-Term Goals, der Identifizierung des Problems und der Entwicklung von Lösungskonzepten. An Tag zwei ging es um die Entscheidung für eine bestimmte Lösung und ums Storyboarding (Darstellung der einzelnen Schritte des zu testenden Erlebnisses und Klärung der für den Prototyp benötigten Teile). An Tag drei wurden Prototypen erstellt und getestet. Bevor wir jedoch loslegen konnten, mussten wir uns auf den komprimierten dreitägigen Sprint vorbereiten, um ein bestmögliches Ergebnis zu erzielen.

Vorbereitungen für den Design Sprint

Vorbereitung ist das A und O bei Design Sprints. Dazu gehören Primär- und Sekundärforschung, die zeitliche Planung für den Sprint und so weiter. Es gibt keine festgeschriebene Vorgehensweise, und die Art und Weise, wie der Design Sprint abläuft, hängt vom Zweck des Sprints ab.

Bei der Vorbereitung auf unseren Design Sprint haben wir darauf geachtet, das richtige Team für die Teilnahme auszuwählen. Zu den Akteur:innen, die Teil des Design Sprint von portagon waren, gehörten:

  • Teamleiter Produktmanagement: Leon Stamm
  • Produktverantwortliche: Luc Zoe Pastor
  • Senior User Experience (UX) Experte: Marcel Kohnz
  • Senior Entwickler: Nanook Bergmann
  • Benutzertest-Kandidaten (Kund:innen, Mitarbeitende usw.)
    Interne Expert:innen für Interviews (Customer Success Manager, Datenanalyst)

Zur Vorbereitung auf den Design Sprint haben wir auch Lightning Demos durchgeführt. Bei einer Lightning Demo bereiten die Teilnehmer:innen eine Liste von Produkten oder Dienstleistungen mit alternativen Lösungswegen als Inspiration vor. Wir haben diese Methode genutzt, um Lösungen oder Ansätze aus anderen Branchen einzubeziehen. Sie soll dazu dienen, die Denkweise um abstraktere Erkenntnisse aus anderen Branchen, Unternehmen oder Märkten zu gewinnen, die unmittelbar nichts mit unserem eigenen FinTech-Softwaremarkt zu tun haben. Dieser Schritt ist mit der Entwicklung eines Moodboards vergleichbar. Auf diese Weise konnten sich unsere Stakeholder auf drei actiongeladene Tage vorbereiten, die aus Produktideen, der Auswahl von Ideen, Prototyping und Testen bestanden.

Schließlich kauften wir die für den Design Sprint benötigten Materialien und Geräte. Hier sind einige der Dinge, die wir bestellt oder vorbereitet haben:

  • Reservierung eines großen Raums für den dreitägigen Sprint
  • Büromaterial, wie Post-it-Zettel, Stifte, Karten usw.
  • Ein Timer
  • Essen und Snacks

Durchführung des Design Sprints

Tag eins: Problem skizzieren, mögliche Lösungen erörtern.

Am ersten Tag unseres Design Sprints machten wir unsere Teilnehmer:innen schnell mit den Grundlagen von Design Sprints vertraut – also worum es sich dabei handelt und warum wir den Sprint  durchführen. Außerdem führten wir eine „Ask the Expert“-Übung durch, wie sie in dem 2016 erschienenen Buch von Knapp, Zeratsky und Kowitz über ihre Sprints bei GV beschrieben wird. Bei der Übung „Ask the Expertz“ macht sich jedes Mitglied des Sprint Teams Gedanken zu möglichen Problemen, die im Designprozess für das Dashboard auftauchen könnten.

Als Nächstes machten wir eine “ How Might We „-Übung, bei der wir die möglichen Lösungen für die Probleme aufzeichneten. Alle Teilnehmer:innen wurden aufgefordert, sich Notizen darüber zu machen, wie wir im Sprint die Herausforderungen bewältigen könnten („How Might We“-Notes). Jede:r Teilnehmer:in schrieb seine Herausforderungen auf einen Klebezettel.

Anhand dieser Zettel stimmten wir gemeinsam über die wichtigsten Herausforderungen ab, auf die wir uns in diesem Sprint konzentrieren wollten. Um die Abstimmung durchzuführen, gaben wir dem/der Entscheider:in vier große Punktaufkleber, alle anderen bekamen nur zwei große Punktaufkleber, die sie auf die Haftnotizen mit den Herausforderungen, die sie angehen wollten, klebten. Die Abstimmung machte jeder für sich. Die Teilnehmer:innen konnten für ihren eigenen Zettel stimmen oder auch zweimal für denselben Zettel stimmen.

Danach haben wir die long-Term Goals und Fragen des Sprints besprochen. Einige der Fragen, die wir uns stellten, waren:

  • Welche brennende(n) Frage(n) müssen wir in diesem Sprint beantworten?
  • Wenn wir unser long-Term Goal erreichen wollen, muss dies
    unbedingt der Fall sein: _____________.
  • Wenn wir in eine Kristallkugel schauen und sehen, dass unser Produkt furchtbar gescheitert ist, können wir die Gründe dafür erkennen?
  • Woran werden wir merken, dass unser Produkt ein Erfolg war?
  • Wie wird das Management unser Produkt als Erfolg definieren?
  • Wie werden die Kund:innen das Produkt bewerten?

Außerdem haben wir User Maps erstellt. Die Erstellung von User Maps für unser Software-Dashboard war schwierig, da es keinen wirklichen Workflow oder Prozess für ein Dashboard gibt.

Wir nutzten verschiedene Design-Thinking-Techniken, um Ideen zu sammeln und konkrete Designlösungen zu entwickeln. Hier einige der Übungen, die wir an diesem Tag durchgeführt haben:

Notizen machen: Wir machten uns Notizen zu den spezifischen Lösungen, die wir in den verbleibenden zwei Tagen des Sprints prototypisch umsetzen und testen wollten.

Kritzeln und Skizzieren: Wir kritzelten und skizzierten einige Ideen zur Lösung visuell.

Crazy 8s: Wir nahmen ein Stück Papier und falteten es dreimal, sodass acht Rechtecke oder Zellen entstanden. Die Teilnehmenden hatten eine Minute Zeit, um einen Teil der Lösung pro Zelle zu skizzieren.

Skizzieren eines Lösungskonzepts: Wir baten die Teilnehmer:innen, ein Lösungskonzept zu skizzieren, als eine Art Pitch Deck, um ihre Idee den anderen zu präsentieren. Am nächsten Tag stellten die Teilnehmer:innen ihr Konzept dem Rest der Gruppe vor, und die Gruppe entschied sich für eine Lösung.

Tag zwei: Entscheidung für eine Lösung und ein Storyboard.

Nach dem ersten erfolgreichen Tag, an dem wir Lösungen entwickelt haben, verbrachten wir Tag zwei damit, uns für eine Lösung zu entscheiden. Einige der Wege dahin waren:

  • Storyboarding von Lösungen. Ein Storyboard ist eine Erzählung, die die Erfahrungen eines/einer Benutzer:in mit einem Produkt beschreibt. Mithilfe des Storyboards konnten wir feststellen, ob die Lösung wirklich zur Lösung der Probleme des/der Nutzer:in beiträgt.
  • Untersuchung des User Test Flow. User Test Flow, User Flow oder UX Flow ist eine visuelle Darstellung des Weges, den ein/eine Benutzer:in nehmen könnte, um ein Ziel zu erreichen, wenn er/sie mit dem Produkt interagiert. Der Benutzerfluss reicht vom Einstiegspunkt in die Arbeit mit einem Produkt bis hin zu den letzten Schritten. Dies war eine Herausforderung für uns, da ein Dashboard einen minimalen UX-Flow hat. Was die Besonderheiten des Benutzerflusses betrifft, so haben wir verschiedene Einstiegspunkte diskutiert – wie die Benutzer auf die neuen Dashboards aufmerksam werden würden. Wir sprachen auch darüber, welche Calls-to-Action oder CTAs für die Nutzenden wertvoll sein könnten, sobald sie das Dashboard sehen. Ein Beispiel hierfür ist die automatische Anzeige von Empfehlungen mit Tipps und Tricks zur Verbesserung der Investitionskampagne.
  • Erstellung einer Impact-Effort Matrix. Die Impact-Effort Matrix ist ein Diagramm, das auf der x-Achse zeigt, welche Aufgaben dringend und welche nicht dringend sind, und auf der y-Achse, welche Aufgaben wichtig und welche unwichtig sind. Wir haben die Impact-Effort Matrix verwendet um festzustellen, welche Lösungen mit dem geringsten Aufwand die größte Wirkung erzielen würden.

Wir stellten die Ideen in Form einer Art Vernissage auf, sodass die Teilnehmer:innen die verschiedenen Optionen durchsehen und Fragen stellen oder ihre Unterstützung notieren konnten. Wir stimmten über die Lösungen per Straw Poll Voting und später per Heatmap-Abstimmung ab. Anders als bei der Abstimmung an Tag eins, bei der allgemeine Ideen im Vordergrund standen, ging es bei der Abstimmung an Tag zwei um die Elemente des Dashboards, die einer von uns gezeichnet hatte. Wobei der Schwerpunkt auf den visuellen Aspekten des Dashboards lag und nicht auf dem schriftlichen Inhalt. Am Ende von Tag zwei hatten wir uns für eine Lösung entschieden, die wir am nächsten Tag als Prototyp vorstellten.

Tag drei: Prototyp und Test unserer Lösung.

An Tag drei erstellten wir einen Prototyp und testeten die Lösung, auf die am Vortag die Entscheidung gefallen war. Wir bereiteten den Inhalt und den Text für den Prototyp vor und erstellten Interviewfragen und Richtlinien für unsere Nutzer:innen, die das Produkt testen sollten.

Wir haben den klickbaren Prototyp mit einem Softwaretool namens Figma erstellt. Als unser Prototyp fertig war, baten wir um Feedback von potenziellen Nutzer:innen. Wir führten Interviews mit einigen Kund:innen von portagon.

Lehren aus dem Design Sprint von portagon

Wir haben gelernt, dass ein Design Sprint eine tolle Möglichkeit ist, um neue, innovative Ideen zu sammeln und fast sofortiges Feedback von den Kund:innen zu erhalten. Wir haben festgestellt, dass der Design Sprint uns später viel Zeit erspart hat, aber er erfordert anfangs auch eine erhebliche Investition von Ressourcen. Beim nächsten Mal werden wir uns vielleicht für eine Umgebung außerhalb des Büros entscheiden, um Störungen zu vermeiden und uns während des gesamten Design Sprints fokussieren zu können. Am dritten Tag der Kund:innen- Interviews empfehlen wir, genaue Fragen vorzubereiten und vielleicht sogar ein paar Testinterviews durchzuführen, um Suggestivfragen zu vermeiden und die Gruppe auf die richtige Art und Weise Fragen zu stellen vorzubereiten.

Unser Fazit ist, dass Design Sprints vor allem für Prozesse oder umfangreichere User Flows geeignet sind. Ein Software-Dashboard ist jedoch eher etwas zu statisch für den Design Sprint.

Alles in allem freuen wir uns, dass wir unseren Design Sprint als Erfolg verzeichnen können und sind darauf gespannt, die gewonnenen Erkenntnisse bei der Entwicklung unseres Software-Dashboards einzubringen.

Wie hat Ihnen dieser Beitrag gefallen?

Durchschnittliche Bewertung 4.5 / 5. Anzahl der Bewertungen 11

Es tut uns leid, dass dieser Beitrag für Sie nicht nützlich war!

Verbessern Sie diesen Beitrag!

Was hat Ihnen nicht gefallen? Was können wir verbessern?