At some point during a discussion of project deliverables, confusion will result due the similarity of scenarios: user’s stories and usage cases. Despite the similarity in name, each results in a different deliverable because each has a different intended audience. Scenarios are created by user researchers to help communicate with the design team. User stories are created by project/product managers to define the requirements prior to a sprint in agile development. Use cases are created for developers to help with testing. The difference in target audience means that the structure and information contained in the three approaches also varies.
Scenarios are stories that capture the goals, motivations, and tasks of a persona in a given context. A scenario will include pictures of the persona, the context, and anything else that contributes to the story. Scenarios are used to bring the persona to life so that designers can role play when making design decisions. An example of a scenario, minus the accompanying imagery, is shown below.
“Jim, a second year internal medicine intern at Mount Pleasant Hospital, walks into the room of his patient, Andrew Ross. Since Andrew stayed the night in the hospital, Jim needs to review Andrew’s medical records to see if the nurses on the night shift had checked in and recorded any changes in Andrew’s condition.”
Generated at the beginning of an agile sprint, user stories are brief statements regarding the requirements of the system. While the format varies on organizational/personal preferences, the traditional format for creating user stories uses the following statement; “As a <User Role>, I <<want/need>> <<goal/desire>> so that <<benefit>>.” Use of “need” versus “want” indicates if a requirement is required or a “nice to have” when building the system. An example of a user story is shown below.
As a doctor, I need to get up to medical date records so that I know how to proceed with my patients’ treatment
Use cases are a set of instructions for achieving a goal. The audience should be able to read each step in a user case and know what to do with the system and how it should respond. Use cases will also include branching logic so that steps will be skipped depending on what actions the users performs. Use cases can be represented as a flow chart. To add to the confusion, there are also usage scenarios which typically only follow one sequence of steps in the use case, and the actor is assigned a name, like in a scenario. For example of a use case is shown below.
Use case: Review Records
Doctor walks into room
Doctor sees patient in bed
Doctor identifies patient in bed
Doctor sees medical charts on foot of bed
Doctor gets medical charts from foot of bed
Doctor opens medical charts
Doctor reads medical charts
Doctor changes pages to continue reading
Doctor closes medical chart
In summary, the scenarios, user stories, and user cases are not the same thing though the people will try to use them interchangeably. While the context may help determine which of the three approaches is best (scenarios when dealing with researchers, stories in an agile environment, cases for developers), make sure everyone in a project group understands the differences to avoid confusion around deliverables.
Daniel Iaboni , is Lead User Experience Specialist at Akendi, a firm dedicated to creating intentional experiences through end-to-end experience design. To learn more about Akendi or user experience design, visit www.akendi.com.
Akendi is a product strategy, user experience design and usability research firm. We are passionate about the creation of intentional experiences – whether those involve digital products, physical products, mobile, service or bricks-and-mortar interactions. We work shoulder-to-shoulder to optimize the experiences you deliver. Akendi Corporate Overview (PDF).
Experience Thinking innovation firm in Product UX Strategy, User Experience Design & Usability Testing for Companies: Toronto, Ottawa, Montreal, Vancouver, Canada.
T: +44 (0)20 35982601
22 Highbury Grove
London, N5 2EF