“Paylib entre amis” & Group expenses
This experience was my first mission as a freelancer. The opportunity took me in the bank field which was brand new to me and I knew nothing about the product I was going to work on.
During 18 months, my mission here as a UI designer was composed of two projects. I worked first on “Groups and expenses”, a new feature that helps the user to manage group expenses.
The second step was the rework of the whole “Paylib entre ami” app, turning it into an ecosystem app for Paylib mobile services.
Group spendings feature
Problem
Paylib entre amis is a bank service that allows users to make P2P payments.
To be used, the user has to activate the Paylib service on their bank application through the Paylib entre amis application.
Meaning that, back in early 2021 the “Paylib entre amis” app’s only use was redirectional. It was then only downloaded for the purpose of activating a service.
Our solution
The main issue we encountered is that users have no reason yet to keep using Paylib entre amis after the service’s activation.
To bring a solution, we aim to create a feature that would fullfill a large range of use cases in term of spendings management in the user’s daily-life.
That is how a the idea of a feature able to manage spendings in groups emerged.
What’s “groups and expenses” ?
This feature is a place where the user can create a group, add members, share it to them then creates expenses that the app will automatically split between the members.
Members can then pay their debts to each other through the app.
Lately, we added the possibility to change the currency and the parts of each member (couples, childrens…) that the app takes into account in the calculation.
Research
- Competitor analysis
The first step for me into this mission was to make a competitor analysis to establish what already exists on the market.
I downloaded few applications close to what we aim to and I started making a list of their value proposition, their features.
The last step in this research was to extract reviews from Google Playstore and Appstore to understand the user’s needs and expectations to avoid some possible mistakes.
- Use cases
After researches, we found out use cases that helped us to design the different flows. There are many different situation where such a feature can find itself useful : trips with friends, shared presents, parties, spendings between flatmates, supplies for a child’s needs, festivals etc… That said, we think this feature can bring a great value to make users use the app after the service activation, and thus, it could answer our problem.
Main path
Here is the main flow of the “groups and expenses” feature.
It begins on the left with the empty state of the “Groups” tab displaying the “Create a group” CtA.
First, the user has to register entering their e-mail and going through the verification. Then, they have to give the group a name, an icon and to fill up their name.
Once in a group there are three tabs : Members, Expenses and Pay.
Members : Here we can add new members, send them invitations and see their balance.
Expenses : In this tab, the user goes through many steps to create an expense : Who paied? For who? For what reason? In which currency? When? What are the parts of each member?
Pay : This section is a recap of the debt balance of each member, a debt tag (orange) is tapable to initiate a refund to another member.
Design system
Micro-interactions
Using Protopie, a prototyping and animation design tool, I was in charge of designing the app’s micro-interactions such as feedbacks on actions, loaders and page transitions. This powerful softwere brought me creating also short animations for the tutorial.
Choregraphy
What I call “choregraphy” here consists of the succession of transitions between screens. We decided to work on it using the operating system’s native transitions to create a logical arrangement.
Our goal here is to present a new navigation as it would be a physical space that would lead the user through the application.
The animations, transitions and micro-interactions that come from it must arouse the feeling of a polished product.
In practice we imagined our app being a deck of card (each screen being a card) that would open and interact as a reversed pyramid using the z axis.
The z axis is the height in a 3D environnement. It’s original value is 0.
Opening a screen at z0 will be on the same height as the previous screen but if we open a screen at z1 it will seem to be higher than the previous screen (level 1).
For instance, we imagined 4 levels, the home page being at the level 0 and when the user enters a feature it opens a screen at the top of it, the level 1 is opened. An opened screen in the level 1 will add another layer, creating the level 2 of the pyramid.
The navigation between screens follows up 4 main native transition types :
- Push ( iOS — Android) : horizontal navigation from right to left in a screen sequence inside a same layer.
- Fade (iOS — Android) : screen A dissolves into screen B to open it, used as a nonsequential interaction inside a same layer.
- Slide in/out (Android) : opens screen B upon screen A from any side of the screen (usually from right to left). Used to enter a new layer.
- Modal : modalsheet/pagesheet/fullscreen (iOS) : opens screen B upon screen A from bottom to the top. Used to enter a new layer. This effect is the same for bottomsheets, windowed and fullscreens.
- Instant (iOS / Android) : screen B instantly opens upon screen A. Used for interstitial screens and error screens.
Video
Ecosystem
Once the group spendings feature released, we had to think about how could we clearly integrate it with Paylib’s main product “Paiement entre amis” and with the upcomming features.
Problem
Here is what our homepage looked like just after the release of the feature. We had to spot out what we would like our app to be used for in the future so we could start thinking about the whole app architecture.
The main issue here is that the P2P service is still shown as the main app feature and group expensive remain secondary. It is also a good apportunity for a graphic rework of the app.
Our solution
Creating an ecosystem app where each Paylib service would be accessible and connected to each other on the same level such as on a platform seems for us to be a good answer.
What’s next ?
To conclude, there are yet several evolution possibilties for Paylib entre amis. Indeed the development of the HCE service is still ongoing since it currently redirects the user to their bank app. We aim to make the card emulation available inside Paylib app anytime soon.
Also, this feature is for now only in sight for Android devices since Apple doesn’t allow the use of it’s NFC technology yet.
