On Venmo, I repeatedly make the same payments and requests, however, the data of a previous transaction is never utilized to auto fill the information of the same transaction made later on. Frustrated by this pain point, I designed a repeating transaction feature, Repeat, for Venmo. Repeat removes the need for users to go through the transaction flow if the payment or request they’re making has already been made before. You can view the feature here.
To begin my research I articulated the user goal that Venmo is centered around.
A design should be able to adapt to the way it’s being used and capitalize on any redundancy present in the system. From a holistic view Venmo supports its users’ goal, however, the experience does not optimize for users’ previous activity.
Surveying the Problem
To add greater context to my pain point, I conducted a brief survey around the following research question.
- RQ1 - What types of transactions do Venmo users make?
After surveying a handful of avid Venmo users, I learned that several of them have a set of transactions they repeatedly make. Typically made weekly or monthly, the most notable reoccurring transactions are scheduled bills.
- “Every week I pay my tutor the same amount” - P2
- “I usually either use Venmo to pay my roommate money for house bills or to pay people for food and drinks” - P3
Tackling the Tasks
To understand how the transaction process could better support repeated transactions, I broke down the flow into its tasks. These tasks play a redundant role in the transaction flow of a payment or request that is identical to a previous transaction; they were the root of my pain point.
- Assert you want to make a transaction
- Select recipient(s) of transaction
- Specify transaction amount
- Add a note to the transaction
- Choose the viewing permissions
- Specify the type of the transaction
- Confirm the transaction
By leveraging the data of a previous transaction, these tasks could be eliminated for future identical transactions. Doing so would reduce the amount of time users have to spend in the app as well as the cognitive, motor, and visual load put on them.
Beginning to think how the data of previous transactions could actually be utilized, I took a look at the transaction processes of other virtual wallet applications.
Following my walkthroughs of their transaction processes, I had enough direction to begin ideating and I drafted the following solution criteria:
- Easily accessible by users
- Presented to users at a logical point in the transaction process
- Leverages the information of previous transactions
- Doesn’t impede the existing transaction process
Putting pencil to paper, I began to ideate a solution.
Once I’d narrowed my ideas to a single solution, I transferred my sketches into wireframes.
Content with the flow and functionality of the solution, I moved it into a high-fidelity stage to further visualize and refine it.
Once a user fills out the necessary transaction info and specifies what type of transaction they’re making, they’re given the option to schedule future instances of the transaction.
Setting Repeat Preferences
When a user toggles the Repeat switch on, they can set preferences for the frequency and duration of the reoccurring transaction. After a user has set their repeat preferences, they can confirm the current instance of the transaction as well as its repeat settings.
Updating Repeat Preferences
Once a repeating transaction has been set up, users can still access and edit its repeat preferences.
Deleting a Repeating Transaction
Repeat transactions will be removed by the system once their duration has been reached, however, users can delete a repeat transaction at any time.
The greatest challenge in this case study was determining how to integrate the feature into the transaction process without disrupting its flow. I chose to implement the solution on the Confirm screen for two reasons. Firstly, the screen’s vast amount of whitespace allowed me to design around existing elements rather than having to significantly alter their position or size to accommodate the feature. Moreover, surfacing this feature on the Confirm Screen, the end of the transaction flow, ensures that users know the details of their transaction before they attempt to repeat it. If I continued building out this concept, I’d have users walkthrough the various flows to identify unforeseeable gaps in the designs. I’d then use the feedback to direct the next iteration of the feature.