COMPSCI 345 S1 C and SoftEng 350 S1 C Discovery: Interpretation and Documentation Lecture 7 Chapter (Heim)

Discovery The voyage of discovery is not in seeking new landscapes but in having new eyes. (Proust, 1982) Discovery Phase Framework Collection Interpretation Documentation 2 © Heim 2008

Discovery Phase Framework During the discovery phase we must find out what we will need to know about the work that people do –We must understand what data is needed to create the design –We must create the proper tools to gather and interpret that data 3 © Heim 2008

Interpretation After collection you interpret the information by: –Creating descriptions of the people who do the work –Describing the different goals involved in the work –Documenting the work step by step –Creating different stories about how the various aspects of the work are done –Creating charts and diagrams of the work flow –Tracing the different stories identified with the various people through the charts and diagrams 4 © Heim 2008

Organizing the Discovery Process The data collected must be organized and transformed into information The tools we will explore include the following: –Task analysis –Storyboarding –Use cases –Primary stakeholder profiles 5 Interpretation means going from data to design requirements © Heim 2008

Task Analysis Task analysis is a way of documenting how people perform tasks A task analysis includes all aspects of the work flow It is used to explore the requirements of the proposed system and structure the results of the data collection phase Task decomposition –A linear description of a process that captures the elements involved as well as the prevailing environmental factors. Hierarchical task analysis (HTA) –HTA provides a top-down, structured approach to documenting processes. 6 © Heim 2008

Task Analysis - Task Decomposition Identify the process Describe the steps Include the following: –The reasons for the actions –The people who perform the actions –The objects or information required to complete the actions Should try to capture: –The flow of information –Use of artifacts –Sequence of actions and dependences –Environmental conditions –Cultural constraints 7 © Heim 2008

Task Analysis - Task Decomposition Task decompositions include: –Goal—This defines the top-level goal for the analysis E.g. Schedule a team meeting –Plans—Describe the order and conditions required to proceed with subtasks E.g. Reserve the conference room, A.V equip. based on availability of team members –Information—This includes all of the information you need to perform the task E.g. Team member contact info, conference room schedule, A.V equip. use procedures –Objects—These include all of the physical objects you will use to find the information E.g. Conference room calendar, team address book, A.V sign-up sheet. 8 © Heim 2008

Task Analysis - Task Decomposition –Methods—These are the various ways you can proceed. E.g. Can contact team via , IM, phone etc… –Objectives—These are the subgoals E.g. Contact team members, Coordinate schedules, book room, book A.V equip, confirm meeting with team –Procedures—These are the triggers that may initiate contingency activities E.g. Coordinate schedules, Check room & A.V bookings –Contingencies—These will describe what you need to do if one of your methods does not work E.g. If you get no response from try other methods of communication. 9 © Heim 2008

Task Analysis - HTA 10 First part of the HTA of the “schedule a team meeting” task. Start with a specific goal and then add the tasks or subgoals required to achieve that goal. Overall goal Subgoal Contingencies © Heim 2008

Task Analysis - HTA 11 Second part of the HTA of the “schedule a team meeting” task. © Heim 2008

Storyboarding Storyboarding involves using a series of pictures that describes a particular process or work flow –Can be used to study existing work flows or generate requirements. –Can facilitate the process of task decomposition –Used to brainstorm alternative ways of completing tasks. 12 © Heim 2008

Use Cases Use cases represent a formal, structured approach to interpreting work flows and processes –Designed to describe a particular goal and explore the interaction between users and the actual system components. The two main components: –Actors: similar to stakeholders, but can also include other systems, networks, or software that interacts with the proposed system. –Use Cases: Each actor has a unique use case, which involves a task or goal the actor is engaged in. Describe discrete goals that are accomplished in a short time period Describe the various ways the system will be used and cover all of the potential functionality being built into the design 13 © Heim 2008

Use Cases Example 14 Use case diagram of “schedule a meeting” process. Use Case Actor © Heim 2008

Use Cases Can be diverse paths through a Use Case –Basic Path: The primary path through the use case is the one that is completed without any diversions from error conditions or extenuating circumstances –Alternate Path: Alternate paths test the exception-handling capabilities of the system. They capture premature termination of a process, choosing of a different method and possible error conditions –Scenarios: Each unique path through the use case is called a scenario. Scenarios represent discrete instances that combine to create the complete use case. They are the lowest level of the use case and should cover all conceivable paths and alternatives. 15 © Heim 2008

Primary Stakeholder Profiles Primary Stakeholder Profiles are used to define the target user The constructs covered include: –Context of use –Cognitive ability –Physical ability –Individual profile 16 © Heim 2008

Primary Stakeholder Profiles Context of Use for a common office desktop system 17 © Heim 2008

Primary Stakeholder Profiles Cognitive Abilities of the target user affect the design The cognitive abilities of the target user may be specific or more general Note: Domain expertise may not correlate with computer literacy 18 © Heim 2008

Primary Stakeholder Profiles Physical Ability: the human condition includes wide ranges of abilities –visual –auditory –haptic 19 © Heim 2008

Primary Stakeholder Profiles Individual profiles: There are situations when personal user information is required –E.g. if you are designing educational software you may want to specify age by grade level. 20 © Heim 2008

Documentation Mission Statement –Project goals: What is the value proposition? What needs will the new system address? How will it address these needs? –Project scope What does the proposed design include or exclude? What are the external constraints such as time and finances? How will you decide when it satisfies the design proposal? 21 © Heim 2008

Documentation Requirements Document –Requirements Functional –basically a list of required features Information – what info. is needed to carry out functional requirements Physical – hardware? Also consider interoperability with legacy systems –Inputs/outputs –Constraints - e.g. time, money, security… 22 © Heim 2008

Documentation Project Management Document –Definition of the tasks involved in the project –Risk – e.g. time, money, security, safety –Evaluation criteria and methods –Implementation –Training requirements –Maintenance –Future needs 23 © Heim 2008

Case study: A Real-time Anaesthesia Diagnosis Display System with Multi-modal Alarms Anaesthetists have an overwhelming amount of data available Rare, but possibly fatal conditions, can be identified by automatic diagnostic software Protocols for treating these conditions are well researched, but there is not time to ‘look up the book’ Operating theatres are noisy crowded places, when things go wrong they can get chaotic This project is the interaction design for RT-SAAM 1 that uses a range of AI techniques to identify critical conditions The current RT-SAAM interface is a test interface as apposed to a ‘user interface’ 24 Tyler Yang, Ken Lee, Beryl Plimmer & Michael Harrison, OZCHI 2008 Current RT-SAAM User interface

Case study: A Real-time Anaesthesia Diagnosis Display System with Multi-modal Alarms User Centred Design Approach: Collection –Observation Field trips to simulation operating theatre –Direct Elicitation Interviews with anaesthetists and RT-SAAM team Expert consultation –Indirect Elicitation Analysis of data provided by RT-SAAM –Research Review of previous work 25 Tyler Yang, Ken Lee, Beryl Plimmer & Michael Harrison, OZCHI 2008

Case study: A Real-time Anaesthesia Diagnosis Display System with Multi-modal Alarms Interpretation & Documentation: Identified requirements & constraints of interaction –Visual There are many visual interfaces vying for attention in a crowded space –Audio Likewise there are lots of audio alarms Studies show that they have low recognition rates There are standards for alarms –Input Please no keyboard! 26 Tyler Yang, Ken Lee, Beryl Plimmer & Michael Harrison, OZCHI 2008

Case study: A Real-time Anaesthesia Diagnosis Display System with Multi-modal Alarms Design –Use of personas and scenarios –Lo-fidelity prototyping Discussion of audio options –Alarm sounds –Generated speech Issues with sound being serial rather than parallel Bluetooth headset to direct and restrict output to anaesthetist Touch screen input 27 Tyler Yang, Ken Lee, Beryl Plimmer & Michael Harrison, OZCHI 2008

Case study: A Real-time Anaesthesia Diagnosis Display System with Multi-modal Alarms Implementation 28 Tyler Yang, Ken Lee, Beryl Plimmer & Michael Harrison, OZCHI 2008 Pulsing Green ‘all is well ’ Monitored conditions displayed on request

We have now covered discovery, the first part of the design process model Next lecture: Design – Conceptual (Heim Ch. 5.1 – 5.3) Summary: The Design Process Model 29

Questions Draw a use case diagram for reserving a book from the library. When constructing primary stakeholder profiles describe situations where cognitive ability must be specific and where it is more general 30