Job Story

Von nanologika | 23. Januar 2026 |

Definition

Eine Job Story ist ein kompaktes Format aus dem Jobs-to-be-Done-Ansatz (JTBD), um den Kontext, die Motivation und den gewünschten Nutzen eines Nutzers präzise zu beschreiben. Im Gegensatz zu klassischen User Stories stellt die Job Story weniger die Rolle („als Nutzer“) und mehr die Situation und den Fortschritt in den Mittelpunkt, den die Person erreichen will.

Standard‑Syntax

Wenn [Situation/Kontext], möchte ich [Motivation/Absicht], damit [erwarteter Nutzen/Outcome].

Beispiel

Wenn ich in der Bahn mit schwachem Netz bin, möchte ich Artikel offline speichern, damit ich sie später ohne Unterbrechung lesen kann.
Wenn ich kurz vor einem Meeting stehe, möchte ich schnell die letzten Projektnotizen finden, damit ich vorbereitet in die Besprechung gehe.

Zweck & Nutzen

Fokussiert auf Problem, Kontext und erwünschten Fortschritt statt auf Features.
Hilft Teams, Relevanz (wann/wo/wieso) zu verstehen und bessere Lösungsansätze abzuleiten.
Ermöglicht klarere Priorisierung (welche Jobs sind häufig, wichtig, schlecht bedient?).

Abgrenzung zur User Story

User Story: „Als [Rolle] möchte ich [Funktion], um [Nutzen].“
– Gut für agile Planung/Backlog‑Items.
Job Story: „Wenn [Situation], möchte ich [Motivation], damit [Outcome].“
– Besser für Discovery, Problemverständnis und kontextbezogene Lösungen.

Best Practices

Kontext konkretisieren: Wann, wo, unter welchen Bedingungen tritt der Job auf?
Motivation messbar machen: Welche Hürde löst die Lösung? Woran erkennt man Erfolg?
Outcome statt Output: Ergebnis (Zeit gespart, Risiko reduziert) priorisieren, nicht Funktionen.
Evidenzbasiert: Auf Nutzerinterviews, Logs, Supportdaten stützen.
Segmentierung nach Jobs: Nicht nach Demografie, sondern nach Situationen und Treibern.
Varianten erfassen: Haupt‑Job, Begleit‑Jobs (z. B. „suchen“, „vergleichen“, „entscheiden“), emotional/sozial/funktional.

Typische Fehler

Zu generisch („Wenn ich online bin…“).
Lösung in die Job Story schmuggeln („…möchte ich einen grünen Button“).
Outcome schwammig („…damit es besser ist“).
Keine Häufigkeit/Schmerzstärke erhoben (führt zu Fehlpriorisierung).

Wann einsetzen?

Product Discovery: Bedürfnisse explorieren, Chancenräume definieren.
Priorisierung: Jobs nach Häufigkeit, Wichtigkeit, schlechter Bedienung bewerten.
Design & Content: Flows, Microcopy und Onboarding auf Situationen zuschneiden.
Akzeptanzkriterien ableiten: Aus dem Outcome konkrete Erfolgsmaße formulieren.

Vorlage (Template)

Wenn …(Situation/Trigger, Umfeld, Einschränkungen)…
möchte ich …(Motivation/Absicht, gewünschter Fortschritt)…
damit …(Outcome/Nutzen, wie Erfolg messbar ist)…

Optional ergänzen

Beobachtete Evidenz: Zitate, Metriken, Supporttickets.
Häufigkeit & Schmerz: z. B. täglich, hoch.
Aktuelle Workarounds: Wie lösen Nutzer es heute?
Risiken/Annahmen: Was müssen wir überprüfen?