A Story about Job Stories and User Stories

Online Marketing

 /  K. Mittelberger
Job Story & User Story Image

Immer dann, wenn Sie sich Gedanken über die Anwendungsbereiche und -fälle eines Produktes machen müssen, versetzen Sie sich in die Lage der Zielgruppe, auf die das Produkt zugeschnitten ist. Sei es bei der Konzeption eines neuen Haushaltsgerätes, der Entwicklung einer Softwarelösung oder auch in einem Dienstleistungsbetrieb: Der Fokus auf Kundenorientierung ist branchenübergreifend.

Hierfür bedient sich die alte Schule der IT-Branche der Methode der “User Stories”. Mittels dieser überlegt man sich Anwendungsfälle, die von gewissen Benutzern zum Erreichen eines konkreten Zieles durchgeführt werden.

Doch diese Methode ist nicht naht- und lückenlos. Denn bei User Stories wird versucht, sich in die Lage eines Anwenders zu versetzen, ohne empirisch fundierte Daten über dessen tatsächlichen Wünsche und Ziele zu berücksichtigen. So entstehen rasch Annahmen.

Sehen wir uns dies an einem Beispiel an

Als Betreiber eines Webshops würden Sie für das Hinzufügen eines Produktes zum Warenkorb wohl folgende User Story definieren:

“Als Besucher eines Webshops möchte ich Produkte in den Warenkorb legen um dieses im Anschluss kaufen zu können.”

Nun, welche Annahmen stecken also in dieser Aussage?

  • Sie gehen davon aus, dass jeder der Besucher Ihres Webshops auch zumindest ein Produkt in den Warenkorb legen will.
  • Sie nehmen weiters an, dass diese dann auch automatisch erworben werden.
  • Ebenfalls schließen Sie, sollten Sie noch andere Benutzergruppen, beispielsweise “Angemeldete Kunden”, haben, diese durch die Verwendung des Wortes “Besucher” aus diesem Anwendungsfall aus.

Dieser Problematik haben auch schon einige kluge Köpfe einhalt geboten. Mehr und mehr ersetzen Job Stories (oder auch “Jobs to be done” (= JTBD) die altbekannten User Stories.

Bei Job Stories konzentrieren Sie sich nicht mehr auf eine konkrete Person bzw. Benutzergruppe, von der Sie glauben, sie wolle etwas durchführen, sondern auf die gegebene Situation selbst. Damit reduzieren Sie Verallgemeinerungen bezüglich einzelner Benutzergruppen und stärken gleichzeitig den jeweiligen Anwendungsfall. Job Stories sind meist nach dem Schema “Situation, Motivation und Erwartung” aufgebaut.

What is Jobs to be Done

Eine passende Job Story zu ersterem Beispiel würde also lauten:

“Wenn ich an einem Produkt Interesse habe, möchte ich es dem Warenkorb hinzufügen, damit ich dieses später erwerben kann”

Um zu entscheiden, ob Sie User- oder Job Stories für Ihre Zwecke heranziehen sollten, müssen Sie sich überlegen, was für Sie und Ihr Produkt wirklich von Relevanz ist.

Wie wichtig ist es für Sie zu wissen, WER etwas durchführen könnte? Wäre es nicht effizienter zu definieren, WANN etwas überhaupt in Betracht gezogen bzw. relevant werden kann?

Sagt Ihnen Letzteres eher zu, so werden Sie mit Job Stories einen starken Verbündeten gefunden haben. Dennoch liegt die Wahrheit wie so oft irgendwo dazwischen - keine dieser Methoden wird perfekt auf Sie zugeschnitten sein und es macht auch keinen Sinn ihre Anforderungen durch diese Methoden zu beschränken - dafür sind diese ja gerade nicht entwickelt worden. Am kundenorientiertesten arbeiten Sie dann, wenn Sie sich ihrer Möglichkeiten bewusst sind und aus beiden Ansätzen das für Sie persönlich Beste herausnehmen.

User Story/User Story- Illustration

Kurz und kompakt:

  • Job Stories sind eine Alternative zu klassischen User Stories, die im Gegensatz zu Letzteren den Fokus auf die Situation anstelle des durchführenden Benutzers legen.
  • Nichts ist in Stein gemeißelt - adaptieren Sie die Methoden zu ihren Gunsten.
  • Verwenden Sie Job Stories immer dann, wenn das, was durchgeführt wird, bedeutender ist, als die durchführende Person.

Buchempfehlung und weiterführende Quellen für Interessierte:

 
Artikel zum Thema: uxdesign.cc

Zurück