Redesigning the Bridj Driver App
The Bridj driver app guides our drivers on routes that have been created by our internal data science team as well as communicates information to the traveler app. It also served as a means of getting the drivers familiar with a digital interface as we shifted our service to dynamic routes based on user requests. Before fully implementing those changes, the app required some design tweaks.
The original driver app displayed the route stops and trip schedule, plus some basic interactions to indicate reaching and leaving each stop. Drivers learned the route path during their introductory training and followed the same directions every trip. With the development of dynamic service, our routes and stop plans would be changing dependent on user requests, so turn-by-turn directions needed to be implemented and tested thoroughly before our drivers could rely on them. Without a seamless navigation experience in place, not only would our drivers' experience suffer, but our customers' experience would deteriorate as well.
One of the primary objectives of designing the original driver app was to limit the analog interactions drivers had with it in order to keep distractions at a minimum. The only contact necessary was a single tap while stopped upon arriving and leaving each stop. Adding turn-by-turn directions onto the screen would create an additional minor distraction and any other improvements that I chose to make during the development cycle would need to be mindful of this. Luckily, our vehicle tracking had greatly improved since the first implementation of the app, and I was able to begin testing an auto-reach feature that could automatically detect when a vehicle was approaching and departing stops. This removed the biggest touch point obstacle that drivers had to deal with, reducing their cognitive load and freeing up some attention for the turn-by-turn directions. The progression buttons were kept as a backup in case of technical issues.
Sketches: A significant challenge in designing the new interface came in balancing the trip details with the map view, making sure all elements were clearly visible at a glance. As a tablet-based app, plenty of screen real estate is available but buttons and text still need to be extra large as to not be a hindrance to a driver during their shift.
Qualitative Research: After putting together a couple of low-fidelity mock-ups and reviewing their technical feasibility with the production team, I went out to the driver lot to interview drivers as they wrapped up their shifts with the goal of getting feedback on the proposed design layout, as well as gather any additional thoughts they had on what we could do to improve the service for them. Much of their feedback focused on the visibility of each screen element when viewed at a glance while driving, particularly taking into account the wide age range of our drivers and their visual acuity. Additionally, I discovered that many drivers would tap through each step of their entire trip before driving to view the number of confirmed riders boarding at each stop. Not only was this an unnecessary hoop for them to jump through, it occasionally caused the drivers trip to permanently close prematurely, which then required a remote reboot by our operations team to resume proper service. This also lead to excessive use of the back button, which was already difficult to hit and only meant for infrequent use.
In addition to the UI redesign, the integrated turn-by-turn directions required their own testing for functionality and usability. We began by implementing the Nokia HERE SDK into a rough prototype and began driving our existing bus routes through the city, using HERE maps to guide us. This quickly lead to discovering some glaring problems with the vehicle tracking accuracy and viewing angle of approaching route directions. After making some adjustments to the most critical issues, the prototype was distributed to a small group of our drivers for additional testing and feedback, and eventually to the entire fleet. Drivers were able to give feedback on the fly through Slack or e-mail and I visited the driver lot once more to review the last round of changes based on their previous comments.
This design update smoothly transitioned our driving fleet to a new user interface in preparation for implementing our fully dynamic routing system. Though it still operated on our predetermined static routes, I was delighted to find it making minor route modifications in real time depending on traffic flows that avoided long delays and kept vehicles running even more efficiently. It also streamlined drivers' ability to preview their imminent passenger counts as well as simplified our operations team's workflow. Lastly, it greatly reduced usage of the awkward back button, which meant it's functionality could be delegated to the default Android back button, freeing up screen real estate and reducing visual confusion. Work continues on this as we begin to fully integrate our dynamic routing system and a new traveler app to accompany it.