Product Design

Tip Tip Hooray

The Challenge

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

My Approach

It was a bit tempting to just jump right into sketch and push pixels for hours given the time constraint. However, in order to best design a consumer facing app like this one, I believe it is important to first understand:

Therefore I will approach this exercise in five parts:

  1. Context: Problem/Goal, Constraints
  2. Understanding Users: Guerrilla User Research, Competitive Review
  3. Setting the Stage: Requirements, User Flow, Brainstorm
  4. Design: Wireframes, Interactions, Feedback Iterations
  5. Final considerations: Edge cases, Next Steps, Last Thoughts

And with that, let's begin!


CONTEXT

Problem/Goal

Splitting bills with friends after a night out is very convenient! Yet when you include tips, the process becomes really cumbersome. With services like Venmo and Square Cash allowing for quick payback options, people need a way to determine who owes what efficiently and transparently too bypass any potential awkward scenarios.

The goal is to design a simple mobile tip calculator app that helps users successfully and transparently work out service tips, as well as how to evenly split the bill between multiple people.

Constraints/Technology

Calculators can be complex and come in all shapes and sizes. I chose to design for a native iOS app. I decided to go down this route for a couple of reasons:

  1. I am an iOS user and therefore am familiar with the platform's design principles, native interaction models and design patterns.
  2. Based on research and analysis from market research tool CivicScience, I hypothesized that iPhone users are a notch up in the socio-economic scale and therefore have higher income. This leads to iPhone users having the means to go out more often and in turn increases the chances of using a product like this.

UNDERSTANDING USERS

User Research

While thinking of the possible user problems I began developing some questions I needed to learn from users. For example, I began thinking that most users were unaware of how much they should tip. But were they really? I quickly interviewed 5 people I knew who regularly went out with friends to discover the kinds of situations or use cases where friction points may occur. Asking questions like, “When you eat out at a restaurant, how do you calculate the tip?” I was able to nail down some user behaviors, needs, goals and synthesize them into user types below.

The Clueless Tipper

I go out often but I never know how much I should tip for different services. At this point I just have a fixed amount I tip everyone to remove any confusion. I’m willing to pay evenly within friends to be efficient.

Young professionals who are just now starting to enjoy the benefits of adult life. Restaurant tipping comes easy to them but it becomes much harder to determine the tip amount for other services that they are now able to afford (i.e. hairdresser, nails, cab, barber, etc…). They need the app to simple and fast—requiring as least thought as possible.

Job Story: When users open the app to see how much they should tip for a certain service, users want to easily distinguish tipping customs between services so they know how much it is acceptable to tip. One size does not fit all. Efficiency must be key in order to establish a meaningful engagement and permanent habit.

The Group Papa

I usually only go places to hangout with friends and therefore don’t mind taking the bill upfront. And then open Venmo to request money from friends. It’s annoying to split everything and then forget about the tip.

The professional who enjoys going out with friends to big restaurants or events. Typically they are well off and are willing to put bills in their card to optimize the group’s paying experience. They are seen as the group’s papa since in a way they care for them. They need a highly functional and reliable check splitting experience because of their increased responsibility handling the group’s money. They can either split evenly or based on individual expense—depending on context.

Job Story: When users need to split a bill, users want to be able to decide whether the circumstance requires and even split or a more customized split. Seeing how they usually will request money after calculation has taken place, there should be a way to ease the transition from calculator to payment service (i.e. Venmo, Square Cash, etc…).

Competitive Review

I also took a quick look at some of the apps that users had mentioned:

A quick review of the competition gave me an inventory of existing mobile patterns, strengths and weaknesses to begin brainstorming designs for these different types of users. Also gave me ideas of possible ways in which the product can enter a somewhat cluttered market in a strong and unique way.


SETTING THE STAGE

Requirements / User Flows

I came up with a list of general requirements for a tip calculator and started to work through a user flow of splitting bills with special attention paid to tipping.

Brainstorm

Working through the task flow, I began to see where each type of user converged and diverged in their path to split a bill, tip, and ultimately pay their bill. Initial ideas began to form based on these needs:

Idea 1: Design the flow with steps.

The group papa needs to have the ability to determine how the split should be (evenly or customized), while being efficient. Provide the user with a flow that takes them through the various steps to reach their goal. Each step informs the one after and creates a focused unique experience for all users.

Idea 2: Use natural swiping gestures.

The clueless tipper needs the process of determining a tip to be extremely efficient—otherwise they will give up and revert to the fixed amount behavior. Take advantage of the universal pattern of swiping gestures in iOS to provide a quick flow in interacting with data.


DESIGN

Initial Wireframes

Initially, I created two wireframe flows based on two different concepts models: single page vs. paging (steps). But eventually, I took parts from both these ideas to satisfy multiple user groups.

This wireframe flow allows the user to select their desired service and determine what their tip should be, while not distracting users with splitting functionality if the user is alone. The initial state is for one user/clueless tipper scenario where I’am able to provide a very quick and simple experience that focuses on bill + tip. Only adding complexity as the number of people increases and there is a need for splitting bills— ideal for both user types who want to have speed and the functionality of splitting a bill.

Interacting with data

In order to maximize speed and efficiency, the app by default assumes the user is alone (fastest way to get through the flow) and at a restaurant (the most popular setting for determining tip amount). This simple solution only has a single keypad based input: the amount. The tip is then influenced by how much you slide your finger up and down in the cell which then updates the total in real time—my hypothesis being that a vertical slide is more intuitive as there is no need to adjust the grip of the phone. Always having the amount field focussed means making a change to the amount only requires using the backspace. Similarly changing service only requires a tap on respective icon.

Splitting bill… The messy way

Once the user determines he/she would like to split the bill, complexity is added to the screen (a little bit of chaotic beauty). Having determined the tip and bill total in the previous view, I’am able to provide the user with a small selection of actions—as to not overwhelm them. According to research on the paradox of choice, more choices can actually lead to decision fatigue, less happiness, and increased cognitive load. With this approach there is a tradeoff in speed, as there is now an extra step (tap back) to edit the bill amount. However, given that the user agreed to the extra complexity for added functionality—as well as the reduced cognitive load which in turn increases maximum usability, I decided that the tradeoff was worth it.

Visual Direction and Dropbox Vibes

I spent time hyper-analyzing the new visual language developed by Dropbox in addition to the iconography and the interface of all mobile apps to ensure a consistent experience across this app and the brother Dropbox ecosystem. However, aside from visuals Dropbox design is renown for its beautifully simple way of dealing with solutions at hand without any distractions.

Final Wireframes

This last stage was all about refining current ideas and connecting the whole product to Dropbox, not only visually and through the experience, but also placing it within the ecosystem. Here are the shots in higher resolution.

I quickly iterated based on both user feedback and guerrilla usability testing—going to parks in NYC and asking people a couple minutes of time. In this iteration, the focus was on the interaction details and UI design. For example, users said, “They expected a horizontal slide rather than a vertical one when interacting with a slider…icon wasn’t enough to change behavior”. The circular service selection felt random and took too much real estate. In my final wireframes, I leaned on established iOS (and Dropbox) patterns for interacting with data. Adding in finalized colors and iconography also helped reassess UI decisions.

Due to time constraint and Principle being Principle, the sliding functionality is not part of the prototype. However I do provide an idea of what it would look like in the wireframes.

Interacting with data

Instead of having a carousel of services in the top of the view, there is now drop-down menu. User testing showed that people were getting distracted with the carousel and some showed confusion as to what service they were currently using. Seeing how my main goal was efficiency things needed to change. Like I mentioned earlier, the less actions and decisions I give the user, the faster he/she will focus on the task at hand (in this case calculating a tip). The dropdown is able to kill two birds with one stone. It uncluttered the screen and gives a clear indication of the service currently being used—I also included an icon to drive the point home and reduce doubt. Seeing how the most common case is a restaurant, that was the default.

The slider reverted back to it’s more traditional functionality of horizontal dragging due to the added time users needed in order to adapt to the new style. I did however gave it a unique dropbox feel that makes entirely new and very familiar. I didn’t want to take any risks some users (specially older ones) not being able to understand how a slider works, so I included a simple on-boarding experience. I removed the slider indicator as it gave me room to place the monetary value of the percent tip—it was a tradeoff I was willing to makes due to the changes I made to the slider itself as well as the on-boarding experience.

Dealing with complexity

Visual tweaks were made to create sense of hierarchy with the information. This view builds on what the user has experienced in the previous view with no input taking more than one tap. By default the splitting functionality is set to even split as it allows the user to immediately exit the flow by finishing and requesting the money through a third party. And of course the option is present for the more complex situation where the split is uneven. The “save to Dropbox” link helps bring this product into the fold/ecosystem and provides a new way to enter the Dropbox new account flow—where the company provides them with the tools to manage and store financial data.

After much research on how to deal the custom data that comes from splitting the bill unevenly I decided to go with computer vision. After the user decides to go deeper in the “complexity rabbit hole” and selects No to splitting evenly, They are given the ability to snap a picture of the receipt and allow Dropbox to analyze and convert printed information to digital. While computer vision is resource/engineering heavy, I believe it is the path that gives users the least amount of friction in completing their task. Seeing how Dropbox already offers a document scanning feature, the value the user gets with using this feature greatly surpasses the cost of tuning it for receipts. From there is a matter of simple selections based on your party’s selections. I offered the user with a clear color coding in order to improve readability.


FINAL CONSIDERATIONS

Next Steps and Final Thoughts

Errors, dead-ends, failures, so much! Next steps would be to test again and see how these concepts fare in the hands of more users. I’d remind myself of the original goal:


The goal is to design a simple mobile tip calculator app that helps users successfully and transparently work out service tips, as well as how to evenly split the bill between multiple people.


Testing for success and efficiency would be a usability test, which could measure how long it would take for users to determine their tip, how successful they are splitting their bill evenly and unevenly.


Next iterations would also work through more edge cases. Some examples:

  1. Enter manual selections. What would happen if a user’s camera is broken or not modern enough to allow the computer vision algorithm from doing its job. What kind of error would it give the user? Should this edge of the market be ignored or addressed? Is there enough demand to apply more resources to this problem.
  2. How to provide information about tipping. Should users be given a sort of crash course into what tipping customs are? Should they need to know what a 5 star experience is compared to 3 star one?
  3. Should there be tipping location context. Will users find value in knowing which countries are knowing for tipping? (I.e. USA vs Italy) Or is that something they learn in trip planning/already know?

I’d be especially curious to see how the app performs in an iPhone X seeing all the new gestures that are part of the experience, maybe some interactions could change to take advantages of these. My hypothesis still remains that gestures provide a faster data manipulation experience than typing or selecting — it no doubt will affect precision, but speed (in the context of this app) is more valuable for the user — but I might be wrong! I’d be keen to learn how much value that interaction actually provides users in splitting checks and calculating tips… If it indeed would be worth the development cost.

Thank you! 😀


All assets and files can be found in this folder.

Have a project? Let’s talk about it.

Get in touch