Reducing the number of trip cancellations due to unsafe cars.
the problem
Through analysis of usage metrics, it was discovered that the top reason that borrowers were cancelling their trip was the car was not in driving condition option. At this point, car not in driving condition accounted for 43% of trip cancellations.
As the product designer for the borrower experience, this was a concerning for several reasons reasons. Firstly, it would have been a significant negative user experience that many users were encountering poor quality cars and having to cancel their trip, but more importantly that users were hiring potentially unsafe vehicles that should not have been available for hire.
I wanted to better understand what might be contributing to poor quality cars being on the platform, and to further explore how might we reduce trip cancellations due to the car not being in driving condition.
Step 1: research & discovery - understanding The existing safety reporting flow
I wanted to better understand the user experience of how borrowers were submitting a safety issue, and during this research phase I developed a number of hypotheses around what improvements could be made to the existing safety reporting flow.
Placement
The only point in the user journey where a borrower could report a safety issue with the car, was part of the review process that is available at the end of the user’s trip. I felt this placement was not ideal, as it was most likely that a borrower would encounter a safety issue during their trip (not at the end) and it seemed likely that the user would want to report it at the time the issue arose, and not wait until the end of their trip to do so.
In addition to the safety reporting flow only being available at the end of the borrower’s trip, there was no education or awareness for the user that should they need to a report an issue that they are able to do this at the end of their trip when it comes time to submit a review.
In addition to the above, through conversations with the customer support team, it was discovered that users would reach out directly to them which was putting an unnecessary strain on the support team.
Lack of accountability
In the instance when a borrower would submit a safety report for the car, I uncovered a bug where the report was being sent as private feedback to the owner which Uber Carshare was not notified about - despite the app informing the borrower that Uber Carshare would be notified.
As a result of safety issues being reported directly to the owner, and with no oversight from Uber Carshare, there was a lack of incentive or certainty that the owner would address the safety concern for the next borrower.
I also discovered that no tracking had been set up on the ‘safety concern’, resulting in Uber Carshare having no insights or user data as to how many borrowers were flagging or submitting safety concerns once they’d entered the review process.
I developed a hypothesis that car not being in driving condition was the main reason for trip cancellations due to:
Users being unable to report a safety issue at any point during their trip
Uber Carshare were not receiving safety reports, and were unable to follow up with the owner to have these issues fixed
This was resulting in an ongoing cycle of a borrower submitting a safety report, the owner not actioning a repair, and as result the next borrower encountering the same problem with the car.
step 2: ideation & concept development - ideal state vs Minimum viable product
My initial concept was to decouple the safety reporting flow from the review stage, and to make it possible for a borrower to report a safety issue at any point during their trip. This initial concept would allow borrowers to indicate the type of issue they had encountered, as well as the ability to upload supporting imagery, and Uber Carshare would be notified of these reports and be able to follow up with the owner.
After discussions with the engineering team and my PM, it emerged that balancing the scope and complexity of this new safety flow with the squad’s capacity would not be possible, so I looked to ways that my initial concept could be simplified. Engineering advised me at that time that they were limited to only making changes to the existing review flow at the end of the borrower’s trip, and were unable to make changes to the during trip borrower experience.
With these limitations in mind, I was able to explore a concept where the safety concern would be decoupled from the review stage. The borrower would indicate in their review if there was a safety issue, submit their review in the app, and then be taken to a safety reporting flow that already existed on web where they could submit a more in-depth safety report..
Whilst this approach was viewed as low effort and easy to deploy from an engineering point, I had concerns that this MVP approach would not have the desired impact of accurately capturing safety reports from borrowers.
Step 3: Testing & Validation - how did users react to the changes?
I wanted to test the updated safety reporting flow in order to gain user insights that would validate my design decisions. User testing was conducted through interviews with new and existing Uber Carshare borrowers who were provided with hi-fidelity prototypes, and unsurprisingly many users shared similar sentiments:
After presenting to internal stakeholders that the user feedback did not support the proposed changes, I was able to advocate for my initial concept of a more thorough uplift and more engineering resources were allocated to my squad.
Step 4: refinement, testing & validation - next steps for the safety flow
Armed with the user feedback and insights that the safety reporting flow was not performing as expected, this provided justification that the necessary squad resources would be required in order to implement the desired user experience for borrowers to be able to report a safety issue.
My initial idea of a dedicated safety reporting flow within the app was revisited, and designs went through multiple rounds of high fidelity prototypes and iterations to incorporate user testing again with with new and existing Uber Carshare borrowers.
Step 5: Launch & Post-launch - How is the safety flow performing?
After completing the pickup steps, borrowers are now primed that if they encounter a safety issue they can report this either during or after their trip. Borrowers are also prompted at the end of their trip when they have returned the car if there are any safety issues that the owner needs to be aware of.
In addition to these changes, now when a safety issue is reported Uber Carshare’s support team receives a copy of the report, allowing them to ensure that the owner is addressing the issue.
Since the release of the updated safety reporting flow, now 88% of all of Uber Carshare’s safety reports are captured in the app. In addition to this, cancellations due to car not being in driving condition has decreased from 43% down to 13%.