Tab

Splitting bills, not headaches

Overview

Design a standalone bill splitting app for iOS or Android:

• Ability to split bill and tip with multiple people
• Ability to specify tip amount or percentage (ex. 10%, 15%, 20%)
• Be creative with what features you decide to include

Approach

Ask Questions

The first step in my approach is to ask questions. By doing so, you get a much better understanding on the problem that needs to be solved, as well as its context.

Some questions asked along the way were:
• What is the base issue with splitting bills at a restaurant?
• What is the current bill splitting experience like?
• What are the current user frustrations?

Research

Next, research helps find answers to these questions and I can start to brainstorm in the back of my head. Based on the timeline given, I conducted my research online, discussing with friends, and looking at competitive apps in this space.

All of the apps I found were visually cluttered and unappealing. They were seemingly all built for utility and not simplicity. Even then, the utility of these apps wasn’t usefully as the visual clutter impeded the speed users need for apps in these environments.

What is the base issue with splitting bills at a restaurant?
"I don’t know of any good apps to split and even then I don’t think I would really download one just to split bills." - Gabe L.

"Sometimes they don’t accept my card so I have to use another or rely on someone to spot me." - Dom T.

What is the current bill splitting experience like?
"I just open up my calculator, do the math, and then ask people or request people on Venmo for the amount." - Connor M.

"It’s just easier if everyone puts their cards down and the waiter/waitress splits it for us." - Alex L.

What are the current user frustrations?
"Even when we Venmo each other, the person who pays for everyone initially ends up paying more because people either Venmo just the cost of their meal or approximate." - Kathryn L.

"I’m don’t want to do the math so I’ll pay now and just figure it out later with everyone." - Alyssa C.

From talking with my close friends and seeing the experience of current bill splitting apps, it just made sense that Venmo was the clear solution for one reason: speed. Everyone around me already has and uses Venmo so why not use that for splitting bills? It’s quick, convenient, and secure. I needed to prioritize speed as my primary design principle and reinforce simplicity into the design.

Infomapping

Infomapping is one the most important parts of this design process. It allows you to map out just the content you need to have included on each screen. It also gives you a general sense of the flow of the product. The green boxes indicate the screens that users must see in order to complete the objective of splitting a bill. The gray boxes indicate screens that users don’t have to see, but are complementary to the process. The green text in the boxes indicate calls-to-action that exist on those screens.

Ideate

This is the part of the process where I can think about blue sky ideas and potential solutions without any constraints. Here are some ideas that came up:

Thumbs In: When one person pays the bill, open up the app. Then pass the phone around the table to scan everyone’s thumbprint to get their Apple Pay information. They can type in how much their meal cost, in addition to their custom tip amount.

Computer Vision: Take a picture of the receipt to gather everyone’s amounts. Then assign each item to a specific person in your contacts. They’ll receive a notification on the payment method you’ve selected.

Who’s Nearby: Enable Bluetooth to find the people sitting at your table. Then send them bill splitting requests. Each person would get a notification for the split.

One Step at a Time: Guide the user through the bill splitting process, similar to an onboarding process. Each step would focus on a single task for the user to achieve.

Design

Sketch

Putting pen to paper begins the visualization process where I can take these concepts and turn them into components. It becomes a brain dump of the ideation process and exercises like Crazy Eights can help here as well. Although unorganized and raw at first, I can begin to refine these visual components, piece together the ones that work together, and take them into wireframes.

After several sketches and ideations, this emerged as the flow for the product. It would have one main user flow (green boxes), with secondary actions along the way (white boxes). From the first screen, it only takes the user two steps to the quickest possible split. This reinforces the principle of speed that is so valuable to the user when splitting bills.

Wireframes

The happy path would be a user splitting an even bill. They would be able to enter the amount of the total bill, choose who they wanted to split with in their contacts, and send off the request. Although tipping is encouraged, I didn’t want to force the user to do so as the primary objective of this challenge was to facilitate bill splitting. The user also has the option of changing the split method, whether it’s with Venmo, Square Cash, BTC, etc. (assuming that the user has added and authorized permissions for the payment platform).

One of the challenges here was tipping. What was the easiest way to encourage tipping without making it mandatory? The first was having preset tipping amounts. I used the three most common amounts for restaurant tipping amounts (10%, 15%, and 20%). To account for no tip and custom tip amount, I added an increment system so users could change the tip percentage amount to their choosing. I didn’t want to have a custom tip amount input because that would pull up the iOS keyboard, making this experience feel clunky and inconsistent with the rest of the app.

If the user did choose to split unevenly, they would be asked to input the item amount for each person they paid for. One of the challenges here was balancing utility and simplicity. On one hand, I wanted to have the user enter all the amounts on one screen. However, I felt that this would be overwhelming to the user and clunky to enter, edit, and delete amounts all on one screen. I decided to lean towards simplicity and introduce a similar UI to the home screen where the user can input each amount depending on the number of splits. Each amount would be easy to edit and see who ordered what. Finally, they are able to review the split before sending the request. If they wanted to make an edit, the user could tap the name of the person to edit their amount instead of going back through each person. In addition, they would see their own amount for the meal (total - sum of other amounts). This way, they wouldn’t see a total amount that didn’t add up.

High Fidelity

Confident in the concept and flow, I moved on to high fidelity designs. Some new screens emerged as I ran into other use cases during this phase. The Past Tabs screen allows users to see their past bill splits including the total amount of the bill and their splits. The Split Using screen allows users to choose their preferred split method or add another. One of the changes from the wireframes I implemented was adding a review screen after the even split as well. I did this for three reasons:

1. The user experiences inconsistent actions with even versus uneven splits.
2. A review of the splits reassures that user that even split amounts are correct.
3. Requesting immediately after selecting users can be jarring.

Adding Tips
The tip screen changed visually from the wireframes for a few reasons. First, I wanted to better utilize the space on the this screen. Second, I wanted to keep the calls-to-action consistent across the app. Finally, I wanted to place the presets above the increments to promote them as they as standardized and much faster than entering a custom amount. Having increments eliminates the need for custom amount and no tip calls-to-action. On the tip screen, the user sees the dollar amount of the tip based on their bill. When they confirm their tip, “Add Tip” is replaced with the percent and dollar amount of the tip.

Even Split
The tip screen changed visually from the wireframes for a few reasons. First, I wanted to better utilize the space on the this screen. Second, I wanted to keep the calls-to-action consistent across the app. Finally, I wanted to place the presets above the increments to promote them as they as standardized and much faster than entering a custom amount. Having increments eliminates the need for custom amount and no tip calls-to-action. On the tip screen, the user sees the dollar amount of the tip based on their bill. When they confirm their tip, “Add Tip” is replaced with the percent and dollar amount of the tip.

Uneven Split
For uneven splits, the call-to-action changes to “Next” instead of “Review” because they have to put in custom amounts. They are able to see the image, name, and individual amount for that person’s split. In addition, they see the total amount plus tip at the top of the screen reminding the user that this is the full amount being split up. The uneven split review follows the same convention as the even split review screen.

Past Tabs
I added this into the high fidelity flow because I realized the importance of past bill splits. The user can see a history of all their past splits, as well as the amount of their own meal here. Think of it keeping digital receipts in one place. On this screen and the review screens, you can see the default avatar that is assigned to contacts without an image set in the phone.

Prototype

The area where much of my design focus lies is prototyping. With a prototype, you can convey any thought or interaction without explanation. Having a prototype gives you an advantage in user testing and engineering. It’s a magical feeling seeing a user’s reaction to a prototype. The two tools I use are Principle and Framer. Principle is great for speed and micro-interactions whereas Framer is great for modules and end-to-end flows. The prototype below was created in Framer.

(Due to time constraints, the prototype may lack certain functionality/act buggy)

Speed Comparison (Even Split 3x, $30 @ 10% Tip)
Current Venmo experience: 33 seconds
Proposed concept experience: 15.27 seconds

Next

Challenges

One of the biggest challenges that I experienced when designing was the definition and distinguishment between terms. These terms also assume tax is included in the total bill:

Total Bill: The bill amount you receive after your meal EXCLUDING tip
Individual Subtotal: The individual amount for one person EXCLUDING tip
Total: The bill amount PLUS the tip

Another challenge was the timeframe of 3 days to complete the challenge. I would have liked to have done user testing with the prototype and see it in action at a restaurant.

Edge Cases

There were several edges cases I considered throughout this process. Some I addressed in the designs, some I didn’t include because I felt that they were more suited to v2 of the app.

• What if I didn’t eat anything, but paid for others?
• What if each person wants to tip a different amount?
• What if I want to see my past splits?
• What if I don’t want to use Venmo?
• What if a contact doesn’t have a picture?
• What if I have a super expensive meal? How would that fit? (e.g. $10,000)
• What if I went out with a large group of 20+ people?
• What if we shared a plate, but some people didn’t eat any of it?
• What would the notifications look like on iOS when a person receives a split request?

Next Steps

Going forward, I would definitely explore more of these edge cases and see how many of them occur in the field. By user testing, I could see where the design fails and what could be improved, keeping speed and simplicity as the core principles behind this product. One of the ideas that could implemented is to expand this splitting service to other verticals outside of meal splitting. This could be used for a multitude of purposes such as rent, subscription services, and ride-sharing. It would also be neat to integrate a rating system as the dining experience is much more than just the food. After heavy user testing and weighing its potential, I would go forward with development if the product eased current user frustrations and was used more frequently than the incumbent Venmo.