Ein Brief, viele Schritte: Bei meinem Arbeitgeber, der Krankenversicherung CONCORDIA, sollte ein Brieferstellungsprozess automatisiert werden – klingt simpel, war es aber nicht. Erst die Methode des User Story Mapping brachte Übersicht ins Chaos. Sie half uns ein gemeinsames Verständnis zu schaffen.
Automatisierung klingt nach Technik – tatsächlich beginnt sie mit Verständnis. In unserem Projekt bei der CONCORDIA möchten wir den Prozess rund um den „Brief Weiterführung OKP“ digitalisieren. Dieser Brief wird verschickt, wenn Kundinnen und Kunden ihre Grundversicherungsprämien nicht bezahlt haben und die Versicherung deshalb nicht verlassen dürfen.
In der Transferarbeit unseres CAS Requirements Engineering griff ich diesen Fall aus meinem beruflichen Alltag auf. Gemeinsam in der Gruppe machten wir uns daran, die Abläufe zu analysieren, Anforderungen zu sammeln und eine Lösung zu entwerfen.
Schon bald stellte sich heraus: Die Herausforderung lag darin, dass gleiche Verständnis über die angestrebte Umsetzung in der Gruppe zu schaffen.
Jeff Patton bringt die Wende
In dieser Phase erlernten wir im Unterricht die Methode des User Story Mapping von Jeff Patton. Was mir daran gefiel: Es bietet keine Methode um der Methode willen, sondern ein praktisches Werkzeug, um gemeinsam über Prozesse, Bedürfnisse und Prioritäten nachzudenken – und das visuell, iterativ und fokussiert auf den Nutzer.
User Story Mapping – was ist das eigentlich?
User Story Mapping ist eine Methode, um Anforderungen aus Sicht der Benutzer:innen zu erfassen – und das visuell. Statt eine Liste mit Einzelfunktionen zu erstellen, wird der Nutzungskontext in Form einer „Geschichte“ aufgebaut: Was passiert zuerst? Was folgt danach? Und welche Funktionen gehören zu welchem Schritt?
Wozu braucht es überhaupt ein User Story Mapping?
Wenn du schon mal an einem Softwareprojekt gearbeitet hast, kennst du Aussagen wie:
- „Was war nochmal der Auslöser für diesen Prozess?“
- „Brauchen wir dieses Feature wirklich?“
- „Was ist eigentlich das Ziel aus Sicht der Benutzer:in?“
- „Haben wir irgendwo eine Übersicht über alles?“
In unserer Transferarbeit zum „Brief Weiterführung OKP“ tauchten genau solche Fragen auf. Anfangs schien das Projekt simpel – ein Standardbrief sollte automatisiert werden. Doch mit jedem Schritt wurde klarer: Wir verloren die Übersicht und diskutierten wiederholt dieselben Themen, weil nicht alle vom Gleichen sprachen.
Wann macht User Story Mapping Sinn?
Immer dann, wenn man:
- komplexe Abläufe verstehen muss
- Anforderungen strukturieren will
- ein gemeinsames Bild schaffen möchte
- wissen will, was Nutzer:innen wirklich brauchen
- agil, iterativ und nutzerzentriert arbeiten möchte
Aus welchen Elementen besteht eine User Story Map?
Eine typische User Story Map besteht aus drei Ebenen:
- Aktivitäten: Die groben Nutzungsschritte – z. B. „Einkauf für das Wochenende besorgen“.
- Tasks: Konkrete Handlungen innerhalb einer Aktivität – z. B. „Menus planen“.
- User Storys: Detaillierte Teilschritte – z. B. „Familienmitglieder nach Menu-Wunsch fragen“.
Diese Ebenen werden von links nach rechts (zeitlich) und von oben nach unten (in der Tiefe) angeordnet.
Folgendes Beispiel aus dem Alltag veranschaulicht dir die Methode.
Warum User Story Mapping bei uns den Unterschied machte
Die User Story Map schaffte endlich Verständnis bei uns allen. Statt lange über Details zu diskutieren, sahen wir den Gesamtprozess. Auch Diskussionen über Prioritäten wurden einfacher, weil die Karte visuell zeigte, was zusammengehört.
Fazit: Ein Werkzeug, das verbindet und Klarheit schafft
Was ich aus diesem Projekt mitnehme: User Story Mapping ist ein einfaches, aber erstaunlich wirkungsvolles Werkzeug. Es hilft, komplexe Themen gemeinsam zu durchdenken, Nutzerbedürfnisse zu verstehen und tragfähige Lösungen zu entwickeln – bevor auch nur eine Zeile Code geschrieben wird.
Mein Tipp: Schnappt euch ein paar Post-its und erstellt gemeinsam eine Story Map. Ihr werdet sehen – es ist mehr als nur eine Übung. Es ist ein echter Gamechanger für euer Projekt.
