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 Kundensicht 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.
Was ist eine User Story?
Eine User Story beschreibt eine Funktion oder ein Feature aus Sicht des Nutzers, um den tatsächlichen Mehrwert für ihn in den Mittelpunkt zu stellen. Sie folgt einer einfachen Struktur: „Als [Nutzer] möchte ich [Funktion], damit ich [Nutzen] erreiche.“ Diese Methode hilft, benutzerfreundliche Lösungen zu entwickeln, die sich an den Bedürfnissen der Zielgruppe orientieren.
In der agilen Entwicklung sind User Stories ein zentrales Werkzeug, um Anforderungen klar und verständlich zu formulieren. Sie erleichtern die Zusammenarbeit im Team, fördern kreative Lösungswege und sorgen dafür, dass Projekte in kleine, umsetzbare Schritte unterteilt werden.
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 deiner 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ührt. 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 aufzurufen?
- 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 einer 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, zur Erstellung von User Stories
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 einfacher 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!
Zusammenfassung des Artikels – wichtige Erkenntnisse zu User Stories
User Stories rücken den Nutzer in den Mittelpunkt
Eine User Story beschreibt nicht nur die Funktionalität einer Software oder Website, sondern fokussiert sich auf den tatsächlichen Nutzen für den Endkunden. Dadurch entstehen benutzerfreundliche und zielgerichtete Lösungen, die die Bedürfnisse des Nutzers konsequent in den Mittelpunkt stellen.
Klare und einfache Formulierungen verwenden
Bei der Erstellung von User Stories ist es entscheidend, möglichst einfache und prägnante Sätze zu verwenden. Fachvokabular sollte vermieden werden, um sicherzustellen, dass alle Teammitglieder – unabhängig von ihrer Expertise – die Anforderungen verstehen.
Akzeptanzkriterien festlegen
Neben der eigentlichen User Story sind Akzeptanzkriterien ein wichtiger Bestandteil. Sie helfen dabei, messbare Anforderungen zu formulieren und sicherzustellen, dass das Ziel der User Story auch wirklich erreicht wird. Diese Kriterien fungieren als eine Art Checkliste für die Abnahme.
Projekte in kleine, machbare Schritte unterteilen
User Stories zerteilen komplexe Projekte in kleine, überschaubare Aufgaben. Das erleichtert nicht nur die Planung und Umsetzung, sondern schafft auch klare Meilensteine, die dem Team Orientierung bieten und für ein kontinuierliches Erfolgserlebnis sorgen.
Gefahren durch falsche User Stories erkennen
Nicht jede User Story bringt automatisch Mehrwert für den Nutzer. Wenn Funktionen beschrieben werden, die der Nutzer nicht wirklich möchte, kann dies zu einer schlechteren User Experience führen. Stattdessen sollte immer hinterfragt werden, ob die beschriebene Aufgabe tatsächlich dem Nutzer hilft, sein Ziel möglichst einfach zu erreichen.
Alternativen zur klassischen User Story nutzen
Neben der klassischen Formulierung „Als [Nutzer] möchte ich [Funktion], damit ich [Nutzen] erreiche.“ können auch alternative Satzschablonen genutzt werden. Diese bieten mehr Flexibilität und ermöglichen es, die User Story stärker auf das eigentliche Ziel des Nutzers auszurichten.
Nutzerperspektive durch Namen und Rollen verdeutlichen
Indem der Nutzer in der User Story nicht nur als anonyme Rolle, sondern mit einem konkreten Namen oder einer klaren Persona beschrieben wird, kann das Team sich besser in die Perspektive des Nutzers hineinversetzen. Das hilft, noch gezielter auf die Bedürfnisse der Zielgruppe einzugehen.
Tools zur Unterstützung von User Stories nutzen
Um den Überblick über viele User Stories zu behalten und sie sinnvoll in den Projektkontext einzuordnen, können Tools wie JIRA, Trello oder Notion eingesetzt werden. Sie ermöglichen es, User Stories visuell darzustellen und ihre Beziehungen zueinander zu verdeutlichen.
Kosten für den Nutzer minimieren
Statt nur den Nutzen einer Funktion zu betrachten, sollte auch der Aufwand (die „Kosten“) für den Nutzer im Fokus stehen. Die beste User Story ist die, bei der der Nutzer mit minimalem Aufwand sein Ziel erreicht – idealerweise ohne unnötige Schritte wie das Ausfüllen eines Formulars oder das Anlegen eines Benutzerkontos.
Häufig gestellte Fragen zu User Stories
Was ist eine User Story?
Eine User Story ist eine kurze, prägnante Beschreibung einer Funktion aus Sicht des Nutzers. Sie hilft dabei, den Nutzen eines Features klar zu definieren und den Fokus auf die tatsächlichen Bedürfnisse der Nutzer zu legen.
Wie formuliere ich eine User Story richtig?
Die klassische Formulierung lautet: „Als [Nutzer] möchte ich [Funktion], damit ich [Nutzen] erreiche.“ Alternativ kann auch die Struktur „Um [Nutzen] zu erreichen, möchte ich als [Nutzer] [Funktion] nutzen.“ verwendet werden.
Was sind Akzeptanzkriterien und warum sind sie wichtig?
Akzeptanzkriterien definieren, wann eine User Story als erfüllt gilt. Sie helfen dem Team, die Anforderungen klar zu verstehen und stellen sicher, dass die entwickelte Funktion den gewünschten Nutzen bietet.
Worin liegt der Unterschied zwischen einer User Story und einem Use Case?
Eine User Story beschreibt eine einzelne Anforderung aus Sicht des Nutzers, während ein Use Case detaillierter ist und mehrere User Stories umfassen kann. Ein Use Case beschreibt den gesamten Ablauf einer Nutzerinteraktion.
Wie detailliert sollte eine User Story sein?
Eine User Story sollte kurz und verständlich sein. Sie sollte das „Was“ und „Warum“ einer Funktion beschreiben, aber keine technischen Details oder Umsetzungsschritte enthalten.
Welche Tools eignen sich zur Verwaltung von User Stories?
Zur Organisation und Verwaltung von User Stories können Tools wie JIRA, Trello, Productboard oder Notion genutzt werden. Diese helfen, den Überblick über die verschiedenen Anforderungen zu behalten.
Wann ist eine User Story abgeschlossen?
Eine User Story gilt als abgeschlossen, wenn alle Akzeptanzkriterien erfüllt sind, das Feature getestet wurde und es den gewünschten Nutzen für den Nutzer bietet.
Welche Fehler sollte man bei der Erstellung von User Stories vermeiden?
Zu allgemeine Formulierungen, fehlende Akzeptanzkriterien und das Einbeziehen technischer Details sind häufige Fehler. Zudem sollten User Stories stets aus Sicht des Nutzers und nicht aus Entwicklerperspektive geschrieben werden.
Warum sind User Stories in der agilen Entwicklung so wichtig?
User Stories erleichtern die agile Entwicklung, indem sie große Projekte in kleine, umsetzbare Einheiten zerlegen. Sie fördern die Zusammenarbeit, ermöglichen eine iterative Verbesserung und stellen sicher, dass der Fokus auf dem Mehrwert für den Nutzer liegt.
