CASE STUDY
Divvy
2023
An app to easily split or claim specific items of a restaurant bill.
Divvy effortlessly simplifies the process of splitting bills. Just snap a photo of your receipt from a restaurant, and let Divvy take care of the rest.
By leveraging object character recognition (OCR) technology, Divvy accurately identifies tax, tip, and individual shares. Whether you prefer an even split or want to claim specific items, Divvy ensures a seamless experience, ensuring everyone pays their fair share based on what they ordered.
from idea to implementation
Picture this: you're out to eat with your friends, and the waiter drops the check. Everyone stares at each other awkwardly, waiting for someone to take one for the team and put their card down. Someone eventually caves, and they panic as they take photos of the receipt, calculate tax and tip, and Venmo request everyone.
...it's a pretty awkward situation. But it happens all the time. Enter: Divvy.
Divvy is an app that makes splitting the bill easy. Simply upload a photo of your receipt and Divvy does the rest, using image recognition technology to determine tax, tip, and how much everyone owes. Friends can choose to split the bill evenly or claim items on the receipt so everyone pays for what they ate.
With Divvy, you don't have to dread the end of a meal.
main user flow
We first brainstormed "dream features" that we would want our app to have. At this point, we knew that we wanted to find a way to easily split items from scanning a receipt.
whiteboarding dream feature list
opportunity areas
How can we display easy identification of pending payments to friends, rephrasing "unclaimed expenses"?
What does it look like to have a group and receipts assigned to a group?
How do we make it clear on which user has finished claiming their items?
initial design concepts
Getting stuck on edge cases while going through the user flow
While working on our low fidelity design and essentially user flow, we ran into a ton of edge cases. While seemingly minor, the edge cases disrupted the current user flow we had.
This is what we knew before starting on the low fidelity flow:
It's crucial to distinctly differentiate between paid and ongoing expenses within the group's interface.
It's essential to display both the original receipt and its scanned version for reference.
low fidelity sketching
edge case
When do individuals scan the receipt?
Do users scan an itemized receipt before they put down their card to pay or after? This is variable for determining the tip amount, who the person who scanning is, and when the menu items are "divvy-ed" to each user.
edge case
What if someone gets added mid-process of scanning a receipt?
We had to consider scenarios where someone joins a group before the receipt is scanned.
edge case
Who assigns a menu entree?
Does the person who scanned the receipt have to figure out what everyone else ordered and do all the work to get paid back? Should individual members of the party be able to claim their own items simultaneously?
iterating to high fidelity designs
Iteration v0
As a group, we needed to reorient the project as we had less than a month to implement the MVP. Due to the time constraint, we must rethink how this flow would work PAST dinner, not at the table when they’re currently paying.
high fidelity overview
Product Architecture
Last updated on July 20, 2024, 5:46 PM EST