The problem with User Stories as a framework to think about product is that they make too many assumptions and don’t acknowledge causality. When a task is put in the format of a user story — “As a [type of user], I want [some action], so that [outcome]” — there’s no room to ask ‘Why?’. You’re essentially locked into a particular sequence with no context.
A far better framework is what I call Job Stories, an idea from the really smart guys at intercom. Frame every design problem as a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ . For example, “when an important new customer signs up, I want to be notified, so I can start a conversation with them.”
The Job Stories framework is great because it makes you think about motivation and context, and de-emphasizes any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.
(1) As Alan Klement shows above, whenever you specify a Job To Be Done, the emphasis is on what the person is trying to achieve, not performance of a task. So it’s easy to ask “Why does the person want to achieve that outcome?”. This question frequently leads you to a better solution than the one you’re considering.
(2) Framing every product task as a Job To Be Done can be powerfully combined with Joe Natoli’s framework for clarifying what your users care about. First, ask what the user is trying to achieve with this page, interface, feature or task (= Job To Be Done); then ask what information they most care about to get that job done (= information architecture).