Stakeholders use the terms ‘User Stories’, ‘Scenarios’, and ‘Use Cases’ often, and usually interchangeably. What are these things and are they the same or different? Well – they are different, and below we’ll go through what they are and when to use them.
Why are we discussing this?
The next step in our User Centric Design for developers series after knowing your users is understanding what these users want from your product, or in other words, what it is that you need to deliver. User stories, scenarios, and use cases are all methods of describing user needs. Any of these can be used by the product team to help define the product in a user-centric manner. Sometimes one method is more useful than another method, or sometimes you might want to walk through each of these methods incrementally as you learn more and want to capture more detail.
User Stories
User stories are usually a great place to start. They are quick and easy to capture even through a simple brainstorming session, and they force you to keep ideas user-centric since each feature must have a target user and reason associated with it. User stories are best known as being associated with Agile development, but can be used with any development methodology as it is just a framework to capture requirements and user needs in.
As a <user type/persona>, I want <feature> so <reason>.
As a human resource recruiter, I need to record a prospective recruit’s information, contact date, and action items so I can keep track of who I have talked to recently.
User stories are a minimum requirement for project teams to have in my opinion. Scenarios and Use Cases are more granular than these, and can be used instead.
As a developer, if you are not getting at least user stories – FIGHT BACK!
Demand that you get this level of detail from your product owners. User stories don’t only tell you what you need to build – they also explain WHY you need to build it and for WHOM you are building it! This is critical to building a usable, desirable system if you are not in close contact with your users only a daily basis.
Scenarios
Scenarios are narrative descriptions of how a particular persona interacts with a system within the context of their larger environment. Scenarios should elicit emotion when reading them, making us feel empathy for what the user is trying to accomplish. They typically read like a fictional story, giving readers an idea of all of the surrounding environmental factors that affect a user’s usage of the product.
Scenarios are effective at making the team think about and research the environmental factors and context that a user will be in when using the product. This can greatly change how you go about implementing a solution. For instance, if someone typically needs to access your product when they are riding public transit in the mornings rather than once they get to the office, maybe your solution need to focus on easy, mobile controls to work with rather than a complex web application they can only access from their laptop.
Scenario: Record prospect recruits information
Sarah is on her way into work after a morning doctor’s appointment, and the bus system is taking longer than usual. Yesterday she had reached out to several new prospects for a VP job she is responsible for filling. She had to leave a voice mail for two of them. On her way into work, her phone rings and it is Kevin, the top-most prospect she thinks fits the job at this point. She talks with Kevin about the position for 10 minutes, and Kevin decides he is willing to move forward with a phone interview with the CTO. Sarah tells Kevin that as soon as she gets into the office, she will set up the phone interview and send him some further information about the position. Sarah hangs up and decides she wants to get the information about this call into the system as soon as possible, because she has a lot of other candidates that might call back and she could mix up with Kevin’s needs. She uses her Android phone to open Kevin’s file and record the call notes and action items she committed to.
Use Cases
Use cases capture further detail of the interaction between the user and the system. In a systematic way, it captures the steps required from the user and from the system to complete a goal, and any alternative paths that might also exist for this goal. Use cases are typically more granular and systematic than scenarios, and you are likely to get many use cases out of one scenario.
Use Case: Record prospect recruits information
Brief Description: As a human resource recruiter, I need to record a prospective recruit’s information, contact date, and action items so I can keep track of who I have talked to recently.
Actor: Sarah, recruiter
Main Success Path
1. Open software and sign in
2. Navigate to recruit’s list
3. Search for and select Kevin
4. Create new recruit contact note
5. Contact note captures current time and date, can be modified to an earlier time and date.
5. Record call information & action items
7. Save contact note
Alternatives
1. Open software and sign in
2. Find Kevin on dashboard in recent recruit list
3. Create new recruit contact note
4. Record call information & action items
5. Save contact note
Related information
Recruit contact notes will have some pre-filled fields upon entry that can be modified if needed.
With these three tools, the product team can come to a combined understanding of what your user needs from your product, and what driving environmental factors might influence your product design.
In our next step of the series, we’ll talk about moving into the design phase to mock up your solution now that you have an understanding of the requirements and needs of the users.