Venmo is a digital wallet, widely used to make and share payments between friends and acquaintances. As a mobile phone and web app it provides a frictionless way for people to pay each other, and allows its users to avoid using cash altogether. When making or requesting a payment on Venmo, you must select a recipient, add a dollar amount, choose a viewing status (public, friends, or private), and write a note to the recipient before you can complete the transaction.

As an avid user of Venmo, I often find myself making the same payments to the same people. Often I use Venmo for reoccurring expenses, such as rent, utilities, and food. Unfortunately, Venmo’s current payment process does not utilize the information from any of my previous payments. As a result, each time I attempt to make a reoccurring payment, such as paying my math tutor weekly, I am required to set its dollar amount, choose its viewing status, and attach a note, all tasks that could be automated by utilizing the information of a previous payment that is identical to the one I am currently making. 

Frustrated by this inefficiency in Venmo’s payment process, I was curious to see if this pain point was felt by others too. Specifically, I wanted to explore whether my friends also use Venmo for reoccurring expenses and if so devise a solution that would prevent me, my friends, and any other Venmo users from feeling this paint point.

My Process

Each step in this process is a crucial driving force in achieving a user-centric solution. All aspects of this process guide me, helping to ensure that there is extensive thought and research put into the solution of the problem I am currently tackling. 

1. Approach

Ask Questions, Conduct User Interviews, Research, & Ideate Solution

Ask Questions

To add greater context to my pain point and to better understand why and how other people use Venmo, I began my approach by formulating several questions.

Conduct User Interviews

User Interviews are a great way to gain insights and to validate assumptions with limited resources. Specifically, surveys are a quick and affordable way to obtain a thorough and clear understanding of the needs of users and the current problem they’re facing.

Acutely aware that one must design based on facts not assumptions, I conducted an informal survey on twelve Venmo users to gain an understanding of the degree to which my pain point was felt by others. A few of the answers I received are provided below.

The survey results revealed that a majority of the participants use Venmo to pay off reoccurring expenses, especially household bills or restaurant bills. I also discovered that the reoccurring payments participants make are often fixed, meaning that each time they are made they are issued to the same recipient in the same dollar amount for the same reason.

Research

Research provides structure to the process of understanding a problem and how that problem might be solved. It is a necessary part of creating a user-focused product.

Confident that my user interviews had validated my pain point, I began my research by gaining a better understanding of how Venmo’s payment process currently works. In order to solve the pain point I first had to be certain of the root of it. Closely analyzing and walking through Venmo’s current payment process several times, I composed a detailed description of what exactly it entails.

After writing this description I became certain of what I had already assumed to be the root of my frustration with Venmo’s current payment process: previous payment’s information is being stored in the application but is unused for identical future payments. Additionally, using my description of Venmo’s current payment process, I was able to pin point exactly what steps in Venmo’s current payment process were fueling my paint point. I determined that the Specify Payment Amount, Give Context to Your Payment, and Clarify You Want To Pay steps could all be removed by using the information of payments that have previously been made to the same person in the same amount for the same reason.

Now certain of which actions in Venmo’s payment process were unnecessary when making a payment identical to a previous payment, I continued my research by exploring the payment processes of other virtual wallet applications and evaluating whether the structure of their processes mitigated or solved my pain point. After downloading and navigating through the interface of Paypal, Google Wallet, Zelle, and Square Cash, I discovered that these widely used virtual wallets set up their users to feel my pain point too.

Zelle however has a feature that resonated with me. Based on who users have made past payments or requests to, in the beginning of their payment or request process, users are presented with a list of suggested recipients.

Although this feature did not mitigate my pain point, its ease in access, optimal position in the payment process flow, and use of users’ past payment and request information helped me in generating a criteria for the solution to my paint point. My solution criteria was as follows:

Ideate Solution

In brainstorming possible solutions to my pain point, I composed a list of ideas that met my criteria. 

After much thought I decided to build out the Display Previous Payments Made To Recipient feature, Previous Payments feature for short. Unlike the Make a Repeated Payments List feature, the Previous Payments feature would not require a new screen, rather it could be integrated into an existing screen in Venmo’s current payment process. Additionally, unlike the Display Users’ Frequent Payments feature, the Previous Payments feature would allow users to effortlessly utilize the information from a previous payment even if that previous payment was not a frequent payment.

2. Design

Sketch, Wireframe, High Fidelity, & Prototype

Sketch

Putting pencil to paper and creating quick and rough sketches allows me to focus on honing the idea itself, rather than worrying about the design and aesthetics of it. Thus with a solution in mind, I began to sketch out what it would would look like as a feature in Venmo.

In visualizing how the Previous Payments feature would function and be displayed to users, I ensured that its incorporation into Venmo’s current payment process would not negatively affect users who were making a payment they had never made before (i.e making a payment not applicable to the Previous Payments feature). The flow of Venmo’s payment process with the Previous Payments feature integrated is detailed below.

As shown above, the Previous Payments feature would allow users who are making payments that they have made previously to avoid unnecessary steps. In using this feature users would avoid typing in a dollar amount, creating a note, confirming the viewing status, and clicking the pay button to clarify that they are making a payment. As a result, the Previous Payments feature would decrease the time and effort that would be required of users who are making a payment to a recipient that is identical to one that they have made in the past.

Wireframe

Wireframing is the refinement of the ideas formed during sketches, and presents the design solution in greater detail. It allows me to focus on the structure of the design without worrying about color, font choices, or any other aesthetic related design elements. So using my sketches, I brought my solution to life.

Located below the top navigation bar, the Previous Payments feature presents users with up to three past payments that they have made to the recipient they currently have selected. Displaying reoccurring payments is prioritized over displaying recent payments, thus the past payments that are displayed to users are ordered, from left to right, by the amount of times that they have been issued. Each past payment displays its dollar amount, viewing status, and its note.

Note: All elements except those contained between the two divider lines located on the upper section of  the screen have been designed by Venmo and are used in their current payment process. 

High Fidelity

Happy with the flow and functionality of the Previous Payments feature, I fleshed out my design to be consumer-face ready.

Throughout the design process, I ensured that my decisions did not cause the Previous Payments feature to deviate from my solution criteria.

Prototype

Below is a video comparing the time it takes to make a payment using Venmo’s current payment process (left) and to make a payment using Venmo’s payment process with the Previous Payments feature added (right).

Left Side (Venmo’s current payment process) Right Side (Previous Payments feature)
3. Reflect

Challenges, Edge Cases, Next Steps

Challenges

While still conceptualizing the Previous Payments feature, the greatest challenge was determining how it would be integrated into the application without hindering or drastically changing the current payment process. I ended up going through Venmo’s current payment process several times before choosing where to integrate the previous payment feature in the payment process. I decided to place the previous payment feature in the pay or request screen for two reasons:

    Additionally, it was difficult figure out how to display the dollar amount, viewing status, and note of each previous payment without cluttering the screen. Designing how the note would be displayed was especially challenging because I had to find a balance between the amount of context it gave to users and the amount of space it filled on the screen. After mulling the issue over and sketching a few ideas on paper, I decided that if a note exceeds 15 characters it will be cut off and displayed as a preview to the full note.

    Edge Cases

    Throughout the design process, I thought about several edge cases. Although my prototype does not address how each edge case would be accounted for, I have thought through all of them extensively and would address them in a more extensive prototype.

    Next Steps

    Completing this case study was daunting at first, but it was a tremendously valuable experience. Closely analyzing a design issue and thinking through a solution for it was enjoyable, but even more fascinating to me was extensively researching what a case study entails and exploring how other designers tackle such an endeavor.

    If I was to take my idea further, I would conduct user testing on my prototype and use the feedback to iterate my designs. Additionally, instead of only showing previous payments users have issued, I think it could be valuable to show previous requests that users have issued too; of course I would have to conduct user interviews to determine whether it would be a feature addition that users would even want.

    Michael Rigney - mrigs@umich.edu