Photo by Macau Photo Agency on Unsplash
The terms ‘scenario’ and ‘user stories’ are often used interchangeably, but are they essentially the same or are there differences? and if there are, when is it better to use a scenario and when is a user story more appropriate?
The reason for the ambiguity is understandable as there are many similarities between the two, for instance they both:
are driven by and focus on the user and their perspective
help to describe or formalise a user’s engagement with a new or future product or service
are used to gain a better understanding of a user’s needs and requirements
serve as an anchor for designers and development teams to align goals, focus discussions and evaluate against
are based (ideally) upon actual user data and evidence of use
benefit from having an associated user persona
help to inform the formulation of user-requirements and functional specifications
So how are they different? They differ primarily in the level of detail, supporting context and application within the design and development process. Scenarios, for example typically comprise a highly descriptive narrative detailing a user’s engagement with a product or service within a particular context, whereas user stories tend to be brief, formulaic listings capturing specific activities and goals required for a user to achieve a particular outcome. In addition, whilst scenarios often evolve throughout a development process they offer a unitary reference point, whereas user stories are traditionally ‘worked through’ one by one, as part of an agile approach to product development.
Want to learn more? Watch our webinar "DIY Design Research for new product and services"
What are scenarios?
A scenario uses a story-based format or narrative to explore the future use of a product or service from a user’s perspective. They are typically developed in conjunction with a persona, both reinforcing each other, with a single persona often having several associated scenarios, each reflecting different contexts and situations of use. In addition to describing any typical or ‘representative’ situations of use, scenarios are also valuable for exploring and presenting other atypical situations or ‘extremes’ of use.
As with personas a scenario should be based upon actual user data and real insights, gathered either directly from interviews or focus groups with target users, or alternatively from internet based research e.g. online videos, discussion forums or desk-based research. Grounding scenarios in evidence avoids them becoming merely ‘speculative stories’, based upon how the development team assume, imagine (or hope) a product or service might be used. It also helps to avoid any tendency to focus on technical requirements, centring instead on practical, meaningful expressions of use.
Format: Scenario
Scenarios can take different formats but typically begin with a description of a key situation or envisioned task or activity that the user is required to address or complete. They are contextually rich, detailing times, places and other key actors, in addition to users’ intentions/motivations, their circ*mstances, ongoing considerations and decision making as they engage with a particular product or service.
For example: Samantha is a University student who has her final exams in 3 weeks. However, she often struggles to manage her time between studying and her other University activities, including running the University’s climbing group which is important to her. She needs to find a platform or app that helps her to manage her time between academic work and other commitments, which she can access on the go - giving her timely updates and clear reminders, so she can reach her goal of passing her exams whilst also continuing to support the group.
Some scenarios may be directly inspired by the account of an individual user or interviewee, or alternatively they may be a composite from a diversity of more generalised descriptions or insights. Either way, it is important that scenarios purposefully include a range of potential difficulties and challenges, in order that key issues can be addressed.
Scenarios can be applied throughout the design and development process and are often used to inform a variety of other research methods and techniques, from highly visual storyboards, through to more formalised use cases and functional specifications. They are also often used as the basis for user journeys.
What are user stories?
User stories are used as a tool to capture the specific functionality of a product or service, giving an insight to the development team of not only what they are building, but why and the value it creates for a variety of users. They are also used to encourage the development team to collaboratively discuss (rather than simply write about) the desired functionality of products or services, through a series of structured conversations. They are typically written as single sentences on cards or sticky notes, so that they can be quickly and flexibly worked with by the team or other stakeholders. The language used is deliberately simple and concise, avoiding technical or ambiguous terminology and presenting the voice of the user.
User stories are typically applied using the ‘3 C’s’ which include:
1) Card - stories written on a card or sticky
2) Conversation - promotes incremental and continuous collaboration
3) Confirmation – forms the acceptance criteria against which a user story can be considered as ‘done’
Format: User stories
User stories usually have the same basic format:
As a <type of user or persona>, I want <some goal/objective> so that <some reason/benefit>
‘As a’ - focuses on who the product or service is being developed for, ideally this will be based upon an established persona
‘Wants to’ – focuses on what the user is trying to achieve, their desire and intent
‘So that’ – focuses on the desired result and benefit of what they are trying to achieve
For example:As a credit card holder, I want to view my statement balance, so I can pay the balance due.
User stories can be written at varying levels of detail and can incorporate increasing amounts of functionality, however these larger stories are generally known as ‘epics’. Part of the Agile development process is to break these epics down into individual, manageable stories, that can be prioritised and actioned systematically within a concise timeframe.
Whilst this outlines the basic method, there are increasingly a number of derivations such as ‘job stories’. These serve to shift the emphasis from the user to the actual job to be done and work well if you only have one audience:
When <the situation>, I want to <motivation> so I can <expected outcome>
For example:
When it's dinner time tonight, I want to order a pizza so I can easily feed my friends.
So, which should I use?
Whilst there are many overlaps between scenarios and user stories, if you need to develop a contextually rich description of a user’s engagement with a product or service, particularly in conjunction with a persona and as a single point of reference, then a scenario would be preferable. Alternatively, if you need to capture/focus on the component tasks and activities a user wants to engage in to achieve a particular outcome in a structured yet succinct way, a user story would be recommended.
The next step in creating user stories and scenarios is to create a user journey, which details the steps a user takes as they progress through a particular task or process. Read a guide from our CRO Michael Brown onhow to create a user journey.
We regularly run free webinars exploring various research skills, all of which are available on our YouTube channel. If you'd like to be informed about our future webinars and other free resources, sign up for our quarterly newsletter.
If you'd like to talk about a project you're working on, get in touch.
