150 likes | 365 Views
ALMOST DEAD ON ARRIVAL. A Case Study of Non-User-Centered Design for a Police Emergency-Response System. Aaron Marcus, Jim Gasperini 2006. S-72.2530 Acceptability and Quality of Services Otto Parantainen 4.12.2008. Emergency-Response Practise. HELP NEEDED. DISPATCHER. POLICE VEHICLE.
E N D
ALMOST DEAD ON ARRIVAL A Case Study of Non-User-Centered Design for a Police Emergency-Response System Aaron Marcus, Jim Gasperini 2006 S-72.2530 Acceptability and Quality of Services Otto Parantainen 4.12.2008
Emergency-Response Practise HELP NEEDED DISPATCHER POLICE VEHICLE
Case study background • San Jose Police Department (SJPD) • June 2004 • Mobile, in-vehicle communication system • Developed in 1990 • Spent years on customizing • Was becoming obsolete
Case study background SJPD appointed a committee to investigate strategies • Managers • IT representatives • At least one dispatcher Upgrading the system seemed to be more expensive than using an ”off-the-shelf” system • Decided to replace it
The new system Intergraph’s I/CAD (Intergraph/Computer-Aided Dispatch System) • I/Dispatcher • I/Mobile Customizing and debugging • Intergraph • SJPD’s IT department
Problems arise (1/2) Officers and supervisors became concerned • I/Mobile crashed upon first roll-out • 3 hours of training (16h recommended) • Incorrect of missing map data • Difficult and confusing to use • Training on desktop PCs • Varying versions in vehicles
Problems arise (2/2) San Jose Police Officers’ Association (SJPOA) • Concerned about the situation • Invited ergonomic & UI analysts to investigate Usability evaluation by Aaron Marcus and Associates, Inc. • Evaluate the software’s user interface • Make preliminary suggestions for repairing or improving the usability
Faults in the acquisition process (1/2) • Usability vs. functionality & cost • Acquisition team did not have a user representative • The users weren’t queried • Evaluation of the finalists • Setting up initial conditions • Customization of functions, layouts, content etc. • No user profiles or use scenarios
Faults in the acquisition process (2/2) • Maps from the city’s Department of Public Works • Minimum training for cost reasons • The onsite Intergraph team members • Not as cooperative as should have been • There had also been problems with other installations of the software
Most severe issues in the UI (1/2) • Difficulty of completing tasks while driving • Eg. Running a licence plate • Indirect rather than direct controls • UI not optimized for touch screen • Pull-down menus • Confusing layout • Poor and inconsistent labeling • Poor filtering of important information • Key facts buried in useless and redudant details
Most severe issues in the UI (2/2) • Information laid out poorly • Key info missing and useless info in prominant places • Problems with sending/receiving messages • Too many steps • Forced tabbing through seldom used fields • Hard to distinguish between important and unimportant messages • Crossing district borders • Issues with mapping and routing • Symbols, colors, text etc. were confusing
Solution to the situation • Letters to management • Also circulated to the city council and the press • News paper coverage • City council began supervising and demanding reports • Intergraph replaced their on site team • SJPD IT management group made a real effort to include officers and lieutenants in review teams
Conclusions (1/2) • A really good example on the effects of neglecting user-centered design • Possible dangers to officers • Annoyed and angry users • Involvement of other organizations • Problems for the dispatchers • Time / expense of the software vendor • Total costs were about the same as a pure custom-solution from the previous software vendor
Conclusions (2/2) • The article didn’t really propose any clear answers • Just pointed out what went wrong • The things happened 4 years ago and the article was written 2 years ago References: • http://www.intergraph.com • http://www.wikipedia.org