[ID] Week 10. Journey Map and Use Case

1. Lecture 10 Journey Map & Use Case Interface Design/ COM3156, 2015 Fall Class hours : Wedn 1-4 pm 4th November

2. USER STORY MAPPING Workshop #3 Analyzing Contextual Data Lecture #10 COM_Interface Design 2 Jeff Patton (2014) User Story Mapping, Cambridge : O’Reilly.

3. Change-the-World Lecture #10 COM_Interface Design 3 The truth is, your job is to change the world.

4. Change-the-World Model Lecture #10 COM_Interface Design 4

5. 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

6. 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

8. 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

10. 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.

11. Let’s get started Lecture #10 COM_Interface Design 11

12. 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

13. Frame Your Idea Lecture #10 COM_Interface Design 13

14. Describe Your Customers and Users Lecture #10 COM_Interface Design 14

15. 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.

16. Explore Details and Options Lecture #10 COM_Interface Design 16

17. Explore Details and Options Lecture #10 COM_Interface Design 17

18. The Backbone Lecture #10 COM_Interface Design 18

19. The Map Loaded with Ideas Lecture #10 COM_Interface Design 19

20. Talking Through Each Activity Lecture #10 COM_Interface Design 20

21. Prioritizing Lecture #10 COM_Interface Design 21

22. Plan to Build Less Lecture #10 COM_Interface Design 22

23. Plan to Build Less Lecture #10 COM_Interface Design 23

24. Narrative Flow Lecture #10 COM_Interface Design 24

25. Slice Out a Minimum Viable Product Release Lecture #10 COM_Interface Design 25

26. Slice Out a Release Roadmap Lecture #10 COM_Interface Design 26

27. 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

28. Don’t Prioritize Features —Prioritize Outcomes Lecture #10 COM_Interface Design 28

29. How to Prototype Lecture #10 COM_Interface Design 29

30. OK, LET’S TRY STEP BY STEP Lecture #10 COM_Interface Design 30

31. 1. Write Out Your Story a Step at a Time Lecture #10 COM_Interface Design 31

34. 2. Organize Your Story Lecture #10 COM_Interface Design 34

35. 3. Explore Alternative Stories Lecture #10 COM_Interface Design 35

36. 4. Distill Your Map to Make a Backbone Lecture #10 COM_Interface Design 36

37. 5. Slice Out Tasks That Help You Reach a Specific Outcome Lecture #10 COM_Interface Design 37

38. 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

39. It’s a Now Map, Not a Later Map Lecture #10 COM_Interface Design 39

40. 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

41. Customer Journey Map Canvas Lecture #10 COM_Interface Design 41 http://files.thisisservicedesignthinking.com/tisdt_cujoca.pdf

42. Journey Map Example Lecture #10 COM_Interface Design 42

45. GETTING STARTED WITH USE CASE MODELING An Oracle White Paper, May 2007 Lecture #10 COM_Interface Design 45

46. Introduction Lecture #10 COM_Interface Design 46 “This is not a use case”

47. What is Use Case Modeling Lecture #10 COM_Interface Design 47 The core items of use case modeling are use cases and actors.

48. 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

49. 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

50. 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

51. 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

52. 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

53. 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

54. 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

55. 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

56. 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

57. Use Case Diagram Lecture #10 COM_Interface Design 57 Actors, use cases and communications

58. 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

59. 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.

60. 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

61. 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.

62. 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

63. 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

64. 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

65. Homework Lecture #10 COM_Interface Design 65 Develop a Journey Map Develop Use Cases Complete the Project Requirements 1 2 3 Your Blog Post #7 - 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 #8 - A Text form - Use case diagrams - Actor-Goal List with MoSCoW prioritization Your Team Blog Post #6 - Requirement Matrix - Context Scenario - Journey Map - Use Cases Submission Due : 11: 59 pm Mon. 9th November

[ID] Week 10. Journey Map and Use Case

dsd.lab

[ID] Week 10. Journey Map and Use Case