User scenarios, user stories, use cases — what’s the difference?

The three are different, but not as much as you may think. Let’s talk about stories.

No, not user stories… stories. We are wired to engage with and tell stories — it is a seminal part of the human species. It is the way we transferred knowledge before the written word, it is the reason why we have words — we need the words to tell the stories. Stories help us understand things, helps us learn and grow — stories nourish us as much as food and water does.

Stories are very effective things.

The three type of stories that are being discussed — user stories, scenarios, and use cases — all are different conceits that help communicate what a solution that is being created needed to do. The differences are in structure and perspective.

User stories are from the perspective of the end user, and very simple in structure:
As a (user type) I want to (action/feature) so that (reason)
As a (user type) I want to (action/feature) because (reason)

Example: As a runner I want to track the miles I run each day so that I can have a good understanding of how much I have exercised.

They also contain details that indicate what should happen, driven by context and other situations:
If (context) and (additional context) when (event) then (outcome)

Example: If I stop running and I stop for more than ten minutes, then the record of my run needs to be saved as a new run record.

User stories are used in the agile development process to scope features. They allow developers to focus on what the user has to do. The best user stories are grounded by user research and understanding — they aren’t “made up” and actually reflect what users have to do.

The next level of detail, the next “format” these stories can take in a design/development project are user scenarios. These are much more detailed and include details such as user’s motivation and environment. As opposed to the simple narrative of above, these are often presented in storyboards and as “blueprints” with a lot of details and texture that may often be superfluous.

User scenarios paint a picture that is more complete, but they are often viewed as superfluous on projects that have an aggressive schedule. When to use scenarios depends on the project and the needs of the project.

Finally, use cases are structured documents that contain requirements and details of what functionality should exist. Use cases are (usually) extremely entailed and detail both user behavior and system response. They are less about user needs and mental models and more prescriptive direction as to what needs to be developed. As these documents usually take some time to create, they have fallen out of favor with many companies who have adopted agile development processes.

So, the difference between the three type of stories? It’s all about approach, the author, and what detail is needed. For user experience practitioners, user stories and scenarios are the way most use to convey design direction and context. For business analysts, use cases is the known and used format. The line is getting blurred though — many business analysts are moving into UX these day. They key is to use the right tool for the right job, and to not overthink or over document.

After all, companies don’t ship design documents… they ship products and services produced from such documentation.