Use cases A tool to figure out what users will want to do system functions

1. Use casesA tool to figure out what users will want to dosystem functions Lecture # 8 Gabriel Spitz

2. User Interface Design Process Requirements Development NeedsAssessment Competitive Analysis PersonaDevelop Task Analysis Design MockDesign PrototypeDesign WorkflowDesign ConceptualDesign WireframeDesign Formative Evaluation MockupDesign Evaluation MockDesign Summative Evaluation Gabriel Spitz

3. Determining What Users Will to Do • Understanding who are our focal users and what are their characteristics is very important, but it is not sufficient to start a design • To start the design we need to understand • Why users use an application - Goals • What exactly they are looking for or would like to do– Tasks • How they go about it – Task Description or use case • Analyzing the ways an application is expected to be used will helps us grasp user’s goals, methods, and actions, as well as design our product to match them.  Gabriel Spitz

4. What are Use Cases? • A usability tool that helps us determine the content/functionality that an application might offers • A use case is a story that describes specific users trying to attain specific goals using our application (Application can be a website too) • It is articulated in semi-formal way that includes the steps a user will take to accomplish a a task • Use Cases are the expectations that users bring to an application and in turn the requirements an application should satisfy • Use cases are used both for designing an application and for evaluating it Gabriel Spitz

5. Usage and Use Cases The aggregate of Use Cases describe how an application will be used Usage of an Application Use case Use case Use case Use case Use case User User User User User Goal Goal Goal Goal Goal A Task A Task A Task A Task A Task A Task Description A Task Description A Task Description A Task Description A Task Description Gabriel Spitz

6. Example – Use Case Story • Jena is a Web engineer at a major news company in New York City. Recently the company decided to change their free viewing policy of their website. The new policy enables anybody to read all the headlines, however, access to the complete story is reserved to subscribers only. • As the Web Engineer, Jena goal is to organize the Company’s web site so that it will serve headlines to all and detailed stories to subscribers • Jena’s first task is to create 2 content buckets (properties) on the portal of their content delivery’s company; one for headlines and one for headlines and details Gabriel Spitz

7. Example – Use Case Decomposition Create a Property Gabriel Spitz

8. Analyzing Use Cases • The process of creating and analyzing use cases is • Systematic in nature • Analytic rather the intuitive or speculative • We often feel at the intuitive level that we understand users’ task, but this understanding is frequently incomplete and wrong • e.g. the lath operator that used cloth pin to lock one of the safety buttons Gabriel Spitz

9. Value of Use Cases • Use cases describe the key task users intend to perform with our application • Use cases help us focus on the users and what they are trying to accomplish • They also help us understand what functionality our application must have vs. nice to have, as well as how frequently such functionality will be used Gabriel Spitz

10. Good Use Cases • Good Use Cases are • Short • Relevant • To the point • They describe • Who is the user • What dose s/he wants from my application • How is the user going to achieve his or her goal Gabriel Spitz

11. Motivation for Creating Use Cases • Ensure that what we design is congruence with users need • Customers often forget their bank card in the ATM machine • Ensure compatibility with users’ characteristics • Displaying date as Nov, 12, 2002 (for 12/11/02) • Ensure compatibility with common’ activity flow • Do not forces the user to perform a task in an uncommon way such as reverse polish notation • 3 enter 4 + rather than 3+4 Gabriel Spitz

12. What is a Task (1/2) • A core element of each use case is the task • A task is what users are trying to do • E.g. Compose an email • It is aimed at getting a job done • While it involves interaction, the task itself is not to interact with a computer • E.g. Select a menu item Gabriel Spitz

13. What is a task (2/2) • A task has many different definitions • It can be conceptualized in terms of goals, activates, action. • For example update a contact in my contact list • Goals - Have an up to date list of contacts • Activities or Tasks - Verify and update individual contacts • Actions - Represent what has to be done. E.g., • Access a contact form • Read the content • Change the content if needed • File the form • Note: we describe the actions of a task in a technology neutral way Gabriel Spitz

14. Questions asked When Identifying Tasks • What tasks do users perform and in what order • What tasks are desired • What happens when things go wrong • What tools are used in conjunction with task performance • Who else can impact task performance and how • E.g., when using ATM consider the next person in line Gabriel Spitz

15. Organizing Tasks in a Hierarchy Gabriel Spitz

16. How to develop Use Cases • Once tasks are identified we need to build the use case around key tasks • The set of use cases that we create need to cover a wide range of usages of our application • We also need to make sure to include some negative use cases, also known as misuse cases, to also investigate other non-functional requirements (such as security and accessibility) • Finally use cases should be a mixture of simple and complex tasks Gabriel Spitz

17. Steps to develop Use Cases • The steps to developing scenarios of use • Describe what the user has to do to achieve his/her goal, and how will the system respond to the user’s action • For basic activities consider alternate courses of events and add those to “extend” the scenario of use. • The results will give you a basis for deciding what the user interface design should be like and what needs it will have to satisfy. • Kenworthy, E., (1997) Use Case Modeling: Capturing User Requirements Gabriel Spitz

18. Focus of Each Use Cases • Goal or Intent of the user and what s/he is trying to achieve • Sequence steps and decisions that are involved in executing each use case • Hierarchy of use cases and how they are related o each other Gabriel Spitz

19. Describing use Case • Technology neutral - Say what the user wants to do, but not how the user would do it • E.g., Contact dept head, but not send email to dept head • This allow comparing different design alternatives • E.g., Letter, Email, Facebook, Skype, etc • Specific • Forces us to consider how features work together • Include • The information that the user need for a task • Both related and unrelated to software • What the users sees and interacts with Gabriel Spitz

20. Expected Outcomes of Creating Use Cases • A set of functional requirements • Functions that are needed and desired by end users • A set of non-functional requirements for UI design • A Metaphor or a conceptual model • Users describe contacts as items in a Rolodex • Specification of the task flow • Focus areas for UI evaluation • Benchmark tasks for usability testing Gabriel Spitz

21. Creating Use Cases Gabriel Spitz

22. Methods for Identifying Key Use Cases • Review documentation • Observations – preferably in the workplace • Interviews - preferably in the workplace • Questionnaires and surveys Gabriel Spitz

23. Usage of Data Gathering Methods • Documentation review • Develop a high level understanding of features, task, and procedures – what is there • Observation • Develop a detailed understanding of tasks, and procedures in the real world – How is it used • Interview • Explore issues and develop use scenarios – What is missing • Questionnaires • Gather specific information Gabriel Spitz

24. Choosing Data Gathering Method • Most of the time we use all methods during the UI design • Selection of a specific method is driven by: • The type of information that is needed • General understanding, specific data, …. • Availability of resources • Money, time, people, …. • Access to users Gabriel Spitz