Paylib : Une façon simple de partager ses dépenses en groupe.

Pendant 18 mois, ma mission en tant que UI designer s’est articulée autour de deux projets : la conception d’une nouvelle fonctionnalité « Groupes et dépenses », puis la refonte complète de l’application « Paylib entre amis » pour en faire une application écosystème regroupant l’ensemble des services mobiles Paylib.

Fonctionnalité « Groupes et dépenses »

Problème

Paylib entre amis est un service bancaire permettant d’effectuer des paiements P2P.
Pour l’utiliser, l’utilisateur doit activer le service via l’application Paylib entre amis, en passant par l’application bancaire de sa banque.
‍
En 2021, l’application Paylib entre amis n’avait donc qu’un rôle redirectionnel : elle était téléchargée uniquement pour activer le service, puis n’était plus utilisée.

Solution

Le principal problème identifié était l’absence de raison pour les utilisateurs de continuer à utiliser l’application après l’activation du service. Nous avons donc cherché à concevoir une fonctionnalité capable de couvrir un large éventail de cas d’usage liés à la gestion des dépenses du quotidien.
‍
C’est ainsi qu’est née l’idée d’une fonctionnalité de gestion des dépenses en groupe.

Qu’est-ce que « Groupes et dépenses » ?

Cette fonctionnalité permet à l’utilisateur de créer un groupe, ajouter des membres et leur envoyer une invitation, enregistrer des dépenses que l’application répartit automatiquement entre les membres.
Les membres peuvent ensuite se rembourser directement via l’application.
‍
Dans un second temps, nous avons ajouté la possibilité de modifier la devise et la part de chaque membre (couples, enfants, etc.) prise en compte dans le calcul.

Recherche

Analyse concurrentielle ("benchmark")

Ma première étape sur ce projet a été de réaliser une analyse concurrentielle.

J’ai téléchargé plusieurs applications similaires afin d’identifier :leur proposition de valeur,leurs fonctionnalités.

J’ai également analysé les avis utilisateurs sur le Play Store et l’App Store pour comprendre les besoins, attentes et points de friction, et ainsi éviter certaines erreurs.

Cas d’usage

Ces recherches nous ont permis d’identifier de nombreux cas d’usage et d'en dresser des personas : voyages entre amis, cadeaux communs, fêtes, colocation, dépenses liées aux enfants, festivals, etc.

Nous avons estimé que cette fonctionnalité apporterait une vraie valeur ajoutée et inciterait les utilisateurs à continuer à utiliser l’application après l’activation du service.

Parcours principal

Prototype du parcours principal

Le parcours commence sur l’état vide de l’onglet « Groupes », avec le bouton « Créer un groupe ».

L’utilisateur doit :s’inscrire via son e-mail,nommer le groupe, choisir une icône, renseigner son nom,accéder au groupe composé de trois onglets : Membres, Dépenses, Paiement.

Membres : ajout de membres, envoi d’invitations, visualisation des soldes.
‍
Dépenses : création d’une dépense via plusieurs étapes (qui a payé, pour qui, raison, devise, date, parts de chacun).
‍
Régler : récapitulatif de la balance et possibilité d’initier un remboursement.

Bibliothèque

En tant qu’UI designer, mon rôle a également été de constituer une bibliothèque de composants dédiée au projet, centralisant les éléments d’interface, les tokens typographiques et colorimétriques ainsi que les composants natifs Android et iOS, afin d’assurer cohérence et réutilisabilité.

Tokens typographiques et colorimétriques

Banque de composants

Composants natifs Android & iOS

Micro-interactions et animation

À l’aide de Protopie, j’ai conçu l’ensemble des micro-interactions de l’application (feedbacks d’actions, loaders, transitions, animations du tutoriel) afin de rendre la navigation plus lisible, de guider l’utilisateur dans les parcours et de renforcer la sensation de fluidité et de qualité perçue du produit.

Animation de chargement type "skeleton"

« Chorégraphie »

Ce que j’appelle ici la « chorégraphie » correspond à l’organisation logique des transitions entre les écrans.
Nous avons choisi de nous appuyer sur les transitions natives des systèmes iOS et Android afin de créer une navigation cohérente et intuitive.
‍
L’objectif était de faire ressentir l’application comme un espace physique dans lequel l’utilisateur se déplace naturellement.
Les animations, transitions et micro-interactions ne sont donc pas décoratives : elles servent à structurer la navigation.

Concrètement, nous avons imaginé l’application comme un jeu de cartes où chaque écran serait une carte.
Ces cartes s’empilent et s’ouvrent selon une logique de profondeur, en utilisant l’axe Z (la profondeur dans un espace 3D).

L’axe Z représente la hauteur :
- Un écran ouvert au niveau Z0 reste au même niveau que le précédent.
- Un écran ouvert au niveau Z1 donne l’impression de se superposer au précédent, comme une nouvelle couche.

Nous avons ainsi défini 3 niveaux de profondeur :
- La page d’accueil se situe au niveau 0.
- Lorsqu’un utilisateur entre dans une fonctionnalité, un écran s’ouvre au niveau 1.
- Depuis cet écran, une nouvelle action peut ouvrir un écran au niveau 2, ajoutant une couche supplémentaire.

Cette logique permet de rendre la navigation plus lisible, en donnant à l’utilisateur une perception spatiale claire de sa position dans l’application.

La navigation entre les écrans repose sur quatre types de transitions natives :

Push (iOS — Android) :
L'écran B pousse l'écran A. Navigation horizontale de droite à gauche entre des écrans appartenant à un même niveau.

‍Fade (iOS — Android) :
L’écran A se dissout pour laisser apparaître l’écran B. Utilisé pour des interactions non séquentielles au sein d’un même niveau.

‍Slide in/out (Android) - Modal (iOS) :
L’écran B vient se superposer à l’écran A en glissant depuis un côté de l’écran (généralement de droite à gauche). Utilisé pour entrer dans un nouveau niveau.

‍Instant (iOS / Android) :
L’écran B s’affiche instantanément par-dessus l’écran A. Utilisé pour les écrans interstitiels et les écrans d’erreur.