Below are the primary issues and associated questions that my team addressed in order of priority. We prioritized issues in this way because it made the most sense from the mobile developer's perspective and the team agreed that, by fixing the first two issues, we'd be better set up to respond to the needs of install technicians moving forward.
When the app was working, it did provide some feedback but it came in the form of a meaningless loader and text that quickly flashed across the screen before disappearing. Technicians found this experience frustrating and it diminished trust in the app.
As is often the case, the app's error messages were seemingly not intended for human consumption. This was especially problematic given the range and likelyhood of errors that could occur when dealing with bluetooth, wifi, LTE, humans, AND a motor vehicle.
The main screen of the app displayed a list of nearby VQ devices. In a crowded parking lot, it wasn't always obvious which device was correct. There was also a general lack of detail provided in the list.
For many, pulling down on a mobile screen to refresh a list feels like second nature. But, if that's not a gesture you're familiar with and refreshing is necessary to complete some tasks in your app, the refresh mechanism should be very discoverable. Add to this the complication that refreshing can sometimes be disruptive or technically expensive, i.e., using more data or power than necessary, then you'd better be very careful about how it's implemented.
The previous app experience during VQ installations presented technicians with a flurry of messages, some only lasting a fraction of a second. I collaborated with the mobile dev and firmware engineers to decipher what was happening during this process and essentially translate what all these messages meant. We organized the different messages into categories based on things like the type of communication occurring, e.g., VQ-to-cloud vs. phone-to-cloud, and, most importantly, points of failure. This turned out to be crucial for solving the issue of poor error messaging (see section two below).
I'll admit that it wasn't immediately clear to me why technicians frequently complained about this part of the experience, even when no errors occurred. After all, the app was clearly doing something during this process, and what did they care what was going on in the background? It wasn't until speaking with them directly that I realized what they were looking for was a sense of empowerment. Given all of the potential things that could go wrong in this process, they wanted to know exactly what the app was doing during each step so they could take action as soon as possible.
An important part of this solution was the inclusion of animations to indicate the flow of data. By displaying icons of the phone and VQ device on the install progress screen, I was able to indicate exactly what type of communication was occurring during each step. This was especially well received by install technicians because it allowed them to quickly identify what was happening and respond if needed—finding better cell coverage for cloud-to-phone events, for example.
The mobile dev and I went through a long series of trial and error to get these animations just right. At first we tried animated GIFs but the file sizes were too large and the quality was not great. We also considered using small videos but that turned out to be impractical. The solution we arrived at was Airbnb's Lottie. I created the high-framerate animations in Adobe After Effects and handed off the tiny Lottie files (~12k per file 😎) to the developer who was able to quickly install the library in Xcode.
There was a frustratingly large variety of reasons a VQ installation could fail, and the initial implementaion of error messaging gave technicians little to no insight. By collaborating with VQ customer support, the dev team, and install technicians, I created an inventory of the different failure states for the app and incorporated appropriate solutions—either through improved copy, or by branching the app into further actions that install technicians could perform.
One example of a frequently encountered error occurred when a VQ was plugged in and failed to identify a vehicle identification number (VIN). This typically happened on older-model vehicles and required install technicians to call customer support to have the VQ and VIN associated in the database manually. I collaborated with the database team and others to incorporate these extra steps into the app, allowing the install technicians to complete any installation without external help.
An important part of this solution was the inclusion of animations to indicate the flow of data. By displaying icons of the phone and VQ device on the install progress screen, I was able to indicate exactly what type of communication was occurring during each step. This was especially well received by install technicians because it allowed them to quickly identify what was happening and respond if needed—finding better cell coverage for cloud-to-phone events, for example.
The mobile dev and I went through a long series of trial and error to get these animations just right. At first we tried animated GIFs but the file sizes were too large and the quality was not great. We also considered using small videos but that turned out to be impractical. The solution we arrived at was Airbnb's Lottie. I created the high-framerate animations in Adobe After Effects and handed off the tiny Lottie files (~12k per file 😎) to the developer who was able to quickly install the library in Xcode.
One of the first problems that I observed in the original version of the app was how difficult it could be to identify and select the correct device. There was an audio locate feature for confirming the correct VQ by making it beep, but the feature was not super discoverable and the tap target for the button was quite small. There was also no way to discern a previously installed VQ from one that was ready to install. I generally cleaned up the UI and thoroughly tested the results to confirm everything had improved.
Another element that I pushed for in this solution but was unable to get included were vehicle photos. I had a hunch that including an image of each vehicle could go a long way toward making visual recognition faster and more seamless. I confirmed this by including vehicle images in prototypes and clocking the improved recognition times. Ultimately, the idea of including images was abandoned for performance reasons, but the research turned out to be invaluable for a subsequent project (see Epilogue below).
An often requested feature that wasn't in the app's initial version was the ability to refresh the device list. Without this feature, early versions of the app refreshed automatically, causing disruptive shifting of the list and unwanted taps.
When I recommended adding pull-to-refresh, the mobile dev suggested that it might be too advanced of a gesture to include for our audience. I initially baulked at this suggestion, then I setup interviews with installers and confirmed that the dev was correct—pull-to-refresh was not necessarily a ubiquitous or discoverable gesture for all those using the app.
The comprimize solution that we implemented turned out to be benefitial in two ways: it leveraged the pleasantly smooth experience of pull-to-refresh while providing a clear and persistent indicator of when refreshing might be necessary. This last point was important because refreshing the list was not a trivial action—it measurably increased battery drain for both the phone and vehicle by forcing greater bluetooth activity.
By almost every measure, the VQ Installer project was a success. The end results of the above solutions was that install technicians could complete their work and get paid faster, without outside help in almost every case, and Derive was able to honor its ambitious commitments to Comcast. This project also set a benchmark for a design-led, research-based approach at Derive.
Early in my work on the VQ Installer app, I began hearing ideas and suggestions from throughout the organization about other features that, given Derive's product roadmap and the nature of the VQ itself, would eventually need to be incorporated into an app. According to the mobile dev team, the Installer app itself was not an ideal place to incorporate these features, so I collaborated with the Installer app's product manager to document, sketch, and prototype what this more robust application might look like. Thus the VQ Utilities app was born.
Rather than focusing on the VQ itself, the Utilities app was a much more vehicle-centric application. By simply scanning a vehicle's VIN, the app could unlock a range of options for managing, monitoring, and upgrading various features of the vehicle including improved fuel efficiency and added safety. This application became one of the primary projects of the mobile dev team and was still in Alpha when I left Derive in January 2022.