Venmo: Split the Bill

Developing a new feature to help users split complicated checks with ease

Proof of concept
User Research
1 month (2022)


The Problem

There’s a reason splitting the check is a staple of situational comedy—it’s an awkward, tedious, and complicated task.

Often, one person will put the bill on their card and ask others to Venmo them back. But someone almost always ends up paying more than their fair share, and people can leave unsatisfied with the way things were split.

The Task

Since Venmo is already the favored service for small cash transfers like drinks or dinner, users would greatly benefit from the addition of an integrated “Split the Bill” feature to streamline the process of splitting a cheeck.

This would boost user loyalty and satisfaction by providing a solution to a common headache and in turn increase the number of Venmo transactions.
project constraints

Dev workload

Utilize underlying processes already existing within Venmo as much as possible to minimize backend demands.

Brand style

The new feature should integrate seamlessly into the preexisting product.

Time crunch

Only 80 hours in total to tackle a complex project.

This feature hits the sweet spot of being valuable for the users yet simple for the devs on the backend.

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.

There were two distinct possibilities for the end product:

Single person

The entire flow is managed on a single device.

Group involvement

The flow involves multiple interconnected devices. Each member controls their own involvement.

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.

Competitive Analysis

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:


Manual entry or OCR (camera) scanning


Assign items to users or split between users


Display payment breakdowns (may include link to use Venmo)

Using the same hypothetical use case for each app, I tested out competitors’ solutions and took note of their strengths and shortcomings.

Selected notes on two competitor products

I indentified two major pitfalls to avoid: tedious item entry and overwhelming displays of data.

Time-consuming item input

OCR scanning technology proved error-prone and frustrating on receipts, but manual input quickly becomes tedious and repetitive. Input must be as fast and simple as possible.

Information overload

The data needed to carry out the flow builds up fast. For bills with more than a few items, the data begins to look like a wall of indistinguishable text and overwhelms the user.

Using the camera to scan the receipt is ideal in theory but error-prone in reality.

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.

A feature native to the Venmo app would have a crucial leg up over third-party competitors.

Use full names & avatars

Instead of having to remember an arbitrary color or cartoon animal, users can identify their friends directly by their Venmo handle and avatar.

Send all requests at once, right in the app

Since the tool would be integrated into the payment method, the user could save time by requesting all payments with one tap.

The core challenge would be in finding the right degree of complexity.

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.

User Interviews


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:

Identify common logistical difficulties in splitting the bill.

Understand the various challenges users run into and their corresponding solutions and workarounds.

Gain insight into the emotional underpinnings of the process.

This part was especially important for this project—when money enters close relationships, things can quickly get uncomfortable.
Findings & Analysis

The user interviews were very illuminating, particularly in terms of the subjects’ emotional experiences.

Overwhelmed by my interview notes, I created an affinity map to parse out common emotional threads and logistical insights. The following themes emerged:







Selected affinity map clusters

Some selected research findings and the design insights they inspired:


Friends value the laxity of loans between each other and view it as a symbol of trust.

“It’s kind of a nice thing to have with friendships—that trust that they’re eventually going to get you back.”

— Interview participant


Account for a range of desired precision.

The feature should accomodate this laissez-faire attitude and support both a relaxed and a strict approach towards splitting the bill.

People find it uncomfortable to remind someone about a debt they owe.

“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.”


If the feature doesn’t offer a choice between paying or requesting, this guilt could be absolved.

In other words—it’s the technology, not the user, who makes the call.

In most use cases, the environment is chaotic and not conductive to objective, focused thinking.

“At the end of a meal, somehow basic arithmetic turns into computer science.”


Minimize the load on the user’s working memory.

Eliminate the need for any mental math.
single person or group involvement?

Single person

The entire flow is managed on a single device.

Group involvement

The flow involves multiple interconnected devices. Each member controls their own involvement.

Based on my findings and the reality of dev demands, I decided to go with the single-device option.

Since it uses local variables instead of importing variables across devices from synchronous users, it would be much simpler on the backend.

The sunk cost taken on by the person covering the check means there is a financial incentive to complete the flow.

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.

I considered the MVP to be a feature that accounted for three main situations.

For the scope of this project, I decided it should address three use cases, in which the bill becomes progressively more complicated:


Even Split

A total amount split evenly


A subtotal split unevenly

Sales tax split proportionally

Food & drink

A subtotal split unevenly

Sales tax split proportionally
Tip split proportionally

Ideate & Design

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.

For a complex bill with many items, how could I create structure and order in the mass of information?

Use chronological groups to categorize items—like a restaurant menu.

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.

How could I make the item input process as fast and simple as possible?

Input items by category

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.

“Add Another” button

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.

Progress bar

A progress bar based on the remaining unassigned subtotal would provide clarity and motivation to complete the flow, minimizing abandonment.

Even with these changes, I wondered if the input process was still too much work.

Would the clarity and convenience of the assignment process be worth the input labor needed to get there?

Prototyping, Testing, & Iterating

Setup & user tasks

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:

Task 1: Even split

Gas money on a roadtrip

Task 2: Retail

IKEA run with roommates

Task 3: Food & drink

Dinner at a Mexican restaurant
The first of three user tasks for the usability test, demonstrating the “Even Split” scenario.

A preliminary run through my usability test fed into my suspicion that the flow required too much input labor.

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 went back to the drawing board to develop a simpler input method that required less user labor upfront.

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.


Part of what makes Venmo so simple to use is its built-in calculator.

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.

The native arithmetic operators currently used in Venmo’s Pay or Request screen.

Taking this into consideration, I brainstormed a flow that...

Makes use of Venmo’s preexisting built-in operators
Supports longer strings of operations without straining working memory
Allows the user to quickly split an item between specified people

and landed on the following design:

A version of the familiar request overlay.

Visually, it was a multi-person version of the default Pay or Request flow, so the user knows what functionalities to expect.

Calculations stay visible in the input field.

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.

“Shared item” button allows for quick splits.

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.


While building the interactive prototype, I quickly ran up against the limitations of available tools.

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.)

Without access to a developer or the time to code a prototype myself, there was no way to allow for the flexibility that would be central to the feature’s success.

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.

results & findings

Overall, participants were excited and enthusiastic about the feature.

“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.

I decided to move forward with the second, simpler method for the "Retail" and "Food & Drink" situations.

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.

Custom components precisely modeled after Venmo’s existing UI.

The Final Product

If the videos aren't playing in your browser, you can view them in Dropbox.

Splitting a complicated dinner bill between four people using the Split by Item option.
Splitting a simple total evenly between people using Split Evenly.
The feature would be integrated into the top of the page that appears after the user first clicks Pay or Request.
Split Evenly / Summary screen
Split by Item / Number entry and tip calculator
Split by Item / Multi-person calculator tool. Blue numbers represent a portion of a shared item.
Split by Item / "Add a shared item" overlay. Reopens when a blue number is tapped to allow changes.
Split by Item / Summary screen, where the user confirms the total and sends the requests.