Expanding on Brendan's post about designing for the “job to be done” rather than starting with a visual design, Alan Klement introduces us to the idea of using "Job Stories" instead of "User Stories":

Summed up, the problem with user stories is that it's too many assumptions and doesn'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.

The distinction may seem subtle at first, but it's easy to make the mistake of designing a particular interface or workflow to meet the needs of one specific “user”, when it will actually be used by different people in different roles seeking different ends. Writing a story about the job someone wants to do—rather than assuming what kind of user they are—should lead to designs that work better in the real world.

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding 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.

We've seen something like this at work in our Feature Request Forum. Users suggest features based on their own particular user stories (nothing wrong with that). But it's not until other users pile on with their own suggestions (and user stories) that the job story emerges. We've found that it often takes multiple perspectives on the problem for us to identify the job to be done.