Designing a Partner-Centric Experience

An inside look at the process of redesigning the Uber Partner app from the ground up

Molly Nix
Uber Design
6 min readDec 10, 2015

--

This year, the Uber design team focused on bringing our simplicity-first philosophy to our partner experience. While many people think of Uber as a way to get a reliable ride, there’s an entirely different side of the Uber experience that only partners see. Over 1 million driver-partners around the world rely on the Uber Partner app for a flexible way to earn money. For an app to support all their needs, it needs to do more than just start and end trips — it also needs to give partners all the information they need to make decisions before and after driving.

Balancing safety, clarity, and usability while solving for diverse needs across the globe can be an overwhelming prospect. To succeed in bringing a completely overhauled product to our users, we relied on a design process that emphasized getting into the shoes (and cars!) of our partners. The result is a dramatically improved app experience that serves the people that power Uber.

Identifying the problem

To start the design process, it was important to hear directly from our partners to get a broader sense of their needs, and identify gaps in the experience. We needed to give our team the knowledge to design from a place of deep understanding, rather than from speculation.

Foundational exploratory field research allowed us to see what partners experience first-hand

Previously, the only functionality in the app was for picking up riders and taking trips. We discovered some partners would keep a notebook in their car to manually track the fare earned from every trip they took. The app did not provide real-time earnings reports, and our partners needed to know exactly how much money they were making so they could pay bills. Other partners talked about taking pride in the service they provided, and wanted to understand how they could adjust their style if their rating dropped. Every session with a partner uncovered new insights, and from these conversations we synthesized the common themes of pain points and important design considerations to take us forward.

A lightweight journey map helped us stay in the mindset of our partners

Designing the right thing

Armed with insights from our research, we started exploring a wide range of options for the navigational structure of the app, and converged on an information architecture that reflects what’s most important to partners:

  • Knowing where and when to drive and getting timely information (the Home tab)
  • Tracking earnings (the Earnings tab)
  • Getting feedback from riders (the Ratings tab)
  • Managing information (the Account tab)

Many teams at Uber build products and features designed to enhance the partner experience, such as a rewards program available exclusively for Uber driver-partners, or emails that operations teams send out that gives advice on the best times to drive. Previously, partners had to dig through their email inbox or look through their SMS logs to get the information they needed. All of this information is important to provide to partners, but the key design challenge was creating an information hierarchy that prioritizes the right information at the right time, and optimizes for safety by ensuring all distractions are out of the way while driving.

Designing the thing right

After weeks of iterating on low-fidelity prototypes through feedback sessions with partners, we shifted gears into high-fidelity prototyping. This meant diving into and refining the visual and interaction design, such as how a scrolling feed would feel sliding over an inspectable map.

A full prototype built in HTML and CSS with fake data allowed us to paint an interactive picture of what the brand new Partner app experience would be like, all before engineers got started building the mobile front-end. The sharable prototype was critical to keeping the rapidly expanding engineering teams informed of the latest design, while still allowing us to iterate and test with driver-partners on a daily basis.

Despite gathering research and insights before high-fidelity prototyping, no design is perfect on its first pass. We prioritized testing both end-to-end flows (can a partner find their pay statements?) and the core interactions (did the partner understand how to go online?), all while getting a continued source of high-level validation from the people our designs would serve.

Down to the last detail

After our engineering team completed the impressive feat of rewriting the Partner app from the ground up, it was time to start beta testing the experience with real partners and real data. In the beta, the core flows were complete, but some of the animations that appeared in the prototype we tested with partners were pushed down in priority to the “design polish wish list” for the beta implementation.

One of those animations was the transition from being offline to going online to accept trips. When a partner taps the button, there is a call to the server to verify that this partner has the appropriate qualifications to be be allowed to take trips in the given area. This delays the transition, particularly in low-network environments. In the initial implementation, there was no feedback to the partner when they tapped the button — the screen just froze — so partners did not know if their action was successful. It became clear this transition should not have been considered “polish” — it was core to the usability of the app. After implementing a delightful animation to indicate progress and clarify latency, we were able to resolve this issue and improve the usability of the product.

Upon hearing feedback from partners that the lack of transition was confusing, engineers rallied quickly to build this animation that makes the transition of going online clearer.

Learning from broader use

Prioritizing clarity over cleverness is one of our design principles at Uber, and it’s especially important to remember when designing for our partners in countries like India where literacy rates vary widely, many of whose first-ever experience with a smartphone is the one they use to drive with Uber. These partners depend far more on visual cues, and adding in an icon or illustration to accompany text makes our interfaces more understandable to low-literacy partners.

Updating the Earning icons from a bar chart to cash made this tab clearer to our partners in areas with low network connectivity.

The first icon designed for the Earnings tab was intended to represent the charts that visualize daily earnings. When partners in India were asked what they expected to be inside this tab, most responded with a clear answer that it is where they would go to try to fix their unreliable network connection. To these partners, the icon we were using looked more like cellular signal strength rather than a bar graph. This finding prompted us to update the icon to be a more direct and universal representation of money.

When surveying partners who have the new design, we have seen an increase in overall satisfaction with the Uber Partner app. But this stage of the process is only the beginning, and our team’s job is never done; as the new design goes out to more partners around the world, we will continue to use both data and feedback to refine the experience.

As designers, we internalize the mantra: “You are not the user.” This forces us to be objective and make decisions based on what the user needs, transcending subjective preference or business goals. The outcome is a design that gives partners an improved experience so Uber works better for them, and offers people new ways to earn money on their own terms.

Uber Design is continuing to tackle problems of growing scale. If you’re looking to design experiences that bridge the digital and physical divide and work on products that move people — we’re hiring.

Thank you to Patrick McKiernan, Maya Choksi, Melissa Pak, Evelyn Kim, and Stan Yeung for editing drafts of this piece, and our wonderfully talented extended team for their hard work on this project.

--

--