Splittt main

Splittt: share payments as a group

The problem:

People who want to pay for expenses in groups do not have a synchronized and seamless way of paying each other. Most of the time, members who purchase products or services for other members do not get repaid mostly because they forgot or do not want to have an awkward conversation about money.

what I did:


User Interviews

Feature Competitive Analysis

User Personas & User Stories

User Flows

UX & Visual Design

Prototype for User Testing


3 Months


People love to do things in groups, be it trying out a new restaurant, taking a vacation to a faraway island, or simply sharing a cab. Sharing experiences in groups tend to make these experiences more fun and enjoyable for the people involved.

It is common that among a group of people trying out something, one or two persons might make the payment as it would be strenuous for a lot of people to make payments at once for a group experience, but what happens most times is that, after sharing that experience, the others simply forget to pay back their share to the people who paid and these people might not want to bring up the situation about the debt thereby foregoing the debt.


To get started, I conducted some extensive research on group payments platforms like Splid, Splittr, and Monshare to find out why they weren't as seamless and synchronized as they should be.

The first thing I realized from my research was that while these platforms allow you to keep records of expenses and debt payments, you can't repay your debts directly from the app. As a result, you would have to leave the app after finding out how much you owe, go to a payment app and make the payment, then come back to the app to record your payment. This should be available directly from the app.

The second thing to notice about these platforms is that they do not support recurring payments, so people who want to create recurring expenses like rent, monthly groceries, etc would have to create an expense for these every single time they need to receive payments instead of setting the expense billing frequency and having the app take care of reminding others in the group when it's time to pay again.

So, I already had my theories on what features would make this product seamless and easy to use. But seeing I'm not designing this product for myself, I had conduct interviews with potential users to help me get a better understanding of their challenges with group payments.

From the interviews, I got some definitive results that helped me:

Excerpts from Interviews

From the results of the interviews, I was able to see that not a lot of people have tried using a group spending app. Of the people I interviewed who have used them, I was able to prove my theory about the feature to repay debts directly on the app.

With the results of the interviews, I felt I could move on to the next stage of the product.

Understand & Define

Before any further steps, I had to fully understand and define the solution. To do that, I needed to answer a couple of questions:

What will be the end result?

The end result should be a product that allows people to split expenses and make payments in groups, giving them the ability to create recurring expenses and repay debts directly from the app.

Who are the users?

These are the users for this product:

  1. The Admin: This is the user who creates and controls the group, this user has administrative rights in the group.
  2. The Member: This is the user who joins the group created by the admin.
What are the competitive features needed for this product that others don't have yet?

To achieve this, I conducted a competitive analysis on competitive features comparing the product feature goals with a couple of products out there; Shown below

Feature Competitive Analysis

Exploring Solutions

Having been able to understand and define the solution, I had to figure out what form my solution would take. To achieve this, I had to answer one question

What would be the expectations of the users for this product?

To understand the different user types and what their expectations would be, I created some User Personas & User Stories from the results of the research and interviews.

User Personas

Ada User Persona

Tolu User Persona
User Stories

Group Admin User Stories

Expense Creator User Stories

Expense Benefactor User Stories

From the User Personas & User Stories created, I was able to understand that this solution has to be in a mobile form to be able to receive synchronized notifications when an expense is created in your group. Also, it should be integrated with your payment wallets and bank account for easy payments and receipt of payments.

User Interface & Experience

It was finally time to bring everything together visually with the User Interface design.

Displayed below is the userflow for the registration and groups exploration process

Traveller User Persona
Splittt: Visual Design

Onboarding & Registration process

Onboarding Flow Sign Up Flow

For the onboarding process, I had to make sure the message passed was clear and describes the app experience while also making the signup and login buttons immediately accessible so the user can skip the onboarding if they wish.

To make the registration process seamlessly integrated, there had to be options for users to validate their account using their social accounts thereby saving them a lot of time using the email verification process.

Creating a group

Create Group FLow

There are two options here, either creating a new group or joining an existing group. I tried to make the steps for creating a group as short as possible while spreading out and grouping the information according to the steps. The first two steps help you personalize the group with a name, description, and photo. The third step lets you set preferences for the group and the last step lets you invite members with the group code or by sharing an invite link.

Creating an expense and sending payment reminders

Create Expense FLow

The user creates an expense in three simple steps;
The first step describes the expense, here the expense creator describes what they paid for, what category it falls under(they can choose a pre-existing category or create a new one), and how much the expense was.
The second step is where they choose the billing frequency, they can either choose to bill the group once or set the frequency for billing, they also choose when the billing should start and if they would like the members to get notifications when it's time to pay.
The third step lets the expense creator choose who paid(if more than one person paid), and who benefited from the expense in the group.

Adding a payment method

Add payment method flow

The process for adding a payment method is made to be as simple and seamless as possible, all the user has to do choose the "Add payment method" button at the bottom of the page and they are presented with a modal to add either a payment card or a payment wallet.

Paying a debt

Pay debt flow

For this process, I started the journey from the notification to better show how the user proceeds to make payment for a debt. After clicking on the notification, they are taken to the group page where they see the expense they are required to pay for. Upon clicking on the expense, they are taken to the expense page where they see the details about the expense and how much each person is to pay or has paid. The pay debt button is displayed prominently at the bottom of the screen for easy access. Once they select the button, they are shown their payment methods, they choose their preferred method and pay immediately. Once payment is successful, they are taken back to the expense page where they see that their payment has been automatically updated without having to do that themself.

Some other screens

Extra Screens

Learnings & Conclusion

TThe initial idea created was to have the recurring payments added when creating a group, but after testing with some users and getting some feedback I decided to change it to have it when creating an expense because creating a group for every expense would be counterproductive and unintuitive; for example, flatmates who pay rent, buy groceries and other miscellaneous charges in groups would have to create a group for recurring payments like rent and utilities and create another group for one-time payments like a TV or fridge which wouldn't be ideal.

There were a lot of iterations done while working on this project, I learned a lot and also had fun working on this.

You can view and test the Figma prototype here: Splittt Prototype