tricount
Duration
Still in progress
TYPE OF PROJECT
Personal project
LEARNING
UX Design, UI Design
Tool
Figma
Still in progress
Personal project
UX Design, UI Design
Figma
Tricount est une application qui permet de gérer les dépenses entre amis, partenaires, colocataires... Et pour cela, il suffit simplement de renseigner sa dépense et de sélectionner les participants à cette dépense.
Grande partisane du moindre effort, Tricount est donc un produit que j’utilise et apprécie grandement pour la simplicité de son expérience utilisateur.
Seulement, l’UI étant à l’image de l’UX de ce produit, le visual design est donc tout aussi élémentaire. Parti pris que je comprends, car on ne voudrait pas perdre l’utilisateur en cours de route avec une interface un peu trop élaborée.
Mais je pense qu’on pourrait garder la clarté du produit tout en le rendant un peu plus fun, alors explorons tout ça !
Au fil de mes utilisations, je regrettais un peu l'aspect sommaire de la homepage présentant l'ensemble des tricount.
Les deux éléments présentés étant un titre et une description, inscrits librement par l'auteur du tricount, on finit par se sentir assez limité dès qu'on atteint un certain nombre de tricount.
Pour utiliser l'application à minima de manière mensuelle, j'étais dans l'obligation d'indiquer le mois et l'année manuellement dans le titre de chaque tricount pour m'y retrouver.
Et n'étant pas la seule à créer des tricount, j'ai aussi remarqué que peu d'utilisateurs prenaient la peine d'indiquer une description (car finalement tout était indiqué dans le titre).
Mon dernier drôle de constat était lors de création d'un tricount, une catégorie doit être obligatoirement indiquée parmi les choix suivants : Voyage, Coloc, Couple, Evénement, Projet, Autre. Pourtant, alors qu'il s'agit d'un paramètre obligatoire à la création d'un tricount, l'utilisateur ne voit en aucun cas en quoi cela impacte son expérience une fois le tricount créé.
Partant de ces petites frictions d'utilisation, je me suis lancée dans une refonte de homepage tout en pensant à une expérience utilisateur plus optimisée.
Mon idée de base était de différencier en un coup d'oeil les lignes de tricount d'une homepage et les lignes de dépense d'un tricount. Plutôt que de m'aligner sur la structure de base qui était donc plutôt similaire en terme d'UI, le but était de créer une card.
Au départ cette card devait mentionner : titre, description, mois et année, total dépenses et l'équilibre. Il me paraissait intéressant de voir en un instant depuis la homepage où est-ce qu'on en est dans le budget total et si on est à l'équilibre vis-à-vis du groupe. Mais aussi et surtout, de pouvoir situer dans le temps les dépenses en question !
La constitution de cette card était l'opportunité parfaite pour travailler un composant plus complexe sur Figma !
J'avais déjà bien exploré les variants simples, principalement pour créer des états de boutons différents. Mais l'apport des propriétés boolean, instance swap et text permettaient de mieux expérimenter des structures un peu plus complexes.
J'ai remarqué que l'utilisation de ces différentes propriétés me permettait aussi de jongler entre des look&feel variés. A titre d'exemple, j'avais du mal à trancher s'il fallait oui ou non afficher une ou des icone-s. Et créer ces variants m'a donc laissé la possibilité d'avancer sur d'autres écrans, tout en gardant en tête les potentielles versions de ma homepage. Eventuellement, cela pouvait aussi servir dans le cas où je voulais soumettre à d'autres designers pour feedback (sans avoir besoin de tout casser).
J'avais donc plusieurs variants structurés pour offrir une expérience utilisateur un peu plus poussée.
Comme mentionné au départ, cette card tricount devait à priori mentionner : titre, description, mois et année, total dépenses et l'équilibre. Mais en créant des tricount variés et tirant parti de mes observations d'utilisateurs, il m'apparaissait plus cohérent et pratique de mentionner : titre, mois et année, nombre de participants, total dépenses et équilibre.
J'ai donc fini par créer un icone pour la date et les participants (pouvant varier de 1 à 50). Ces mêmes icones pouvaient donc être ré-utilisés à l'intérieur du tricount, en entête.
Comme je l'ai expliqué un peu plus haut, il m'apparaissait évident que la catégorie indiquée lors de la création du tricount ait une incidence dans l'UX en elle-même. Le fait de créer un espace pour les icones de dates et de participants, donnait finalement du sens à l'apparition de l'émoji de catégorie choisie.
Avec une homepage un peu plus poussée, l'utilisateur peut donc voir en un coup d'œil l'état des dépenses du groupe et son équilibre vis-à-vis de celui-ci.
Léger focus sur la partie dépenses une fois qu'on clique sur un tricount.
Je voulais garder la structure de base, qui à mon sens, représente bien la simplicité de Tricount. Mais pour aller au bout de cette simplicité tout en l'adaptant à mon UI, le travail sur les icones s'avérait être assez primordial.
Simplifier les icones au maximum, voire en retirer quand elles s'avèrent pas forcément nécessaire a été le fruit d'une certaine réflexion.
Pour commencer, il me paraissait plus adéquat de retirer les icones des onglets "Dépenses" et "Equilibres" qui ne parlent pas forcément pour elles-mêmes. Et ces icônes en tant que telles, ne présentent pas une affordance concluante.
Puis, en terme d'UX, pas de modification particulière à effectuer, l'idée étant de jouer sur la cohérence de l'UI et le look&feel général.
La partie équilibres s'est révélée assez prenante en terme d'UX.
Cette partie est très lisible en soit et elle ne semblait pas avoir besoin de grand chose. Mais c'est en explorant un peu plus pleinement ce niveau que j'ai réalisé les différents boutons qui pouvaient potentiellement nous intéresser.
En effet, l'équilibre d'un tricount pouvant être positif, négatif ou nul, cela représentait une variété d'actions qui était intéressant de redesigner. J'ai finalement découvert 3 versions de call-to-action qui se retrouvaient "cachées" sous un bouton "Plus d'options".
En fait je n'avais jamais réalisé qu'il existait un bouton "Marquer comme payé" permettant de mettre l'équilibre du tricount à 0 en seulement 2 clics (i.e. sans avoir à ajouter une dépense et renseigner le montant, le participant etc.). Je trouvais ça dommage que ce bouton ne soit pas mis directement en avant, sans avoir besoin de passer par "Plus d'options".
Par conséquent, mon objectif sur cette partie était principalement de travailler sur ces 2 à 3 call-to-action en 3 versions, avec variante ou non. Ainsi, ma première volonté était de mettre tous les boutons au premier niveau.
Le bouton "Marquer comme payé" ne posait pas d'interrogation particulière, étant donné qu'il était commun à toutes les versions.
Qu'on soit en équilibre négatif, positif ou nul, on a la possibilité de marquer comme payé ce qu'on doit, ce qu'on nous doit, ou ce que un tiers doit à un autre tiers.
La difficulté résidait plus sur le bouton "Inviter" qui avait 3 variantes : inviter X à nous payer, inviter X à voir les balances, inviter Y à payer Z.
C'est vraiment en cliquant sur le bouton, qu'on comprend l'action en question : ouverture d'un overlay qui invite à envoyer un message personnalisé pré-rempli par Tricount, pour faire la demande en question via le canal de son choix (whatsapp, twitter, insta direct...)
En réalité, le fait d'expliciter chaque version du bouton, ne clarifie en rien son impact, au contraire il apporte plus de confusion. Donc mon choix a été de l'uniformiser sur son premier état avec une simple icône de partage, qui a une forte affordance. Ensuite l'idée était d'améliorer la présentation de l'overlay et du message pré-rempli pour qu'il soit le plus clair possible.
Avec ce bouton "inviter à" retravaillé en bouton de partage, l'utilisateur comprend que le call-to-action va lui permettre de partager une information provenant de Tricount. Dès que ce bouton est actionné, l'utilisateur se retrouve face à un écran qui l'invite à partager l'information via une application externe.
Avec ce projet perso, j'ai appris à constuire des composants plus complexes mais aussi à structurer un UX et UI qui font sens.
J'avoue que mon idée de base était de m'amuser sur la partie UI plus que UX.
Mais finalement, l'UX a été mon fil rouge du début à la fin ! Bien qu'il n'y ait pas vraiment de fin car tout est perfectible quand on travaille sur un produit aussi grand public.
Alors que mon but premier était de faire une refonte de homepage, un objectif produit s'est révélé à moi : comment inciter les utilisateurs à rendre leur tricount équilibré ?
Ainsi, on aurait pu à titre d'exemple mesurer le nombre de clics par bouton dans la partie Equilibres. La suite pourrait éventuellement être de nouvelles propositions pour le feed, les notifications et/ou la partie catégorie/tag des dépenses.
En attendant, je vous invite à consulter le case sur Figma !
Check FIGMA
