How We Design on The Uber Growth Team

Growing a hypergrowth startup

I’d never heard of a growth team when I joined Uber. When the company created one, our CEO emphasized the importance of focusing one team on driving the growth of the business. Intrigued, I volunteered to lead design. We started small, just two designers with a few engineers, product managers, and analysts. In two years we’ve grown to a 300 person organization, with a 30 person design team.

Design plays a pivotal role in the growth team’s mission to accelerate the growth of the business. We touch all parts of Uber — product, marketing, and internal tools. We design for riders, drivers, and operations teams across the 68 countries where Uber operates. Everything we do gets tested, tracked, and measured to ensure we’re maximizing growth in all areas of the company.

Two years ago, I wasn’t entirely certain how design should fit into such a metrics-oriented team. Since then, my teammates and I have developed an approach that achieves speed, quality, and impact in a fast-paced, hyper-growth environment. Here’s how we do it:

We get scientific with our art

Designers on the growth team take an empirical approach to every project. We start by identifying the criteria that will prove the design successful. This criteria could be something quantitative (like an increase in rider or drivers signing up), something qualitative (like ease of use), or some combination of both. Once we’ve defined success, we hypothesize how to achieve it and design around that hypothesis. When the design is done, we run a test. This could entail conducting a user study with our research team, shipping the design to a small segment of our user base, or launching to everyone and monitoring the performance closely. If we achieve our goals, we consider the hypothesis valid, fully roll out the design, and move on to the next project. If we don’t achieve our goals, we iterate on the solution using the insights from our invalidated hypothesis.

The process feels more like a chemist methodically working in a laboratory than an artist whimsically flinging paint at a canvas. Very little happens by chance. We base our design decisions on proven facts and learn from our mistakes. This approach allows us to drive growth in a controlled and understood way.

We dive into the data

Designers on the growth team love data. We work closely with data analysts and product managers to dig into the metrics that relate to our projects. We don’t do the actual analysis, but we grasp concepts like click through rates, cost per acquisition, and statistical significance. We constantly review the numbers and use the insights from analytics reports to inform our design decisions.

When beginning projects, we look for trends in the data that corroborate our own observations and what we learn from user research. If we’re advocating to put projects onto the roadmap, we’ll always use data to strengthen our case. This ensures we always focus on the right problem, not a best guess of what to do next.

After a project ships, data validates the impact of our design. We measure key metrics to ensure our design does what we intended. For example, if we work on a new signup feature, we’ll monitor things like button clicks, conversion rates, and the number of accounts created. If we don’t see improvement in those metrics as we test our designs, we’ll iterate further before rolling the feature out to all customers. This ensures we maximize the effectiveness of our work and get it right before moving on to the next project.

We do more

Our approach relies heavily on a/b testing, so we design more than one solution to each problem. This doesn’t mean throwing a few random options against the wall to see what sticks. It means carefully crafting multiple variations, each based on a clear hypothesis. Always fully designed and high quality, each option “works,” but for a different reason. We test these variations on a small segment of customers and iterate if necessary before fully launching the strongest solution.

For example, when we design ads for Facebook to attract new driver-partners, we always test multiple headline options that tout different benefits of signing up to drive. We often try different visual directions to find what will attract the most attention — photography, illustration, copy-driven, etc. Every option stays true to Uber, but each emphasises a different aspect of the service and brand.

Testing in this way does two things. First, it maximizes the impact of our design. If we simply shipped what we believed to be the best solution, we would risk leaving the actual best solution pinned to the concept board. If we fully develop and ship multiple concepts, we stand a better chance of releasing the best design to our customers. Second, it helps us learn. Tracking what performs and what does not provides insights about what resonates with different customers and on different mediums. We take those learnings into future projects and build an even smarter suite of options the next time.

We do less

We design very efficiently to minimize our effort and maximize our impact. If a small change will bring a big improvement, we don’t completely overhaul a product or feature. We always start by looking for the simplest, easiest, lightest solution to the problem.

For instance, when looking at ways to improve access to our give a ride / get a ride invite feature in the rider app, we started by simply changing the menu link from “share” to “free rides.” Shifting from describing the action to describing the value of the feature significantly increased the number of people who invited friends. This improvement required zero design hours, so our designer was able to instead invest her time in building a different, brand new feature.

This bias towards doing less allows us, paradoxically, to do more. We can do more variants in our a/b tests, more iterations of each project, and more projects in general. Doing less doesn’t mean that we don’t take on big, meaty design projects (just look at the cash feature in India). It means considering the easiest solution first and not wasting time overhauling a feature that doesn’t need overhauling.

We move fast

Moving fast amplifies our impact. The quicker we ship, the quicker we learn from research and a/b tests. These learnings influence future iterations and help our projects find success faster. The faster we find success, the sooner we can move onto the next project and create impact in other areas.

Speed is also strategic to the success of Uber. The ecosystem gets better as more people use the service. More drivers on the road means shorter wait times for riders. More people requesting means more rides per hour for drivers along with less down time between trips. We grow fast to improve the experience for all our customers.

The challenge is moving fast while still thinking deeply about the problem and fully refining the design. We do this by working together to supercharge our process. We start many projects with cross-functional brainstorms that leverage the brainpower of the entire team to generate ideas and solutions. We sketch together constantly, exploring multiple directions in low fidelity before investing more time on refinement and polish. We review work early and often to safeguard against wasting time going down the wrong path.

We don’t forget the magic

Despite the focus on data and metrics, we still aim to create emotional impact with our work. One of Uber’s cultural values is “make magic,” and we don’t consider a design successful unless it both achieves our growth goals and feels magical. This could come from a superb visual refinement, beautiful illustrations and photographs, or delightful animations and interactions.

Magic isn’t an easy metric to measure, but we value it just the same. We constantly strive to find ways to weave a little something extra into the work. It’s the best part of working on this team.


We’ve grown considerably since I started on growth design two years ago, and we’re not stopping anytime soon. We need great designers, writers, and researchers to help us continue our mission to drive growth around the world. Do you want to rapidly ship products and experiences, impact people worldwide, and make cities more productive and efficient? If so, check out uber.com/design to see our latest career opportunities.

Next Story — What I Learned in My First 120 Days at Uber
Currently Reading - What I Learned in My First 120 Days at Uber

What I Learned in My First 120 Days at Uber


I’ve been at Uber for four months. It’s been an exciting ride, and full of surprises. For example, I didn’t expect one of my best moments at work would be overlooking Chengdu, China riding up an elevator on the way to lunch with our local city team. Nor did I expect to be editing this post from an airport in Manila, Philippines. But then, the platform we are building is global, and the speed we’re scaling is accelerated, and so here I am at Terminal 3 in Manila Ninoy Aquino International Airport having been to 4 countries in as many months. And — because it doesn’t look like Uber will be slowing down anytime soon, I’m committing myself to documenting my experiences on a semi-regular basis. In the coming months I’ll write about what we’re working on, and explore the systems, teams and processes we’re building to solve insanely interesting problems and scale quickly at warpspeed.

I hope you find this and future posts as interesting to read as I have found them to experience!

Why did I join Uber?

It’s fitting to begin by answering the question: why Uber? After all, when I left Google four months ago life was great. My team there was amazing. We focused on fascinating domains. I had good work/life balance (which means a lot to this father of two). Further, I loved — and still love — Google as a company for its ambitions, its transparency and objectivity, and for the way it values its employees. So why did I leave?

What is Uber’s Mission?

First, I’m inspired by Uber’s mission. At Uber, we’re focused on two key areas. First, we want to make transportation as reliable as running water, and second — we aim to celebrate cities by making them better. Better how? By making them more efficient, less congested, less polluted, and more vibrant centers of culture and commerce. We do this by eliminating parking lots, reducing traffic, lowering drunk driving rates, and solving the last mile problem by amplifying access to public transportation. We also do this by driving traffic to local businesses and making the act of getting to work, home, or everywhere in between as easy and affordable as possible for people across 6 continents and 60+ countries.

To me, the first mission, when accomplished, will result in more economic opportunities for driver-partners, lower cost transportation options available for people everywhere, higher utilization of vehicles (more butts in seats), and most importantly — carbon reduction. Each of these are great goals I stand behind. Especially carbon reduction. I can’t think of a more important goal towards which I can contribute my energy.

Our second goal — of celebrating cities, and through that celebration improving them — is a bit more amorphous, but entirely fascinating.

Why Cities are the Ultimate Service Design Problem

Transportation is a fundamental component of any city. Urban environments, and the economies and cultures they create are massively influenced by the quality of transportation. Throughout my life, I’ve been influenced by the work of Kevin Lynch, William Whyte, and the impact of Robert Moses. It’s exciting to work at a company whose mission is to transform urbanism worldwide, and in ways uniquely beneficial to individual cities. It’s the ultimate service design problem. And now, with the advent of autonomous vehicles, that future — and the city of the future — is waiting to be defined at the very intersection of software and streets. Uber is both a driving force of that intersection and a bridge between bits and bricks. As both a citizen and a designer, I find this totally inspiring.

Why My Team Inspires Me

The second reason I joined Uber is for the team.

During my interview process, I had the opportunity to meet with folks who work across Uber’s product and design organizations. Everyone I met was smart, high-energy, and passionate. I aim to work with people who challenge and inspire me, and I came away from the interview process confident that at Uber, I’d find both. Four months into the job, that hunch is confirmed.

Full-Stack Product Design Meets Full-Service Agency

First, let’s talk about the design team. Uber’s design team contains the broadest spectrum of creative roles I’ve experienced at a company. We’re a big happy team of Product Designers, Visual Designers, Illustrators, Prototypers, Researchers, Copywriters, Content Strategists, Producers, Communication Designers, Brand Designers, Video Editors, Photographers, Industrial Designers and, yes, we even have an Interior Designer on the team. That mix of disciplines adds a richness to our organization that is unique in the tech industry, and new to me. The best way to describe it is a combination of a product design firm coupled with a full-service agency. We work and play together, sharing techniques, practices, and collaborating without ego. And we all share a common goal to do the best design and research possible in the service our our riders and partners, our cities, and our mission.

How Product Works With Design

But attaining great design doesn’t happen in a vacuum. To accomplish truly great design, it takes an entire product organization. And it’s at this junction of design and product execution where I’ve found that Uber shines, especially in comparison to past companies I’ve worked at. At Uber, design works side by side with our product management and engineering partners, developing strategy, planning product, and executing operationally together. This team collaboration can get fierce and passionate, but it’s always respectful. Our PMs do a great job of providing impactful feedback on designs (it’s part of what we look for in a great Uber PM), but they always defer to the designer to make the final call on the delivering the experience. And when it comes to product execution, our engineering team is highly dedicated to excellence. They care about the details, they focus on shipping code with pixel-perfect beauty. I experienced this first hand in a design review with an excellent engineer who, in response to viewing a series of design options, stated firmly:

The bottom line is that Uber is obsessed with quality and product excellence. Everyone across the entire organization is aligned around this. It’s refreshing, inspiring, and makes for a great place to work on design.

How We Work at Uber

The third reason I joined Uber was to experience a new way of working. After four years at Google, I had learned an enormous amount, but I was ready for new challenges. I had heard about Uber’s rapid growth, which was intriguing to me. And I used the app frequently, which was a good sign. But what piqued my interest the most was an analysis of Uber’s operational model by General McCrystal. He described Uber as a constantly evolving group of teams structured to quickly take on new challenges at a global scale — like a special forces unit. I’m an operations wonk, and so was naturally excited by his depiction.

General McCrystal Hit the Mark

Here’s an illustrative — albeit dramatically simplified version — of how we work. At Uber’s HQ in San Francisco, we build core products that are distributed across the world. Once released, city teams can customize our products to meet the distinct needs of their local markets. Occasionally, these city teams invent a new product or tool to accomplish their goals. Driven by their goal to succeed, they just get scrappy and do it. They don’t need to ask permission from HQ to accomplish their goals. Then, the best of these innovations cycle back into HQ, where they contribute to the next wave of core product development.

Accepting cash payments in India is a great example of this. What started as an innovation for the market in India has proliferated worldwide.

At Uber, we live and breathe innovation at a global-scale. It’s a part of our DNA. It’s a virtuous cycle that allows us to adapt and evolve to meet the needs of our users across the world. And, as I’ve travelled to China, India, and South East Asia over the last four months, meeting city teams and learning about their unique challenges and opportunities, I get increasingly excited about Uber’s positive, measurable, and visible impact on the world.

Want to Learn More?

In this article, I’ve only lightly touched on my experiences at Uber. There is much more to write about. If you have specific areas you’d like me to cover, drop me a line via LinkedIn. Also, if you are a designer, writer, or researcher and are interested in careers at Uber, we’re hiring. Send me a note! I’d love to learn how you can help us grow.

Next Story — Designing a Partner-Centric Experience
Currently Reading - Designing a Partner-Centric Experience

Designing a Partner-Centric Experience

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

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.

Next Story — Field Research at Uber
Currently Reading - Field Research at Uber

Field Research at Uber

Observing what people would never think to tell us

Uber design researcher, Grace, observing a research participant request a ride in downtown San Francisco. Photo credit: Peter Ng

As technology becomes more ubiquitous in our lives and a networked economy emerges, it’s important for companies to understand the physical, emotional, and social contexts in which people engage with their products. This is especially important for Uber and other technology-enabled services that depend upon interactions and experiences that happen outside of an app. Our end-to-end user experience spans multiple modes and locations, and asks customers to engage in both digital and physical interactions — sometimes at the same time.

In an ideal world, we could design every moment of that journey to ensure comfort, safety, and ease-of use. But in the real world, key service moments are affected by factors beyond our control: public infrastructure, differences between riders and driver-partners, including varying social and cultural norms, and even the way the sun hits a partner’s windshield in the early morning. While we can’t predict or control these things, we can design for the need to adapt and respond to such dynamic factors. However, before we can design a solution, we need to clearly define the problem.

The Uber Design Research team uses a range of research methods to uncover what matters most to riders and partners, and how our product helps or hinders them as they go about their lives. Often, we invite them to our lab to participate in interviews and usability studies. We also conduct phone interviews, surveys, and unmoderated usability studies to reach riders and partners all around the world. Getting research participants who visit our lab to tell us stories about their lives, and not just about our products, is one way to discover moments of friction in the product flow. But there are certain things participants may never think to tell us. Frequently, these are moments they don’t recognize as disruptions to their experience, but rather, they see them as small annoyances or frustrations that they have adjusted to over time.

To catch a glimpse of these small but highly significant moments, we need to conduct field research. Field research, put very simply, is getting out of the lab and into the world to talk with and observe people in their environment. It’s trying our best to walk in their shoes, see their point of view, and understand the context they live and work in. By seeing it ourselves, we recognize workarounds, physical artifacts, and motivations that are essentially invisible to our participants.

Uber is one of the most fast-paced startups in the world. Some might argue that field research would slow down a company of this velocity, but it actually saves us time. We could spend an hour interviewing someone telling us about their experiences or we could take an Uber ride with them and see their point of view first-hand.

Field research uncovers workarounds

When researching a new feature for the Uber Partner app, Grace Vorreuter will go out driving with partners and give them real world scenarios and tasks to test. Since she is getting into their car, she gets to observe not just how the app is functioning, but also physical artifacts that the partner interacts with. Some partners mount their phones on the left side, some on the right, while some prop it up in their cup holder. We take note of the arm’s-length gestures the partner makes to interact with our app and how it’s difficult to see the screen when there’s a glare — all things we could never encounter if trying to replicate these scenarios in the lab. We also see workarounds that partners create to fill in the gaps of their work flow.

An Uber Partner added the anonymized rider contact number to his contacts and uses the voice command “call muppet!” when contacting the rider.

While studying the new partner app on-trip flow, Grace conducted in-the-car research, running partners through different test scenarios. During one of these tests, she discovered that one partner had created a contact in his phone called “muppet,” which had the anonymized phone number of his upcoming rider. He did this so that he could easily call the rider using the voice command “call muppet!” A partner might not mention in an interview that he or she had created this workaround — by going out into the field to conduct this test in real driving scenarios, we were able to learn about this unmet need and this one partner’s unique solution.

Field research shows the effects of physical environment

Lane and sidewalk barriers extend throughout downtown Guangzhou, China.

In a sense, every Uber employee is conducting research every time he or she takes a ride. This helps create empathy across our organization for riders and partners. However, we are aware that our experiences in San Francisco or other US cities are not representative of the range of experiences users have with Uber across the world. When Amy Chong went to Guangzhou and Shanghai in China, she noticed important differences in the physical environment that are unique to those locations and cannot be understood from a distance. For instance, barriers that are meant to control pedestrian entry onto roadways extend multiple blocks along the sides of roads in Guangzhou and Shanghai. Amy also saw that highways run above street level in downtown Shanghai. These seemingly small physical differences could wreak havoc on uberPOOL pickups.

Highways above street level in parts of downtown Shanghai, China.

Imagine you are an uberPOOL passenger and you’ve just been matched with another rider who is standing on the other side of the street — in seemingly close proximity. In Guangzhou, a partner may need to drive more than four blocks to reach an opening where they can turn around and drive to the second rider. Or, imagine you’re riding on one of the highways above Shanghai when you’re matched with another rider, but that person is standing below you on the street level. Your Uber Partner would need to exit the highway and wind their way down to the street level and then return to the highway again. A car-sharing nightmare! Had we spoken to a rider from Guangzhou or Shanghai over the phone, they might have told us that wait times for uberPOOL are long. But they might not have thought to mention the physical details of their environment because they are immersed in it. Yet, it’s critical for Uber to consider these factors when calculating the estimated time of arrival for a partner in Guangzhou and Shanghai.

Field research reveals motivations and embedded attitudes

Alisa and Brion tag along with an UberRUSH Courier to deliver a package in New York City.

It’s one thing for an UberRUSH bike messenger, known as a “Courier,” to tell us about what it’s like to deliver a package from Chelsea to the West Village in New York City. It’s another thing to ride behind him as he navigates vehicles, avoids pedestrians and struggles to mark a job “complete” using the app on a snow-soaked iPhone screen.

Braving a bike ride on a cold February day allowed Design researcher Alisa Weinstein and UberRUSH’s lead designer, Brion McDonough, to see the tension between the needs and motivations of customers requesting an UberRUSH delivery and Couriers making the delivery. Customers often don’t consider how an item is transported from point A to point B — just that it gets where it needs to be as quickly as possible. Couriers, however, are primarily thinking about how a package will affect their ride. Their ability to navigate the city streets and control their body and bike is central to making a safe, successful delivery.

So while a customer may not be focused on the size, shape, and weight of a package, the Courier knows those factors affect his balance. Understanding the motivations of different actors in an end-to-end experience helped Alisa and Brion design with both sets of needs in mind. They may not have understood the importance of the physicality of the job had they not been there to see it for themselves.

Like any exploratory research method, fieldwork is an excellent tool for uncovering previously unknown or little-known motivations and problems that affect the way services are used and perceived. Sometimes the solutions or next steps are clear, but other times we may learn something that isn’t immediately actionable. This is often why some teams may push back against doing this kind of in-depth, exploratory research. But, we believe the payoff for this type of research is worth the time invested because the insights are so much more rich, nuanced, and tangible.

Field research is especially effective when product managers, engineers, and designers venture into the field with us to observe. When this happens, we see them internalize the experiences and stories much more than bullet points presented in a research report. We’ve seen these team members become stronger advocates for research, and also riders and partners, because they’re drawing from their own first-hand experiences in the field. Our field research gives our designers the confidence and conviction to design from a place of knowledge and deep understanding of riders and partners, rather than from a place of speculation and guesswork.

Contributors:

Grace Vorreuter is a design researcher on the Driving Experience team at Uber. Grace enjoys bad movies, cross stitching, and people-watching. She also puts way too much sugar in her coffee.

Amy Chong is a design researcher who focuses on experiences and initiatives related to Supply Growth at Uber. She loves to travel and run marathons; running a marathon on every continent is on her must-do list.

Alisa Weinstein is a design researcher at Uber who has worked with the Uber Everything, Uber for Business and Partnerships teams. She is a passionate armchair TV critic and has a Masters in Design from the IIT Institute of Design in Chicago.

Thanks to Shruti Kataria and Rick Bond for your editing help!

If this sort of research interests you, the Uber Design Research Team is hiring. Please get in touch with us! It’s not a requirement that you wear glasses…

Next Story — Designing the Uber Cash Experience
Currently Reading - Designing the Uber Cash Experience

Designing the Uber Cash Experience

Designing magical experiences is a local effort.

Uber was imagined as a private driver that appears at the tap of a button. And, since your private driver would never ask you to hand over money at the end of your ride — neither would driver-partners using the Uber platform. An elegant and hassle-free exit has always been core to the Uber experience.

The Uber Design team is always looking for ways to improve the Uber app for both our riders and driver-partners. And on the India product team, our job is to unlock growth by removing barriers and eliminating friction-points specific to our Indian users. To accomplish this, soon after the India product team formed we traveled from San Francisco to Bangalore and Delhi to immerse ourselves in the markets.

We immediately discovered that users in India live in a different payments landscape than most Uber riders around the globe. The difference: 95% of Indians don’t have access to a credit card, and due to local regulations, paying for anything digitally is a cumbersome process. When your service relies on mobile transactions, like Uber does, that’s not great. However, India has a well developed e-commerce ecosystem. Companies like Amazon and India’s home-grown Flipkart have thrived by facilitating their customers’ primary payment needs: cash.

Sitting in San Francisco, or any other major city in the western world, it’s hard to imagine preferring to pay your UPS or Fedex driver with cash. Today, Europeans and North Americans carry little or no physical currency. India couldn’t be more different — cash is the ubiquitous mode of payment. It’s reliable, trustworthy, and free of service charges.

For us to ensure Uber was available to every potential Uber rider in India, we knew we needed to do it with cash. The team returned home ready to take what we had learned and apply it to a new design solution.

Back Home — Time to Reevaluate as a Group

After our trip, we gathered together at an offsite house to collaborate on solutions.

We started our process by documenting the existing user journey and all of its pain points. We then moved on to the cash user journey and sketching out the flows for both the rider and driver experience. Soon, there were five post-it pad sheets stuck to the side of the house and the flows were fully sketched. None of these were particularly beautiful documents, but the content was invaluable. Seeing everything was a relief; cash didn’t look so intimidating after all.

Sketching with the engineers, PMs and analysts.

Bringing the whole team through that early design exercise was galvanizing. Traveling, believing, and designing together were important so that we all felt ownership over the paradigm-shifting experiment that we were about to pitch to our colleagues at HQ.

Selling Cash in San Francisco

A principle of Uber’s culture is that the best idea wins. But, not everyone was immediately convinced with our plan; a cashless experience is so core to Uber’s product identity. Whenever there’s a stalemate at Uber, we turn to the data. And, in the absence of data, we generate some. So to convince everyone that cash is king in India, we launched an experiment. To get there, there were some unique design challenges that needed to be addressed.

Getting the Experience Right

Existing user research and our own usage told us that, at the end of the trip, riders often have the Uber app closed or their phone tucked away in their pocket. Obviously, we didn’t want riders to get out of the vehicle and forget to pay. The driver-partner also needed to know that they were conducting a cash trip so that they’d make sure to collect the fare. We knew that their end-trip screen would need to be responsible for taking care of this critical moment before the rider exited.

Having that interface clearly communicate the trip was a cash trip was a challenge, partly because driver-partners in India have varying literacy rates. To help with this constraint, we used color, iconography and breaking of the driver-partner’s memorized app routine to remind them that a cash trip was different.

With the new demands on this screen, another issue became clear: notoriously spotty wireless networks across cities in India. Frequently you’ll pass through 3G, 2G and zero connectivity zones driving through Mumbai, Bangalore or any other Indian megacity. This wasn’t an issue with credit card transactions since payment could be processed long after the end of the trip. But for us, having the fare at the end of the trip was essential. Our engineering team came through with a solution that falls back to a redundant fare calculation happening on the driver-partner’s phone. Barriers removed!

George, sketching. Eric, thinking.

On-the-Ground Testing

With the experiment designed and built, we flew to Hyderabad for a week of field tests. Working with the local city team, we were able to team up with a small group of driver-partners to participate. To test the rider experience, all Uber team members in Hyderabad were set up with a special Cash vehicle type in our personal rider apps.

Armed with rupees, we headed onto the streets for the first ever Uber cash trips. Right away, our trips were successful! Handling cash came naturally for the driver-partners. Our user research had told us that partners were eager to have spending money in between their weekly payments. Seeing that happiness on their faces was great validation. From our perspective as riders, while certainly different, paying with cash was easy. We were even having fun.

The first ever Uber trips paid with cash.

Like any good experiment, some of our hypotheses were proven wrong, so we put together a plan to tweak our design with the new learnings. One example is we had assumed a prompt at the start of the trip announcing that this was a cash trip would be useful to the driver-partner. Nope. It turned out that, by the end of the trip, our partners felt the initial prompt was not useful. We removed it altogether.

Hanging out with the awesome Uber team in Hyderabad.

After testing and squashing bugs in the code for the week, the team flew back to San Francisco satisfied with the qualitative success of our experiment.

Letting the Data Speak

Having proven that cash was a viable option for a tiny group of employee-users, we rolled out a more expansive test to the entire population of riders and driver-partners in Hyderabad. Today, while still in testing mode, the data has been impressive. In fact, the majority of our trips in Hyderabad are now paid for in cash.

With this data, we were able to justify that a cash option is needed for our Indian users and the experiment has now rolled out to every Indian city Uber operates in. The cash option has also been rolled out in Nairobi, Kenya and other markets where cash is also preferred. We’re excited about the results so far and we’ll keep working to deliver a truly Uber experience, whether you have credit cards or cash in your wallet.

Want to help us improve transportation in India, China and beyond? We’re hiring designers, engineers, product managers, and more. You can contact me directly about positions with our India and China teams. Let’s move the world!

Thanks to Adam Starr, Andrew Crow and Ethan Eismann for editing drafts of this post.

Sign up to continue reading what matters most to you

Great stories deserve a great audience

Continue reading