|Project Name:||Trouble Call Application (2012)|
|Type of Project:||Emergency phone call logging|
|Primary Roles:||usability testing, front-end coding, ui design|
Defining the Problem
The outage center takes calls from staff and the general public regarding power issues (downed power lines, unplanned power outages, storm “bust ups”, etc.). Once they have the appropriate details on what the situation is, they dispatch crews to fix the problem. They needed to move off of their logging/dispatch system because it was on an old mainframe machine that was being decommissioned. Unsurprisingly, it was also outdated, slow, and missing features. Our team was asked to work with the .NET group to provide a new solution. I was tasked with front end coding, assisting with UI and graphic design, and testing prototypes with users.
Understand the User
Unlike a lot of projects, we knew exactly who the users were: the people that work at the outage center. It’s certainly nice to be able to test with 100% of your user base!
We quickly found that these people were “power users”. Step by step or ‘wizard’ style interfaces were not appropriate for this project. They are in this software all day, every day. A complex interface would be okay, as long as they can get up to speed quickly with any new features.
We also realized that the work the users do is crucial. If the app doesn’t work properly, it would cause huge stress for the user, it could mean bad press for the corporation, and most importantly it could put people (staff and customers) in harm’s way.
Many brainstorm sessions took place as there were many more groups involved than usual. We needed to be especially considerate to the needs of the .NET group (who were new to the corporation), very demanding users (the end product needed to work quickly, and flawlessly), and an outside graphic designer that we’d never worked with before.
Make it fast for the user—not an easy task! The previous version was old, but well used; people could fly around screen using keyboard alone. Although we only got to test with the users one time, we did get to observe them working. Watching them was like watching a pianist. They didn’t need to think about the keys they were hitting—it was second nature to them now. We needed to bring that same fluency to the new application.
- Replace existing trouble call (CSTC) functionality with a custom built trouble call solution (.NET)
- Fix specific issues with current system (problems with duplicate entries, better reporting)
- No mouse, all keyboard shortcuts.
- Need specific search requirements (custom wildcards)
- Make it resemble the old system as much as possible, especially important were tab order, placement on screen.
- Fill in gaps in process that older version didn’t have.
- Keep code TIGHT so would load fast.
Unfortunately, even though we had 100% of the users, their time was tight. We showed wireframes, walkthroughs, and graphic designs to their manager, but would only got to test with users once. To try and mitigate the lack of user testing, we did cognitive walkthroughs and heuristic evaluations on HTML coded mock-ups.
Develop Testing Plan
Main goals of testing were:
- Show users the ‘final’ design.
- Validate the application flow correlates to the work flow of the outage team
- Keyboard shortcuts worked as expected
- Ensure the experience was at least as fast as current system
Four task scenarios were developed and tested with five of the users.
Test Results Document
We took the feedback from our testing and tweaked the layout slightly, but sadly, the app was pretty much already built, so no major changes were implemented. This is unfortunate as during testing there seemed to be an overall sense of frustration. The users were happy with what they had and were very resistant to change.
This project taught us how not to do a lot of things. Lessons learned include:
- Test with users, not their manager
- Work out UI/workflow issues on paper way before getting graphic design involved
- Test many times before starting high fidelity mock-ups/prototypes.
- Don’t finish developing the app before testing is done!
- Follow up with users! We did the ol’ “launch and leave” and had no idea if the product was working out for the users or not.