A faster, more intuitive way to pay groups of people.
Design • Prototype

Winter 2018
UX Designer
Allow people to pay others faster.

Ostin Kurniawan, Product Designer
A personal redesign of Venmo's Search functionality.

A UX analysis and redesign of the payment/search user flow in Venmo.


As a side project to put my HCDE theory and interaction design skills to the test, I challenged myself to do a (unsolicited) redesign for a feature of an app I used regularly in a single weekend. I chose Venmo since it has largely become an essential tool in the average college students’ arsenal of smartphone apps, seeing regular use for all sorts of financial transactions — from splitting rent to meals alike. The feature I saw the most potential for a redesign was the integrated Search and Pay function. There are a couple reasons as to why.

The Venmo app, as of January 2018. Note the small "QR" icon near the user image in the left screenshot, and the fact that my Facebook friend "Casey" does not show up immediately as a search result.

Venmo effectively has two types of ‘Friends’ — Venmo Friends and Facebook Friends. This distinction is not immediately clear.

While the act of scanning Venmo Codes is immediately accessible and easy to use, finding the Venmo code to share is not very intuitive or quick.

Here's an example of these issues in practice:


I researched other “peer payment” apps like Cash App (previously Square Cash), Messenger Pay, Apple Pay Cash, and Google Wallet. I studied their search functions, especially in relation to the process of group payments. I also studied the search functions of other social apps like Snapchat, Facebook, and Instagram to identify best practices in ensuring that what is searched for is most relevant to the user. In doing so, I came up with a number of key insights:


I conducted informal user observations to identify the pain points during this process. I asked four of my friends (three college students, one high schooler) to request a sample payment from a group of five of my other friends, while I watched them use the application. I asked them to think aloud, and especially voice any concerns when the application became confusing. In doing so, I found and/or confirmed a number of issues:

Facebook friends not prioritised

All participants had difficulty finding the target recipient. All were Facebook friends with the recipient, but the target recipient was never the first result, rather it was usually the fourth or fifth result, preceded by other people they did not know. They only identified the target recipient by the profile picture.

Pay when they mean to request, and vice versa

At the end of the transaction sequence, three of the four participants hovered over 'request' button before they pressed the 'pay' button, i.e. they almost paid the transaction targets when they meant to request money from them.

Difficulty finding the Venmo QR code

When asked to find the Venmo QR code, three of the four participants replied "there's a Venmo code?". These three were then asked to look for the code and show it to me. All three opened the hamburger menu and tapped their profile picture (they missed the small QR icon), then tapped the small QR icon beside their profile picture. When asked why they tapped on the second one rather than the first instance of the QR code, answers included "because it was still there, there was no other option" and "I didn't know the button was so small".


With the user research and my insights in mind, I started to sketch out requirements and ideas for enhancing the search function in Venmo. These rough sketches gave me insight into the moving components, the touch targets, and informational architecture of the the application.

A sample of my ideation sketches!


Since I would be iterating on the existing Venmo interface rather than completely redesigning it, I decided that jumping straight into high-fidelity prototyping would save me time. Framer allows for quick and live iterations, and so I could test these live, especially with the Framer Preview app, which allows me to send the prototypes to a phone for live testing. I started the redesign process by re-creating screenshots of the Venmo Android app. My goal is to redesign the Search interaction and not the entire app, and so copying the original Android app gave me insight into both Venmo’s design language and the Material Design specification used. Once three basic screens were copied (Venmo home screen, Pay/Request opening screen, and Pay/Request search results), I iterated on these until solutions were achieved.I focused on solving only one user flow: requesting/paying people that are not your Venmo friends. There are three types of screens in the Payment/Request sequence (referenced as “P/R sequence” hereafter):
The changes I made and the rationales behind them will be explained screen-by-screen.

Recent Users

Problem: Users do not have access to a list of people they have recently interacted with.
Solution: Split the users listed in the “Add” Screen into “Recommended” and “Recent” instead of just “Top People”.

Search results now listed

Facebook Friend Search Result Prioritisation

Problem: Search results are only prioritised by Venmo friends and Venmo mutual friends. If Facebook friends are not a user’s Venmo friend too, they have the same low priority as random people.
Solution: Group search results by “Suggested” and “Other People on Venmo”.  “Other People on Venmo” will have a secondary hierarchy, showing people you have the most mutual friends in descending order. If you have recently had an interaction with a user, a “Recent” tag will also show up.

Results now grouped by "Suggested" and "Other People on Venmo"

Venmo Code ACCESS

Problem: Finding your own Venmo code requires too many steps.
Solution: Put the Venmo code directly in the main hamburger menu.

Venmo code is now directly integrated into the hamburger menu.

Multi-recipient payments/requests

Problem: When creating a payment or request to multiple people, it is difficult to check whether or not the right people are in the payment/request.
Solution: Replace the comma-separated chain of users in a payment/request with a vertical list including their profile pictures.

Vertical list of recipients/payees, including profile pictures for quick reference

Accidental payments/requests

Problem: It is too easy to pay when you mean to request and vice versa.
Solution: Introduce the type of interaction earlier and add icons to enhance glanceability.

The pay/request decision is made earlier, so the final tap (seen in the next screen) is a finalising one rather than an all-in-one.

UNCLEAR Transaction details

Problem: Transaction details in the “Finishing” screen are hardly visible
Solution: List the transaction recipients vertically, with profile pictures, and move the transaction amount to the bottom of the screen, near the “Confirm” button. Add a “total number of participants” detail.

Transaction details are made more prominent and displayed near the confirmation button.


Framer allows me to prototype high-fidelity animtions, which I’ve been able to play around with more. Here are some of the interactions I implemented for this redesign. An interactive prototype can be accessed here.

Adding another person to a payment/request

Finalising the payment

Accessing the hamburger menu, with the QR code.


I conducted a second round of user testing with my original testing participants, and received feedback. While most of the feedback was positive, there are a couple of things they found unintuitive:

Adding a user to the recipient list is jarring

One participant found that the lack of animation when adding a person to the list of participants was jarring and unituitive. This could be resolved by adding a quick animation showing a user "card" sliding right of the search results then sliding into the recipient list from the left, or moving straight up from the search results to the recipient list.

Transaction amount selection too close to confirmation button

While the transaction amount was clearer and accidental false payments were mitigated, two users felt that the payment "tab" was too close to the "confirm payment" button, leading to a higher likeliness of sending a payment/request with a wrong amount.


Over this process, I have learned a ton about the micro-interactions that make interactions more intuitive, less painful, and more efficient. This project has allowed me to also become much more familiar with the Material Design spec, making me more confident that I can use it effectively and efficiently. In addition to the suggestions made in round 2 of the user testing, some things I’d like to improve on are in-screen animations that use movement, especially within the Material Design spec, to make the interactions clearer and even more intuitive. Overall, I’ve had a ton of fun doing this redesign and it has only solidified my love for the process.
other work