Part of what excited me about this idea was that the framework for this already exists within Venmo and would require only minor changes to implement—a solution could be made only requiring simple arithmetic using input values local to one device. It would also fit neatly into the current interface and could be implemented without disrupting any of the pre-existing system.
The information architecture of the user interface and the backend framework required to support the two features would be vastly different. Before investing my limited time in the design process, I’d need to determine which of these options to pursue.
Though the four competitor products I explored in detail demonstrated a range of approaches to the problem of splitting the check, all consisted of three main stages:
Using the same hypothetical use case for each app, I tested out competitors’ solutions and took note of their strengths and shortcomings.
Reliable OCR technology would eliminate the first of the above pitfalls entirely, but until the technology is there, I believe it’s more trouble than it’s worth. Because my experience using OCR scanning features on competitor apps was prone to frustrating errors, I chose to design for manual input.
Based on my research at this point, one thing was clear: the biggest challenge would be giving the user the control and options needed to account for a wide range of use cases without presenting them with an interface that would be massively overwhelming.
My user interviews look the form of four in-depth conversations with people who fell into Venmo’s target demographic (young adults with some degree of disposable income) based loosely around a framework of questions and lasting around one hour.
My goals during this phase were to:
Overwhelmed by my interview notes, I created an affinity map to parse out common emotional threads and logistical insights. The following themes emerged:
Trust
Guilt
Reluctance
Bitterness/Injustice
Difficulties
Solutions/Workarounds
Some selected research findings and the design insights they inspired:
“It’s kind of a nice thing to have with friendships—that trust that they’re eventually going to get you back.”
— Interview participant
“When you’re having a good time, it sucks to be in a situation where you have to put your fingers in each others pockets at the end of the night.”
“Sending a request instead of just waiting for them to pay me back always feels passive-aggressive.”
“At the end of a meal, somehow basic arithmetic turns into computer science.”
Since it uses local variables instead of importing variables across devices from synchronous users, it would be much simpler on the backend.
Although the single user approach requires more work by the user in charge of the process, the person carrying out the flow is also the one who covered the bill and is therefore invested—literally—and more likely to follow the flow through to completion.
Additionally, this solution still allows for the possibility of group involvement—the user could decide to pass their device around and have each person control their part of the split.
For the scope of this project, I decided it should address three use cases, in which the bill becomes progressively more complicated:
I built out a user flows with lo-fi wireframes to imagine how a user might proceed through the three main situations I’d isolated. The “Food & Drink” situation was the most complex, and it became clear that the item input stage would be the biggest challenge—I needed to avoid making the mistakes I’d observed in competitor products.
I explored splitting the items into chronological groups, so items would be grouped together in roughly the same order in which they appeared on the table. Besides being familiar from menus, the groups would mirror the actual experience of the meal and make it easier for the user to recall and locate items during the assign flow.
In order for this to work, I’d need the user to identify the item’s type as well as its ID, price, and quantity when they input the item.
My initial idea was to guide the user through the item categories one by one [A]. While this approach seemed to minimize confusion about the desired actions, it would be too involved for simple or small meals.
Instead, having all options on one screen [B] would allow the user to only select the relevant categories, eliminating extra steps. This way, the addition of a new item and its categorization was combined into one action.
To add another item within a category, the user could tap this button to reveal an input field for another item directly within the same overlay, avoiding the extra work of closing and reopening the overlay for each item.
A progress bar based on the remaining unassigned subtotal would provide clarity and motivation to complete the flow, minimizing abandonment.
Would the clarity and convenience of the assignment process be worth the input labor needed to get there?
I carried out usability tests with four subjects who fit into Venmo’s target demographic. I centered the test around three fictional use cases, giving the subject a narrative to aid recall and a fake “receipt” of the transaction to refer to. There would be three tasks, each corresponding to one of the three main payment situations:
I originally planned to test Task 2, the “retail” scenario, with a variation of the “food & drink” flow without the chronological categories—but this entry process was still tedious. (“It’s like I’m ordering the food again.”) I needed to consider a solution that traded clarity and elegance in the assign phase for speed in the input phase.
I was short on time for testing, so if I wanted to test another input method, this would be my only chance. I felt like I’d maxed out on how much I could minimize input labor while still gathering all data needed for the assign flow; a faster method would require a different input framework entirely.
A custom keyboard with basic arithmetic operators makes it easy to split or combine items right in the price input field.
However, like a calculator, it only stores one value at a time, resetting as soon as an operation is performed. The only way to check your work is to start over and hope the result is the same, making it unsuited to anything beyond simple calculations.
Taking this into consideration, I brainstormed a flow that...
and landed on the following design:
Visually, it was a multi-person version of the default Pay or Request flow, so the user knows what functionalities to expect.
Instead of resetting, the calculator “history” is stored and displayed in the field beneath the current value, giving the user the option to view or revise operations.
The “Shared Item” button allows the user to quickly split a price between specified users. Tapping the blue price reopens the overlay panel, where the user can edit the price or users assigned.
For a number of reasons I didn’t anticipate early on, this project was tricky to prototype and test with limited time and resources. I wanted to observe exactly how the subject would enter the data into the device, but I couldn’t account for all possible paths they might take. (For example, some subjects would do simple arithmetic in their head before entering the result into the product.)
Even more advanced tools like ProtoPie weren’t sufficient solutions. Although I could allow the subject to use their native keyboard and assign integer variables to mimic the backend calculations, the custom numerical keyboard with arithmetic operators—critical to testing this feature—wasn’t supported.
I made do by building out a few paths in the prototype and asked participants to verbally walk me through any alternative paths they would take, but this was a tedious and imperfect solution.
“I really wish this actually existed. I’d use this a lot.”
All four usability test subjects were able to complete the tasks successfully—however, all but one participant ran into problems related to the prototype limitations, attempting to carry out actions outside the scope of behavior I’d accounted for.
Two subjects expressed confusion about the input process of Task 3 (Food & Drink), specifically about the use of the chronological categories:
“I don’t get why I need to say what kind of item it is.”
However, both later expressed that they found the assignment flow simple and satisfying. If I had more time, I would have loved to repeat a similar test with the same subjects a short time later to see if their resistance to the input flow persisted or if it mostly came down to a learning curve.
Compared to the item-by-item method, this method offered more flexibility to the user and would require far less work to develop, so it could hypothetically be shipped out to users sooner.
The tests helped me identify many small improvements that could be made to improve the clarity of the flows. Here’s an example from Task 1, the even split:
To make sure the feature would integrate seamlessly into Venmo, I needed to make it look and feel like the product customers were already used to. I recreated and closely studied pre-existing elements from Venmo’s UI kit and applied the same visual and interaction guidelines to my own designs, fleshing out the wireframes with custom components that blended into Venmo's existing design system.
If the videos aren't playing in your browser, you can view them in Dropbox.
