I interviewed with Dropbox for a product design position, and was tasked with designing a tip calculator mobile app in 48 hours. I ended up focusing on the problems of splitting a bill evenly or calculating a tip based on your current context/location, and splitting a bill unevenly. My solution was a mobile app that not only calculated the tip both fixed and dynamically, but also integrated computer vision to read receipts through the camera.
I was an aspiring Dropbox product designer interviewing for their product design position.
Design a calculator mobile app that addresses the following: ability to split bill and tip with multiple people and ability to specify tip amount or percentage (ex. 10%, 15%, 20%) in 36 hours.
It was tempting to just jump right into defining the problem given the time constraint. However, in order to best design a consumer facing app like this one, it’s important to first understand a) who are we designing for, b) what kinds of problems do they face, and c) how can this app find product-market fit within the context of this problem.
I began by talking to some friends in depth about the kinds of situations or use cases they encounter where they might want a solution to their friction points. One friend in particular described her experiences with tipping:
As demonstrated, use cases with the most frustration/friction are most likely not restaurants - they’re encountered primarily with edge cases, such as hairdressers/barber shops, cabs, etc.
Another friend described his own experiences, specifically regarding splitting a bill unevenly based on what individuals ordered. We’re both on the rowing team, and every time we go out, he pays for everyone, then goes home and uses a google spreadsheet (below) to calculate out, and uses Venmo to individually charge each person.
Spreadsheets are a usability nightmare, especially in this case. He can’t do this on the spot because he uses his computer, which means the first step of his work flow is marking what each person ordered on the receipt. Then, he must go home, manually enter each item into the spreadsheet, apply some formulas, ensure that there are no errors, then individually charge each person on Venmo for a payment.
While the 1:1 interviews were eye opening, I wanted to also guage how a larger number of individuals responded to these same issues. I asked the following questions and yielded the following results:
My survey sample consisted of UPenn Seniors & UPenn CS majors. I collected 63 total responses.
Users face two primary problems when faced with tipping/splitting a bill:
With these two problems in mind, I focused my efforts on designing a variety of solutions to create a cohesive product to best solve these customer pains.
When approaching wireframes, I considered the variety of possible features and actions users might need or take to solve the two core issues.
However, one can not design this functionality without keeping in mind the second challenge: designing an experience for users to also split the bill dynamically based on each person’s individual orders.
While the two mental models of splitting the bill evenly and splitting the bill dynamically are closely paralleled, the actual processes that translate into an interface are very different just given the variability of the latter process. With this in mind, I iterated through some wireframes, each with a variety of potential interactions users can take to best achieve their goals.
From an interaction design standpoint, my primary was was to incorporate interactions that would be the fastest and most efficient, specifically for inputting specific small ranges of numbers (tip %, number of people). From a visual design standpoint, I hyper-analyzed the visual language used in both Dropbox iconography as well as the interface of the mobile app to ensure consistency across my app and the Dropbox brand/mobile user experience.
I also scoured online to find representations of Dropbox iconography and visual design to best replicate the visual language.
In this example, a user is currently inputing the bill amount with the iOS numerical keyboard. Once a user taps the “Bill Amount” form field, the keyboard pushes everything on the screen up to allow users to also manipulate the tip amount without any extra back and forth friction. As the user is typing, the tip amount automatically updates based on the above input, allowing users to get the total tip amount in real time based on the default settings.
In terms of the default values, they change depending on the context. In this case, for a restaurant, 15% is typically the most common; thus the default is set at 15%. For something like a barbershop or tattoo parlor, however, because it’s more personal, the default might be set at 20 to 25%. An interesting possibility might be the integration of ML to set defaults. When users set a default for “restaurant” to 20% to a point where it’s statistically significant, make the default 20%.
The typical mental model for users splitting a bill evenly follows: 1) look at bill amount 2) take a percentage of that to yield a dollar amount 3) add to bill amount 4) divide by number of people. Thus, the purpose of this specific design tradeoff was to parallel that existing mental model - allowing users to naturally follow the same route in their heads on an interface like this one.
The little info icon next to “Tip Amount” displays a modal window that allows users to gain a better understanding of how to tip in their current context. In the case of a restaurant, this is a possibility of how a modal window might convey that information to the user in a straightforward fashion.
The default option is always a restaurant because that is the most common use case. Not at a restaurant? Simply tap “Restaurant” in the nav bar to reveal a dropdown menu with a variety of options to choose from, established in a hierarchical order from most common to least common. To exit, simply tap anywhere outside of the dropdown menu, or any category/location in the nav bar.
I designed each icon to correspond to both the categories as well as Dropbox’s visual design language.
Tapping the ellipses allows users to access a few less used options, including country (important because of ambiguity of tipping customs in different countries). The reset field is also nested in here because most likely, users won’t need a full reset of fields just given that this app is probably only used for one bill at a time, but it might still be handy to have that option. Finally, the share option generates the standard iOS GUI element of sharing over messages, Facebook, etc. to allow users to send the copy of the inputed check to their friends if they do decide to request it.
Once the check has been scanned, we can also provide physical feedback through a phone vibration, alerting users that the scan was successful. Users get a condensed view of the breakdown of the check. Similar to the “even-breakdown” UI, users here can also manipulate the tip amount or number of people with the same interaction using the slider. When they’re done, they tap the “Assign individual items” to get to the next screen.
Each individual item and it’s respective cost has been added. “Person 1” is automatically selected, marked by it’s active state of green. The name assignments are arbitrary for smaller gatherings, because at a dinner table, usually the person paying will say something like, “What did you order, Jeff?”. Jeff then responds, allowing the user to quickly scan the display of items and tap the ones that correspond to Jeff. When users tap on an item, a green checkmark icon appears on the left, identical to the one found in the current Dropbox design language.
Finally, users can then request individuals on Venmo. I did some research on accessing a third party app like Venmo and automatically plugging the value into Venmo’s dollar amount form field after user’s select who to pay, but I found limited information about their API access. I imagine you can probably pay someone for an API key to implement this though.
If the engineering implementation were possible, all the user would have to do is type in their friend’s name in Venmo and it automatically assigns the amount requested into the amount field.
test on users. Ideally, even just doing as simple as a full Invision prototype to see how individuals navigate through the entire app would be very informative as to how useful of a tool they see this, and what kinds of features might not be necessary for an MVP or what might be missing. This is something that just sending static, individual screenshots to friends can simply not uncover.
see if there is potential for social gamification? In one of my interviews with my buddies Josh, a former PD intern at Facebook, he describes how he always tries to calculate tips in his head because of a social stigma of using a calculator, specifically for Asians. Indeed, I can empathize with this. Is there a possibility of gamifying this so it can also be some kind of social tool?
One potential idea could be “masking” this behind another app, for example an integration with FourSquare, or perhaps a feed of who has been to what kinds of locations as a feed in this tip calculator app.
At holistic level, this could also be very useful because of the potential for more data mining. By aggregating and analyzing data between restaurants and user’s tipping habits, we might be able to make inferences about the user’s spending habits depending on cuisine, time of day, etc.