CPIS 354 - Principle of Human Computer Interaction

1. CPIS 354 - Principle of Human Computer Interaction Department of Information Systems Faculty of Computing and Information Technology King Abdul Aziz University Khalid Al-Omar 1 1

2. Previous lecture • What is the difference between unstructured interview and structured interview? • What is the difference between direct observation and indirect observation? • Understand the users? Why • Usable? Why • After understanding users, tasks, and environment. What we need? Why?

3. Requirements and Task Analysis Lecture 9 3 3

4. Overview • What are requirements? • The importance of requirements • Different types of requirements • Task descriptions: • Scenarios • Use Cases • Task analysis • HTA

5. What are requirements? • Requirement is a statement about an intended product that specifies what it should do and how it should perform. • Requirement activity aim is to make requirements as specific, and clear as possible. Why? • For example: • User need to login • In the website the time to download any complete page is less than 5 seconds • Children should find the website attractive

6. Requirements what, how, when • What are we trying to achieve in the requirements activity? • 1. Understand as much as possible about users, task, and environment • 2. Produce a stable set of requirements • How can we achieve this? • Data gathering, analysis, and interpretation

7. Requirements..(cont.) • Why bother? The important to getting • the requirements right? • Significant Cost of fixing errors in later stage

8. Different kinds of requirements • Functional: • What the system should do • Understanding the functional requirements for interactive system is essential • Example: login, logout • Non-functional: • memory size, response time, Usability, Security…

9. Different kinds of requirements • Technical requirements: • What technologies will be used or available? • What technologies will the product run on or need to be compatible with? • What technologies limitations might be

10. Different kinds of requirements • Physical requirements: dusty? noisy? vibration? light? heat? humidity? …. (e.g. ATM) • Social requirements: sharing of data, work individually, privacy for clients • Organisational requirements: IT department’s attitude, user support, availability of training

11. Different kinds of requirements • Users requirements: • Characteristics: • ability, limitation, background, experience, knowledge, preferences, attitude to computers • System use: • novice, expert, frequent, infrequent

12. Different kinds of requirements • Novice: step-by-step, need constrained interaction with clear information • Expert: flexible interaction with more control • Frequent: short cuts • Infrequent: clear instructions, e.g. menu paths • home>your profile>personal info

13. Some basic guidelines for requirements • Focus on identifying the stakeholders’ needs • Involve all the stakeholder groups • Involve more than one representative from each stakeholder group • Use a combination of data gathering techniques • Support the process with props such as prototypes and task descriptions • Run a pilot session • Consider carefully how to record the data

14. Task Analysis 14 14

15. Tasks • A task is a unit of human activity, carried out in order to achieve a specific goal. • A more complex situation may need several related tasks to be carried out. All tasks must be completed in order to achieve the goal. Each task has a separate goal.

16. Complex tasks • Examples of complex tasks which have been simplified or reduced to a single task by the use of interactive systems include: • starting a car - electronic ignition requires only the turn of a key • international telephone calls - direct dialling removes the need for an operator • online airline reservations provide instant information on flight availability • Can you think of any others?

17. Task descriptions • Task descriptions are used as part of a user-centred approach to design and development, from early analysis activities through prototyping and evaluation. • Task descriptions may describe: • existing tasks, to help developers to understand what users currently do • proposed tasks, to help designers to describe how users will use new interactive systems • There is no single agreed way to describe and analyse tasks.

18. Task descriptions • Task descriptions may take one or more of the following forms: • Scenarios • an informal narrative story, simple, ‘natural’, personal • Use cases • assume interaction with a system • assume detailed understanding of the interaction

19. Scenarios • What is a Scenario? • A scenario is a description of a person’s interaction with a system. • Telling a story is a natural way for people to explain what they are doing or how to achieve something. • Scenarios provided by users, maybe in an interview or workshop session. Not intended to be a complete description • Help designers to identify users’ goals

20. Scenarios • When are scenarios appropriate? • whenever you need to describe a system interaction from the user’s perspective. • They are particularly useful when you need to remove focus from the technology in order to open up design possibilities • So designers concentrate on the human activity rather than the technology

21. Scenarios • Advantages • Help designers to identify users’ goals • Understand why people do things as they do • What they are trying to achieve

22. Scenario for ATM “It’s Friday afternoon and Jon is flying to Sydney. He doesn’t have enough money for a taxi to the airport, and he’s running late. He goes to the local ATM and identifies himself. The machine welcome him and asked Jon to choose the language he prefer. Jon get angry because he doesn’t have enough time!. However, he chosen the language. He specifies that he wants $100 from his savings account. He’d like the money in $20 notes so that he can give the taxi driver the correct change. He doesn’t want a printed receipt, as he doesn’t bother keeping track of transactions in this account …”

23. Scenario for ATM • This scenario declare: • The ATM should check users details • The ATM should check users preferable language and store it to next time. In addition, it should provide the option to change it at anytime. • The ATM should provide the option to allow users to choose the type of change the users need. • The ATM should provide the option to print out the receipt.

24. Use case • Another way of describing tasks, borrowed from object-oriented approaches to system development • Use cases are associated with actors, and capture the actor’s goal in using the system • A use case is a more formal task description than a scenario

25. Example use case diagram for ATM

26. Use case for ATM The user entered his card. The system prompts for password. User enters password. The system verifies password. The system prompts for language types. User chooses language. System displays the main menu. User chooses the cash option. System displays the different amounts. User chooses the amount. System displays the option to print out the receipt. User chooses not to print the receipt. System display the card and then the money

27. Task analysis • Task descriptions are often used to envision new systems or devices • Task analysis is used mainly to investigate an existing situation • Many techniques, the most popular is Hierarchical Task Analysis (HTA)

28. Hierarchical Task Analysis • Breaking a task down into its steps, or sub-tasks and then grouping them to show how the tasks are performed in the actual situation. • It focuses on the actions that are performed by users • These are grouped as plans which specify how the tasks might be performed in practice

29. Why Hierarchical Task Analysis? • It provides knowledge of the tasks that the user wishes to perform • It is a cost-saving exercise. • 3. It enables us to specify the functions to be included within the system and the user interface more accurately • 4. It makes it possible to design an efficient tasks.

30. Generating the hierarchy • get list of tasks • group tasks into higher level tasks • decompose lowest level tasks further • Stopping rulesHow do we know when to stop?Is “logout” simple enough?

31. Example Hierarchical Task Analysis 0. In order to purchase items from the internet

32. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. add item to basket 4. purchase the item and checkout

33. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. add item to basket 4. purchase the item and checkout plan 0: do 1-2-3-4. What about if item located on the main screen. do 1-3-4

34. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. add item to basket 4. purchase the item and checkout What about if user want to select more than one items??!! do 2-3 until you select all items you want

35. Example Hierarchical Task Analysis 0. In order to purchase items from the internet 1. go to the website 2. search for the required items 3. select the item 4. purchase the item and checkout plan 0: do 1-2-3-4. if item located on the main screen do 1-3-4. if purchasing more than one item do 1- do 2-3 until you select all items you want - then 4

36. Example Hierarchical Task Analysis 36

37. Example Hierarchical Task Analysis 0. In order to login to email via E-services at KAU 1. go to the website 2. go to e-services 3. select category “employee” or “students” 4. Click “KAU email” 5. select category “employee” or “students” 6. Insert username and password 7. Click “login” 37

38. Textual HTA Hierarchy description ... 0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 4. empty the dust bag 5. put vacuum cleaner and attachments away

39. Textual HTA Hierarchy description ... 0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 4. empty the dust bag 5. put vacuum cleaner and attachments away ... and plans Plan 0: do 1 - 2 - 3 - 5 in that order.when the dust bag gets full do 4

40. Textual HTA Hierarchy description ... 0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 3.1. clean the hall 3.2. clean the living rooms 3.3. clean the bedrooms 4. empty the dust bag 5. put vacuum cleaner and attachments away ... and plans Plan 0: do 1 - 2 - 3 - 5 in that order.when the dust bag gets full do 4 Plan 3: do any of 3.1, 3.2 or 3.3 in any orderdepending on which rooms need cleaning Level 1 Level 2

41. DiagrammaticHTA

42. Diagrammatic HTA What is missing!! 42

43. Summary • Getting requirements right is crucial • There are different kinds of requirement, each is significant for interaction design • The most commonly-used techniques for data gathering are: questionnaires, interviews, focus groups, direct observation, studying documentation and researching similar products • Scenarios, use cases and essential use cases can be used to articulate existing and envisioned work practices. • Task analysis techniques such as HTA help to investigate existing systems and practices

44. References • Based on the slide available at www.id-book.com • http://www.infodesign.com.au/ftp/Scenarios.pdf