Der schnelle User Story Mapping Workshop Guide

Nach etlichen Planänderungen und einigen verbrannten Ressourcen ist es endlich soweit – wir können unser Mam­mut­pro­jekt releasen. Anfangs ist die Freude groß, doch schnell stellt sich ein Gefühl der Ernüchterung ein. Mithilfe des Story Mapping Workshops wollen wir genau diesem Effekt vorbeugen, indem wir unsere Nutzer in den Mittelpunkt stellen.

Als ich Anfang 2017 bei der vetevo GmbH als UX-Consultant angefangen habe befand sich das Unternehmen gerade im Umschwung, mit einer genialen Idee in der Hinterhand. Die ersten Ansätze zu Realisierung waren bereits zu erkennen. Leider ging es ihnen wie vielen Jungen Startups, sie hatten zu viele Ideen und zu wenig Ressourcen, so dass sie zwar schon einiges vorweisen konnten, aber eben noch nichts Funktionelles. Der Weg bis zum Ziel schien nahezu endlos. Das Team war vielleicht klein, aber ihr Ehrgeiz und ihr Glaube haben sie wahrlich großartiges schaffen lassen.

Damit das Projekt wieder in die Spur kommt, entschieden wir uns zu einem User Story-Mapping Workshop – Was das genau ist, will ich dir anhand eines Beispielprojektes verdeutlichen:

Kein Story Mapping ohne User Story, keine User Story ohne Persona

Das Fundament

Bevor wir uns ungeduldig an das schreiben unserer User Storys machen können, benötigen wir unsere Personas – auf dessen Basis wir den "Story Mapping Workshop" aufsetzen. Hierzu kannst du entweder auf die bestehenden Personas deines Unternehmens aufbauen, oder neue generieren. Für letzteres hast du zwei Möglichkeiten.

  • Erstelle unter Einbezug einiger Stakeholder ein Paar schnelle "Lean Personas"
  • Setze für dein Team einen Lean Persona Workshop auf

Letzteres hat den großen Vorteil, dass ihr die Personas gemeinsam erarbeitet und sich somit jeder mit ihnen identifizieren kann. Auf einen Persona Workshop werde ich hier nicht im Detail eingehen, da ich mich innerhalb des Artikels vor allem auf das sogenannte User Story Mapping fokussieren will.

Am Ende des Tages wollen wir das MVP/MVE eures Projektes herausarbeiten, so dass ihr ein gemeinsames Gefühl für die kommenden Herausforderungen bekommt – erfahrungsmäßig ist dies der Moment in dem euch das erste Mal, dass wahre Ausmaß des Projektes klar wird. Aber keine Panik, von hier aus geht es auch schnell wieder bergauf, lasst euch nicht entmutigen!

Das Team bestimmt die Qualität des Workshops, umso diversifizierter das Team, umso besser das Resultat
David Schulz, uxactly

Die User-Story

Bevor es losgeht solltest du bereits eine Haupt User Story definiert haben. Guck, dass du für deinen Workshop alle relevanten Stakeholder – Designer, Entwickler, Projektmanager usw. – mit an Bord holst.

Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.

Jeff Patton

Mögliche Akteure für deinen Workshop

Bevor du dich in den Workshop stürzt ist die Klärung der relevanten Parteien unabdingbar. Der beste Workshop der Welt bringt dir nichts, wenn du nicht die richtigen Leute einlädst. Deswegen mach dir vorher Gedanken wer an deinem Workshop teilnehmen sollte und plane idealerweise im Voraus.

1-2 Wochen sind schon mal ein guter Anfang, um sicherzugehen, dass alle relevanten Parteien dabei sind. Hier ein paar Inspirationen für mögliche Teilnehmergruppen, aus denen zumindest eine Person teilnehmen sollte.

  • Entwickler/in

    Stets interessiert und skeptisch, keiner kennt die technischen Möglichkeiten besser. Seine Insights in die Machbarkeit und seine bedingungslose Kooperation sind kriegsentscheidend für das Projekt.

  • Marketer/in

    Wer könnte besser wissen was dem Kundengefällt? Er/Sie beschäftigt sich den ganzen Tag mit der Vermarktung des Produktes und weiß was dem Kunden gefällt.

  • Customer Service

    Keiner kennt die Leiden deiner Kunden besser als das Customer Service Team, versuche sie von daher auf jeden Fall mit an Bord zu holen. Denke aber daran, dass der Nutzer oftmals mit der Auswirkung und nicht mit der Ursache an ihn herantritt.

  • Geschäftsführung

    Ohne C-Level Support fehlt dir der nötige Rückhalt. Auch ein Stellvertreter kann hier bereits wahre Wunder bewirken. Am Ende des Tages bringen die tollsten Ideen und Workshops nicht wenn der Rückhalt fehlt.

  • Designer/in

    Der kreative Kopf hinter deinem Produkt. Er/Sie bestimmt maßgeblich wie der Kunde dein Produkt nutzt und wahrnimmt. Versuche auf jeden Fall einen der Designer im Unternehmen dabei zu haben, egal ob UX, UI, IxD, Consumer Designer oder Service Designer. Zum einen sind sie es die mit an dem Kern arbeiten werden und zum anderen sind ihre Insides unbezahlbar.

  • Product Owner

    Sein höchstes Ziel ist der Erfolg des Produktes. Er plant mit euch den Backlog, hält euch den Rücken frei und hält das Projekt in der Spur. Von daher ist es eine sehr gute Entscheidung ihn mit an Bord zu holen.

Der Workshop ist das Sah­ne­stück

Die Warmup-Phase und die Endphase dürfen dabei allerdings nicht außer Acht gelassen werden. Plane viel Zeit mit ein. Im Schnitt kommst du nicht unter 6 Stunden aus dem Workshop.

Für das Warmup kann ich dir z.B. einen "Doodle Jam" empfehlen. Schau dir dazu das Projekt aus einer holistischen Sicht an und überlege dir welches Warmup für die Aktuelle Projekt und Teamsituation am effizientesten wäre. Oftmals ist es gut erst einmal spielerisch für Empathie zu sorgen - Immerhin wollen wir doch alle das Beste für das Projekt und unsere Nutzer.

Bevor wir mit dem Workshop anfangen können ist es wichtig die User Story(s) zu definieren. Dies kannst du entweder vorweg machen, um dich mit deinem Team am Workshop Tag auf das eigentliche Mapping zu konzentrieren, oder gemeinsam mit ihnen als Teil des Warmups. – Behalte dabei stets deine Zielgruppe im Auge und vergiss nicht wer die Dienstleistung, das Tool, die Idee oder das Produkt am Ende des Tages nutzen wird. Eine typische User Story könnte wie folgt aussehen:

Nach dem Warmup

Damit wirklich alle Teilnehmer auf dem gleichen Stand sind. Hat es sich in meinen letzten Workshops bewährt, nach dem Warmup die Personas durchzugehen und deren User Storys laut vor zu lesen.

Post-It Time!

Den Anfang machen wir mit einer kleinen Denkübung. Versucht alle nötigen Aufgaben/Task die der Nutzer bewältigen soll aufzulisten. Nehmt euch hierfür am besten die einzelnen User Storys vor. Dies könnte dann wie folgt aussehen: "David will nach einem erfolgreichen Gespräch mit seinem Arbeitskollegen, ein Meeting planen und geht dazu an sein Smartphone, um den Termin einzutragen". Was benötigt er dazu? Bei einer Kalender-App könnte dies wie folgt aussehen:

Erstellung des Backbones

Nach dem du und dein Team alle nötigen Tasks aufgeschrieben habt, erstellen wir das Rückgrat (auch Backbone genannt) der Story Map. Hierzu gruppieren wir alle vorhandenen Zettel mit dem Team und versuchen im Anschluss für alle Gruppen eine Überschrift zu finden.

Denkt dabei am besten an eure User Story und guckt was für den Nutzer / David am wichtigsten sein könnte.

Kann der Nutzer vor dem Erstellen des Termins eine Auflistung der Termine benötigen? – Wohl eher nicht. 😉 In seltenen Fällen kann es auch schonmal sein, dass zwei Aufgaben gleichzeitig bewältigt werden wollen, um den simultanen Ablauf deutlich zu machen könnt ihr die Tasks untereinander kleben.

In die Tiefe

Nach dem wir das sogenannte Backbone aufgebaut haben, geht es darum weiter in die Tiefe zu gehen in dem wir uns nun überlegen was genau wir für die jeweilige Funktion benötigen. Am besten geht ihr gemeinsam die einzelnen Tasks mittels User Story ab und versucht auf dessen Basis die benötigten Bausteine zu Identifizieren.

Zur Release-Planung

In diesem Schritt geht es darum die Tasks in Holistische-Releases zu teilen. Im Klartext bedeutet das, dass wir uns überlegen welche Features den größten Mehrwert für den Nutzer stiften.

  • Welches sind die essentiellen Features eures Projektes?
  • Mit welchen Features könnt ihr einen ersten Release bauen um Nutzerfeedback einzuholen?

Um den Nutzern einen ersten Eindruck eurer Vision zu geben und erstes Feedback zu sammeln, solltest du immer im Hinterkopf behalten, dass es vorrangig darum geht einen MVP auf die Beine zu stellen.

Schlusssatz

Wahrscheinlich wirst du dir nun denken: "Ja, aber mein Produkt kann ich nicht in einem MVP runterbrechen, warum sollten die Nutzer es dann nutzen?"

Glaube mir, ihr spart euch unheimlich viel Zeit und Nerven, wenn ihr euch auf einen soliden MVP einigen könnt und diesen frühzeitig auf den Marktschmeißt.

Für mehr Informationen zu dem Thema kann ich dir das Buch The Lean Startup empfehlen. Das Buch vermittelt bereits einen soliden Eindruck in die Thematik.

Denke daran, dass es sich um ein digitales Produkt handelt und ihr immer iterieren könnt.

Am Ende des Tages könnte deine User Story Map ungefähr so aussehen. Du und dein Team sollten nun ein besseres Gefühl für das bekommen was noch vor euch liegt. Erfahrungsgemäß ist die Map für das ganze Team hilfreich, um sich auf die wesentlichen Sachen zu fokussieren.

Zum krönenden Abschluss hast du oder der SCRUM Master nun die ehrenhafte Aufgabe die daraus resultierenden Tickets in ein Ticketsystem eurer Wahl zu gießen (Jira, Trello, Microsoft Planner usw.).

Ähnliche Artikel

Bis jetzt hat noch keiner kommentiert. Sei der/die erste!

Hinterlasse einen Kommentar

Ich freue mich immer über Feedback. Ein fairer Umgang miteinander ist wichtig, deshalb bleiben wir bei Diskussionen bitte konstruktiv, fair und sachlich.

Sign up for blog and
project updates

Leave your E-Mail here or follow me on Instagram, Facebook or Twitter.