Der einfache "User Story Mapping" Guide – von 0 auf 100 zum ersten Workshop

Irgendwann nach etlichen Planänderungen und einigen verbrannten Ressourcen später ist es endlich soweit... Wir können unser Mam­mut­pro­jekt releasen! Anfangs ist die Freude noch groß, doch schnell stellt sich die Ernüchterung ein. Mithilfe des Story Mapping Workshops wollen wir genau diesem Effekt vorbeugen und die Nutzer in den Vordergrund stellen.

Als ich Anfang 2017 bei der vetevo GmbH als UX Consulting 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 werden. Hierzu kannst du entweder auf die bestehenden Personas deines Unternehmens aufbauen, oder neue generieren. Für letzteres hast du zwei Möglichkeiten.

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

Letzteres hat den großen Vorteil das ihr die Personas gemeinsam erarbeitet und jeder im Team sich 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, das 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 auch wirklich dabei sind. Hier ein paar Inspirationen für mögliche Teilnehmergruppen, aus denen zumindest einer 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 (C-Level)

    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 4 Stunden aus dem Workshop. Für das Warmup kann ich dir z.B. einen "Doodle Jam" zum Auflockern 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. – Post-It Time! – versucht alle nötigen Aufgaben/Task die der Nutzer bewältigen soll aufzulisten. Nehmt euch hierfür am besten die einzelnen User Storys vor. Stellt euch vor was "David" wohl machen würde, um seine Aufgabe zu erfüllen. 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 noch vor Ort den Termin einzustellen – 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 Storymap. Hierzu gruppieren wir alle vorhandenen Zettel mit dem Team und versuchen im Anschluss für alle Gruppen eine Überschrift zu finden.

Von links nach rechts

Denkt dabei am besten an eure User Story und guckt dabei 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 das zwei Aufgaben gleichzeitig bewältigt werden wollen, um den simultanen Ablauf deutlich zu machen könnt ihr die Tasks unter einander 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 erstes Nutzerfeedback einzuholen? Behalte immer im Hinterkopf das es vorrangig darum geht ein MVP auf die Beine zu stellen, um den Nutzern einen ersten Eindruck eurer Vision zu geben und erstes Feedback zu sammeln.

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?" Glaubt 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 euch das Buch The Lean Startup empfehlen. Das Buch vermittelt bereits einen ersten soliden Eindruck in die Thematik.

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 immer wieder 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.