SPLITWISE
ADDING A PAYMENT FEATURE TO REDUCE STRESS WHEN SHARING EXPENSES
Background
Splitwise is a free tool that keeps track of shared expenses and balances with housemates, trips, groups, friends, and family. Splitwises’ largest customer base is in the USA. These users have access to a different set of features than those based in Europe and else where. Understanding how European customers are using their services and what new features are desired would be critical in growing this audience. The products current utility was investigated for feature additions to improve user satisfaction.
The problem
Users are unable to pay each other directly within the application.
Initial tests
Users were tested on both the time it took them and the number of applications they used to complete a single payment. Users who already had the payment details of the payee took 5 minutes and 24 seconds and used two applications—Splitwise and their banking app—to complete the payment. Users who did not have the payment details of the payee took 8 minutes and 35 seconds and used three applications—Splitwise, a messaging app, and their banking app—to complete the payment, assuming the payee immediately responded to their request for payment details.
Competitor analysis
Products have differentiated themselves within the market by optimising their services to particular situations under which expenses are usually split. None of these products allowed users to pay each other within the application.
The solution
I asked myself if a direct payment method could be integrated within the application. This would enable uses to not only calculate their shared expenses but also settle outstanding debts with each other without ever leaving the application.
Research
I had two aspects to research that would be critical to the project’s value proposition:
User research
​Absent direct payment method is frustrating. Difficult conversations persist around expenses due to repayments. Users have issues with group and individual expense repayments.
The primary function of the product, keeping track and remembering expenses, is highly valued by users. Multiple expense sharing scenarios are also used by most users.
Secondary research
UK legislation dictates that if a service offers it's customers the ability to move money between two accounts, they must meet a list of legal requirements. Due to the complexity of these requirements necessitating additional professional support, the integration of a payment system can be very expensive if a business seeks to do this by themselves. With this in mind, I identified the financial transaction service provider Mangopay. Mangopay enables businesses to design their own payment system. In the case of Splitwise, users would need to be able to link their bank accounts and pay each other directly. Users would also need to hold money within the application and use this credit to make purchases and sales.
Defining the audience and application features
The findings show that the primary function of the application, sharing expenses, is successfully retaining users, however, adding an in application payment method would complete the service, resolve some of the current pain points and attract new users.
Personas
User research, strongly indicated that the designs should seek to fulfil the needs of the following 3 key personas.
The Forgetful
Needs an easy way to “settle up” with other users that does not require them to remember any information when doing so.
The Unconfident Mathematician
Wants a payment system that reduces their frustration with numbers when paying other users.
The Impatient Technophobe
Struggles to learn and remember how to operate applications. They want to reduce the number of applications they are using when paying other users.
User flows and navigation
The applications established information architecture was used to identify the level on which to add the new features. In order to design a fully integrated payment system, 3 key user flows were identified.​
​
1. Payment
2. Withdrawal account and payment account
3. Withdrawing
Wireframes
Low fidelity wireframes were produced by carefully integrating existing examples of payment systems into the current Splitwise designs.
High fidelity design
Once the added features were optimally integrated, I began to create the high fidelity designs and a prototype. At this stage I revisited my user research key insights to ensure that my designs addressed “how I might”:
BEFORE
Maintain the current functionality of the product that users place most of the value, by utilising existing user flows.
AFTER
Enable users to pay each other directly within the application by integrating payment methods.
Reduce difficult finance related conversations, and assisting users with group and individual expense repayments, by providing payment confirmation for reassurance.
Revisions
BEFORE
AFTER
The wording was changed from “You paid” to “You’re paying” to make it clear that the payment had not cleared yet.
I added an underlined button on the payers bank information as users repeatedly tried to select this information. This button will enable users to change their bank details.
The wording was changed from “Add card” to “Add new payment option” and “Change bank account’ to “Change withdrawal account” to help users have a clearer understanding as to how their card information would be used. I also added an information icon next to “Change withdrawal account” that will give users access to a new information screen that explains the “withdrawal account” functionality.
I added an information icon next to “Pending balance” that will give users access to a new information screen that explains the “Balance” functionality to help support their understanding of the feature.
New design tests
After the redesign, users completed a single payment in 46 seconds using only Splitwise.
Conclusion
The payment feature will allow users to pay each other within the application. This increased utility will reduce user fatigue or frustration by removing user money transfer errors.
The greatest challenge of this project was adding a feature that would bring greater value to the product whilst not disrupting the primary function which has already proven to be very useful for attracting and maintaining its large user base.
Looking forward
Further feature designs need to be created for the payment approval system for users receiving funds.
The edition of this feature could result in the following product wide changes:
-
New methods of shared expense calculations.
-
Agreed budgets “pots of money”.
-
Monthly management systems.