AC4D  design library use cases scenarios
Upcoming SlideShare
Loading in...5
×
 

AC4D design library use cases scenarios

on

  • 415 views

Austin Center for Design is an ...

Austin Center for Design is an
educational institution in Austin, Texas,
teaching Interaction Design and Social Entrepreneurship
- See more at: http://www.ac4d.com/home/news/#sthash.SYjQ5U6H.dpuf

All content is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. This license means that, while the author retains the copyright to the work, you are permitted to a) share this work with anyone you like, as long as you don't charge money for it; b) change this work and re-release it under your own name, with attribution to the original source; and c) integrate this work into your own work in small or large portions.

Statistics

Views

Total Views
415
Slideshare-icon Views on SlideShare
415
Embed Views
0

Actions

Likes
2
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    AC4D  design library use cases scenarios AC4D design library use cases scenarios Presentation Transcript

    • Use Cases & Scenarios Matt Franks Professor, Austin Center for Design
    • Use Case A description of steps or actions between a user and a system, which leads the user towards something useful (a goal).
    • Use Case A description of steps or actions between a user and a system, which leads the user towards something useful (a goal). The user or “actor” might be a person or something more abstract, such as an external software system or manual process.
    • Use Case A description of steps or actions between a user and a system, which leads the user towards something useful (a goal).
    • Use Case A description of steps or actions between a user and a system, which leads the user towards something useful (a goal). Use cases treat the system as a black box. The system is considered to technically work, but we don’t particularly care about how it works. This forces a consideration of value from the perspective of the user, rather than implementation or technical feasibility.
    • A Use Case Should: •  Describe what the system should do to support the user as they achieve their goals. •  Avoid implementation-specific language (nothing about how it’s done) •  Be written at an appropriate level of detail •  Abstract away form elements, user interfaces, screens, or more specific implementation details. These details will be added in later.
    • Developing Use Cases Use an iterative process; use cases will be continually refined and edited through life of the project.
    • Creating Use Cases 1.  Identify “actors” – all of the people / systems / entities that will be using the system. Label them as primary or secondary actors. For Example: Creating an Online Payment Platform Primary Actors: Payer Recipient Secondary Actors: Bank CC Company 8
    • Creating Use Cases 2.  Identify primary use cases ( also known as “sunny day” or “happy path”) Image all is well in the world, and your users are able to successfully complete the key tasks they are trying to accomplish with your product. Think about what the user is trying to accomplish, and use user language rather than system language. For example: Users do not approach a system with the goal of “Managing their account”. Rather, they almost always have a more direct human goal – “Check my balance”, “Get some money”, etc. 9
    • Creating Use Cases 2.  Identify primary use cases, continued For Example: Creating an Online Payment Platform Primary Actors: Payer Recipient Payer Use Cases: •  •  •  Create Account Send Payment Check Payment Status Use the 80/20 rule – if you write an exhaustive list of all possible use cases, typically 20% of these will account for 80% of the activity. The other 80% of the use cases would support 20% of the activity. 10
    • Creating Use Cases 3.  Identify edge cases (also known as “rainy day”). An edge case is a problem or situation that occurs only at an extreme operating parameter, generally with limited frequency. It can break an otherwise good experience. For Example: Creating an Online Payment Platform Primary Actors: Payer Recipient Payer Edge Cases: -  -  -  Cancel a Payment Report a False Charge Retrieve Lost Username or Password 11
    • Creating Use Cases 4.  Create a use case visualization. Use case diagrams are used to represent the functionality of your system from a top-down perspective. The system’s functionality is obvious at a glance, but all descriptions are at a very high level. Use case diagrams have 4 components: •  Actors interacting with the system or product •  The system or product itself •  The use cases the system or product is able to support •  The relationships between these components 12
    • Creating Use Cases 4.  Create a use case visualization, continued Create the use case diagram – Outline and label the actors Payer System 13
    • Creating Use Cases 4.  Create a use case visualization, continued Place the primary use cases (“happy path”) inside of the system. Payer System Create an account Send Payment Check Payment Status 14
    • Creating Use Cases 4.  Create a use case visualization, continued Add more detail – Sometimes a use case <<Includes>> an additional step. Payer System Create an account Send Payment In the example of our payment system, the user needs to find a payment recipient in-order to send a payment. This type of detail is an <<includes>> detail, because the user is unable to complete the primary task without finding a recipient. Check Payment Status 15
    • Creating Use Cases 4.  Create a use case visualization, continued Add more detail – Sometimes a use case <<Includes>> an additional step. Payer System Create an account Send Payment <<Includes>> Find Recipient Check Payment Status 16
    • Creating Use Cases 4.  Create a use case visualization, continued Sometimes a use case <<Extends>> and modifies initial behavior. Payer System Create an account Send Payment Check Payment Status In the example of our payment system, when sending a payment, the use case <<includes>> selecting the recipient because this is required to complete the primary use case. In addition, the send payment <<extends>> to selecting a shipping / delivery option that is different from the default. In this example, shipping options outside of the default are optional 17
    • Creating Use Cases 4.  Create a use case visualization, continued Sometimes a use case <<Extends>> and modifies initial behavior. Payer System Electronic Delivery (Default) Create an account Send Payment Check Payment Status <<Extends>> Paper Delivery USPS Paper Delivery Overnight 18
    • Creating Use Cases 5.  Write a description for each use case The description of the use case includes and considers time and sequential actions. Online Payment Platform: Actor: Payer #P2 Use Case: Send Payment The payer has decided to send a payment. The payer locates the recipient within the system <<includes>> Find Recipient. The payer selects the appropriate recipient and specifies the amount of money to be sent. The payer decides which account they want the money to come from. The payer enters all information into the system and the system verifies and validates all the recipient and payment details. The payer selects the shipping method Paper check – Overnight <<Extends>> Alternate Shipping Option. The system provides feedback to the payer that their payment is complete, with notice of any delays or other important information. 19
    • Complexity More complicated systems require more complicated and numerous use cases. Numbering and indexing your use cases is always a good idea, as it allows you to quickly edit and scale your use cases to accommodate changes or growth to your design. Consider using a database or spreadsheet tool (like Excel) to write your use cases.
    • Activity: As a group, create 2 – 3 primary use cases for one of your ideas on a whiteboard or large sheet of paper. 1.  Start with the user’s goals •  What are the primary things the user is trying to accomplish? •  Tip: Users do not typically set out to “log in” or “manage” something. Users generally try to accomplish some larger goal that requires them to complete an artificial interim goal. 2.  After you’ve created your primary use cases, add additional detail •  Does your use case <<include>> any steps that are required for it to be completed? •  Tip: Try to be as generic as possible when describing <<includes>>. Example: (A user must Authenticate) vs (A user must Log In). 3.  Write a description for each use case.
    • Scenarios Similar to a use case, scenarios are a written story that explains how a person will use a product, service, or system to achieve a goal. Scenarios are different in that they include the context of use and can include multiple use cases.
    • Scenarios Similar to a use case, scenarios are a written story that explains how a person will use a product, service, or system to achieve a goal. Scenarios are different in that they include the context of use and can include multiple use cases.
    • Scenarios Similar to a use case, scenarios are a written story that explains how a person will use a product, service, or system to achieve a goal. Scenarios are different in that they include the context of use and can include multiple use cases.
    • Scenarios Similar to a use case, scenarios are a written story that explains how a person will use a product, service, or system to achieve a goal. Scenarios are different in that they include the context of use and can include multiple use cases.
    • Scenarios Similar to a use case, scenarios are a written story that explains how a person will use a product, service, or system to achieve a goal. Scenarios are different in that they include the context of use and can include multiple use cases.
    • Scenarios Similar to a use case, scenarios are a written story that explains how a person will use a product, service, or system to achieve a goal. Scenarios are different in that they include the context of use and can include multiple use cases.
    • A Good Scenario 1.  2.  3.  4.  5.  6.  Acts as a bridge between an initial design idea or problem and a solution Advances the fidelity of an idea Stands on its own, without explanation Does not prescribe interface elements in any great detail Includes a rich description of a person Includes a rich description of a goal 7.  Is credible
    • Writing Scenarios 1.  Identify the people involved: What are their names? Where do they work? What level of technical experience do they have? What level of technical competence can you assume with this system, specifically? It’s often helpful to write a three or four sentence introduction to each person, describing their background and helping to humanize them. 29
    • Writing Scenarios 2.  Identify the starting state / context Where will the people using your system be, physically, when they encounter it? What state is the actual product or service in when they first acknowledge it? 30
    • Writing Scenarios 3.  List the goals a user may have, as they pertain to your product or service. A goal is about a fundamental want, need, or desire that is presently unattained. Goals rarely change, even as technology progresses. For example, when using a printer, my goal is not “to print” – it is “to communicate my intent to other people when I’m not there through a lasting artifact.” List as many goals as you can think of. 31
    • Writing Scenarios 4.  Prioritize the goals, based on your understanding of your users. Stack rank the goals, putting them in order from “most important to achieve using this system or service” to “least important to achieve using this system or service.” 32
    • Writing Scenarios 5.  Craft Stories. Using the people, context and goals as a starting point, craft a narrative that explains how a person will use your system to achieve their goals. Don’t try to achieve all goals in a single epic story; instead, create multiple stories, one for each goal. Keep the conversation at a high, behavioral level, rather than a low user interface level: Good: Fred grabs his phone. He opens the beer-finding app, and locates a beer nearby. He chooses to have it delivered, enters his payment information, and completes his order. Bad: Fred grabs his phone. He taps the beer finding app icon. He taps the zip code input box, and the onscreen keyboard appears. He taps the numbers for his zip code, and then taps “find beer.” An hourglass appears on his screen, and after several seconds, search results begin to show up.. 33
    • Activity: As a group, craft a narrative that explains how a person will use your product, system, or service to achieve their goal. Try to describe the ideal state, or “happy path.” 1.  Identify who is using your product, system, or service •  Describe your primary user •  Give them a name 2.  Identify the starting state – a context of use 3.  List and prioritize the user’s goals 4.  Using the people, context, and goals as a starting point, craft a narrative that explains how a person will use your system to achieve their goal. •  Don’t worry about edge cases or potential fail points in your narrative •  Keep it simple
    • Matt Franks Professor, Austin Center for Design Mfranks@ac4d.com Download our free book, Wicked Problems: Problems Worth Solving, at http://www.wickedproblems.com