The Problem

Previously within OnDemand, a Dispatcher could book only single rides for call-in riders. As services ramped up and new use cases emerged, we found that riders often were frequent, regular riders, taking microtransit to weekly doctor's appointments, school, and work. Dispatchers were forced to create multiple single rides to meet the needs of their riders.

‍

When we took on this body of work, we heard fears from agencies that creating long-running repeating rides would increase the occurrence of riders no-showing and cancelling their rides, which comes at a large cost for the agency. Agencies wanted a way to understand the behaviors of their riders in order to take action to correct the behavior before it became a widespread problem.

‍

On top of these concerns, we were on a time crunch to get this feature out within two sprints in order to meet the pressing need of one our our largest clients.

‍

Discovery

Since we were on such a tight deadline, we decided to take the first sprint for a research and technical spike to really dive in and understand the best plan of attack for the work involved in the Recurring Rides MVP. We immediately kicked off the project by holding a discovery with our members of our CX department who had clients that shared this need. We used an Example Mapping exercise to identify all of the use cases for recurring rides to gain a deeper understanding of the complexity of the problem.

‍

‍

Image Credit: https://cucumber.io/blog/bdd/example-mapping-introduction/

‍

During the discovery, we identified all of the use cases (examples) for the recurring rides feature. These were then bubbled up into business rules, and then stories that went into our development backlog. We also identified any open questions and assumptions made during the Discovery session.

‍

One team comprised of Development and CX squad during the Example Mapping Discovery session

‍

From there, we logged all of the data from our discovery session into a Google Sheet, and started categorizing the use cases into emerging themes. Once all the use cases were grouped, we identified which features we would be address in the first version, a future version, or features we would not be addressing because they fell outside the scope of the team or body of work.

‍

Google Sheet of use cases, groupings, and fix version.

‍

This document lead into a FAQ for our CX for the release of the this feature, based off the questions that arose during the Discovery session, and what was (and wasn't) going to be included in the first release.

‍

Prototyping & Testing

We further validated the V1 version of the recurring rides feature by hopping on our clients' weekly CX check-in calls and running them through high-fidelity prototypes. Our goal was to make sure everything we were leaving out of V1 was acceptable and the feature would still accomplish the majority of our client's goals without over-investing engineering effort to solve edge cases.

‍

‍

In this mockup, you can see minor adjustments to our ride booking panel with the addition of a segmented control for agencies that had multiple ride booking capabilities. You can see the call-to-action at the bottom of the ride booking panel on the left isn't fixed to the bottom. We purposefully did not make this sticky because everything on the panel is required. We wanted to introduce a moment of friction so that Dispatchers had to scroll through all fields in order to submit the ride.

‍

‍

One sticking point of the OnDemand app is our validation. At the time, we weren't able to validate a ride in the side panel before a Dispatcher scheduled the ride. We also had no feedback after a ride was submitted if it was scheduled for the future, since only rides happening for the current service day show up on this Dispatch page. To solve these two issues, we introduced a confirmation modal after a ride was selected. This allowed us to show Dispatchers how many rides were successfully scheduled, we were able to carry through the rider card visual, link out to where the recurring ride instance lived on the Rides tab, and alert the Dispatcher to any booking errors that occurred in the booking process (these errors were rare and resulted from service outages, so there was no corrective action that could be taken).

‍