Möglichkeiten, neue Ideen oder Problemlösungen zu finden, gibt es viele. Doch die wichtigste Komponente wird häufig vergessen: der Nutzer. User Story Mapping stellt den Nutzer mit seinen Anforderungen an ein Produkt oder eine Dienstleistung in den Mittelpunkt. Die Methode hilft vor und während einer Produktentwicklung, die Bedürfnisse eines Nutzers zu berücksichtigen.
Das User Story Mapping ist eine Visualisierungsmethode, die mit Post-its auf Wänden, Tischen oder dem Boden arbeitet. Die Methode besteht insgesamt aus drei zentralen Elementen: Backbone, Epics und User Storys.
Das Grundgerüst ist der sogenannte Backbone. Hier werden alle Aktivitäten, Aufgaben und Stationen, die ein Nutzer durchführen muss, um eine Aufgabe zu erledigen, chronologisch aufgeführt – es spiegelt quasi den Tagesablauf eines Nutzers wider. Die einzelnen Aufgaben werden Epics genannt, die verschiedenen Unteraufgaben eines Epics sind die User Storys.
In unserem Beispiel ist, wie auch im Artikel zu Design Thinking, die Ausgangssituation folgende: Die Call-Agenten eines Telekommunikationsunternehmen beschweren sich, dass die Suchfunktion ihrer Case Management Software nicht richtig funktioniert und sie deshalb Schwierigkeiten haben Kundenanliegen zu bearbeiten. Um das Problem der Agenten zu lösen, setzt sich ein Team aus Softwareentwicklern zusammen und entwirft eine User Story Map.
Das Ziel dieser User Story Map ist: „Kundenanliegen muss gelöst werden“ (pink) und steht über dem gesamten Prozess. Darunter befindet sich der Backbone mit den verschiedenen Epics (gelb). Die Epics zeigen hier die einzelnen Arbeitsschritte eines Call-Agenten vom Eingang eines Kundenanliegens bis zur Schließung eines Falles auf.
Das Backbone ist das Grundgerüst der User Story Map und wird chronologisch mit Epics (gelb) sortiert.
Sind die Epics identifiziert, werden konkrete Unteraufgaben, die User Storys (orange), den Epics zugeordnet. Dadurch werden die Arbeitsschritte, die ein Agent mit der Case Management Software durchlebt, detailliert beschrieben. Alle User Storys zusammen bilden die sogenannte User Journey ab.
In unserem Beispiel fallen folgende Aufgaben für die einzelnen Epics an:
User Storys (orange) erläutern die einzelnen Unteraufgaben der Epics (gelb).
Nun soll aus den User Storys ein Prototyp, oder auch das Minimum Viable Product (MVP) (neon-gelb) entstehen. Das MVP umfasst die Basisanforderungen, die ein Produkt oder eine Dienstleistung enthalten muss. In unserem Fall sind das: „Agent nimmt Kundenanliegen entgegen“, „Agent tippt Kundenaussage in Suchmaske ohne vorher Schlüsselbegriffe zu identifizieren“ und „KI-basierte Such liefert Links & Überschriften der besten Suchtreffer“.
Ist der Prototyp erstellt, können bessere Softwareversionen ausgearbeitetwerden, die über die Grundanforderungen hinausgehen. Hierzu eignen sich weitere Releases (pink). Für das MVP sind sie aber nicht zwingend notwendig. In unserem Beispiel ist ein erster Release „ Statt eintippen ein Speech-to-Text System benutzen“.
Das MVP (neongelb) muss in einem Prototyp vorhanden sein, weitere Releases (pink) können das Produkt in späteren Schritten ergänzen und optimieren.
Das User Story Mapping verbildlicht dem Entwicklerteam alle einzelnen Arbeitsschritte und Aufgaben eines Call-Agenten - vom
Anruf eines Kunden bis hin zum Schließen des Falles. Diese Visualisierung hilft den Entwicklern, die Arbeitsweise der Agenten zu verstehen und auch welche Anforderungen diese an die Suchfunktion der Case Management Software haben. Durch die Methode werden die Bedürfnisse der Nutzer herausgearbeitet und die Software kann entsprechend entwickelt, angepasst und verbessert werden.