Lecture 10
Journey Map & Use Case
Interface Design/ COM3156, 2017 Fall Class hours : Fri. 1-4 pm Lecture room : #210 Billingsley Hall, Main Campus 10th November
USER STORY MAPPING Workshop #3 Analyzing Contextual Data
Lecture #10 COM_Interface Design 2
Jeff Patton (2014) User Story Mapping, Cambridge : O’Reilly.
Change-the-World
Lecture #10 COM_Interface Design 3
The truth is, your job is to change the world.
Change-the-World Model
Lecture #10 COM_Interface Design 4
Now and Later
• The model starts by looking at the world as it is now.
– When you look at the world as it is now, you’re going to find people who
are unhappy, mad, confused, or frustrated.
– Now, the world’s a big place, so we’ll focus mostly on the people who use
the software we make, or the people we hope will use it.
– When you take a look at what they’re doing—and the tools they use and
how they’re doing things—you’re going to come up with ideas, and the
ideas might be for:
• Entirely new products you can build
• Features to add to an existing product
• Enhancements to products that you’ve built
Lecture #10 COM_Interface Design 5
Now and Later
• Later,
– they’re not happy because they saw the pretty box it came in—software
doesn’t usually come in boxes these days anyway.
– They’re not happy because they read the release notes, or downloaded
the app to their mobile device.
– They’re happy because when they use the software, or the website, or the
mobile app, or whatever you’ve built, they do things differently— and
that’s what makes them happy.
Lecture #10 COM_Interface Design 6
Change-the-World Model
Lecture #10 COM_Interface Design 7
Software Isn’t the Point
• Impact
– It’s that longer-term stuff that happens as a consequence of good
outcomes that’s I’ll label impact. Outcomes are often something you can
observe right away after delivery. But impact takes longer.
Lecture #10 COM_Interface Design 8
Change-the-World Model
Lecture #10 COM_Interface Design 9
Build Less
Lecture #10 COM_Interface Design 10
There’s always more to build than we have time or resources to build—always.
Minimize output, and maximize outcome and impact.
Let’s get started
Lecture #10 COM_Interface Design 11
Think — Write — Explain — Place
• Get in the habit of writing down a little about your idea before
explaining it.
1. If you’re using cards or sticky notes, write down a few words about your
idea immediately after thinking it.
2. Explain your idea to others as you point to the sticky note or card. Use big
gestures. Draw more pictures. Tell stories.
3. Place the card or sticky into a shared workspace where everyone can
see, point to, add to, and move it around. Hopefully, there will be lots of
other ideas from you and others in this growing pile.
Lecture #10 COM_Interface Design 12
Frame Your Idea
Lecture #10 COM_Interface Design 13
Describe Your Customers and Users
Lecture #10 COM_Interface Design 14
Mapping your story helps you find holes in your thinking.
Lecture #10 COM_Interface Design 15
Reorganizing cards together allows you to communicate without saying a word.
Explore Details and Options
Lecture #10 COM_Interface Design 16
Explore Details and Options
Lecture #10 COM_Interface Design 17
The Backbone
Lecture #10 COM_Interface Design 18
The Map Loaded with Ideas
Lecture #10 COM_Interface Design 19
Talking Through Each Activity
Lecture #10 COM_Interface Design 20
Prioritizing
Lecture #10 COM_Interface Design 21
Plan to Build Less
Lecture #10 COM_Interface Design 22
Plan to Build Less
Lecture #10 COM_Interface Design 23
Narrative Flow
Lecture #10 COM_Interface Design 24
Slice Out a Minimum Viable Product Release
Lecture #10 COM_Interface Design 25
Slice Out a Release Roadmap
Lecture #10 COM_Interface Design 26
Finding a Smaller Viable Release
• After the story map was constructed, SEP guided the FORUM
stakeholders through a simple prioritization model:
– Differentiator
• A feature that set them apart from their competition
– Spoiler
• A feature that is moving in on someone else’s differentiator
– Cost reducer
• A feature that reduces the organization costs
– Table stakes
• A feature necessary to compete in the marketplace
Lecture #10 COM_Interface Design 27
Don’t Prioritize Features —Prioritize Outcomes
Lecture #10 COM_Interface Design 28
How to Prototype
Lecture #10 COM_Interface Design 29
OK, LET’S TRY STEP BY STEP
Lecture #10 COM_Interface Design 30
1. Write Out Your Story a Step at a Time
Lecture #10 COM_Interface Design 31
1. Write Out Your Story a Step at a Time
Lecture #10 COM_Interface Design 32
1. Write Out Your Story a Step at a Time
Lecture #10 COM_Interface Design 33
2. Organize Your Story
Lecture #10 COM_Interface Design 34
3. Explore Alternative Stories
Lecture #10 COM_Interface Design 35
4. Distill Your Map to Make a Backbone
Lecture #10 COM_Interface Design 36
5. Slice Out Tasks That Help You Reach a Specific Outcome
Lecture #10 COM_Interface Design 37
That’s It! You’ve Learned All the Important Concepts
• As you built this map you learned that:
– Tasks are short verb phrases that describe what people do.
– Tasks have different goal levels.
– Tasks in a map are arranged in a left-to-right narrative flow.
– The depth of a map contains variations and alternative tasks.
– Tasks are organized by activities across the top of the map.
– Activities form the backbone of the map.
– You can slice the map to identify the tasks you’ll need to reach a specific
outcome.
Lecture #10 COM_Interface Design 38
It’s a Now Map, Not a Later Map
Lecture #10 COM_Interface Design 39
It’s a Now Map, Not a Later Map
• One of the cool things about "now story maps" is that you can build them to better
understand how people work today.
– You just did this to learn how you got ready this morning. You can learn even more if you go
back and add other things to the map. The easy things to add are:
• Pains
– Things that don’t work, parts people hate
• Joys or rewards
– The fun things, the things that make it worth doing
• Questions
– Why do people do this? What’s going on when they do?
• Ideas
– Things people could do, or that we could build that would take away pain, or make the joys even better
• Lots of people in the user experience community have been building these for years to
better understand their users.
– Sometimes they’re called journey maps, but they’re the same basic idea.
Lecture #10 COM_Interface Design 40
Customer Journey Map Canvas
Lecture #10 COM_Interface Design 41
http://files.thisisservicedesignthinking.com/tisdt_cujoca.pdf
Journey Map Example
Lecture #10 COM_Interface Design 42
Journey Map Example
Lecture #10 COM_Interface Design 43
Journey Map Example
Lecture #10 COM_Interface Design 44
GETTING STARTED WITH USE CASE MODELING
An Oracle White Paper, May 2007
Lecture #10 COM_Interface Design 45
Introduction
Lecture #10 COM_Interface Design 46
“This is not a use case”
What is Use Case Modeling
Lecture #10 COM_Interface Design 47
The core items of use case modeling are use cases and actors.
What is Use Case Modeling
• Use Cases
– Whenever we discuss the requirements of a system we recognize one or
more people or things that have an interest in the behavior of that system.
These are called the stakeholders of that system.
– A use case describes how the system should respond under various
conditions to a request from one of the stakeholders to deliver a specific
goal. This is primarily done in the form of a scenario that describes a
sequence of steps. Each use case captures a “contract” for the behavior
of the System under Discussion (SuD) to deliver a single goal.
Lecture #10 COM_Interface Design 48
What is Use Case Modeling
• Actors
– An actor is anyone or anything with behavior. The primary actor is the
stakeholder that interacts with the SuD to achieve a specific goal. The
primary actor is often, but not always the one who triggers the use case.
It is not, when the use case is actually triggered by an actor who does this
on behalf of the real primary actor, or when the use case is triggered by
time.
– Sometimes an (external) actor needs to provide a service to the SuD.
Such an actor is called a supporting actor. An actor can be the primary
actor for one use case and the supporting actor for another.
Lecture #10 COM_Interface Design 49
A Text Form
• Scenario
– The main part of a use case is its scenario. A scenario describes a
sequence of steps that are executed in order to fulfill the goal the use
case is supposed to deliver. For example, the scenario that describes how
to get a parking ticket from a machine could look like this:
Lecture #10 COM_Interface Design 50
A Text Form
Lecture #10 COM_Interface Design 51
Buy Parking Ticket
1. The Car Driver enters a coin in the Ticket Machine
2. The Ticket Machine indicates until when the Car Driver can park
3. The Car Driver continues with step 1 and 2 until satisfied
4. The Car Driver presses the button to retrieve the parking ticket
5. The Ticket Machine prints the parking ticket
A Text Form
– The scenario must be easy to read. Therefore you should avoid scenarios
of more than nine steps and you should always use the active voice,
stating exactly who or what is doing what. This includes the SuD itself.
– In the scenario above everything goes as planned, which therefore is
called a main success scenario. But in many cases there are exceptions
that require a deviation from the planned scenario. In this example
exceptions may consist of the Car Driver entering a coin of invalid
currency or aborting the transaction. Exceptions are documented as
extensions.
Lecture #10 COM_Interface Design 52
A Text Form
• Extensions
– An exception is documented by specifying an alternate route in the
scenario, which is called an extension (related to, but not the same as an
extension use case, which will be discussed later on). Extensions can be
added to the main success scenario as follows:
Lecture #10 COM_Interface Design 53
A Text Form
Lecture #10 COM_Interface Design 54
Buy Parking Ticket Main Success Scenario: 1. The Car Driver enters a coin in the Ticket Machine 2. The Ticket Machine validates the coin 3. The Ticket Machine indicates until when the Car Driver can park 4. … Extensions: 2a Invalid coin: 2a1 The Ticket Machine returns an invalid coin 2a2 Return to step 1 3a Car Driver aborts transaction: 3a1 The Ticket Machine returns the coins that have been entered 3a2 The scenario ends
A Text Form
• Use Case Properties
– Scope: the name of the (part of the) system the use case belongs to
– Stakeholder: someone or something that has an interest in the goal the use case
delivers
– Primary Actor: the stakeholder who or which initiates the use case to achieve a goal
– Brief Description: a brief description of the goal the use case is supposed to deliver
– Level: at what level the use case has been written (to be discussed in “Scope and Level”)
– Preconditions: what conditions must be met before the scenario can start (to be
discussed in “Preconditions and Guarantees”)
– Postconditions: what conditions must be met for a valid end of the scenario, to be
divided into minimal guarantee(s) and success guarantee(s) (to be discussed in
“Preconditions and Guarantees”)
– Trigger: the event or sequence of events that initiate the use case.
Lecture #10 COM_Interface Design 55
Use Case Diagram
• Actors and Use Cases
– In a diagram you include actors as people-like figures and use cases as
ellipses and draw lines that indicate the relationships, or communications
between them.
– It is custom to draw the primary actor and other stakeholders that
communicate with the use case to the left and secondary actors to the
right. Put the primary actor at the top, as in the following example.
Lecture #10 COM_Interface Design 56
Use Case Diagram
Lecture #10 COM_Interface Design 57
Actors, use cases and communications
Use Case Diagram
• Use Case Inclusions
– Higher-level use cases may call lower-level use cases (that is: require the
behavior of lower-level use cases).
Lecture #10 COM_Interface Design 58
Log Ticket Main Success Scenario: 1. The Helpdesk Employee
Finds Customer using its name or address
2. The Helpdesk Employee enters the details of the Ticket
Use Case Diagram
• Use Case Inclusions
– Higher-level use cases may call lower-level use cases (that is: require the
behavior of lower-level use cases).
Lecture #10 COM_Interface Design 59
Log Ticket Main Success Scenario: 1. The Helpdesk Employee
Finds Customer using its name or address
2. The Helpdesk Employee enters the details of the Ticket
An inclusion is drawn as a dashed arrow from the higher-level to the lower-level use case. The lower-level use case should also be drawn lower to emphasize it is at a lower level.
Use Case Diagram
• Use Case Extensions
– In general an extension use case is an extension of a main success
scenario that has been moved out of the originating use case into a use
case of its own. The point at which it exists the originating use case is
called an extension point like the point at which it returns is called the
return point.
Lecture #10 COM_Interface Design 60
Use Case Diagram
Lecture #10 COM_Interface Design 61
Abort Transaction Trigger: any time in Buy Ticket the Car Driver can abort the transaction Main Success Scenario 1. The Ticket Machine returns the
coins that have been entered
An extension is drawn using a dashed arrow from the extension use case to the originating one. The extension use case should be drawn lower than the originating use case, emphasizing that it is at a lower level.
Use Case Diagram
• There are a few situations in which you create extension use cases,
being:
– To leave details out of the originating use case that otherwise would
clutter its scenario.
– As a way to add to requirements that are fixed and you are not allowed to
change the originating use case.
– When the extension concerns an isolated piece of functionality that may
be implemented by a different team. In this case you may want to be able
to estimate both use cases separately.
Lecture #10 COM_Interface Design 62
Writing in Iterations
Lecture #10 COM_Interface Design 63
Actor Goal Brief Description Prio
Customer Place Order Use the web store to purchase one or more books. M
Receive Purchased Books
Receive books in good order and sign for it. M
Sales Staff Process Order Receive an online order and initiate the delivery process. M
Notify Customer Offerings
Send an email to customers about special offers. S
Book Store Staff
Prepare Shipment Collect all books for one order and prepare it for shipment to the customer.
M
Track Shipment View the delivery status of the shipment C
http://tinyurl.com/q8gvncl
Table 1. An example Actor-Goal List with MoSCoW prioritization
Writing in Iterations
• The short recipe for creating use cases is as follows:
1. Identify the actors
2. List their goals
3. Add brief descriptions to the goals
4. Create an initial use case for each goal
5. Describe the main success scenario for each use case
6. Identify the exceptions to the main success scenarios and work them out
as extensions
7. Validate the use cases
8. Optimize the use cases
Lecture #10 COM_Interface Design 64
Homework
Lecture #10 COM_Interface Design 65
Develop a Journey Map
Develop Use Cases
Complete the Project
Requirements
1 2 3
Your Blog Post #6 - Write Out Your
Story a Step at a Time
- Organize Your Story
- Explore Alternative Stories
- Distill Your Map to Make a Backbone
- Slice Out Tasks That Help You Reach a Specific Outcome
Your Blog Post #7 - A Text form - Use case diagrams - Actor-Goal List with
MoSCoW prioritization
Your Blog Post #8 - Requirement Matrix - Context Scenario - Journey Map - Use Cases
Submission Due : 11: 59 pm Wed. 15th November