VENMO

TYPE
Redesign
ROLE
Research, interface / visual design, wireframes.
DATE
July - August 2016

Context

Over summer 2016, I decided to redesign Venmo’s Pay/Request feature to increase usability. I neither claim to work for Venmo nor am I saying that this is what Venmo will look like in the future. This is just some design thinking that went into a product I use often. (:

Motivation

After a dimsum lunch with six friends, it came time to pay the bill. “Let’s have one person use their card and everyone else can Venmo!” Friend A said. We all agreed, and Friend A volunteered to use his credit card.

From there, a whole slew of problems arose. While dimsum was certainly an accumulation of problems with the Venmo interface (and perhaps our sleepiness from too much food), there are several key obstacles that users seem to face with Venmo which I have seen in numerous other situations:

  • Confusion over total monetary amount for group payments / requests
  • Uncertainty with selecting the correct participants for a transaction
  • Paying instead of requesting

Finally, Friend A received the money he was owed and we finished lunch.

Hypothesis

Based on my discussions with Venmo users and looking at research conducted by Venmo itself, I believe these problems arise in the Pay / Request process because the information displayed to users at any given point is insufficient for them to feel 100 percent in control.

Consequently, proceeding forward in a transaction takes a longer period of time, and the conversion from one point to the next point in the Pay / Request pipeline is lower than what it could be with an interface and visual redesign.

Process

I first began by mapping out all of the distinct features in Venmo’s current Pay / Request design in order to better familiarize myself with all the different edge cases that might arise (i.e. multiple people v.s. one person, not typing in a description for the payment, having to go back and change names, etc.).

From there, I also did some reading on Venmo’s past history with data-driven design for the Pay / Request process, examined the pros and cons of other competitors’ interfaces and flows, and began ideating through what an interface for Venmo’s Pay / Request could look like.

Solution

After asking for feedback from my peers and going through multiple rounds of iteration, I settled on a design that was both intuitive, familiar, and optimized for the display of transaction information.

I began by doing a quick redesign for Venmo’s newsfeed (while adhering to their style guide) in order to 1) get a feel for how I would want the rest of the redesign to visually look 2) practice displaying important information without users having to click anything and 3) implement 1 and 2 while still preserving modularity.

 

 

Based on my own experiences and what I’ve heard from talking to peers, it’s always important to know how much money is in your Venmo account right from the get-go (should I transfer it back into my bank account? Will my next payment be using my Venmo money or will it also draw from my bank account?).

From there, I thought about ways to make the process of selecting transaction participants more intuitive.

 

 

The advantage of the current selection process includes categorization of people (the users with whom you have the most extensive transaction history with will appear first in the search bar). I decided to preserve this in my redesign, while also adding in some more visual design to show when a user had been selected to be a participant in the transaction.

 

 

Fun fact: seems like there’s also a bug in Venmo where if you try to send money to someone with the same name as you, the Done button doesn’t appear!

For the transaction screen, in addition to having the description bar active by default, I decided to include users’ profile pictures in addition to their usernames in addition to their full names. While there are certainly times when redundancy is… redundant, I figured (based on conversations with friends) that the different bits of information (i.e. name, profile picture, and username) would be able to independently validate that the user selected the correct participant, and consequently put together they would make the user feel extremely secure in sending money (this is what I imagine will increase the conversion rate from initiating a transaction to completing a transaction!).

 

The con to all of this is that with many, many participants in a transaction, there will be the issue of space and information overload. While this may certainly be a problem, I attempt to navigate around it by creating a horizontally scrolling participants list, which will keep the user on the transaction screen but still allow them to view every participant’s information.

 

 

For a transaction between two people, it was easy enough to create an intuitive, modular flow that clearly showed the amount of money to be exchanged.

 

For transactions with more than two people, while Venmo currently only shows the amount per person and the total charge, I attempted to show the connection between 1) the amount per person that a user enters with the number pad and 2) the total amount of money that a user can expect to pay/receive, based on the total number of participants in the transaction.

 

Finally, I decided to create redundancy through visual cues for the Pay and Request buttons, which ideally will prevent users from accidentally hitting the wrong transaction type.

 

 

And from there… the transaction is done!

Takeaways

  • Redundancy isn’t always bad. In fact, it can be extremely helpful in encouraging users when their next actions depend heavily on key information.
  • The beauty in mobile payment apps like Venmo is their ability to expedite transactions. It takes a lot of coordination to move money between large groups of people, and a lot of good design to make even that process manageable.

Things I'm working on

While I have all the screen mockups and interface designs for the Pay / Request process, I’m also starting to think about the interaction design that will come into play (will the next screen slide in? Fade in? Slide out?). There’s an entirely separate space that will also help in users’ understanding, but definitely something that would help to determine the overall usability and effectiveness of this design!