Designing for high-stress scenarios
Last Summer, I worked as a Product Design Intern on Uber's Safety team, at their headquarters in San Francisco. For my 3 month long individual projects, I was tasked with redefining the driver app experience of reporting a car accident.
Product Design, UX/UI
2019
Duration: 12 weeks
↓ Uber Internship
Problem Statement
Getting into a crash is one of the most unpleasant and disorienting experiences for Uber Drivers. In addition to the emotional stress of the accident itself, drivers are temporarily suspended from the app until they report it to Uber and fix the damages, causing them to lose valuable time and income.

The current in-app crash report flow collects and sends inconsistent, poor quality data to the Claims Management team. Free form text fields and an unstructured photo upload often results in the need for human review of the claim. Drivers are frequently asked to resubmit information which leads to longer resolution times, and ultimately driver churn.
Select screens from old flow
Opportunity
Currently, Uber receives roughly 169,000 accident claims per year in the US alone, accounting for 82% of the accident claims globally. That is a massive amount of crashes where drivers are stressed, losing income, and waiting to get back on the road.

Uber must streamline the accident claims process in order to get drivers back on the road promptly. By improving the user experience of crash reporting, they can increase the number of crashes reported, and improve the quality of the data, thus reducing resolution time and driver churn.
Uber receives 169K accident claims per year in the US
Constraints
As my three month long intern project, I was to improve this process without overhauling the existing help-form framework. I was the only designer working on this project, however, I collaborated with a product manager and ux researcher to better understand the problem space and conduct user testing.

Additionally I had to operate under specific engineering constraints. Uber uses a framework of reusable components for flows under the help-node called S4, which dictates both what interactions are possible and the overall visual style. Since they are planning to update S4 to fit Uber's new visual style, I decided to make two versions of key flows: one MVP that is S4 compliant and a 'North Star' version to be implemented in the future.
Example of S4 compliant screen (left) vs. Base Mobile compliant screen (right)
Discovery
As I dove into auditing the existing flow and examining the research already done, I discovered two main areas in need of improvement. The first was the crash location selection of the form. To input the location of the crash, users were required to enter the exact address of the crash without any sort of visual reference. This put too much of a cognitive load on drivers as they are forced to recall the crash location solely based off memory and search for a nearby address if they did not write one down at the scene of the crash.
Original crash location selection screens
The next major pain point was the process of uploading vehicle photos. Users were given extremely general guidelines when taking photos, such as "Stand 10–15 feet back", that did not reflect the reality of Uber's strict insurance requirements. Additionally I learned that inadequate vehicle photos are the most common reason for follow up with drivers regarding their crash reports. As stated earlier, longer resolution times can ultimately result in driver churn. When interviewed about deciding to leave the Uber platform, some drivers even cited getting the "runaround" with reuploading photos as their reasoning.
Original vehicle photo upload screens
Ideation
With these issues in mind I began ideating ways to improve the experience. The first and most obvious improvement I landed on was converting the location selection to a map component. If the driver had crashed while on a trip, the trip route would be shown as a visual aid to help them remember where the crash happened.
First iteration of a new map component
Additionally, I became aware of a feature Uber has called Crash Detection, where the driver or rider's phone senses when a crash occurs, and sends them a push notification to make sure they are okay. I decided to integrate this feature into the crash report, such that the location and time of the crash could be suggested to the user if a crash had been detected.
First iteration of crash detection integration
For improving the photo upload experience, my ideas ranged more broadly. I explored detailed checklists, in camera AI to alert the user about framing and lighting, a scanning experience akin to how many apps let you connect a credit card, and a dedicated photo tips page among other things.
Early explorations of a revised photo upload experience
After countless critiques, the design I ended up pursuing was a mix of several of the ideas. Crash detection integration became the happy path for location selection, with a (much revised) map component as the fallback. With engineering constraints in mind, I decided on breaking the photo upload into steps for each angle needed, paired with an illustrated photo tips page.
Revised crash detection flow (happy path)
Revised map component with search bar (fallback)
Revised photo upload experience
User Testing
After I had a working prototype of the revised crash report flow, I set out to test it with some real Uber drivers with the help of a product manager and ux researcher on my team. We had four different drivers talk us through their thought process as they tried the prototype in person. The primary takeaway was that drivers have a natural tendency to upload photos of the vehicle damage, but don't always understand why they need to upload photos of all sides of the vehicle. This helped inform how I revised both the copy and photo tips page.
A driver quote said after they were asked what they'd change about insufficiently cropped photos
Delivery
For the final design, I was able to implement these revised features, as well as update the overall visual style of the entire crash report flow. Additionally, I consolidated some of the other questions making the flow more succinct and added a couple minor features including saving a draft so that drivers wouldn't have to fill out the form all at once if they were missing key information.

A S4 compliant version of the photo upload flow was made to ship immediately, as it became clear that that was the primary issue, while the rest of the design shipped in early 2020.
Final crash detection flow (happy path)
Integration with crash detection notification
Final map component design, on trip
Final map component design, off trip
Final photo upload flow
Final camera UI for photo upload
S4 compliant photo upload