Viewing posts from the Definitions category

User Stories, Scenarios & Use Cases

What’s the difference? Are they the same? Why do I even care?


When designing and developing software and sites, I hear these three terms – user stories, scenarios and use cases –  employed all the time, often interchangeably. While I am not intending to issue a didactic nomenclature smack-down (how tedious!), some definition and clarity can’t hurt. Most importantly, when people are working together on a project team and trying to create and agree to any of these three kinds of deliverables, consensus goes a long way.

In general, all three terms represent ways that application teams try to define and understand what the app will do from the user perspective. User stories, scenarios and use cases can therefore be understood as framing devices; they provide mechanisms to understand and plan technology development around the end user, instead of focusing development and product features around the constraints of the business, the platform or the underlying development languages and libraries.

The exact purpose and audience for each term varies. Scenarios are generally used by user research people to communicate with design teams. User stories are written largely by project/product managers as part of definition and requirements documentation . The audience for use cases  is primarily developers who need to write test cases and need to understand if their data objects are handling the appropriate i/o, errors, and exceptions.

Now let’s examine all three terms and associated deliverables as well as processes more in depth.


Let’s start with scenarios. They are usually tied to personas and are part of creating a story about who the user of a particular technology is, what they want, what they know. A  scenario is therefore usually written in narrative form, perhaps with pictures and illustrations as well. Scenarios are generally written at the beginning of a project during discovery and requirements gathering phases. They provide human-centered anchors to guide design and development by providing tangible faces, names and stories for how technology will be used.

A common generic format for scenarios goes something like this:

User Stories

Now what about user stories? User stories are generally used by Agile development teams. They are meant to replace long complex documentation with short sentences that capture the essence of a user need. They are intentionally short and granular – each story captures just one task or action. User stories are defined during development before or at the beginning of each sprint.

User stories are generally written in this kind of syntax:

Use Cases

Finally, let’s describe use cases. Use cases are generally written as part of detailed product requirement documentation. They capture the goal of an action, the trigger event that starts a process, and then describe each step of the process including inputs, outputs, errors and exceptions. Use cases are often written in the form of an actor or user performing an action followed by the expected system response and alternative outcomes.

Use cases tend to employ this kind of format and content:

Still confused? Maybe a more tangible real-life example will help ….


Josh is a 30 something mid-level manager for an ad agency, metro-sexual and beer aficionado. He likes to try new and exotic beers in trendy locations. He also enjoys using a variety of social apps on his smart phone. He reads a review  on Yelp of a new burger & beer joint downtown with over 100 beers on tap, and decides to go walk over after work and check it out.

User Story:

A user must wants to find a bar, drink a beer.

Use Case:

Customer walks to the restaurant
Customer enters the restaurant
Customer finds a seat at the bar
Customer scans the menu
Customer selects a beer
Customer orders selected beer
Bartender takes order
Bartender pours beer
Bartender delivers beer
User drinks beer
User pays for beer

In Summary

Use cases, stories and scenarios are not interchangeable terms – each defines a specific process and set of deliverables. That said, there are no hard and fast rules. It makes sense to review the needs of your project, what stage of development you are in,  the skills and familiarity levels of the team, and then choose the user and task definition process that will work best for you.

Links & More Info

This is a good example of a well written user scenario
is often over-looked in user scenarios, but not in this excellent example
This pdf includes more definition for user scenarios as well as an example
Here is Wikipedia’s take on scenarios

Here is a good summation article about user stories
Good examples and instructions for writing great user stories
You can buy a whole book about writing great user stories
of course has an overview page as well about user stories
How to write user stories using cards

Wikipedia has a good definition of use cases
And here is a good example of a use case about using an ATM
A good article on forming good use cases
Another longer article on writing use cases (with stick figures!)
A travel related set of use cases
A very usable template for use cases

Do you disagree with my definitions? Have more clarification or obfuscation to add? Please comment below or send me email!

Low-Fidelity vs High-Fidelity Wireframes

Wireframes are a basic part of the application or site design process. They allow the interaction designer to quickly sketch out screen layouts without delving into the niceties of visual design. Wireframes are generally considered blueprints – they define structure, size and layout without proscribing any decorative details such as colors and fonts.

However, all wireframes are not the same. In fact, the variety of types of wireframes is almost as varied as the number of designers making them. There is no fixed recipe for successful wireframing, but generally a distinction is made between low-fidelity and high-fidelity wireframe diagrams.

Low Fidelity Wireframes – A Minimalist Start

Low Fidelity wireframes are generally a very simple place to start design. They attempt to define navigation, framework and basic structure. They are often produced in tools like Balsamiq for an intentionally hand-drawn and informal look. Low fidelity wireframes are useful for starting conversations, deciding very basic functionality as well as navigation layout. These simple sketches are NOT as useful for showing actual interactions, the weighting of elements on a page or paper prototype testing.

Here are some examples of low-fidelity Balsamiq wireframes:

Example 1: A wiki
Example 2: An iPhone app
Example 3: A video player

High Fidelity Wireframes – Designing for the Details

High-Fidelity wireframes fill in the details missing in their simpler predecessors. They define the weighting and visual hierarchy of the page, actual form and interaction elements, and often labels, instructional text and some copy. They can be used in sequence to show how a specific task can be accomplished in a sequence of screens. High fidelity wireframes should always aspire to defining all product and interaction details. They should provide a clear enough visualization of an application or site to allow developers and the engineering team to begin their work.

High-fidelity wireframes are usually drawn in tools such as OmniGraffle (Mac), Visio (Windows) or Adobe Illustrator.

Here are a few examples of high-fidelity wireframes:

Example 1: an enterprise application
Example 2 : a video service
Example 3: an online newspaper