Repeat

Concept

Sep 2019
Integrated a repeating transaction feature into Venmo’s payment and request process, using transaction data to schedule future payments and requests.
Repeat Designs
Down Indicator
Back To Top

Overview

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.


Research

To begin my research I articulated the user goal that Venmo is centered around.

“Effortlessly make payments to and receive payments from other people”

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.

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.

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.

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.

Solution Criteria

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:


Design

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.

Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe Repeat Wireframe

Content with the flow and functionality of the solution, I moved it into a high-fidelity stage to further visualize and refine it.

Entry Point

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.


Conclusion

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.