Das Dokument behandelt die Methoden des szenario-basierten Designs, welches in der Softwareentwicklung und Mensch-Computer-Interaktion verwendet wird, um Nutzerbedürfnisse und -ziele besser zu verstehen. Es erläutert die Erstellung von Nutzerszenarien und deren strukturellen Aufbau, sowie die Abgrenzung zu User Stories und Use Cases, die als Anforderungen in der agilen Softwareentwicklung dienen. Die Dokumentation empfiehlt eine visuelle und iterative Herangehensweise zur Festlegung der internen Abläufe und Interaktionsmomente zwischen Nutzern und Produkten.

1. Szenarien
Szenarien, User Stories, Use Cases

2. Warum Szenarien, Stories?
“Before you make a movie, you
have to have a script, and
before you have a script, you
have to have a story.”
Arthur C. Clarke
Quelle: Kim Goodwin

3. Szenario-based-Design
Die Szenario basierte Designmethode wird schon lange Zeit in
verschiedenen Bereichen eingesetzt, zum Beispiel bei Mensch-Computer-
Interaktionen oder im objektorientierten Software-Engineering.
Szenarien beschreiben in einem größeren Kontext die Ausführung einer
Aufgabe. Sie beschreiben die Bedingungen, die Motivation und das Umfeld
einer bestimmten Nutzergruppe. Es wird sehr detailreich beschrieben, da der
Interaction Designer verstehen muss, was der Benutzer versucht zu tun und
was er dazu braucht.
Using Storytelling to Improve Usability and Plain Language

4. Szenarien, Nutzerszenarien erstellen
Nutzerszenarien sind dafü r da, alle Team-Beteiligten daran zu erinnern,
mit welchen Zielen und in welchem Kontext die Persona mit dem
Produkt interagiert.
Es ist wichtig, dass diese Dokumentation fü r das Team jederzeit
sichtbar und schnell nachzuvollziehen ist.

5. Szenario Dokumentation
Als Text: Oft kann eine kurze Geschichte, idealerweise
kombiniert mit Bildern, viel ü ber die die Nutzung des
Produktes erzählen.
Als Eintrag aus dem Tagebuch: Lassen Sie Ihre Persona
ihren Tag beschreiben und die Abläufe der Interaktion mit
dem Produkt notieren.
Eine Tabelle mit den einzelnen Schritten gibt einen
Überblick.
Ein Storyboard ist die ideale Form fü r ein visuell
geprägtes Team.
Lorem ipsum dolor
sit amet,
consectetuer
adipiscing elit.
Aenean commodo
ligula eget dolor.
Aenean massa. Cum
sociis natoque
penatibus et magnis
dis parturient
montes, nascetur
ridiculus mu
23.1.sociis natoque
penatibus et magnis
dis parturient montes

6. Szenarien - Aufbau
Szenarien haben alle keystory Elemente*
1. Character
2. Conflict
3. Plot
4. Resolution
* Im Gegensatz zu Use Cases & agile userstories
Quelle: http://de.slideshare.net/KimGoodwin/storytelling-by-design-scenarios-talk-at-confab-2011

7. Nutzerszenarien kreieren
1. Überlegen Sie sich verschiedene, fü r Ihre Persona typische
Aufgaben. Gehen Sie in dieser Phase bitte noch nicht tief ins Detail.
2. Entscheiden Sie sich fü r ein paar typische, aber kontrastreiche
Aufgaben (z. B. Neuentwicklung – Überarbeitung, super gelaufen – nicht
so gut etc.). Seien Sie nicht „perfektionistisch“– die Entwicklung von
Nutzerszenarien ist ein iterativer Prozess.
3. Benennen Sie alle und alles, was an diesem Prozess beteiligt ist.
4. Beschreiben Sie die Bausteine – die wichtigsten Schritte des
Prozesses.
5. Fangen Sie an, diese Schritte mit Details zu fü llen.

8. Use case - User stories
Szenario

9. Use Cases, User Story
Lorem ipsum dolor
sit amet,
consectetuer
adipiscing elit.
Aenean commodo
ligula eget dolor.
Aenean massa. Cum
sociis natoque
penatibus et magnis
dis parturient
montes, nascetur
ridiculus mu
Use Cases (Anwendungsfälle) lassen sich aus den
Nutzerszenarien ableiten. Use Cases nehmen die
Interaktionsmomente zwischen dem Nutzer und dem Produkt
ganz genau unter die Lupe.
Das Ziel ist es herauszufinden, in welchem Ablauf die Persona
einen bestimmten Prozess tätigt.
Lorem ipsum dolor
sit amet,
consectetuer
adipiscing elit.
Aenean commodo
ligula eget dolor.
Aenean massa. Cum
sociis natoque
penatibus et magnis
dis parturient
montes, nascetur
ridiculus mu
Eine User Story („Anwendererzählung“) ist eine in
Alltagssprache formulierte Software-Anforderung. Sie ist
bewusst kurz gehalten und umfasst in der Regel nicht mehr
als zwei Sätze. User Stories werden im Rahmen der Agilen
Softwareentwicklung zur Spezifikation von Anforderungen
eingesetzt. Die User Story ist die wichtigste Methode, um ein
agiles Projekt zu steuern.
Quellen: Wikipedia, Interaction design Assosiation

10. UseCases
Anwendungsfälle sollten immer im Set entwickelt werden, um die
Beziehungen zwischen den verschiedenen Anwendungsfällen und
Akteuren darzustellen.
Es ist effizienter mehrere Use Cases gleichzeitig zu schreiben,
als diese der Reihe nach aufzuschreiben. Auf diese Weise kann man
identifizieren und verstehen, welche Auswirkungen die verschiedenen
Anwendungsfälle aufeinander haben.

11. UseCases erstellen
1. Beschreibung – richtig kurz, zwei bis drei Sätze darü ber, was geschieht.
2. Akteure festlegen – Personen und Systeme.
3. Bedingungen, die erfü llt werden sollten, damit dieser Use Case auftritt.
4. Ergebniszustand – nach dem erfolgreichen Abschluss des Use Cases.
5. Standardablauf – das typische Szenario, das am häufigsten vorkommen
wird.
6. Alternative Abläufe – mögliche Verzweigungen in dem Prozess. Die
alternativen Abläufe können mit einen Misserfolg, einer Rü ckkehr zu dem
Standardablauf oder mit Erfolg abgeschlossen werden.

12. User Stories
"Als <Nutzer/Rolle>
möchte ich <Ziel/Wunsch>,
um <Nutzen>"
Nutzer steht im Zentrum
Beschreibung jedes Features aus
Sicht des Nutzers
Begründung, wofür er was braucht.
Beispiel:
Als Autor möchte ich nach dem Start der Anwendung mein zuletzt
bearbeitetes Dokument sehen, um Zeit zu sparen.
Hilfe: Wer will was warum?

13. User Stories
Titel
"Als <Nutzer/Rolle>
möchte ich <Ziel/Wunsch>,
um <Nutzen>" (Story-Punkte)
Vorraussetzung:
Akzeptanzkriterien:
Dokumentation:
Test:

14. User Stories
Log-in
"Als Nutzer möchte ich mich
anmelden können, um Zugriff auf
meine personalisierten Inhalte zu
haben." (2)
Vorraussetzung: Schnittstelle zur Datenbank
Akzeptanzkriterien: Fehlermeldung bei Falscheingabe
Dokumentation: Wireframe XY, Flowchart_login_prozess
Test: ...

15. User stories

16. User stories
30
Tage
24
Stunden
Product
Backlog
neuer
Release
Selected
Sprint
Items

17. Beispiel Backlog

18. UseCases
Use-Case-Diagramme helfen darzustellen, an welcher Stelle und zu welchem Zeitpunkt das System
oder die Anwendung, bestimmte Anforderungen erfü llen muss, um dem Nutzer sein Vorhaben zu
ermöglichen. Es hilft auch die verschiedenen Anforderungsperspektiven darzustellen.
Quelle: www.boxesandarrows.com

19. Szenarien, User Stories, Use Cases
Lorem ipsum dolor
sit amet,
consectetuer
adipiscing elit.
Aenean commodo
ligula eget dolor.
Aenean massa. Cum
sociis natoque
penatibus et magnis
dis parturient
montes, nascetur
ridiculus mu
Lorem ipsum dolor
sit amet,
consectetuer
adipiscing elit.
Aenean commodo
ligula eget dolor.
Aenean massa. Cum
sociis natoque
penatibus et magnis
dis parturient
montes, nascetur
ridiculus mu
Lorem ipsum dolor
sit amet,
consectetuer
adipiscing elit.
Aenean commodo
ligula eget dolor.
Aenean massa. Cum
sociis natoque
penatibus et magnis
dis parturient
montes, nascetur
ridiculus mu
User Stories
Ziele
Bedürfnisse
Aufgaben