Designing For A Cash Experience
What cash trips in Mexico taught me about designing for international markets at Uber
As a product designer at Uber working on the Money team in Amsterdam, it’s my job to help come up with design solutions for Uber products across the globe. Designing globally presents a lot of challenges that don’t come up if you are creating products for a more limited market. We constantly see how cultural context, infrastructure, and on-the-ground realities matter to good design.
The problem
My team recently dealt with a good example of these challenges. On its face, the question was a simple one: How could we better collect the service fees for use of the Uber platform on trips in which the passenger connected to the driver paid in cash rather than through digital payment?
To better understand the problem we were facing, first a little background on digital vs cash payments:
In ridesharing industry, riders often pay digitally to ridesharing companies which then pay drivers. But in countries like Mexico, it is common that riders pay the driver directly in cash, then the driver pays the ridesharing companies.
Things get complicated
Let’s zoom in on how this challenge impacts one driver. When a driver has a positive balance in her Uber account because she’s received payment for digital trips, Uber can just deduct the service fee from her account. When she has $0, however, withdrawing from her Uber account would result in a negative balance.
Now, let’s zoom out to see how this problem grows with the number of cash trips. For drivers with a high volume of cash trips, it could be a struggle to maintain a positive balance. We needed a way for drivers to securely and easily transfer the cash service fees to Uber.
When we started working on this problem, the previous solution wasn’t scalable. When a driver had a negative balance, Uber would send an email with a URL linked to an invoice and instruction on how to make a payment. The driver would then be solely responsible for carrying out a deposit, at which point Uber would receive notification that payment had been completed.
This was a manual experience, with a lot of heavy lifting asked of both the drivers and our Operations team, who were manually managing the emails. It was also opaque, as we had no way of knowing what was going on between sending a driver an email and eventually being notified of the payment.
All of these notifications were being handled via email — there was no related product experience in the app. This was a problem particularly because there was no guarantee that drivers would check their email accounts regularly, or read through all messages thoroughly.
Part I: On the ground
We started with the basics: doing research on the ground in Mexico, to find out exactly what wasn’t working.
Together with one other designer and our product manager and UX researcher, I traveled to Mexico City and Guadalajara, where we spent two weeks working with drivers to get a better example of where the current experience was falling short.
It soon became clear that one way we were falling short was in not effectively disseminating information. There was an overall lack of awareness about how handling service fees worked when it came to cash payments. We needed a better way to communicate.
From our research, we knew we needed to accomplish three things:
- We needed to design a system that provided drivers with more control and flexibility on when, where, and how much they paid.
- We needed to be able to guide drivers through the payment process and provide feedback on the status of their payment.
- We needed to provide more accessible and thorough information to experience drivers about cash trips.
It became clear that handling more of the payment process inside the app would play a crucial role in streamlining the process and making things easier for the driver. In short, we needed to create an in-app collection framework that would satisfy these three needs.
Part II: Bringing it in
During our research, we sat down with volunteer drivers to get their thoughts and feedback on some of our ideas. In many of the sessions, drivers would interact with a prototype we’d made in Figma. We’d pull over the car, load the prototypes onto a test Android device and ask the driver to pretend it was their phone. Some would even put the test phone in the phone holder of their car like it was theirs — a great way to put the driver in the mindset of it being their phone and their experience.
In the prototype, drivers first confirmed how much they wanted to pay at any given time. Then a code would be generated that they could use to make the payment at a convenience store. Once they’d made the payment, they could confirm their payment in the app, and they would see a “pending” screen to communicate processing time.
After interacting with the flow for the first time, drivers would often tap through the screens briskly without taking time to read, internalize, or completely understand what was happening at each step.
Drivers would then get to the end of the flow (the “pending” screen) and assume their payment was processing, even though they had never actually gone to a convenience store and paid:
In some cases, drivers mentioned they would call support immediately upon hitting the pending screen, to find out why it was still processing, even though, a) we communicated on the screen that it could take up to 48 hours and b) they hadn’t paid at all!
Part III: Refinements
We returned home to Amsterdam and began refining the experience. We experimented with step-by-step instructions, pre-flow information, flexibility around starting payment again, help and support, and contextual help during first experiences.
The main issue we saw during our testing in Mexico was that some drivers would get to the end of the prototype flow without actually paying. To account for this, we did two things to help drivers and give them flexibility if they had accidentally gotten to the end of the flow without paying: we enabled them to start over, cancel the transaction, and we allowed them to view their code from the “pending” screen, so that they could subsequently go to a convenience store and make the corresponding payment:
What we learned
In addition to the satisfaction of coming up with a workable solution to the problem, this project offered some valuable lessons in design:
Design for people, not for users
As designers, when we think of “users”, too often we picture someone interacting with our product exactly as we would wish them to, understanding all of our expectations and taking for granted the same things we do.But this idealized user does not exist, because those interacting with our product are people, and in real life — as we saw with drivers speeding through our in-app payment — people are unpredictable, and we need to design with that unpredictability in mind.
As long as it’s clear, it’s okay to be complex
We often conflate clarity with simplicity. We shouldn’t. They are two different things, and while simplicity is often preferable to complexity, sometimes a degree of complexity is necessary when you are dealing with a more complicated problem.
Ignoring complexity in favor of forced simplicity doesn’t help anybody. Instead of trying to ignore complexity, try to deal with it as clearly as possible.
We did this when we offered to let drivers view their payment code or start over from the pending screen, in case they hadn’t actually made their payment yet. Ignoring this problem would have been simpler, but it wouldn’t have led to a better solution.
Localization ≠ translation
A big lesson that was reinforced for us with this project was the importance of localization. This was a product that would eventually be released in multiple markets, including Mexico, Brazil, India, and Japan. During the design process, we’d been writing the copy ourselves in English, thinking that we could leave translation towards the end and do it just before testing.But localization — even when only considering the linguistic aspects — is more than just translation. Culture and usage may alter the intended meaning radically, or render it entirely nonsensical. And this is very difficult for a non-native speaker and cultural outsider to fully mitigate without inside help.
What’s needed instead is “transcreation”: adapting a message from one language to another while maintaining as much as possible consistency of intent, style, tone, and context.
This is best done early, often, and with local help. Who better to ask to serve as your guide around a town than someone who has spent their whole life there? The same is true of language.
Looking ahead
Working on this project has been a rewarding experience. As we move forward and expand this product into other markets, helping other teams adapt it to their own needs, we continue to look for opportunities to improve the experience. This project has been a good reminder for me that our “users” are people; that there are worse things than a little complexity; and that assumptions are to be questioned, not relied upon. Keeping these in mind can only make for better design.
Want more?
I made a video about my learnings from this project, watch below:
About the author:
Femke is a product designer at Uber working within Uber Eats on restaurant tooling. Previously she’d worked on the driver experience focusing on money and payments across the world. You can often find Femke creating videos on YouTube, hiking around Ontario or mentoring on Superpeer.
You can follow her design journey on Twitter, sign up for her newsletter or connect with her at fem@uber.com.
Femke wants to especially thank the Cash Engineering Team and:
Amrita Banerjee— Product Manager
Misha Frolov — Product Designer
Jelle Prins–Design Manager
Ginger Kimler — Content Strategist
Laszlo Laufer — User Researcher
Nick Jones — Data Scientist
Kate Lynch — Product Operations Manager
Adam Weigand– Product Marketing Manager
As well as Thijs Niks, Ebi Atawodi, Albert Malikov and Joost van der Ree
Do you love a good design challenge and working to make better things for people? We’re hiring at Uber! Check out our job openings.
