Der Nutzer steht im Mittelpunkt jeder guten Website-Entwicklung. Vor-Ort-Befragungen, Personas etc. gehören schon lange zum Handwerkszeug von Konzeptern. In diesem Bereich bisher noch selten trifft man die Technik des User Story Mapping. Ein kleines Buch könnte das ändern.
Was sind User Stories?
User Stories stammen aus der Agilen Entwicklung. Diese Art der Softwarentwicklung kam 2001 auf, als eine Gruppe von einflussreichen Programmieren das Agile Manifest verabschiedeten.
Demnach sind
- Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge
- Funktionierende Software wichtiger als umfassende Dokumentation
- Zusammenarbeit mit dem Auftraggeber wichtiger als Vertragsverhandlungen
- Anpassung an Änderungen wichtiger als Festhalten an Plänen
Das Agile Manifest entstand, weil viele Entwickler bei großen Projekten frustriert waren. Sie waren frustriert, weil mit zunehmender Komplexität der Produkte der Aufwand für Dokumentation und Organisation explodierte. Und weil die Qualität der Ergebnisse in vielen Fällen mehr als niedrig war.
Die Idee hinter Agile ist, immer in den persönlichen Austausch zu gehen, in kleinen Teams und in kleinen Schritten zu arbeiten. So schnell wie möglich sollen funktionierende Anwendungen entstehen, die getestet und geprüft werden. Davon ausgehend wird verbessert und an den nächsten Schritten gearbeitet.
Agile heißt Stück für Stück
Leonardo Da Vinci hat die Mona Lisa nicht von oben nach unten gemalt. Sondern er hat erst eine Skizze mit Kohle auf der Leinwand angelegt, dann mehr und mehr Details mit Farbe hinzugefügt, Schicht um Schicht. Und in jedem Zustand hat das Bild „funktioniert“. Jeder konnte sehen, was hier entsteht und der Künstler konnte jederzeit ohne Probleme korrigierend eingreifen.
Nach demselben Prinzip arbeitet Agile: Stück für Stück entsteht das Produkt, und so früh wie möglich soll ein lauffähiges Programm herauskommen. Dieses kann man testen und daraufhin anpassen.
Geschichten erzählen statt dokumentieren
User Stories treten in der Agilen Entwicklung an Stelle der oft sehr langen und schlecht lesbaren Software (Requirement) Specification – also der funktionalen Spezifikation des Projects. Diese soll das gesamte Endprodukt mit all seinen Funktionen vollständig beschreiben.
Das ist sehr aufwendig, in den meisten Fällen klappt es nur schlecht und vor allem ist es sehr schwierig, Fehler zu korrigieren, die während der Umsetzung auftauchen.
Schlimmer: Oft fallen diese Fehler während der Umsetzung gar nicht auf, sondern erst nach Abschluss des Projekts.
Warum User Stories gut sind
User Stories, also Nutzererzählungen, beschreiben in einem einfachen Satz eine einzelne Funktion. Als Beispiel:
Als Leser möchte ich die von mir gekauften E-Books in der Liste nochmal herunterladen können, damit ich sie wiederbekomme, wenn ich meinen E-Book-Reader verloren habe.
Mit User Stories erzählen wir also in vielen kleinen Geschichten, wie die Nutzer mit dem endgültigen Produkt umgehen sollen. Das ist wesentlich lebendiger und leichter zu lesen als die trockenen und sehr umfangreichen funktionalen Dokumentationen. Ganz wichtig dabei: User Stories sind nicht als Dokumentation zu sehen, sondern als Anregung zur Diskussion. Sie sollen das Gespräch im Team auslösen, wie die beschriebene Geschichte umzusetzen ist.
Warum das Buch?
Die Gefahr bei der Arbeit mit User Stories: Diese sind so klein, da verliert man schnell den Blick für das Große Ganze. Wenn man nicht aufpasst, entsteht ein Frankenstein-Produkt – ein seelenloses Monster, das man aus lauter Einzelteilen zusammengeflickt hat.
Der Autor Jeff Patton hat daher das Buch User Story Mapping. Discover the Whole Story, Build the Right Product geschrieben.
Darin erklärt er, wie man mit Hilfe der User Stories eine Geschichte erzählt, die uns hilft, unsere Projekte zu konzipieren und sie umzusetzen.
Die Technik des User Story Mapping
Und so funktioniert das Erstellen der Landkarte der Nutzererfahrungen, also das User Story Mapping:
- Jede Aufgabe („task“) kommt auf ein Post-it. Am besten aktiv formuliert mit einem Verb (z.B. „Nutzer gibt seine E-Mailadresse ein und klickt OK, um den Newsletter zu abonnieren.“). Das wiederholt man so lange, bis man alle Aufgaben gesammelt hat – so entstehen eine Handvoll bis Hunderte von Zetteln.
- Die Notizen werden von links nach rechts an die Wand geklebt, so dass sie den Vorgang logisch beschreiben – also die Geschichte erzählen.
- Die Aufgaben werden nun sortiert und zu Aktivitäten („activities“) zusammengefasst. Die Aktivität ist ein übergeordnetes Post-it (z.B. „Nutzer will ein E-Book herunterladen.“).
Damit hat man die User Story Map bereits fertig. Nun kann man mit ihr arbeiten:
Mit horizontalen Linien trennt man die Bereiche ab, in denen sich ein sinnvoller Teilabschnitt definieren lässt. Beim Beispiel eines E-Book-Kaufs könnten das z.B. folgende Aufgaben sein:
- Eingeben eines Suchbegriffs/Buchtitels
- Auswahl eines Treffers (Klick auf das Coverbild)
- Klick auf „Kaufen“
- Eingeben E-Mail-Adresse & Passwort, Klick auf OK
- Klicken auf „Jetzt kaufen“
Weitere Aktivitäten, die aber nicht zwingend nötig sind, um ein sinnvoll nutzbares Produkt zu erstellen:
- Angabe einer alternativen Versandadresse
- Teilen des Kaufs in Sozialen Netzwerken
- Auswahl weiterer Titel („Kunden, die x kauften, kauften auch“)
- Abonnieren des Newsletters
Anhand der User Story Map kann man nun schnell beurteilen, welche Aufgaben man als Nächstes umsetzen will. Man sieht schnell, was nötig ist, um ein benutzbares Produkt zu bekommen und kann sich entsprechend zuerst diesen Aufgaben widmen. So entsteht schnell ein testbares Produkt, das man dann im weiteren Verlauf optimieren kann.
Agile heißt diskutieren & nutzerfreundlich dokumentieren
Sehr gut gefällt mir Pattons Vergleich von Dokumentation mit Schnappschüssen aus dem Urlaub:
Gute Dokumentationen sind wie Urlaubsfotos: Nur wer dabei war, weiß sie wirklich zu schätzen. Sie sind mehr Gedächtnisstütze als vollständige Beschreibung.
Dieser Vergleich zeigt: Wir sollten es nicht übertreiben mit der Genauigkeit unserer Dokumentation. Wichtig ist, dass sich die Leute im Team (und der Auftraggeber/Chef) darüber einig sind, was Sie warum und wie entwickeln wollen.
Patton schlägt auch vor, Whiteboards/Flipcharts einfach zu fotografieren. So sieht man die User Story Map, in der Form, in der sie entstand. Das hilft den Beteiligten, sich zu erinnern und spart die Mühe, diese später aufwendig nachzuzeichnen für Protokoll.
Oder, in manchen Fällen noch besser: Man stellt sich einfach vor die Wand mit der User Story Map und macht ein kurzes Video, in dem man sie erklärt.
Dazu nochmal Pattons zentrale Botschaft:
User Stories sind keine andere Form der Requirements. User Stories zu erzählen ist die Methode, um ein gemeinsames Verständnis zu erlangen.
Fazit
Das Buch wirkt vom Stil her etwas amerikanisch, mit vielen Fotos von Menschen in Konferenzräumen und einigermaßen witzigen Anmerkungen dazu. Diese lockern natürlich auf, strengen aber manchmal ein bisschen an.
Aber dennoch: Dadurch ist das Buch mit seinen 277 Seiten gut zu lesen. Gerade wer nicht selbst in großen Software-Projekten arbeitet, der kann die letzte Hälfte nur überfliegen.
Aber der erste Teil des Buches gibt auch für kleine Web-Projekte wertvolle Anregungen. Jeder, der keine Lust mehr hat, lange Dokumente zu schreiben, die bei der Umsetzung sowieso niemand liest, der sollte sich die Methode des User Story Mapping einmal genauer ansehen. Und dazu ist das Buch ein optimaler Einstieg.
No Comment