The original desktop application was used across IAA branch operations to facilitate the movement of salvaged vehicles in need of being towed. As the number of vehicles increased, business would require Dispatch to perform more and more complex operations.
Success of the application would be determined on complete adoption by its users.
All information in this case study is my own and does not necessarily reflect the views of IAA
In July of 2015 we had started Visioning and Discovery phases of the project where I led design of the Dispatch Management (DSPM) application, an enhancement of sorts for the original Dispatch (DSP).
I worked alongside our development team to implement the presentation layer (HTML/CSS) when we launched in September 2015. I continued to provide enhancements to both DSP and DSPM throughout the remainder of my employment at IAA.
1. Dispatch Listing
2. Dispatch Mapping
3. Tow Batch Review
4. Dispatch Management
In January 2018, I set out to redesign the DSP and DSPM to demonstrate internally to our teams the benefits of user informed design. Seven months later, I rolled out my findings as part of a case study that I delivered to team leads and members, in conjunction with an angular application proof-of-concept I developed, to help address usability and performance oversights.
I originally performed interviews with our branch users as early as December 2014. For a full transcript of details, click here
Dispatchers, reluctant to abandon IAA's legacy platform, needed new ways to manage stocks, citing poor performance, usability issues, and a bloated interface.
As previously mentioned, DSPM was built to solve those problems. While it was successful, it still did not address feedback discussed during user research and testing.
So although DSPM had solved the initial issue of managing stocks, it created a whole new set of problems for DSP. My goal for the "improved" DSP/DSPM was to leverage our knowledge of the user and to improve overall experience.
- Better integrate DSP/DSPM by deconstructing and rearchitecting a new workflow
- Provide a responsive, modern layout and ui
- Remove and/or consolidate redundancy
While I had a general idea of what I wanted to accomplish, I still needed to validate my course of action. This meant exhuming whatever materials I had to support my case.
In total, I completed interview and screen share sessions with 6 branches, the smallest being Oklahoma City and the largest being Houston, as well as 2 trainers.
|
Small Branches |
Medium Branches |
Large Branches |
Listing Screen |
Larger branches favored the listing screen while reacting negatively to the mapping screen.
Smaller branches were indifferent but used the table in the listing screen differently than larger branches. Atleast 2 Branches suggested they would like to consolidate both into one screen
|
|
|
|
All large branches indicated they would like to remove pagination while medium and smaller branches preferred to paginate their results
|
|
|
|
5 of 6 of Branches suggested that they would prefer to add/remove columns from the listing screen data table
|
|
|
|
Mapping Screen |
Half of branch users interview indicated that most pin icons hold little meaning or relevance and could be removed
Trainer Comments: too many pins in legend confusing to users
|
|
|
|
Atleast 1 Branch suggested a counter for selected stocks
Trainer Comments: the distinction between selected and unselected stocks on the map could be stronger.
|
|
|
|
It was found that in larger and medium sized branches (2 of 6 branches), maps are printed and given to tow companies create their own routes, rendering the generate routes functionality useless
Trainer Comments: “Generate Route” needed at the smaller branch level but not at the higher branch level
|
|
|
|
Review Screen |
5 out of 6 branches agreed that the ability to logout and manage check payments for stocks in bulk would be beneficial
Trainer Comments: current system was too cumbersome to logout one at a time in legacy
|
|
|
|
At least one branch felt that the tabbed sections in the modal were difficult to read, citing font size, shading, and redundancy as the main cause.
|
|
|
|
What I discovered in my process was that there were glaring differences in preferences between large and small branches. I was also surprised to find that the legacy platform showed real advantages over the modernized application, particularly with the time it took to complete the dispatch process as well as training involved with newer users.
I was willing to reconsider the assumption that a more modern interface is a better interface. Underneath it all, users valued accomplishing their task faster over the options and features given to them in this modernized experience.
A lot of the negative feedback embedded in user voices was based out of a similar frustration. “How do I accomplish my task faster”? So by consolidating functionality and providing users the ability to say, keep settings, I was able to remove layers of repeated steps needed to perform the necessary tasks.
First, I needed to deconstruct DSP’s many features by helping the user concentrate on one task at a time. As a result, I wanted to explore using mobile first methodologies.
A. Shortening the Journey
I began to think of the “List”, “Map”, and “Review” dispatch screens as a form with 2 steps - “Select” and “Dispatch” with complete visibility of the entire process on one screen. Validation would prohibit the user from skipping steps.
B. Consolidating "List" and "Map" Screens
An observation made during the interview session was that a lot of data was duplicated from map to listing screen. No longer would users have to select stocks from a list and then refine that search within a map. Now a user could toggle between selecting stocks from a list OR a map while still fulfilling the same requirements.
C. Treating features as secondary
Redundant tasks such as selecting a branch, filtering stock lists, or adding/removing table columns could be performed once or even saved to a user’s preferences. It would always remain accessible within the applications settings or feature panel.
D. DSPM History
When designing the original DSPM screen we couldn’t load all dispatched stocks or the application would crash and so search criteria was added. But for the MDSP, I proposed users could also search using an associative list of dispatched stocks based off date.
1) User selects a branch
2) User creates a batch of stocks by selecting from a map or list
3) User selects a tower to carry out the dispatch
4) After completing a dispatch, user chooses to dispatch more stocks or manage existing dispatched vehicles
5) User selects a batch to manage
6) User selects an action to perform against the dispatch stocks
Overall, users felt the "improved" DSP/DSPM interface was pretty intuitive and a step up from the previous design. However, initial testing showed that after completing a dispatch, it became less clear what to do after a dispatch was submitted. The results were encapsulated and used to inform the development of the angular application that I was building in tandem with the mobile design.
I delivered both the Mobile POC as well as Angular POC to an internal team of designers and developers.
I did not expect to change minds overnight but I do think that I was successful in presenting the
case for user driven development which is commonly overlooked when delivering minimal viable product.
Tools
Sketch, Invision, Material Design Kit