Task Analysis IST 331 Zachary Beard & Frank Ritter Based on Ritter et al oct 2015

Task analysis A description of how to do the task – Just a list, – A network – Timing predections – A program that can do it itself, e.g, Nasa Pride, or, you can do it Many methods Many uses – Describing, understanding, predicting behavior – Comparing designs (old vs new, competing) – Checking task support – Training users, creating manuals – Predicting mistakes – Allocating tasks to multiple users

Task analysis Many ways to collect data to build a TA – For instance, in the New England Telephone case, performance on the existing system was measured using videotaped records of usage, but performance on new system was predicted using system specifications

Task analysis Not always useful in and of themselves However, – A good UI designer can use them to spot problems, suggest improvements – They also add to a designer’s store of experience and expertise, thus helping him or her understand users better

Example: EMS/Hospital Comms Problem: EMS arrives at hospital with patient unannounced – EMS called ahead with patient info, but no-one picked up the phone Observe process from both ends – Ambulance – Hospital Patient Info as a package – Who has the ball? 5

Visualized Workflows Assess/Treat Patient Arrive at Hospital, meet with ED nurse Place patient in Hospital Room, begin treatment. Determine which room to place patient in and Dr. for initial treatment. Place hard copy of report outside patient’s room. EMS Hospital Technology Receive patient, exchange further info with EMS. Hospital Phone Medical Command Phone/Radio Call Hospital with Patient Information Send 12-lead EKG data Wi-fi, Cellular, or Radio Announce to Radio Network Open EMS Radio Frequency EMS/Police Frequencies monitored for situational awareness Receive Call from Dispatch Receive Call from EMS, begin patient report. Attach 12-lead data to patient report Beard, 2015

Hierarchical TA Decomposing goals into subgoals, revealing order and structure More of a representational device than a technique – Data could be gathered in multiple ways – Not a detailed approach, suggestions are not detailed Easiest method – no actual UI required, can be done quickly and early, can be converted into a GOMS analysis later

Hierarchical TA

GOMS Created by Card, Moran, Newell in 1983 Goals, Operators, Methods, Selection rules – Goals: desired states of affairs – Operators: motor, cognitive or perceptual actions – lowest level of granularity – Methods: procedures for achieving goals/subgoals – Selection rules: rules for selecting the best method (when multiple methods are available)

GOMS Specifies error-free, expert behavior – However user may not be trained Acknowledges that multiple strategies may be available to achieve a goal Makes explicit the lowest level of granularity (compared to HTA)

GOMS Problem: no such thing as ‘error-free performance’ – Still better than nothing though – See new work by Paik, Kim, Ritter, & Reitter Problem: Where to get the specification for selection rules? Current context implied, but previous selections could also be used in real life

GOMS Basic GOMS doesn’t support task interleaving/multitasking – variations exist that add support – The New England Telephone case used CPM-GOMS – multi-tasking during slack time was a critical part of the analysis