Reducing the number of trip cancellations due to unsafe cars.

Problem

Analysis of usage metrics revealed that the top reason borrowers were cancelling trips was that the car was not in driving condition. At the time, this accounted for 43% of all trip cancellations.

As the product designer for the borrower experience, this was concerning for several reasons. Firstly, it represented a significant negative user experience, as many users were encountering poor-quality cars and having to cancel their trips. More importantly, it meant that users were potentially hiring unsafe vehicles that should not have been available for hire.

I wanted to better understand the factors contributing to poor-quality cars on the platform and explore ways to reduce trip cancellations due to cars not being in driving condition.

Step 1: Research & Discovery – Understanding the Existing Safety Reporting Flow

I wanted to better understand how borrowers were submitting safety issues. During this research phase, I developed several hypotheses on how the existing safety reporting flow could be improved.

Placement

The only point in the user journey where a borrower could report a safety issue was during the review process at the end of their trip. This placement was not ideal, as borrowers were most likely to encounter safety issues during their trip, not after. It seemed likely that users would want to report issues as they happened, rather than waiting until the trip concluded.

Additionally, there was no education or awareness to inform users that they could report a safety issue at the end of their trip. Conversations with the customer support team revealed that users were often reaching out directly to support, putting unnecessary strain on the team.

Lack of Accountability

When a borrower submitted a safety report, I uncovered a bug where reports were sent privately to the owner, without notifying Uber Carshare—despite the app indicating otherwise. As a result, there was no oversight, and owners had little incentive to address the issue for future borrowers.

Furthermore, no tracking had been set up for safety concerns, meaning Uber Carshare had no insights into how many borrowers were flagging safety issues during the review process.

Hypothesis

I hypothesised that “car not in driving condition” was the main reason for trip cancellations due to:

  • Users being unable to report safety issues during their trip.

  • Uber Carshare not receiving safety reports, preventing follow-up with the owner.

This created a cycle where a borrower would submit a safety report, the owner would not address the issue, and the next borrower would encounter the same problem.

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 make it possible for borrowers to report a safety issue at any point during their trip. This would allow borrowers to indicate the type of issue encountered, upload supporting imagery, and ensure Uber Carshare was notified so they could follow up with the owner.

However, after discussions with engineering and my PM, it became clear that balancing the scope and complexity of this new flow with the squad’s capacity was not feasible. Engineering advised that, at the time, they were limited to making changes only within the existing review flow at the end of a trip, and could not make changes to the in-trip borrower experience.

With these constraints in mind, I explored a simplified concept: safety concerns would be flagged within the review stage. After submitting their review in the app, borrowers would be directed to an existing web-based safety reporting flow where they could provide more detailed information.

While this MVP approach was considered low effort and straightforward to deploy from an engineering perspective, I had concerns it would not achieve the desired outcome of accurately capturing safety reports from borrowers.

Step 3: Testing & Validation – How Did Users React to the Changes?

I tested the updated safety reporting flow to gather insights and validate my design decisions. User testing was conducted through interviews with new and existing Uber Carshare borrowers, who were provided with high-fidelity prototypes. Unsurprisingly, many users shared similar sentiments about the proposed flow.

When presenting the findings to internal stakeholders, I highlighted that user feedback did not support the MVP approach. This allowed me to successfully advocate for my initial concept of a more robust uplift, and as a result, additional engineering resources were allocated to my squad.

Step 4: Refinement, Testing & Validation – Next Steps for the Safety Flow

Armed with user feedback that the safety reporting flow was not performing as expected, I was able to justify the need for additional squad resources to deliver the desired user experience: enabling borrowers to report safety issues more effectively.

My original idea of a dedicated in-app safety reporting flow was revisited. Designs went through multiple rounds of high-fidelity prototyping and iteration, incorporating further user testing with both 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 to report safety issues either during or after their trip. At the end of the trip, when the car is returned, borrowers are prompted again to confirm if there are any safety issues the owner should be aware of.

In addition, whenever a safety issue is reported, Uber Carshare’s support team now receives a copy of the report, ensuring oversight and accountability so owners address issues for future borrowers.

Since the release of the updated safety reporting flow:

  • 88% of all safety reports are now captured directly in the app.

  • Trip cancellations due to “car not in driving condition” have decreased from 43% to 13%.