Was erwartet dich in diesem Beitrag?
Im ersten Teil zum Thema User Story Mapping habe ich euch die Methode erklärt und den Mehrwert, den sie in euer Projekt bringen kann. Allerdings habe ich euch auch ein paar wertvolle Praxitipps versprochen, die ich nun in diesem Artikel für euch aufliste.
Worum ging es nochmal im letzten Beitrag?
Die User Story Map ist eine Methode, die einem Produkt-Team dabei helfen kann, Lücken in der User Journey zu identifizieren und sicherzustellen, dass alle notwendigen Features und Funktionalitäten in die Softwareanwendung aufgenommen werden. Sie ist auch dafür geeignet, Bereiche zu identifizieren, in denen die User Experience verbessert werden kann, z. B. durch die Vereinfachung komplexer Aufgaben oder durch das Hinzufügen neuer Funktionen, die in den User Stories noch nicht berücksichtigt wurden.
Sobald die User Story Map fertiggestellt ist, kann das Team sie als Leitfaden für die Entwicklung des digitalen Produktes oder Services verwenden. Die User Story Map kann auch dazu genutzt werden, die Anforderungen der User:innen an die Stakeholdern zu kommunizieren und sicherzustellen, dass alle am Projekt Beteiligten ein gemeinsames Verständnis dafür haben.
Zusammenfassend lässt sich sagen, dass das User Story Mapping eine leistungsstarke Methode ist, um die User Experience zu verbessern und sicherzustellen, dass Softwareanwendungen im Sinne der User:innen entwickelt werden.
Praxistipps für den Einsatz von User Story Mapping
Folgende 5 Tipps haben sich für uns in der Praxis bewährt und sollen euch dabei helfen, eine erfolgreiche Brücke zwischen Theorie und Praxis zu schlagen.
1. Anforderungen von allen Seiten sammeln:
Bevor man ins User Story Mapping geht, muss man einen guten Überblick über die unterschiedlichen Zielgruppen und ihre Anforderungen haben. Dazu zählen natürlich einerseits die User, aber auch die internen Stakeholder. Wir prüfen vor jedem User Story Mapping, ob wir ein wirklich gutes Verständnis über die Bedürfnisse, Wünsche und Ziele der Zielgruppen haben bzw. ob die Personen, die an der Erarbeitung der User Story Maps teilnehmen, dieses Wissen mitbringen. Sollte das nicht der Fall sein, MUSS zuerst eine User Research gemacht werden. Hier raten wir immer zu einer Kombination aus quantitativen (z.B. eine Online-Survey) und qualitativen Methoden (z.B. User Interviews). Wichtig ist, dass die Research nicht nur das Verhalten der User:innen erfasst, sondern das Warum (also den Need) hinter diesem Verhalten.
Und eines sei hier auch noch ganz klar gesagt: Nein, es ist leider nicht ausreichend, wenn man nur glaubt, seine User:innen “eh gut genug” zu kennen. Solange man nicht mit ihnen gesprochen hat, arbeitet man mit Hypothesen, die man zum Wohle des Projekts überprüfen sollte.
2. Die richtigen Personen an einen Tisch setzen
Es ist außerdem essentiell, die richtigen Stakeholder zur Erarbeitung der User Story Maps einzuladen. Was das genau heißt? Die Gruppe sollte möglichst divers sein und unterschiedliche Sichtweisen aus dem Unternehmen abbilden. Beispielsweise Personen aus dem Call Center, der IT, den Fachbereichen, die Inhalte für das Produkt aufbereiten, dem Marketing, dem Vertrieb, der Business Analyse etc. Dies hilft einerseits, die Ziele des Unternehmens korrekt abzubilden, aber auch dabei ein Verständnis für die Bedürfnisse der User:innen an die richtigen Stellen im Unternehmen weiterzutragen.
Ein weiterer Punkt, der an dieser Stelle oftmals unterschätzt wird, ist es, die Entwickler:innen des Produktes einzubeziehen. Sie werden Fragen stellen, wie es kein anderer tut und einen bereits näher an etwas heranführen, was für jede User Story essentiell ist: die Akzeptanzkriterien.
Allen Entwickler:innen, die an dieser Stelle aufschreien, weil es jetzt noch gar nicht möglich ist, Akzeptanzkriterien zu definieren, sei gesagt: Schon klar, ich bin auch noch nicht fertig.
3. User Stories um erste Minimalanforderungen ergänzen
Und natürlich sei auch für alle gesorgt, die anstatt zu schreien mit googeln beschäftigt waren…
Exkurs Akzeptanzkriterien:
Die Akzeptanzkriterien definieren die Bedingungen, die erfüllt sein müssen, damit die User Story als vollständig gilt und die Anforderungen des Benutzers erfüllt. Sie enthalten spezifische Details, anhand derer das Entwicklungsteam sicherstellt, dass die User Story korrekt implementiert wird und die Anforderungen des Product Owners und der Stakeholder erfüllt.
Schauen wir uns ein Beispiel an.
User Story:
Als Kunde möchte ich meine Bestellhistorie einsehen können, damit ich meine vergangenen Einkäufe und deren Status verfolgen kann.
Akzeptanzkriterien:
- Die Seite mit der Bestellhistorie sollte von der Seite mit dem Kundenkonto aus zugänglich sein.
- Die Bestellhistorie sollte eine Liste aller vergangenen Einkäufe anzeigen, einschließlich der Bestellnummer, des Datums und der Gesamtkosten.
- Die Bestellhistorie sollte den Status jeder Bestellung anzeigen (z. B. in Bearbeitung, versendet, geliefert).
- Der Kunde sollte in der Lage sein, auf eine Bestellung zu klicken, um weitere Details anzuzeigen, einschließlich der Bestellpositionen, der Zahlungsinformationen und der Lieferadresse.
- Die Bestellhistorie sollte nach Datum, Bestellnummer und Status sortierbar sein.
- Die Bestellhistorie sollte nach Bestellnummer, Produktname oder Lieferadresse durchsuchbar sein.
- Die Bestellhistorie sollte paginiert sein, um eine begrenzte Anzahl von Bestellungen pro Seite anzuzeigen.
- Die Seite mit der Bestellhistorie sollte responsiv sein und sowohl auf Desktop- als auch auf mobilen Geräten korrekt angezeigt werden.
Richtige Akzeptanzkriterien können natürlich erst kurz vor der Entwicklung geschrieben werden. Der User Story Mapping Workshop findet aber viel früher im Prozess der Produktentwicklung statt. Beim Schreiben von User Stories passiert es aber meist automatisch, dass im Gespräch bereits erste Ansätze von Akzeptanzkriterien (wir nennen sie “Minimalanforderungen”) mitbedacht werden. Vor allem wenn Entwickler am Prozess beteiligt sind, kommen schnell Fragen auf wie “Was soll mit den Daten passieren?”, “Welche Felder sollen Pflichtfelder sein?”, “Bekommt der Nutzer eine Benachrichtigung per Email?”
Es ist wichtig, sich an dieser Stelle nicht zu sehr in Detailfragen zu verstricken, aber diese Punkte bereits in Ansätzen zu diskutieren und mitzubedenken, haben wir bisher als starke Bereicherung für den Prozess empfunden. Außerdem schafft es vor allem für die Entwickler:innen schon früh mehr Klarheit und auch auf Unternehmensseite werden Punkte, die oft lange in der Klärung benötigen (z.B. aus welchem System bekommen wir diese Daten?) schon sehr früh im Prozess diskutiert und Lösungen in die Wege geleitet.
4. Communication is Key
Gute Produktentwicklung bedarf guter Kommunikation. User Story Mapping konzentriert sich auf eine zielführende Kommunikation und ein gemeinsames Verständnis. Es ist eine Teamaufgabe und die Methodik ist darauf ausgelegt, den Austausch untereinander und die Diskussion zu den Themen zu fördern. Es geht also darum, so lange zu hinterfragen, was hinter einem Post-it steckt bzw. was damit gemeint ist, bis man es versteht. Die Map dient nicht der Dokumentation, sondern dafür, jeden Beteiligten immer wieder daran zu erinnern, wie der Gesamtzusammenhang der User Stories ist. Diese Erwartungshaltung sollte bei allen Beteiligten geschärft werden. Vor allem der Wissensaustausch zwischen allen Beteiligten (sei es thematisches Wissen innerhalb unterschiedlicher Fachbereiche des Unternehmens oder die Expertise von Designer:innen und Developer:innen) ist ein unfassbarer Mehrwert des Prozesses. Umso wichtiger ist es, dass alle relevanten Personen an der Erstellung der Map teilhaben.
5. Starte bei den Aktionen
Wir haben festgestellt, dass es deutlich leichter ist, den Prozess von unten nach oben zu durchlaufen. Also mit den Aktionen zu starten, diese danach zu clustern und passende Themen und Epics zu finden.
Dieses Vorgehen haben wir hier anhand der “perfekten Morgenroutine” für euch veranschaulicht:
1. Sammle alle Aktionen die dir zu deiner perfekten Morgenroutine einfallen
2. Clustere die Aktionen nach einer groben zeitlichen Abfolge – beispielsweise alles, was noch im Bett passiert, dann alles, was im Bad passiert etc.
3. Finde Themen für diese groben Cluster
4. Ordne die Aktionen innerhalb der Themencluster noch einmal erneut in Spalten mit zusammengehörigen Aktionen und Reihe diese Spalten innerhalb der Themencluster in einer zeitlich-logischen Reihenfolge von links nach rechts. Dann findest du erneut Überbegriffe für diese Spalten (=EPICS).
Wenn du in diese Herangehensweise noch etwas tiefer eintauchen willst, dann findest du hier noch eine genauere Erklärung dazu: https://www.youtube.com/watch?v=YumNf61xn5E
So das war’s auch schon.
Ich hoffe, dass ihr euch den Einsatz von User Story Mapping in der Praxis nun etwas besser vorstellen könnt. Vielleicht könnt ihr auch einen unserer Tipps in euer nächstes User Story Mapping mitnehmen. In jedem Fall freuen wir uns, wenn diese Methode zu einem fixen Bestandteil in der Konzeption von digitalen Produkten und Services wird, da sie den Austausch innerhalb von Teams immens fördert, Qualität in den Prozess bringt und einen Weg vorzeichnet, der Lust macht, die Sachen anzupacken und einfach loszulegen.
Hast du Fragen oder möchtest User Story Mapping gerne im Rahmen eines Workshops mit uns erlernen oder hands on umsetzen?
Don’t be shy: Kontaktiere uns und lass uns plaudern!
