Was erwartet dich in diesem Beitrag?
Dieser Beitrag soll dir einen kleinen Einblick geben, warum wir bei Liechtenecker die Methode des User Story Mappings als Fixbestandteil in unserer Konzeptionsphase vorsehen. Sie ist ideal geeignet, um das Big Picture aller Anforderungen zu erfassen und damit eine ganzheitliche Geschichte für User:innen zu verfassen.
Natürlich erwartet dich zu Beginn erstmal ein bisschen Theorie 😉. In einem Folgebeitrag gibt es dann noch weitere hilfreiche Praxistipps, die dir die Arbeit mit User Story Mapping erleichtern.
Was ist User Story Mapping?
Bevor wir auf die Methode selbst eingehen, sollten wir uns kurz mit dem Wort an sich beschäftigen. User Story Mapping enthält die “User Story” und das “Mapping” – es ist also quasi eine Landkarte aus User-Geschichten.
User Stories sind sicherlich jedem ein Begriff, der öfter mit der Kreation oder Entwicklung digitaler Produkte oder im Weitesten mit dem Thema agiler Entwicklung zu tun hat. Doch wir werden jetzt gemeinsam den Buzz-Word Status verlassen und etwas tiefer eintauchen.
Bei User Stories handelt es sich um Satzbausteine, die aus der agilen Softwareentwicklung stammen und folgendermaßen aussehen:
Vereinfacht gesagt handelt es sich dabei um eine Software-Anforderung, die,
- die Zielgruppe enthält,
- die Funktionalität der Software-Anforderung beschreibt
- und den Nutzen der Software-Anforderung für die Zielgruppe hervorhebt.
Wichtig ist dabei zu verstehen, dass ein- und dieselbe Funktionalität für die eine Zielgruppe einen völlig anderen Nutzen erfüllen kann, als für eine andere. Dies wiederum müssen Designer:innen und Entwickler:inne bei der Definition dieser Software-Anforderung berücksichtigen, um nicht an den Bedürfnissen der Zielgruppe vorbeizudesignen / -entwickeln.
So kann es jedoch auch sein, dass unzählige User Stories benötigt werden, um ein Feature zu beschreiben. Das führt schnell zu unübersichtlichen Situationen, die meist eine isolierte Entwicklungsarbeit zur Folge haben. Was meine ich mit isolierter Entwicklungsarbeit? Man verliert den Blick für das Big Picture. Es wird eine Story nach der anderen umgesetzt und am Ende entsteht statt eines user-orientierten Features ein Frankenstein-Monster aus zusammengestückelten Anforderungen.
Damit genau das nicht passiert, benötigt es die bereits angesprochene Landkarte dieser User Stories: das User Story Mapping.
Diese Landkarte zeigt den narrativen Flow des digitalen Produktes/Services. Dieser Flow ist deswegen wichtig, weil man sich immer in einer gewissen zeitlich-logischen Abfolge durch ein Produkt oder einen Service bewegt. So wird man beispielsweise immer ein Produkt zuerst in den Warenkorb legen, bevor man es bezahlt oder man wird sich registrieren, bevor man sich einloggt.
Also kurz zusammengefasst:
Im Zuge der agilen Entwicklung wurde das Schreiben von User Stories eingeführt. Damit diese jedoch nicht einfach unzusammenhängend zu einem Frankenstein-Feature-Monster zusammengebaut werden, wurde das User Story Mapping entwickelt.
Jetzt haben wir mal den groben Entstehungsprozess der Methode verstanden. Weil du aber auch den konkreten Mehrwert von User Story Mapping verstehen solltest, werde ich jetzt noch etwas genauer.
Warum ist User Story Mapping wichtig?
Was hat nun die Entstehung von User Story Mapping mit der unterschiedlichen Arbeitsweise von Design und Entwicklung zu tun? Und warum musste sich jemand eine eigene Methode überlegen, nur um das Entstehen von unzusammenhängender Entwicklung zu verhindern? Sollte es nicht “eh klar” sein, dass man immer den Überblick über das Big Picture behalten muss?
Leider ist es “eher unklar” als “eh klar”, da die Praxis bewies und beweist, dass agiles Arbeiten immer wieder zur Entwicklung solcher Frankenstein-Projekte führt.
Das Problem dabei ist, dass die agile Herangehensweise eher dem Wesen der Entwicklung entspricht als dem des UX Designs. Wenn man eine große Geschichte in ganz viele kleine Teile splittet, dann bringt das sehr viel mehr Klarheit, was die Umsetzung einer einzelnen User Story, eines einzelnen Features oder eines einzelnen Sprints anbelangt – was gut ist, für die Entwicklung.
Die Gefahr dabei ist jedoch, dass bei dieser Aufteilung der rote Faden durch das Produkt (also der narrative Flow) verloren geht – was der Albtraum für jede/n UX Designer:in ist. Besonders kritisch ist es, wenn versucht wird, auch die User Experience auf der kleinteiligen Ebene der User Stories zu definieren, ohne dass man dabei immer wieder einen Blick auf das große Ganze wirft.
Exkurs agiles Arbeiten:
Im Arbeitsalltag bedeutet agiles Arbeiten, dass ein Projekt in kurze Intervalle unterteilt wird. In regelmäßigen Abständen werden Ergebnisse begutachtet, Anforderungen ergänzt oder neu priorisiert. Hierbei wird der Fokus auf die User gelegt.
Die positive Entwicklung dabei:
- Das Gesamtkonzept (große Menge an Anforderungen) wird in kleinere Stücke aufgeteilt.
- Die Anforderungen werden aus Sicht der User:innen beschrieben
Die negative Entwicklung dabei:
- Man verliert sich in Details und hat keinen Überblick über das große Ganze
- Es entsteht ein „Feature-Haufen“ ohne Struktur (z.B. tolle Suche, aber schlechte Userführung dorthin)
Und genau hier schafft es die Methode des User Story Mapping, eine zusätzliche Qualität in das Projekt hineinzubringen, die viele Verständigungsprobleme zwischen Design und Entwicklung auflösen kann.
Jeff Patton arbeitete in der agilen Software-Entwicklung und bekam so diese Verständnisprobleme zwischen den einzelnen Disziplinen und die damit verbundene Frustration hautnah mit. Daraufhin entwickelte er zwischen 2005 und 2014 die Methode “User Story Mapping”.
User Story Mapping ist vor allem durch das Element der Erzählung geprägt. Es geht darum den Austausch der Teilnehmer:innen über die Anforderungen anzuregen. Eine Kombination aus gesprochenem Wort und Notizen auf Post-its lässt eine gemeinsame Sprache zwischen Entwickler:innen und Designer:innen entstehen. Auch wenn es sich sehr banal anhört, aber genau hier passiert die Magie.
Es ist ein bisschen ironisch, wenn man bedenkt, dass wir es gewohnt sind, Dinge aufzuschreiben, damit sie eindeutiger kommuniziert werden und das Risiko von Missverständnissen relativ gering ist. Trotzdem ist oft genau das Gegenteil der Fall, da jeder von uns das Geschriebene anders interpretiert. Geteilte Dokumente sind nicht das Gleiche wie geteiltes Verstehen.
Niedergeschriebene User Stories und Definitionen können niemals gesprochene Erklärungen und gemeinsame Diskussionen ersetzen.
Wie funktioniert User Story Mapping?
Im Grunde genommen ist User Story Mapping relativ einfach und setzt sich aus folgenden Schritten zusammen:
- Die relevantesten Personen für die Entwicklung eines Produktes (meist das Produkt Team) kommen zusammen.
- Sie erzählen die Geschichte (Story) eines Produktes und schreiben jeden wichtigen Schritt, den User:innen im Zuge dieser Geschichte absolvieren, auf Post-its.
- Diese Schritte werden von links nach rechts entlang eines narrativen Flows angeordnet.
- Dann schaut man sich jeden einzelnen Schritt noch einmal genauer an, spricht über die Details dazu, notiert diese auf weiteren Post its und klebt diese vertikal unter dem dazugehörigen Schritt auf.
Es entsteht ein Raster das die Story von links nach rechts erzählt und unter jedem einzelnen Schritt, die damit verbundenen Details auflistet. Die Details sind die Interaktionen, die das Team von den Benutzer:innen erwartet, um ihre Ziele in einem digitalen Produkt zu erreichen.
Über die Zeit haben sich unterschiedliche Herangehensweisen entwickelt mit unterschiedlichen Ebenen, die wiederum unterschiedlich benannt werden. Darum muss man sich (wie überall im Leben) irgendwann für eine Variante entscheiden und sich damit an die Arbeit machen.
Auch wir haben das getan und werden euch nun die 3 Ebenen vorstellen, mit denen wir arbeiten.
Eine User-Story-Map stellt meist diese 3 Ebenen in unterschiedlicher Granularität dar:
1. Themen
- Aufgaben auf hoher Ebene, die Benutzer im digitalen Produkt erledigen können.
- Das „Naming“ dieser Ebene variiert je nach Quelle, so heißt dieses Level auch manchmal Aktivitäten.
- Beispiel: Shop (als Thema bei der User Story Map einer Website)
2. Epics
- Schritte, die der Benutzer durchläuft, um die oben genannte Tätigkeit auszuführen.
- Die Themen und Epics gemeinsam ergeben das Narrative der User Story Map.
- Das „Naming“ dieser Ebene variiert je nach Quelle, so heißt dieses Level auch teilweise Steps / Schritte.
- Beispiel: Warenkorb (als Epic unter dem Thema Shop)
3. Aktionen
- Detaillierte Interaktion, um den obigen Schritt auszuführen.
- Das „Naming“ dieser Ebene variiert je nach Quelle, so heißt dieses Level auch teilweise „Detail“.
- Beispiel: Produkt in den Warenkorb legen (als Aktion unter dem Epic Warenkorb)
- Aus den Aktionen werden dann in weiterer Folge User Stories definiert. Beispielsweise: Als „Super-Shopper“ möchte ich mehrere Produkte gleichzeitig in den Warenkorb legen können, damit ich Zeit spare.
Priorisierung und Backlog
Wenn man die groben Themen, die darunterliegenden Epics und die wieder darunterliegenden Aktionen pro Epic definiert hat und die Struktur der Map einer logischen zeitlichen Abfolge entspricht, geht es darum, aus diesen Aktionen Umsetzungspakete zu schnüren. Dabei definiert man, welche Aktionen bereits Teil des MVP (Minimum Viable Products) sind und welche erst in den darauffolgenden Releases live gestellt werden.
Da es immer mehr zu produzieren gibt, als wir mit unserer Zeit oder unseren Ressourcen leisten können, werden sicherlich auch einige Aktionen in den Backlog verschoben.
Dieses war der erste Streich…
Ja ich weiß, das war jetzt wirklich viel Theorie 🤓. Aber keine Sorge, die praktischen Tipps zur Anwendung folgen im nächste Beitrag✌️. Denn in der Theorie hört sich ja immer alles leicht an aber die Praxis kann einen manchmal vor ganz schöne Herausforderungen stellen.
In der Zwischenzeit kannst du ja schon mal deine eigene User Story Map erstellen – zum Beispiel von deiner perfekten Morgenroutine.
