Making Uber Carshare safer for borrowers, owners, and the business.
Overview
As the sole designer for Uber Carshare's borrower squad, we'd identified that our trip cancellation rate was unusually high, but the data didn't tell us why.
To get closer to the problem, I borrowed a car myself to experience the flow firsthand. What I found was worse than a UX issue: borrowers were encountering unsafe vehicles with no reliable way to report them, and Uber Carshare wasn't even receiving the reports that were submitted.
This project became about more than reducing cancellations, it was about making the platform safer, rebuilding borrower trust, and closing an accountability gap that was quietly undermining the business.
Research & Discovery
My research started with the support team, who confirmed borrowers were cancelling trips at an unusually high rate but couldn't shed light on why. To dig deeper, I reviewed the existing borrower flow across both app and web — then borrowed a car myself to experience the full journey end-to-end, from booking through to trip completion. This hands-on research surfaced several issues with how safety concerns were being handled.
Placement
The only point in the borrower journey where a safety issue could be reported was during the post-trip review - but borrowers were encountering problems during their trip, not after. There was also no in-app education to let borrowers know this option even existed, so many were contacting support directly instead, adding unnecessary load to the team.
Lack of Accountability
Digging into the existing flow, I uncovered a critical bug: when a borrower submitted a safety report, it was sent privately to the car owner - not to Uber Carshare - despite the app indicating otherwise. There was no oversight, no tracking, and owners had little incentive to act. The same unsafe car could be reported repeatedly with no follow-up.
Hypothesis
The data pointed to one likely culprit: borrowers were cancelling trips because cars weren't in a safe or acceptable condition, and the current flow gave them no way to flag it in the moment. Combined with the routing bug, this created a feedback loop where a borrower reports an issue, the owner never hears from Uber Carshare, and the next borrower encounters the same problem..
Ideation & Concept Development
My initial concept was to decouple the safety reporting from the end-of-trip review entirely, and to give borrowers the ability to flag issues at any point during their trip, upload supporting imagery, and ensure Uber Carshare was notified directly.
However, engineering and my PM pushed back on scope. At the time, the squad was constrained to changes within the existing review flow only, so the in-trip experience was off the table.
Working within those constraints, I explored an MVP: surface safety reporting within the review stage, then redirect borrowers to an existing web-based flow for more detail. Engineering considered it low effort and straightforward to ship.
However, I wasn't fully convinced with this approach. Redirecting borrowers to a web flow mid-review felt clunky, and the core problem of borrowers encountering unsafe cars with no immediate way to act,— remained unsolved. Before committing to ship, I pushed to test it with real users first.
Testing & Validation
I tested the MVP approach with new and existing Uber Carshare borrowers using high-fidelity prototypes. Unsurprisingly, the findings validated my concerns.
Users consistently struggled with the handoff from app to web as most didn't realise they needed to complete a second form to actually lodge their report with Uber Carshare. Those who did understand felt it was redundant, as they'd already described the issue in their review message to the owner, so submitting another report felt like unnecessary duplication. Others simply didn't have time at the end of a trip to complete both processes, and abandoned the flow entirely.
The results from the user testing were clear: the MVP wasn't capturing safety reports reliably, it was just adding friction. I brought these findings to stakeholders and made the case that shipping this would defer the problem, not solve it. The team agreed, and additional engineering resources were allocated to pursue the more robust solution.
Refinement, Further Testing and Iteration
With additional engineering resource secured, I returned to the original concept of a dedicated in-app safety reporting flow that didn't depend on the end-of-trip review.
The refined solution introduced an informational step during the pick-up process, making borrowers aware upfront that they could report an issue at any point during their trip. A new in-trip reporting flow was built into the app, allowing borrowers to flag concerns in the moment rather than waiting until the end.
Further user testing shaped the final details. Testers wanted the option to report at the end of their trip too, as not everyone would feel comfortable stopping mid-trip to lodge a report, so we retained that flexibility. Users also wanted confirmation that their report had actually been received, so we introduced an automated help ticket sent via email as a receipt.
When presenting the refined designs to leadership, a new challenge emerged. They wanted a unique reporting flow for every issue type eg. specific questions for windscreen damage, tyres, and so on, and suggested asking borrowers to photograph damage with an item, such as coin for scale. I pushed back that we were asking borrowers to jump through hoops when they were already trying to do the right thing, and risked creating new problems in the process, such as what if they didn't have a coin on them? The simpler path was to launch with a generic flow and iterate based on the quality of reports we received, to which Leadership agreed.
Launch & Results
Since releasing the updated safety reporting flow, 88% of all safety reports are now captured directly in the app, up from a fragmented mix of in-app submissions, owner messages, and support contacts. Trip cancellations due to cars not being in driving condition dropped from 43% to 13%.
Beyond the numbers, the fix closed a genuine accountability gap. Uber Carshare's support team now receives a copy of every safety report, giving the business the oversight it previously lacked and ensuring owners are held accountable for future borrowers.
Reflection
What I learned
This project reinforced something I'll carry into every project - advocating for the user isn't just about the design, it's also about knowing when to push back and why, which I did it twice during this project.
First, when engineering constraints pushed us toward an MVP I didn't believe would solve the problem. I made the case to test it first, and the data proved the concern was valid. Second, when leadership wanted a unique reporting flow for every issue type, including asking borrowers to photograph damage with a coin for scale, I argued we were putting too much onus on borrowers who were already trying to do the right thing. We launched with a generic flow instead, with the plan to iterate based on real report quality.
Testing was the other big takeaway. Both rounds of user testing shaped better outcomes than I would have reached on instinct alone. Given more time, I'd have loved to run A/B variations on the reporting flow itself.