Document Rejection UX
Designing for when things go wrong
As a designer working on giving drivers access to the Uber platform, we often focus on designing the “fastest, lowest friction” way to success, or in Uber’s case, activation. But it’s easy to forget to design an ideal product experience for when things go wrong and users feel stuck.
The Global Problem
About 200,000 drivers per week have a document rejected for a reason they can fix.
However new drivers aren’t getting clear information about why a document is rejected and what to do about it. They are left to dig into the rejection reasons themselves, and often drop out of the funnel entirely.
Defining and stress-testing
From the product perspective, we needed to create a UX framework for rejections that was clear and actionable for the driver, but also scalable for Uber’s variety of documents and rejection reasons. Also due to changing requirements, we needed the system to be fairly straightforward to maintain. With the help of a driver UX writer, I led the design and context exploration.
Visual hierarchy explorations and stress testing
As the UX co-lead, I worked with our product ops team to understand how our documents are reviewed, what the most common rejection reasons were, and what the solutions were.
Then after creating our design principles and starting to lay out the options, we worked with our engineers to make sure our design and content would map out correctly given the data we had.
Before creating our final solution, we had the following considerations:
The existing content for rejection reasons needed to be rewritten
The content model should include the document name, specific rejection reason, remedy, and CTA
Doc rejections are collected and managed locally; the categories are often very generic
Generic messages can still be useful
Document names can be long and create localized challenges
Implementing a templated and globally scalable framework
The final solution involved creating a templated screen, that allowed for the appropriate amount of customization market by market.
The key content elements we landed on were:
Status: What is the status of the document?
Document name: Which document are we referring to?
Rejection reason: Why was this document not accepted?
Remedy: How do I fix this problem?
Nudge: What specific content can we surface to help users with this issue?
CTA: What is the specific call to action?
Variations depending on document, rejection reason, and additional context if needed
We wanted to lead with clarity around the status of the document. Then because we knew we wanted to address that these documents were fixable errors, we wanted to make sure the drivers felt empowered to fix things on their own.
We provided sample images for content, as well as a “What is this?” link for local operations to link out to more information if they needed.
All of these pieces came together and led to a 4% FTR lift in the United States, and a .16% lift in global supply hours. As a true growth experiment, it’s proof that paying attention to the small details can have significant impact on driver’s experience.