There are a lot of discussions and information on the difference between scenarios and use cases, but I want to know how do they - or don't they - work together?

At a high level, the main difference between a scenario and a use case as I understand it is that the scenario does not contain any of the technology or system interactions and is solely focuses on what the user (persona) is doing.

So do scenarios and use cases both get created or is it ok to combine it into one?

I have an assumption that they can help each other in building the valuable information that goes into both, but ultimately gets used for different purposes as in:

Scenarios are used to inform design decisions and help with visualising the user's world more vividly during the design and development cycle keeping everyone focused on building the product for the user.

Use Cases are used to inform business analyst and developers on the logical steps that need to be considered during the development cycle.

Scenario from Wikipedia
...a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story. The story should be specific of the events happening that relate to the problems of the primary stakeholder group, and normally the main research questions the design process is built upon. These may turn out to be a simple story about the daily life of an individual, but small details from the events should imply details about the users, and may include emotional or physical characteristics...

Use Case from Wikipedia
...describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world.

UPDATE: Based on the answer from Aadaam I thought I need to add more detail around the question to clarify what I am looking for.

I understand there is a clear difference in a scenario vs a use case, but there are clear similarities as well. These similarities create confusion when you have a project that uses both.

In the project I am referring to there are ux designers and business analysts. The ux designers rely on scenarios to convey the user's story. The business analysts rely on the use cases to convey the overall business, user and system requirements and functionality.

So with that in mind - how and why would you use both during a project? Or is there a way that you can streamline by building the one and feeding the other?

I have my own opinion on this, but first want to keep my biases out to get an objective answer.

Some more additional information to provide clarity, special thanks to Aadaam for providing insightful answers around this topic.

This information below comes from a course that I have recently gone to about user centered analysis in the ux research field

Distinctions of Scenarios and Use Cases
and how they may fit together in an orginisation

  • Scenarios are fully user stories

    • They do not reflect the system's activities (except as experience by the user)
    • Scenarios should be technology agnostic (as much as possible)
    • For example, "Jim views his current travel plan..."
  • Use Cases tend to be equally about the user and the technology

    • For example, "Jim views the home page, logs on with his user ID and password, and the system retrieves his current travel plan..."
  • 2
    You can't have each separately: if your scenarios have nothing to do on how the system will be actually used, they're useless. If you don't detail scenarios for your use cases, your users can't reason about how they want to use the system, your devs can't imagine it, and you'll end up with a product which'll behave like there was no UX made. A scenario is a plan of a use case (a plan for a solution), a use case is a high-level categorization of goals, needs and problems, and you need both in order to succeed.
    – Aadaam
    Aug 17, 2012 at 9:01
  • I agree that you can't have them separately. But I think they are two different deliverables that can support each other, based on the definitions as taught in the UX field. So would you agree that they are to be used differently? I've added these definitions to my question.
    – Adriaan
    Aug 20, 2012 at 6:27

7 Answers 7


Doing more research around this topic I came across this article about User Stories, Use Cases and Scenarios.

The article defines the three items, but more importantly at the end of the article it sums it up quite nicely, I think.

Information below was written by Nadine Schaeffer.


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 requirement gathering phases.

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. They provide human-centered anchors to guide design and development by providing tangible faces, names and stories for how the technology will be used.

In Summary:

Use cases, stories and scenarios are not interchangeable terms–each defines a specific process and set of deliverables. That being 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.


I contacted Nadine Schaeffer, who wrote the article I refer to in this answer, around getting her opinion and thoughts about my question.

I asked if I could share her feedback here which was a response via email:

I use scenarios and use cases both for different purposes and at different stages in a project.

I like to start a project with a personas and scenarios. In my mind, these two artifacts are closely tied together. Personas create believable archetypes of user types, and scenarios tell plausible stories about what these personas do. As a user experience designer, I tend to do the writing of personas and scenarios.

Use cases, however, are less about people or personas, and more about what a product needs to allow a user to do. They are a user centric method of defining product features and requirements. Therefore, they are often written by the product manager.

Nadine Schaeffer - Principal at Cloudforest Design and a user experience consultant professional

Her answer has given me clarity and put my mind at ease around this question that has been bothering me for a while.

  • 2
    I think "scenario" is being used for two different things: the scenario at the beginning of a project like you state; and the scenario as as the solution or implementation of a use case as Aadaam states in his answer. Find unique names for them (use case scenario comes to mind for the second meaning) and make sure you use them consistently. Aug 17, 2012 at 8:57

Interesting question. I have struggled with the same feelings and now that I reflect back on it, I find that I do use scenarios and use cases intertwined with each other. Where my scenarios describe the whole story of basic (wanted) interactions with the system, the use cases describe the story in more detail.

So, a way to see scenarios and use cases working together is that they work as different levels of detail within your story telling process. When reading through the scenario you can 'zoom in' on a certain aspect by viewing the applicable use case.

The book Storytelling for UX helped me clarifying the main differences between these two methodologies. The various examples in the book provide some insightful excellent reading.

  • 1
    I've started reading the first chapter of the book, Storytelling for UX, as you suggested. So far - what a great read so far and it definitely does answer a lot of questions that has been on my mind lately. Thanks a lot for the recommendation.
    – Adriaan
    Aug 21, 2012 at 6:00

A use case is something the system is used for. That is, a use case is a placeholder for solution of a goal or a method (in GOMS terminology).

Like, if you want to make your wireframes "interactive" by bringing them into some kind of presentation tool and adding navigation to clickable areas, a use case is both of the following:

  • user creates interactive presentation out of mockups in order to present it to customers or do user research (usually shortened to user create interactive presentation)
  • user adds hotspots to a single screen mockup to enable navigation to other screen mockups (usually shortened to user add hotspots to single mockup)

As you see, one of them is a goal (when it's achieved, the task is done),the other one is a meaningful subprocess of reaching that goal, that is, it's a placeholder for a method to reach that goal.

Both of them are called use cases, and they're usually in an "includes" relationship when using UML terminology (which is "UX for software engineers").

use case UML notation

A scenario is a possible sequence of steps which satisfies a given use case. While we would like to have our requirements (use cases) to be as much free of too-early-to-tell decisions as possible, usually it's impossible to tell how a use case could be satisfied without making up some kind of story for its execution.

Example Scenario of UC1: create interactive presentation
Persona: User
Preconditions: the screen mockups are done for each key screen
Postconditions: there's a clickable interactive mockup

1. User adds a single key screen
1.1 Alternative flow: user tries to add keyscreens in batch
    Condition: [User has the keyscreens named in alphanumerical order in a directory]
    1.1.1 User selects batch upload
    1.1.2 Presents directory selection dialog
    1.1.3 User selects directory 
    1.1.4 Opens all the recognizable files in the directory, processes them 
          in alphanumerical order
    1.1.5 Continue from 1.2
1.2 User selects first keyscreen to work with

A quickly-written scenario of the above use case, based on Alistair Cockburn's style

The primary difference is, that a use case is constant: it's a representation of a functional need. A scenario might change as we get to know more about the system. The scenario merely represents an example of an imagined solution.

There are representation methods which possess less unneeded constraints on initial requirements (like, data flow diagrams have no sequence requirements), however, use case seems to be more effective.

Recommended reading: Allistair Cockburn: Writing Effective Use Cases. A classic on the topic, along with Cockburn's blog, which includes parts of it.

  • Thanks for the insightful answer that helps me understand use cases better. This doesn't answer my question in what I was looking for. I have added more information to my question for clarity.
    – Adriaan
    Aug 17, 2012 at 5:33

I disagree, the terms are somewhat interchangeable. Ivar Jacobson who invented use case modelling initially called them usage scenarios and then settled on use cases. Cockburn and Fowler who have written extensively on use case modelling do not distinguish between the terms other than to indicate that use cases are made up of main scenarios and alternative scenarios.

  • Can you provide the links to your references?
    – rk.
    May 27, 2013 at 14:38

I use a "Scenario" when gathering behaviours and trying to give stakeholders and empathetic understanding of how a product or service will concretely be used.

I use a "Use Case" or more commonly "User Story" when analysing and extracting core of UX behind the research detail and also in marshalling a design through the development process.

So yes, they do combine. Especially if you don'y have a convincing scenario for a use case, the don't build it.


I think the issue here goes beyond simple definitions and arguing about terminology. UML components are wholesome artifacts that must be planned, analyzed, designed, developed and implemented using specific strategies, methods and tools.

Deconstructing a use case I normally start by developing a narrative of not only user requirements but also all actors involved in a given scenario. I also pay close attention to the underlying relationships, flow and sequence of events, boundaries, constraints, pre and post and anti-conditions, exception conditions handling, etc.

Developing a use case description Out of the narrative I begin populating a formal use case description with a set of fields pertaining to the above criteria. The use case description provides me with the much needed ontology to better understand the use case I am working with as well as all internal and external elements playing a role in and out of it. It is the use case description that determines the required number of use case scenarios that I will need to develop. Each scenario may spawn one or more use case diagrams.

Use case scenario As the name suggests, a scenario depicts a particular situation that is part of the overall story we are trying to tell with a higher level of abstraction at the use case development phase. At this stage it would be best to develop the scenario in terms of quasi or pseudo code, or simply an ordered list describing the scenario step by step. It is not a far-fetched possibility for one use case description to spawn many use case scenarios.

Use case diagram Now that we have developed all of the possible scenarios based on the use case description, producing use case diagrams is a much easier task to achieve. However, it may be necessary to maintain some level of abstraction initially so to focus on the main actors and use case activities as well as system boundary(ies) and relationships. It would then be a matter of filling in the blanks with typifying the relationships (generalization, include and extend) when more details become available.

Reconstructing the use case When we started with a use case narrative (story) and ended up deconstructing (decomposing) it with all of the necessary descriptions, scenarios and diagrams it would be incumbent now to actually reconstruct or recompose the use case by packaging all of its elements and encapsulating and presenting it as one cohesive package. The package could be tagged with a unique identifier and added to the system dictionary or whatever repository you are using to house your UML components.


I use scenario to determine the objective. Like - "Visitor Books an appointment."

Use case include the interaction - "Visitor reviews his details, and provides the payment information. System validated the payment information and responds with BookingId which customer can use to check his Booking status. System sends a confirmation SMS to the visitor."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.