How to use Scenarios

How to use
Scenarios
Peter Zalman | Based on Cooper

Content
o Introduction to Scenarios
o Creating Scenarios
o Using Scenarios
o Scenario Examples
o Resources

Introduction to
Scenarios
Define what the product will do before you design
how the product will do it.

Goal Directed Design process
Create
Problem and
Vision Statements
Explore and
Brainstorm
Identify Persona
Expectations
Construct
Context
Scenarios
Identify
Design
Requirements
Scenarios are only one aspect of the overall Goal Directed design process pioneered by Alan Cooper.
They are closely related to the concept of Personas and often referred as Persona-based scenarios.

Personas are not market segments
Market segments Pool of interviewees
Personas derives
From behavior patterns
• Buyer
• User
• App Owner
• Operations
• Developers
• Production Support Analyst
• Production Performance Engineer
• Tools Architect
• System Administrator
• Software Architect
• Pete
• Kyle
• Ryan

The Persona creation process
Group interview subjects by role
Identify behavioral variables
Map interview subjects to
behavioral variables
Identify significant behavior patterns
Synthesize characteristics
And define goals
What if there is no extensive ethnographic research available to drive the Persona definition?
Should I create Personas on my own based on team’s current knowledge?

Ineffective Approaches to Design
Talk to some customers or users,
take notes about their complaints,
and then brainstorm features
from there.
Focus energy on screen layouts
and details using requirement
documents and agile user stories
and use cases.
Generate feature lists directly
from persona profiles.

What is missing?
Context causes you to think about users needs in a
deeper way. You must consider what else is
happening, what they are thinking and feeling, and
the challenges they’ll face.
PERSONA
User’s goals, mental models,
and behavioral patterns.
CONTEXT
The world in which the persona
is living—their setting and situation.

Design starts with a story
A scenario is a design tool.
It tells the story of how your product will be used in
the future. It is guided by persona needs and goals
rather than by system features and capabilities.
The scenario’s context helps elicit and prioritize
requirements.

Stories help us to
o Keep sight of the real world context that
informs usage behaviors, patterns, and goals.
o Avoid disembodied feature lists that are hard
to prioritize.
o Maintain continuity of the experience.
o Help us view the big picture and not spend too
much time on tiny details.
o Imagine what the experience should be like,
without worrying about how to achieve it.

The product vision defines the requirements.
Describing users’ ideal experience using the product to
achieve their goals defines the requirements to deliver that
experience.
Imagine users’ ideal experience using the product to
achieve their goals. When you tell that story, you’re
describing the experience the design must deliver.
The stories you tell form the product vision.

What makes a good story
Original life condition
Your persona’s:
o Challenges
o Goals and desired outcomes
o Needs
Transformation
A sequence of events that
explains how your product
helps your persona achieve
their goals or overcome their
Challenges.
Enhanced future
Your persona’s goals,
challenges, or needs are
successfully met.

Creating Scenarios
to tell the story of how your product will be used.

Creating Scenarios
1.Define a Title
Think about what situations your persona is likely to
face, and include challenges that will help to push
the design.
2.Identify story elements
3.Write a scenario story

Identify Story elements
Make a list of elements that could make a believable, relevant story of how your
product ideally supports your persona in achieving his / her goals.
Do not assemble them into a story narrative yet.
• Context | Time, setting, etc.
Just received an incident ticket. Need to upgrade to a major version. Received a call from L1 about outage.
• Plot | Challenges, goals, actions needed to achieve goals
Sending an evidence of the issue to L2. Upgrading to a major version. Diagnosing a configuration issue.
• Touch-points with your product
Change a configuration value. Comparing the metric value in last 2 weeks time-window.
• Expected outcome
Environment runs the latest product version. Issue is solved and service is restored back to normal.

Write a story
• Use the See | Think | Do model to describe what happens step by step.
• Describe the experience, not interface details.
• Focus on what happens and avoid adding detail of how it happens.
• If it’s not a good story, try providing more detail. Iterate.
• Number each step; this will help when you later draw Wireframes that illustrate
each step.

Red flags
The scenario is actually a catalog of functions.
“And then if you click on this tab …”
The scenario includes extraneous functions.
Detours into stuff that the user “might” want to do.
The scenario doesn’t make sense, or isn’t believable.
The user takes actions that don’t support his/her goals.
This suggests that the story is describing what someone else WANTS the user to do, not
what they likely WOULD do.
Unrealistic assumptions about the cognitive perception.
”And then he sees an symbol and he thinks that MongoDB is connected on port 8888.”
The scenario lacks aspirational qualities.
Describes what is happening today in more detail.

Using Scenarios
to define requirements.

Using Scenarios
1. Identify and assign needs
2. Design Framework
3. Jobs to be Done
4. Use Cases
5. Product increment evaluation

Identifying and assign needs
1. Functional needs
What people need to do – Actions.
1. Andrew opens the Agent list and he sees a list containing a few hundred Agents. He tries to find the "Customer
info" production ones.
2. He knows that the customer info runs on Tomcat, so he types that, and the list shrinks a bit, but still contains several
dozens of Agents. He remembers that Kyle showed him how to find them once, but he doesn't remember what the query
string that was...
3.Then Andrew sees a list of names like
1. Production (254)
2. Preproduction (115)
3. Development (65)
4. TicketsNow (211)
5. ESB (4)
6. Portal (16)
7. CustomerInfo (16)
4.He thinks these must be some sort of labels or tags associated with a search query. He also notices that he can create a
new one . Andrew selects "CustomerInfo (16)" and then he can immediately see the 16 Agents. He can see that there are
Agents from all environments mixed up.
5.So he decides to create a new named filter so that he doesn't have to remember it next time, so he selects that and he
2. Data needs
What people need to know – Data and information.
…

Identifying and assign needs
Activity Diagram

Design Framework | Interaction Design
Hybrid UML Flow diagram

Design Framework | Wireframes
Interaction Design Storyboard

Jobs to be Done
o When diagnosing agent configuration issue I want to find my Agent quickly among a huge list so that I don't waste my
time searching.
o When managing thousands of agents I want to store my complex queries so I can re-use them regularly.
o When performing an operation on several Agents using the API I want to specify easy to remember expression to
identify the target Agents so I can change it centrally without having to update my scripts.
https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27

Use Cases
“List of actions or event steps, defining the
interactions between the user and a
system, to achieve a goal.”
Use Cases are great prototyping tool. We
can use click-through prototype to validate
the product design early in the process.

Product Increment evaluation
Scenarios are helping us to define what the product will do before we design how the product will do it.
This is making Scenarios a perfect tool to define the Product Increment goals.
o Product Increment
o Feature
Scenario
o Story
o Task
Scenario
Product Readiness Demo
Tell the story of what the product will do.
End of Sprint Review
Demonstrate how the product does it.
End of Product Increment
Demonstrate how the product does it.
Tell the story of how it enhances the user life and CA business

Product Increment evaluation
Scenarios are helping us to define what the product will do before we design how the product will do it.
This is making Scenarios a perfect tool to define the Product Increment goals.
o Product Increment: CY2016-Q2-A
o Feature: F13674 - Upgrade to 10.3 Agent Bundles
Scenario: Kyle is upgrading an Agent Package to 10.3
o Story: US123123 - Upgrade bundles with user specific overrides
o Task: TA342640 - Detect bad user keys on patch and throw error
Kyle just received the GA announcement for APM 10.3. He reads about the new features and is super happy about the new JMS
support, as many TicketsNow applications use JMS and he gets a really poor visibility into their performance.
1. Kyle goes to the CA Support Online site, and downloads the 10.3 version of APM Command Center for his platform and upgrades
his ACC Server.
2. He then edits one of his existing Agent PackagesHe changes the Agent version from 10.2 to 10.3.He sees that 1 of his custom
bundles is not compatible with APM 10.3 and will therefore be removed from the package.

CA Scenario examples
to take inspiration from others.

1. Marcus is testing the last release of the print-at-home postage app before the last deployment for the
holidays. This one has to be right. Several years ago they had severe problems with their production
applications during the holiday season, so the pressure is high. While this app was not the culprit, any hiccup
in their performance will drive their customers to the competition.
2. Marcus just got the code from the QA team. He loads the code and opens APM, and he is relieved that it is
already set up for monitoring. Instrumenting code used to take hours out of his day, and would often require
him to call on the APM administrator for assistance. Now it’s automatically ready for monitoring, and takes
on the instrumentation he set up the last time he ran performance tests on the application.
3. The code is constantly changing with each new release and Marcus typically feels overwhelmed trying to
track all of the changes. Once he installs the applications, he sees a change overview, indicating the key
components that have been changed by the development team, as well as the new transactions that were
defined by the QA team in their tests. There are several new transactions including the purchase of their
new flat rate boxes. He sees a few suggestions for additional monitoring he may want to add, based on the
changes. He accepts the suggestions, feeling confident that he has saved a lot of time that he can use to
analyze his test results.
Marcus installs the new app release in perf
PERFORMANCE TESTING BEFORE PRODUCTION

4. Marcus needs to ensure that when tested against simulated performance load, the transaction performance
numbers do not degrade, and hopefully improve. Jeevan has set some aggressive performance targets for
this new release.
5. Marcus sets up his test to run overnight on virtual machines in the production environment, when the
production applications require much less hardware support for the lighter overnight traffic.
6. The next morning, Marcus sees a notification waiting for him, informing him of several transactions that are
not meeting performance targets and are slower than expected compared to previous tests. He can see the
likely culprits, as well as the code changes that took place between tests that were most likely to have
affected the performance. Marcus navigates easily into the product to see where the transactions are being
held up.
Marcus installs the new app release in perf
PERFORMANCE TESTING BEFORE PRODUCTION

• Andrew is a developer on the TicketsNow application. The new version of the TicketsNow application now
uses a MongoDB database, and Andrew does not see this backend interaction correctly in APM.
1. Andrew has opened a support ticket about this, and support sent him the "Supported" Mongo DB fieldpack,
which he has successfully imported in his ACC Server.
2. Andrew sees a list of all the package versions that can be deployed without restarting his Agent. He also sees
that other versions exist but need a full reinstall.
3. Since the "latest" version of his current package is indicated as being deployable without a restart, he selects
it and proceeds.
4. Andrew then sees an indication of the operation progress , and after a few seconds, he sees a confirmation
that the "latest" package has been correctly installed on his Agent.
5. He looks at his Investigator and sees a new "MongoDB" backend along with deliciously interesting
performance metrics, so he thinks that life is beautiful and wonders why everything isn't as simple as CA
APM.
• The new version of TicketsNow application now correctly appears in both Web View and ATC and Andrew
thinks that life is beautiful and wonders why everything isn't as simple as CA APM
Push dynamic changes to an Agent
GAIN IMMEDIATE VISIBILITY INTO ALL APPLICATION COMPONENTS

What is wrong with this example?
Andrew opens a new tab, clicks the import button and imports a zip file. He click the Package button inside the sidebar and
set the bundle version to latest. Andrew then navigates to OOTPBO (Out of the Box Package Builder Orchestrator) and see
the effect of his change.
The operation is finished. The operation does not need a restart so the MongoDB backend now shows correctly in
Investigator.

What is wrong with this example?
Andrew opens a new tab, clicks the import button and imports a zip file. He click the Package button inside the sidebar and
set the bundle version to latest. Andrew then navigates to OOTPBO (Out of the Box Package Builder Orchestrator) and see
the effect of his change.
The operation is finished. The operation does not need a restart so the MongoDB backend now shows correctly in
Investigator.
1. There is no obvious motivation to perform this task. Why would Andrew need to perform this operation? The context is
more relevant information to the Scenario than attempting to define UI specifics such as whether it is a tab or button.
2. There is no connection with the previous step. There is missing See | Think | Do link and there is no description of the clue
that would lead Andrew to navigate to another step.
3. This is an internal slang. It is not possible to assume that Andrew would understand what OOTPBO actually means.
4. Since Andres’s goal is missing, it is not possible to evaluate whether the result matches the goal.
1.
2. 3.
4.

Frequently Asked Questions
o What if there is no extensive ethnographic research available to drive the Persona definition?
o Should I create Personas on my own based on team’s current knowledge?
• There is nothing that can stop you from creating ”Proto-Persona” and write-up a set of behavioral characteristic on your
own. However this is not recommended approach.
• Personas are synthesized summary of the User Research. If Personas are missing, then the user research might be
missing too. Do you have qualitative and quantitative data record to demonstrate who is your user?
• Archetypes are not Stereotypes. Stereotypes are based on team biases and assumptions, rather than factual data.
Alternative approach
• Write down characteristics of 1 user based only on the factual data. If you did not asked a certain question, do not assume
an answer. Use real user name and real company name.
• Do you have data to extrapolate and assume that there are more users and companies like this?
• This is your ”persona”. Maintain his real name and real company reference.
• It is always safer to extrapolate from existing data-set than starting with a whiteboard and ”brainstorm” the persona
characteristics.

o What if there is no extensive ethnographic research available to drive the Persona definition?
o Should I create Personas on my own based on team’s current knowledge?

o The other Team/Product developed some Personas already. Can I use them?
• To be effective, personas must be context-specific. They should focus on the behaviors and goals related to the specific
domain of a particular product. Personas, because they are constructed from specific observations of users interacting
in specific contexts, cannot easily be reused across products, even when the product form a closely linked suite.
• For a set of personas to be an effective design tool for multiple products, the personas must be based on research
concerning the usage context for all these products.
• You shouldn't assume that just because two users exhibit similar behaviors in regard to one product, those two users
would behave similarly with respect to a different product.
Alternative approach
• Drive the research to identify Organizational archetypes –
”Organizational personas”.

o My team is only working on features that do not have a GUI.
o I’ll just define the functional specifications directly. How can Scenarios help me?
• Creating Scenario narrative would challenge you to define enhanced future for the user.
Working on a faster build system? New security scan? Database optimization? SQL query correlation?
• Pretend its magic and these features are already implemented.
• How are they enhancing the life of your user? Can you validate the story with a real user?
• Evaluate if the user that you are targeting is not an Internal User.
• Faster build = Faster service pack = Faster issue resolution -> Satisfied CA Support user
• Faster build = Faster service pack = Faster issue resolution -> Satisfied end-user
• Simpler installer = more compelling POC = more sales -> Satisfied CA Pre-Sales consultant user
• Internal users and CA Stakeholders requirement should be taken into account not as direct feature request.
They should be synthetized using the same user research techniques as for end-users. Their needs and
motivations should be captured using Scenarios.

o My product user interface is not task or goal oriented. The UI that we are working on is exploratory UI.
o There are thousands of possible Scenarios and Use cases. How can I use Scenarios?
Red Flags
• The goal of the product is ”Provide an overview of…”
• Scenarios are described with ”Display/Show the data of…”
• Every product feature have to fit a specific user goal.
• For exploratory based user interfaces such as Microsoft Excel, Google Maps…or APM Topology map, there are hundreds
of possible use cases. But there should be a primary Scenario clearly articulating a single user goal – what the user is
trying to achieve with the product.
• A goal of Google Maps’s Navigation feature is not ”providing and overview” of the world. The goal is to display a
sequence of turn-by-run steps that will successfully navigate the user from point A to point B.

o We brainstormed the Scenario with the team once.
o Should Scenario definition be locked or evolve over the time?
• Scenarios are a design tool. Design is a verb – its an activity, not a frozen deliverable.
• Scenarios are great tool for preliminary intent validation with users and stakeholders. Scenarios should evolve
around the actual knowledge and feedback.
• It is much cheaper to change the Scenario or any other design deliverable than already released Product Increment.
• Consider using a central repository for Scenario definition in a content management system – Wiki or Rally. Never
send an important project documentation over email.
• For any major change, write down new factual data that causes the scenario to change.
• Follow the Agile project milestones and rituals. Once the Product Increment starts, Feature and Scenario description
should not change. Scenarios are defining what we are developing. Changing a Scenario mid-flight might indicate a
deeper problem – do we know what problem are we trying to solve?

Where to continue
• Follow Interaction-design.org
• https://www.interaction-design.org/literature/article/four-different-perspectives-on-user-personas
• Follow designers you like J
• https://medium.com/enterprise-ux
• Ask for a Cooper Workshop
• http://www.cooper.com/journal/2015/4/why-personas-get-a-bad-rap
This document contains direct quotations from About Face 4 and Cooper Scenarios workshop deliverables.

How can we help you?
Please do not hesitate to contact the
Design team
Yes We Can:
• Help you with the Scenario structure and form
• Help you to setup Scenario repository
• Help you to find PM buddy to review the Scenario content
• Provide and User Interaction design guidance

How to use Scenarios

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie How to use Scenarios

Ähnlich wie How to use Scenarios (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

How to use Scenarios