One of Venmo’s greatest values is how quick and easy it is to send or receive money. At Venmo, we think that sending someone money should feel as easy as sending a text message; it shouldn’t require much thought. We like to keep this in mind whenever we work on a problem that deals with the payment experience. The following work was no different and our goal was to create a feature that kept true to quick and easy payments.
We started to receive a lot of support cases because people didn’t know which payment method they were using to pay someone on the main payment screen. Below is the screen that was causing problems (this is the final confirmation step of the payment flow):
There were two main issues:
People didn’t know which payment method they were using when making a new payment. Because of this, people were accidentally overdrafting their bank accounts or using their backup payment method on Venmo (which is a problem because Venmo charges a 3% fee for credit cards). This meant that Venmo was losing a lot of money covering these accidental payments for overdraft and credit card fees.
People didn’t know that their Venmo balance was only used for a payment when there was enough to cover the entire payment. This meant that people's bank accounts were drawn to cover the entire payment and people were often overdrafting their bank accounts. Again, this meant that Venmo had to pay the overdraft fees for these accidental payments.
Goals and Design Principles
Our main goal was to inform the user about which payment method they were using before they made a payment. We wanted to lower support cases while keeping the payment experience light and quick.
Keeping this in mind, we wanted to make a product that would:
Require minimal cognitive load to send a payment.
Make payments feel quick and easy; it should feel like sending a text message.
Help people feel in control of their payment experience.
Give people the right amount of information at the right time.
We started by whiteboarding a few concepts around the payment experience. A few ideas focused around the confirmation step of sending a payment:
After many iterations, we prototyped the most promising solutions and tested them internally and also with our users.
User Testing and Results
We received multiple pieces of feedback that this concept "made the payment feel like a checkout experience at a store”. Although we made an assumption that people would be interested in having total control of their payment experience (i.e. being able to change their payment method before making a payment), in fact people didn’t want this much control. Having to see all of their linked payment methods on the confirmation step of the payment screen added too much cognitive load for the experience to feel quick and easy and "like sending a text message". We referred back to our design principles for this decision.
For this concept, we noticed the same feedback as the "Concept 1", although to a lesser degree. People felt that it was nice to have the option to change their payment method on the confirmation step, but it added unnecessary cognitive load to the experience.
"Concept 3" was the most minimal solution that added the least amount of cognitive load. We understood that the tradeoff with this concept was that a person has to go to their Venmo Settings to change their default payment method.
After weighing the tradeoffs against the design principles, we ultimately decided to move forward with the "Concept 3" because:
Most of our users don’t have more than two payment methods linked to Venmo. Furthermore, most of our users don’t ever change their payment method once they add it to Venmo. This means that most of our users would not find value in a feature that allows them to change their payment method during a payment and such a feature would only add unneeded information to the experience. In order to make a decision, we referred back to our design principle to "give people the right amount of information at the right time".
"Concept 1" made the payment experience feel too heavy and "Concept 2" was better at keeping the payments experience feel quick, but it still added unnecessary cognitive load to the experience.
As with most projects, we had technical and time constraints. Given the constraints, we decided that "Concept 3" was the most appropriate MVP.
Building and Shipping
After refining the UI, we decided to ship what you see below as the MVP:
Lessons Learned and Future Iterations
We had some time to reflect on people’s behaviors and other potential solutions for the next set of problems. We took a step back and asked ourselves how we might be able to further help people identify what payment method they are using during a payment and instill confidence during the experience.
One theme we identified was that friction wasn't always a bad thing for a user, especially when it involves money. In other words, more friction might mean that a task takes longer to complete, but the user can take that time to be more thoughtful about the task. Based on this idea, we came up with the two concept below: