Zielgruppenanalysen und Persona kennst du vermutlich schon – eine weitere spannende Methode, aber nicht ganz so verbreitet, ist die sogenannte User Story. Sie ist sozusagen die „Geschichte des Benutzers“.
Hier werden die Anforderungen und Wünsche des Benutzers an die Anwendung auf eine klare und präzise Art und Weise beschrieben. Die Anwendung kann eine Website sein, eine App oder eine Software an sich.
Eine User Story bildet die Funktionsweise eines Features aus Kunden-Sicht ab. Im Fokus steht nicht die Funktion selbst, sondern ihr Nutzen.
In diesem Artikel erkläre ich dir genau, was eine User Story ist, wie du sie erstellst und warum sie so wichtig für eine erfolgreiche Software- und Websiteentwicklung ist. Denn sie hilft dabei den Kunden und seine Bedürfnisse in den Mittelpunkt zu stellen.
Inhaltsverzeichnis
Was ist eine User Story?
Eine User Story (auf Deutsch Anwender- oder Nutzer-Erzählung) beschreibt ein Software-Feature mit seiner Funktionsweise und seinem Nutzen aus Endkunden-Sicht. Damit erleichtert es dem Team, zu verstehen, warum das Feature wichtig ist und worauf es bei der Umsetzung achten muss.
Dieses Werkzeug wird in der agilen Software-Entwicklung genutzt. Die Einsatzgebiete sind vielfältig – von der Validierung von Kundenbedürfnissen bis zur Formulierung von Anforderungen in Frameworks.
Wie sieht eine User Story aus?
Die Antworten auf die Fragen nach dem Wer? Was? und Warum? werden in einer Annahme zusammengefasst und wie folgt formuliert:
Als [Nutzer] möchte ich [Funktion], damit ich [Nutzen] erreiche.
Hinzu kommen sogenannte „Akzeptanzkriterien“ – dazu später mehr.
Von der kleinsten Einheit bis zur User Journey
User Stories stellen die kleinsten Bausteine in einem Projekt dar. Fasst man mehrere zusammen erhält man einen User Case.
Aus aufeinander folgenden Stories bzw. Cases ergibt sich die User Journey – ähnlich der Customer Journey.
Vorteile von User Stories
Die beschriebenen Geschichten aus Anwender-Perspektive bieten viele Vorteile:
- Der Faktor Mensch rückt mehr in den Fokus deiner Arbeit.
- User Stories fördern die Entwicklung kreativer Lösungswege.
- Sie erleichtern die Zusammenarbeit in Teams, denn jeder weiß, was das Endziel ist.
- User Stories zerteilen das Projekt in kleine, machbare Häppchen.
Beispiele für User Stories
Damit du dir nach all‘ der Theorie mehr unter einer User Story vorstellen kannst, kommen hier ein paar Beispiele:
| Wer? [Nutzer] | Was? [Funktion] | Warum? [Nutzen] |
| Als [Onlineshop-Kunde] | möchte ich [mir im Login-Bereich meine Bestellhistorie ansehen], | um [vergangene Bestellungen zu kontrollieren]. |
| Als [Fan von Science-Fiction Filmen] | möchte ich [auf der Streaming-Plattform das Genre auswählen], | um [passende Filme vorgeschlagen zu bekommen]. |
| Als [Bahnfahrer] | möchte ich [in der App auf mein Online-Ticket zugreifen], | um [es bei einer Kontrolle vorzeigen zu können]. |
| Als [Hausbesitzer] | möchte ich [die Heizung smarter regulieren können], | um [Geld zu sparen]. |
| Als [Besucher des Webdesign-Journals] | möchte ich [diesen Artikel über User Stories lesen], | damit [ich sie als Tool in meinem Prozess nutzen kann]. |
| Als [Website-Besucher] | möchte ich [Artikel auf der Webseite teilen], | um [sie mit Freunden und Kollegen zu teilen]. |
| Als [Online-Shop-Nutzer] | möchte ich [Produkte im Shop filtern], | damit [ich schnell das finde, was ich suche]. |
So erstellst du eine passende User Story
Um eine individuelle User Story für dein Projekt zu formulieren, kannst du das User Story-Template aus dem Konzeptions-Kit nutzen. Dort findest du neben wertvollen Anleitungen auch weitere Hilfestellungen für deine Projektkonzeption.
Beachte bei der Formulierung der User Story folgende Punkte:
- Halte deine User Story kurz und prägnant.
- Formuliere möglichst simpel (kein Fachvokabular).
- Schreibe aus Anwender-Sicht.
- Stell deutlich heraus, was der Nutzen ist.
- Beschränke dich auf eine Funktionalität.
- Vermeide technische Details.
- Ziehe bei der Formulierung dein Team hinzu.
- Nutze Akzeptanzkriterien (s. übernächster Abschnitt).
Klassische Satzschablone und Alternativen
Die typische Formulierung lautet:
Als [Nutzer] möchte ich [Funktion], damit ich [Nutzen] erreiche.
Du kannst aber auch mit alternativen Satzschablonen arbeiten:
Um [Nutzen] als [Nutzer] zu erreichen, möchte ich [Funktion].
Oder um Ort und Zeit erweitert:
Als [Nutzer] (wann) (wo) möchte ich [Funktion], weil / um / damit [Nutzen].
Wer? Der Nutzer
Bei [Nutzer] trägst du einen typischen Vertreter der Zielgruppe ein, für die die Anwendung bestimmt ist. Alternativ wird auch von [Rolle] oder [Kundentyp] gesprochen. Um es noch greifbarer zu machen, kannst du der Person einen Namen geben, z. B. „Als Online-Shop Kunde Julian möchte ich …“
Was? Die Funktion / Handlung
Mit [Funktion] ist die Handlung gemeint, die zum Ziel führen soll. Wir sprechen also nicht von der Funktionalität selbst, sondern meinen die Aktion, die der Nutzer ausführt, um Nutzen zu generieren.
Warum? Der Nutzen
Und [Nutzen] beantwortet die Frage, warum die Person handelt. Was hat sie davon? Welchen Mehrwert erschafft sie durch ihr Tun? Mit welcher Absicht agiert sie? Oder welches Problem will sie lösen?
Was bedeutet „Akzeptanzkriterien“?
Gemeint ist eine Auflistung an Ergebnissen bzw. Anforderungen, die durch die User Story erfüllt werden müssen. Mithilfe dieser Kriterien stellst du sicher, dass das Ziel erreicht wurde. Man könnte also auch von Abnahmebedingungen sprechen.
Um Akzeptanzkriterien zu formulieren helfen W-Fragen oder Bedingungssätze:
Was passiert, wenn [Fall xyz] eintritt?
Beispiel für Akzeptanzkriterien
Für die User Story „Als [Fan von Science-Fiction Filmen] möchte ich [auf der Streaming-Plattform das Genre auswählen], um [passende Filme vorgeschlagen zu bekommen].“ können folgende Kriterien formuliert werden:
- Hat die User Story eine Genre-Übersicht?
- Wird Science-Fiction angezeigt?
- Was passiert, wenn das gewünschte Genre nicht angezeigt wird?
Oder für „Als [Onlineshop-Kunde] möchte ich [mir im Login-Bereich meine Bestellhistorie ansehen], um [vergangene Bestellungen zu kontrollieren].“:
- Gibt es eine Möglichkeit, zu den Bestellungen zu navigieren?
- Kann der Kunde zwischen vergangenen und bestehenden Bestellungen wählen?
- Welche Informationen sollen zur Kontrolle angezeigt werden?
Die vielleicht bessere User Story
„Als User möchte ich mich anmelden.“ – Die größte jemals erzählte Lüge über Benutzer.
Ein User möchte sich nicht anmelden. Er muss sich anmelden.
Ein User möchte nicht seine E-Mail-Daten preisgeben, um einen Newsletter zu bestellen. Er muss es machen, um Informationen zu bekommen.
Ein User möchte nicht ein Formular ausfüllen, um eine Bestellung zu tätigen. Er muss es machen.
User Stories haben natürlich auch ihre Grenzen, bzw. Gefahren. Denn nicht alles, was wir vermuten, was der User machen möchte, möchte er gerne und freiwillig machen. „Als Benutzer möchte ich das Formular ausfüllen“ gaukelt vor, dass der Benutzer dies gerne und freiwillig machen möchte. Mit dieser Begründung User Story lässt sich jede Funktion rechtfertigen. Aber der Nutzen und das Benutzungserlebnis für den User sinkt.
Die Geschichte: „Als [Nutzer] möchte ich [Funktion], damit ich [Nutzen] erreiche.“ klingt eher nach Programmierervorstellung, als nach einer tollen User Experience.
Niemand geht zufrieden nach Hause, weil er ein Formular ausgefüllt hat. Was hat er erreicht? Wie passt das Formular in seine Geschichte?
Das was hier als „Nutzen“ bezeichnet wird, sind eigentlich „Kosten“ (Zeit, gedankliche Ressourcen), die der User aufbringen muss, um sein Ziel zu erreichen. Stattdessen könnte man schauen, wie man diese „Kosten“ für den User möglichst gering hält. Wie kann man vermeiden, dass er ein Formular ausfüllen muss (und trotzdem sein Ziel erreichen kann)?
Amazon, in vielen Punkten User Experience-Vorreiter, formuliert es gerne so: „today, customers have to…“.
„Heutzutage müssen User ein Formular ausfüllen, um…“ – Das klingt eher nach einem Kampf als nach einer Funktion, die man absichtlich einbauen sollte.
Die – vielleicht bessere – User Story könnte sich also weniger vom Nutzen, als vom Ziel ableiten:
„Benutzer wollen [Aufgabe erledigen], um [Ziel zu erreichen]“
„Als Benutzer möchte ich bestellen, ohne mich anmelden zu müssen.“
„Als Benutzer möchte ich vermeiden mich anzumelden, aber ich möchte trotzdem meine Daten sehen.“
So wurde die Benutzergeschichte quasi umgedreht. Die Kosten werden nicht auf User abgewälzt und es werden keine Funktionen „erfunden“, die kein User wirklich möchte.
Tools, um User Stories zu erstellen
Mithilfe von User Stories zerteilst du dein Projekt in kleine Aufgaben. Dabei kann es schnell mal unübersichtlich werden. Das Template im Konzeptions-Kit hilft dir dabei, den Überblick zu behalten.
Außerdem kannst du die Stories in einem sog. User Story Mapping abbilden. Es zeigt das Projekt im Ganzen und die Beziehung einzelner User Stories zu einander. Diese Tools erleichtern dir die Arbeit:
Kleine Story – große Wirkung
In diesem Artikel wurde erläutert, was eine User Story ist und wie sie im agilen Softwareentwicklungsprozess verwendet wird. Es wurde erklärt, dass User Stories die Anforderungen und Wünsche der Endnutzer beschreiben und dass sie eine klare und präzise Art und Weise verwenden, um dies zu tun. Du hast gesehen, wie man User Stories erstellt und warum sie so wichtig für eine erfolgreiche Softwareentwicklung und auch Websites sind.
Die User Story ist im Grunde nur ein simpler Satz. Doch ein paar Rückfragen machen deine Arbeit nicht nur einfacher, sondern auch besser. Der kreative Ansatz, bei dem du die Zielkunden-Sicht einnimmst sorgt für Ergebnisse, die noch näher am Kunden sind.
Probier’s aus!
