The Problem

OnDemand is the Dispatcher-facing application for monitoring and booking Mictrotransit rides (think Uber Pool for the public sector). When I was brought on to the team, there were two ways to book rides within OnDemand—a newer experience where Dispatchers can view vehicle locations and in-progress rides, and a legacy floating action button located on the Rides History page (where historical ride data lives). Using Pendo analytics, we found that 60% of Dispatchers were using the legacy Ride Booking FAB, which lead to an unsupported page, to book rides.

‍

60% of Dispatchers were using the unsupported legacy Ride Booking flow.

‍

We wanted to better understand why Dispatchers preferred this unsupported workflow, but we faced one big problem: Dispatchers were our hardest users to contact. In fact, no user testing was done with actual Dispatchers when OnDemand was first designed. This was because our CX department interfaced only with agency Administers, and Dispatchers were often very busy juggling multiple duties during their shifts, or they were third-party contractors outside of the agency or university system altogether.

‍

Legacy Dispatch Page Ride Booking Screen (Accessed by FAB on previous screen)

‍

Newer Dispatch Page Ride Book Screen

‍

‍

‍

Discovery

Getting in contact with Dispatchers was a lesson in persistence and patience. After initial email introductions through CX to Administrators, and two follow-up emails, a portion of Admins were able to contact us with their Dispatch supervisors, and 60-minute interviews were scheduled. We also created two in-app Pendo guides on the new and legacy ride booking flows as a secondary way to gain feedback from Dispatchers. In the end we were able to interview 6 agencies (4 universities, 2 municipalities), and received in-app feedback from 4 agencies (2 universities, 2 municipalities).

‍

In-App Guide of the Rides Page Floating Action Button

‍

‍

Interviews were then transcribed, comments were made on emerging themes within the Google Doc, then themes were pulled in a spreadsheet, and calculated for statistical significance. Once a theme bubbled up to the top, quotes were pulled out to tie the theme to our Dispatchers' narrative. Finally, a findings deck was compiled to educate Stakeholders on the research process, build empathy for Dispatchers and their daily demands, and show evidence for the research findings.

‍

Google Sheet of Research Findings

‍

Findings
‍

We gained a lot of valuable and unprecedented insight into the workflow of Dispatchers through this research initiative which extended even beyond our initial Ride Booking goals. First we discovered when a Rider calls in to book a ride, they naturally state their location and destination initially. In the new Ride Booking workflow. Dispatchers were being forced to take a Rider's name and phone number before validating their ride. This workflow forced Dispatchers waste time entering the Rider's information before they were able to tell the Rider if they could even use the service.
‍

We also learned that the first/last name was not the most useful way for Dispatchers or Vehicle Operators to identify passengers. Names were often hard to understand over the phone, difficult to quickly type, and didn't accurately identify Riders in the way a phone number would. We even heard one agency would just use the last four digits of a Rider's phone number in the name field to identify them as they boarded the vehicle.

‍

"During our peak hours it's difficult to have [riders] spell out their names letter for letter when we’re trying to get through as many calls as possible."

Through this research, we were able to validate that virtually no Dispatchers used the existing account tab on our new Dispatch page workflow. However, Dispatchers did want the ability to store frequent Riders' information, since call-in Riders were often the same riders everyday riding the same route.

‍

Lastly, and most surprisingly, we discovered just how often Dispatchers were navigating outside of OnDemand to Google Maps to understand and validate their Agency's service area.

‍

“I pull up Google Maps and quickly look and find an address that it will accept"

‍

Research findings were then presented to Stakeholders at our team's sprint review. This was a new process for the company in order to publicize the importance of research-backed development. Feedback from the sprint review was overwhelmingly positive, as that level of specific and applicable insight had previously been elusive.

‍

Wireframing
‍

We broke this body of work into two different bodies so that engineering could tackle them in an iterative manner: improved ride booking workflow, and call-in rider accounts.

‍

Improved Ride Booking Workflow

‍

‍

To improve the ride booking panel to meet Dispatchers needs, we grouped like information into visual chunks so that Dispatchers could easily skim the panel to if they chose to enter pickup/dropoff information before rider details. The order of the panel was created so that as a Dispatcher filled out trip details information, the proceeding information filtered down to only valid addresses or service regions available, reducing errors for Dispatcher when booking rides.

‍

Call-in Rider Accounts
‍

‍

During the research process, we discovered that Dispatchers were not using our existing account process because this was managed by the rider on the Transloc app, and call-in riders were not app users. We also discovered that call-in riders were often frequent repeat riders. With this information, we introduced an account concept for call-in rider accounts.

‍

We set out to make this a seamless, integrated process in the ride booking workflow. In the legacy workflow, Dispatchers had to ask the rider to recall if they had an account and find the account using an exact e-mail address. In the new workflow, Dispatchers would fill out the phone number field like normal, and if this email was associated with a previous ride they would be presented with an account match. Once the Dispatcher chose the phone number/account match, the rest of the Rider's information would populate, and they would be presented with recently used trips. After a recently used trip was selected, this area collapse, and the rest of the fields would populate but remain editable for Dispatchers to quickly fix any trip details if needed.

‍

‍

Conclusion
‍

With this large research initiative, we finally were able to get unprecedented access to our Dispatchers and understand their workflow and pain points. I was particularly impressed by the relationships Dispatchers built with their Riders, and all the work-arounds Dispatchers would create for themselves to make the OnDemand product work for their needs. By interview and observing Dispatchers and presenting it back to the company, we were able to build empathy within our CX and Engineering teams and show the impact of their seemingly small daily decisions.

‍

‍

‍