User Story oder Job Story

Neue Prozesse im Produkt Design

User Story oder Job Story User Story oder Job Story? (Bild: Daniel Lee via Flickr)

Bevor man die Frage User Story oder Job Story beantworten kann, sollte man erst über das Problem mit User Stories nachdenken. In Replacing The User Story With The Job Story. Too many assumptions are dangerous. schreibt Alan Klement:

The problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality.

User Story oder Job Story? Wenn eine Aufgabe als User Story verpackt ist, gibt es keine Möglichkeit zu fragen Warum ist die Story so wie sie ist? Man hat einfach überhaupt keinen Kontext. Beispiel aus der Wikipedia zu User Stories:

Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.

Warum ist das so? Hat jemand tatsächlich mit einem Autor gesprochen? Will der Autor immer das letzte Dokument sehen oder nur ab und zu, wenn er an einem Buch schreibt?

User Stories schreibt man meistens in folgendem, populären Format: Als <NUTZER> möchte ich <AKTION>, um <GEWÜNSCHTES ERGEBNIS>. Das Format wird sehr viel genutzt. Eigentlich immer, wenn man nach Scrum arbeitet. Und wer tut das heutzutage nicht?

Das User Story Format ist aber sehr oft nicht mehr als eben nur ein Format. Ohne Wert oder Belang. Es ist quasi eine überlieferte Redensart und wird von Mitarbeiter zu Mitarbeiter tradiert. Ungefähr so wie man zur Begrüßung Grüß Gott! sagt. Natürlich geht niemand los und grüßt daraufhin irgendwelche übernatürlichen Kräfte oder so.

User Story oder Job Story: als Nutzer möchte ich…

Als Nutzer möchte ich…, wenn ich das höre denke ich sofort ach ja? Sagt wer?

  • Als Taxifahrer möchte ich eine Uhrzeit angezeigt bekommen, um immer zu wissen wie spät es ist.
  • Als Powerseller möchte ich eine SMS erhalten wenn ich was verkauft habe, um immer bescheid zu wissen.
  • Als Smartphone-Nutzer möchte ich mir meine Merkliste per E-Mail zusenden können, um für Notfälle ein Backup zu haben.

Die Erwähnung eines potentiellen Nutzers macht eine User Story scheinbar glaubwürdig. Noch besser funktioniert das, wenn man eine der Personas einsetzt die man sich zusammengewürfelt hat. Schließlich haben sich doch alle in der Agentur oder auf Kundenseite auf diese Persona committed. Und wenn sich unsere Persona plötzlich etwas ganz, ganz doll wünscht—na, wer wird es ihr da abschlagen wollen?

User Story oder Job Story

Eine User Story sagt meistens nichts über den Kontext und die Motivation einer Handlungsabsicht. Dafür nennt sie aber oft völlig generische oder beliebige Darsteller welche diese Aktion ausführen möchten. Und: eine User Story konzentriert sich oft auf das Was und lässt das wesentlich wichtigere Warum außer acht.

Das versucht die Job Story besser zu machen. Eine Job Story ist wie folgt aufgebaut: <SITUATION> + <MÖGLICHER ABLAUF> + <ERGEBNIS>

  1. Situation: am Anfang der Job Story wird die Situation beschrieben in welcher ein Problem gelöst werden soll. Hier geht es um Motivation und positive oder negative Kräfte die einwirken.
  2. Ablauf: eine mögliche Option um sich aus der beschriebenen Situation dem Ergebnis entgegen zu bewegen.
  3. Ergebnis: Der Ausweg aus der beschriebenen Situation.

Job Stories

Job Stories versuchen den Leser dazu zu bewegen über Motivation und Kontext nachzudenken und vermeiden es eine exakte Problemlösung vorwegzunehmen. Indem man über das Warum nachdenkt, hat man mehr Spielraum unterschiedliche Lösungen vorzuschlagen und natürlich letztendlich das bestmögliche Ergebnis zu finden.

Nur wenn man sich mit dem Warum befasst hat man die Gelegenheit Probleme zu verstehen und nach passenden Lösungen zu suchen. Gleich mit dem Was zu beginnen und eine Problemlösung ohne Problemverständnis voranzutreiben führt unweigerlich zu einem minderwertigen Produkt.

Ein paar Tipps, wie man gute Job Stories geschrieben bekommt:

  • Job Stories basieren auf echten Gesprächen mit Kunden oder Anwendern.
  • Beschreibe so knapp wie möglich aber so umfangreich wie nötig Kontext und Situation.
  • Wenn man Motivation um wirkende Kräfte ergänzt, bekommt man weiteren, wertvollen Input.

Kräfte und Motivation

Motivation kann zum Beispiel funktional, sozial oder emotional sein. Das ist relativ einfach zu verstehen. Die Sache mit den Kräften ist etwas komplexer: hierbei geht es um das aus JTBD (Jobs-to-be-done) bekannte Wechselverhalten (switching).

Wenn Kunden von einem Produkt zu einem anderen Produkt wechseln wollen, wirken positive und negative Kräfte auf sie ein. Positive Kräfte schubsen sie aus der altuellen Situation zu einer neuen Lösung. Die Attraktivität der neuen Lösung kann auch magnetisch als Anziehungskraft wirken. Auch das ist eine positive Kraft.

Negative Kräfte sind die Angst vor Neuem und die notwendige Energie die aktuelle bequeme und vertraute Situation zu verlassen.

Kräfte und Motivation sind stark situationsabhängig. Daher empfielt es sich bei der Job Story mit der Situationsbeschreibung zu beginnen. Situation, Motivation und Kontext bilden die Basis für innovatives, kreatives und effektives Produkt Design.

About Jan (500 Articles)
Informationsarchitekt und Konferenz-Veranstalter (IA Konferenz, die Konzepter-Konferenz: http://iakonferenz.org, MOBX Mobile UX Konferenz: http://mobxcon.com), Podcaster und Twitter Addict. Geboren in Prag, sesshaft in Berlin.

2 Comments on User Story oder Job Story

  1. Wenn man irgendwann mal z. B. Indi Youngs kaum genug zu empfehlendes «Mental Models» gelesen hat, kommt einem JTBD allerdings nicht gerade neu vor. Das Denken bzw. Konzipieren und Gestalten aus dem Motivations- und Handlungskontext heraus jetzt als große Neuheit zu verkaufen, hat schon einiges an Chuzpe seitens Interkomm >;->

    • Hallo Sascha,

      ja das stimmt 🙂 Das Mental Models Buch ist wirklich lesenswert. Was mich immer etwas irritiert hat ist, dass Indi Young den alten Begriff des Mental Models nimmt und für ihre eigenen Zwecke umdefiniert. Ich glaube daher spricht man heute oft von Mental Model (das “Bild” im Kopf eines Kunden) und Mental Model Diagramm (das Thema von Indi’s Buch).

      Was JTBD betrifft, so glaube ich dass wir gerade eine Mini-Renaissance der Idee erleben (gerade im UX Bereich). JTBD wird so um 2002/2003 bereits in Artikeln und Büchern erwähnt. Z. B. http://www.forbes.com/forbes/2003/1013/082.html

      Das Buch von Indi stammt von 2008.

      Ich sehe die Beziehung zwischen beiden so: das eine ist eine Research Methode (JTBD) und das andere eine Form der Visualisierung (Mental Model Diagramm). Aber lass uns da unbedingt mal drüber plaudern. Mich interessiert Deine Meinung sehr.

2 Trackbacks & Pingbacks

  1. Aufgaben im Usability-Test - DESIGNBRIEF
  2. Jobs-to-be-done Outcome Expectations - DESIGNBRIEF

Leave a comment

Your email address will not be published.


*


css.php