I worked with Uber as an Innovation Engineering and Design Intern from April to August 2018. In the first half of my internship, I joined Uber Freight, Uber’s shipping division. They asked me to design a new support experience, under supervision from designers Adam Schwabe and Dalton Viggers. Freight has since rolled out my solution to all carriers, and is now used worldwide.
When I joined Uber Freight in Spring 2019, they were growing way way too fast. Shipping is complex, and traditional communication processes in the industry were a bottleneck for the team. Carriers were signing up for the platform faster than Freight could support them, and their operations team couldn’t keep up.
Uber Freight needed to find a way to provide en-route carrier support, while still allowing their team to service all carriers.
Prior research and analytics by the Freight team gave me some insight. They could diagnose carriers’ problems fastest through phone calls, but this tied up their team from helping other carriers. On the other hand, they could direct carriers’ requests to a digital form, at the risk of exacerbating already frustrating moments during their trip.
So, what if carriers had an experience that could replicate the direct, explicit nature of phone calls without necessarily having someone on the other end of the line?
After looking at what carriers needed, I constructed a hypothesis. Carriers didn’t necessarily need to talk to someone—they needed Uber Freight to acknowledge and respond to their situation quickly.
An experience that would tread this “middle” ground would still need to parallel communication in several ways. Freight needed to respond to what carriers wanted to say in real-time. They also needed to give carriers the right feedback to inform them on how they should respond to follow-up prompts. This back-and-forth nature of carriers’ needs led us to look at conversational interfaces.
Initially, I looked down the path of chatbots, and while great for creating rapport, decided against them in favor of more utility and urgency. After a few weeks of iteration, we arrived at a solution—a prompt-driven, progressively disclosed set of scenarios carriers could update us about.
Using Freight’s data, I constructed several “base” conversations that carriers could…well…carry throughout this experience. The dialogue used first-person framing and trucker vernacular, such as “bouncing loads” or “reporting detention”, to help carriers identify what conversation was relevant.
From here, carriers could give more details through scenarios within each base case. These scenarios are progressively disclosed, mirroring how questions in a conversation are often built from previous questions in that conversation.
My engineer, Tyler Alves, and I built the support experience as a web app. It needed to support both drivers using Uber Freight’s app, as well as brokerage carriers who didn’t have the app (they refer to a separate broker to book and manage their loads).
To test my hypothesis, Freight ran a test of the experience with 5% of their carriers. They saw 41% of carriers choose to use the experience, leading to a 44% drop in in-bound calls. One carrier, in fact, had opted for the experience on every load they took!
After the experience tested well, Freight rolled the support experience out to all carriers in the US.
Designing this experience took two months, from initial ideation to testing. After the success of my support experience, my team handed off the project to the larger Uber Freight organization, and placed me onto another project. I’m very happy to say since then, that Freight has adapted my solution for countries beyond the US. It is also getting an update to handle extra languages as well :)