User Stories For User Experience

I’ve always found it interesting how a simple change in semantics can make a huge difference for a team. One area that I’ve been thinking about for a while is the structure of user stories.

In it’s basic structure, a user story follows the format of:
As who, I want what, so that why.
Most teams (at least in my experience), use the format:
As a role, I want feature, so that benefit.
An interesting assumption of this format is that we know what the feature that we will be implementing should be.

In many cases, this format neglects the tasks of taking some time and dedicating some effort to think about a suitable implementation. In some cases this might be ok (commoditized software, maintenance modifications, a thorough understanding of the solution space, et cetera). But, in cases where we are innovating or focusing on providing a differentiated user experience, this assumption can lead to a me-too product or mediocre software.

In the event that we need to think a bit about the solution, I’ve found it very useful to change the story format to be goal-oriented. My recommendation is to use a slightly different format:
As persona, I want to goal, so that value.
This is a minor modification, but it certainly changes the focus.

The goal-oriented story format encourages empathy, understanding, and exploration. When we are in a situation where we are focused on delivering an optimal experience to our users, I think that the latter format is appropriate.