Mehr Klarheit in der Anforderungsanalyse – mit User-Story-Mapping zur bestmöglichen Experience für Nutzer:innen

Ein neues Produkt oder ein innovatives Feature gemeinsam mit unseren Kunden zu entwickeln, ist ein spannender Prozess. Der Auftakt ist meist leicht: Da geht es um die Vision und erste Lösungsideen. Konkret wird es, wenn es daran geht, die Anforderungen zu analysieren und ein Product Backlog für die agile Umsetzung aufzubauen.

Seit einiger Zeit setzen wir im Prozess der Anforderungsanalyse erfolgreich eine Visualisierungsmethode ein, mit der sich der Fokus gezielt auf die späteren Nutzer:innen setzen lässt: das User-Story-Mapping, welches das Big Picture all der gewünschten Anforderungen übersichtlich macht und damit die Planung, Pflege und Priorisierung von Aufgaben im Projekt erleichtert.

Gerne möchten wir diese Technik etwas näher vorstellen: Was ist das überhaupt und funktioniert‘s? Wie entsteht eine solche Map, wie lässt sie sich einsetzen und welche Mehrwerte erwachsen daraus

Mit User Story Maps gegen den Tunnelblick

Zum Hintergrund: In der agilen Softwareentwicklung wird ein Projekt in kleine Stücke aufgeteilt – die User Stories. Das sind kurze Beschreibungen eines Features aus der Perspektive von Nutzer:innen. Sie sollen es erleichtern, anfallende Aufgaben innerhalb eines Sprints übersichtlicher zu managen und den jeweiligen Projektfortschritt im Blick zu behalten.

Diese einzelnen Anforderungen werden stets einheitlich aufgebaut:

Als _________<Nutzer:in>
möchte ich _________<Funktionalität>,
um __________<Nutzen> zu erreichen.

Allerdings bieten solche User Stories mitunter einigen Spielraum für Interpretationen. Denn an einem Projekt sind ja meist ganz viele unterschiedliche Rollen beteiligt, also neben verschiedenen Fachbereichen auch Product Owner, Developer, UX/UI-Designer und Berater:innen. Jede Rolle bringt eine eigene Perspektive mit sich, so dass ein und dieselbe User Story unterschiedlich interpretiert werden kann.

“The idea is that if I have an idea in my head and I describe it in writing, when you read that document, you might quite possibly imagine something different. We could even ask everyone, “Do you all agree with what’s written there?” and we might all say “Yes! Yes, we do.” – Jeff Patton, User Story Mapping, O’Reilly 2015

Zudem besteht das Risiko, dass das Team durch die vielen kleinen User Stories das Gesamtbild, das „Big Picture“ des zu entwickelnden Produktes, aus dem Blick verliert. Denn der starke Fokus auf einzelne User Stories befördert hier und da einen Tunnelblick.

User-Story-Maps fördern das gemeinsame Verständnis

Das von Jeff Patton entwickelte User Story Mapping löst dieses Problem mit einer Art Landkarte: Auf dieser werden die User Stories horizontal den Etappen einer Nutzergeschichte zugeordnet und somit in eine zeitliche Reihenfolge gebracht. Diese Visualisierung der zukünftigen User Journey fördert das gemeinsame Verständnis des Gesamtprozesses.

Von Personas über Aktivitäten zu User Stories: Wie eine User Story Map entsteht

Am effektivsten entsteht eine User Story Map im Rahmen von Workshops, in denen möglichst alle Stakeholder und Teammitglieder involviert werden. Das gemeinsame Erarbeiten schafft nicht nur Transparenz, sondern auch ein gemeinsames Verständnis von der Produktvision und den Release-Zielen.

Beste Voraussetzungen schafft man, wenn zu Beginn des Workshops die Produktvision und das Wissen über die potenziellen Nutzer:innen des Produkts geteilt werden, beispielsweise in Form von Personas.

Die User Story Map lässt sich dann klassisch am Whiteboard mit Stiften und Post-its oder in kollaborativen Online-Tools wie Miro erstellen – jedoch nicht, um sie danach in der Schublade verschwinden zu lassen. Ganz im Gegenteil: Die User Story Map begleitet den gesamten Projektverlauf und ist innerhalb dessen niemals abgeschlossen. Wenn sich beispielsweise neue technische Möglichkeiten ergeben oder nach und nach Feedback aus Nutzertests dazukommt, fließt dies im Laufe des Projekts ein. Zudem bietet ein Blick auf die Map zwischendrin immer wieder eine Übersicht über den Projektfortschritt.

Sequenziell und zielgerichtet: Der Aufbau einer User Story Map

Eine User Story Map hat eine horizontale und eine vertikale Ebene und besteht aus den folgenden Elementen:

• Nutzer:innen (grün): Nutzer:innen, die mit der Anwendung interagieren
• Aktivitäten (orange): Beschreibung der wichtigsten Aktivitäten der Nutzer:innen
• Backbone (rot): Beschreibung der einzelnen Schritte der Nutzer:innen in chronologischer Reihenfolge
• User Stories (gelb): Der so genannte Body der Map enthält die Stories, die nötig sind, um das erwünschte Ziel der jeweiligen Aktivität zu erreichen – typischerweise priorisiert und verschiedenen Releases zugeordnet

Der Aufbau einer User-Story-Map

Horizontale Ebene: Etappen der User Journey festlegen

Den Startpunkt bildet der Backbone, also das Rückgrat der User Story Map. Dabei handelt es sich um die Abbildung der Hauptaktivitäten eines Nutzers oder einer Nutzerin. Das können Aufgaben, Stationen oder Etappen sein, die ein Nutzer oder eine Nutzerin eines Produkts erledigt oder hinter sich bringt.

Nehmen wir ein einfaches Beispiel: Persona X möchte sich per App Essen bestellen und liefern lassen. Die Hauptaktivitäten sind dann die folgenden:

• Essen auswählen
• Essen bestellen
• Essen liefern lassen
• Bewertung abgeben

Häufig lassen sich die Aktivitäten in einzelne Schritte unterteilen. So lässt sich die Aktivität “Essen auswählen” beispielsweise unterteilen in die Schritte:

• Restaurant wählen
• Produkte wählen
• Auswahl anpassen

In der User Story Map werden diese Aktivitäten und Schritte horizontal chronologisch angeordnet – also entsprechend der Reihenfolge, in der ein Nutzer oder eine Nutzerin mit dem Produkt interagiert. Somit wird die Struktur eines Rückgrats sichtbar, dessen Wirbelsäule durch die Schritte (rot) und dessen Rippen durch die Aktivitäten (orange) abgebildet werden.

 Das Backbone einer User-Story-Map

Vertikale Ebene: Etappen der User Journey konkretisieren

Unter jeder Aktivität des Backbones werden nun die einzelnen User-Stories erstellt, die die Reise der Nutzer:innen konkretisieren. Beispielsweise könnten wir unter dem Schritt “Restaurant wählen” Stories für die folgenden Aktionen festhalten:

• Freie Textsuche
• Stöbern nach Kategorie
• Stöbern nach “Am besten bewertet”
• Stöbern nach “Am beliebtesten”
• Auswählen in Karte
• Auswählen aus Historie
• Voraussichtliche Lieferzeit sehen
  
  

Nach der Sammlung möglichst vieler User Stories werden diese gewichtet und entsprechend ihrer Priorität vertikal unter der jeweiligen Aktivität angeordnet. Sobald der Backbone und sämtliche Stories angeordnet sind, erschließt sich das Gesamtbild des Produktes.

Stories erscheinen unter den jeweiligen Aktivitäten

Releases slicen: in fest definierten Schritten zum Produkt

Um die einzelnen Schritte der Umsetzung zu definieren, werden nun die User Stories in mögliche Product Releases aufgeteilt. Dafür wird horizontal gekennzeichnet, was zu welchem Release gehört.

Im Release der ersten Produktversion – auch MVP (Minimum Viable Product) genannt – muss darauf geachtet werden, dass jeder Schritt so viel Funktionalität bietet, dass sich das Ziel auch wirklich erreichen lässt. Dagegen können User Stories, die nicht zwingend von Anfang an vorhanden sein müssen, in spätere Releases verschoben werden. Auf diese Weise wird die Grundlage für ein inkrementelles Vorgehen geschaffen und ein Go-live-Termin nicht unnötig in die Zukunft verschoben.

Bereits die erste Produktversion schafft einen tatsächlichen Wert und ermöglicht beispielsweise eine Vertestung mit Nutzer:innen. In den folgenden Releases werden die einzelnen Aktivitäten mit weiterer Funktionalität angereichert. In unserem Beispiel liegen die Schwerpunkte von Release 1 auf der Suche sowie neuen Liefer- und Bezahlarten. Release 2 ermöglicht die Individualisierung von Produkten und eine bessere Verfolgbarkeit der Lieferung.

Die User Story Map zeigt nach dem Release Slicing, was wann ausgeliefert wird

Diskussionen? Sind vorprogrammiert!

Möglicherweise löst in einem echten Projekt die Tatsache, dass Coupons nicht im MVP umgesetzt werden, eine Diskussion aus. Der Bereich Marketing legt ein Veto ein: “Das geht doch nicht. Der neue Online-Shop soll doch direkt zum Go-live mit Gutscheincodes beworben werden!”. Dieses Detail war bisher nicht bekannt, so dass die Auswirkungen nun im Team diskutiert werden. Und genau das soll User Story Mapping bewirken – das Entdecken bislang noch unerkannter Anforderungen und eine Diskussion aller Beteiligten darüber, wie man den Nutzer:innen eine bestmögliche Experience bieten kann.

Unser Fazit

Mit User Story Mapping lässt sich in der Regel ziemlich effektiv ein initiales Backlog für die Entwicklung eines neuen Produktes oder eines innovativen Features aufbauen. Denn die User Story Map illustriert den Zusammenhang der verschiedenen Anforderungen und ermöglicht so allen Beteiligten schnell ein gemeinsames Verständnis der Anforderungen und einen Gesamtüberblick über das zu entwickelnde System. Indem das Team gemeinsam die Nutzerperspektive einnimmt und die Geschichte durchläuft, werden frühzeitig potenzielle Lücken und Hindernisse offenbar, die unter Umständen kostspielig werden könnten, wenn man sie erst in der Umsetzungsphase entdeckt.

Über den Autor:

Moritz Köditz ist UX Architect bei der Digitalagentur Basilicom. Als Medien- und Kognitionswissenschaftler vereint Moritz interdisziplinäres Wissen aus Psychologie, Informatik und Wirtschaftswissenschaften. In seinem Arbeitsalltag prägt er digitale Nutzererlebnisse und bringt auf dem Weg dahin Anforderungen von Stakeholdern, Bedürfnisse von Nutzer:innen und die technische Umsetzung in Einklang miteinander. Dabei kommen unterschiedlichste Methoden zum Einsatz, in die er gerne einen Einblick gibt.

Credits:

Photo by Jeremy Bishop on Unsplash
Illustration by Jeff Patton / Luke Barret – CC BY-NC-SA