As the world becomes increasingly digital, so does our money. Venmo is a peer-to-peer money transfer app that allows users to connect to their bank accounts and send money to others with just a few taps. It’s used by millions of Americans use to pay back a friend for coffee, split a bill, or buy movie tickets off of someone else. The app’s especially popular among millennials and college students due to its social features: it boasts a “news feed” showing payment records and emoji-themed payment descriptions.
Like many other students on campus, I’m a frequent Venmo user, but during 10 weeks in the summer, I lived off of it: it was the most efficient way to split payments among my friends and roommates. Most people on the same summer internship program were in a similar situation. The constant use put me in a great position to be able to critique Venmo on a deeper level.
All of my user research was conducted on peers in the program, so the demographic was college students between the ages of 18-22.
Through my own experience using the app and discussions with friends about their experiences, I identified some problem areas and potential solutions which eventually evolved into this case study. At the end of the program, I sent out a survey to everyone asking about their experience using Venmo to further collect feedback, which about half the fellows (10 people) answered fully. Some highlights of the survey include:
- 80% of those surveyed started using Venmo in college
- 50% of those surveyed enjoyed looking at the payments news feed in their app, whereas the other 50% expressed desire to hide or remove it
- 60% did not know how to request money/pay multiple people at once, and another 20% did not know how to do so until someone else showed them. The remaining 20% figured it out on their own
- 30% said they did not find the payment process intuitive the first time they used the app and needed time to adjust, whereas the rest was fine with it
After analyzing the results of the survey and recalling conversations with others about the app, I identified the following key pain points to solve through this redesign:
1. How to further separate the actions of paying and requesting
2. How to visibly indicate the addition of several people to a payment/request
3. How to satisfy users who have different opinions about the app’s payments feed
My goal was to separate the pay and request actions more since it currently only takes one tap to determine the course of action. It also doesn’t help that the two buttons are right next to each other. I had friends tell me that they’ve been mind-mapped to one course of action because they pay more frequently than they request or vice versa, and they accidently tap the wrong action as a result. That happened once when were splitting groceries and she paid all of us instead of requesting the payment. I heard many other stories of similar incidents.
I envisioned a process where the user explicitly selects an action to initiate the payment and there are steps along the way to remind the user what action they’re taking to catch any errors. I started off with some paper sketches.
Then I used Sketch to create the full user flow as well Framer to build an interactive prototype showing how a payment could be initiated.
The redesigned user flow requires one more screen than what the user would go through with the current app. However, that sacrifice was made for clarity: there many reminders along the way to make sure the user is performing the course of action they want. For example, they can change whether they want to request or pay using the top selection bar, even in the late stages of the transaction. Also, as a feature of convenience, the last few screens are designed so that the user’s thumb stays near the bottom of the screen and doesn’t have to move anywhere far to complete the payment.
Note that if the user decides to change their action at the final confirmation, they will be provided further confirmation from the action they switched to.
A small but important change is the addition of “tap to add people” as hint text in the search bar to make sure users know they can add multiple people to their transaction. I was originally debating between other texts such as “add more people” and “tap to add more people”, but after further thought and consulting more people, “tap to add people” won out because it was succinct and prompted action.
Below is the completed user flow for a payment:
Similarly, here is the completed user flow for a payment request.
To accommodate the variety of perspectives people have on the “social” features of the app, I decided to add customization options for the payment feed under the ‘Friends and Social’ panel in the Settings. Currently, the Friends feed (showing Venmo activities of the user’s friends) is the default feed users see when they open the app. Users can tap on the Me and Public tabs to see personal activities and activities of all users on Venmo, respectively, but the non-changeable default is still the Friends feed. Being able to set which feed the user sees upon entering the app would reduce clutter for people not interested in the the whole Venmo social scene, but the features would still be available for access. The new feed settings and their corresponding home screens are shown below.
And here’s an interactive prototype showing feed customization in the context of the overall settings:
This was my first UX case study and I found that it was a great way to motivate me to increase my awareness for design issues I face from day to day. I believe that existing solutions should always be questioned and potential improvements should be explored because often times, users who experience flawed UX won’t be vocal about it. I personally have been guilty of pushing twinges of uncertainty and confusion felt from an app to the back of my mind or convincing myself that I’ll get used to it over time. UX case studies are a great way to directly address those problems while becoming more familiar with the design process.
I’m grateful to have had the opportunity to use Venmo extensively with many others to gain insight for this case study. Unfortunately, due to time constraints, I wasn’t able to send out my prototypes for user feedback and iteration. Therefore, the next step would be to further build and refine the interactive prototypes and use them for user testing and then of course, iterating based on the feedback.