UI / UX Design
FLUX, un design system complet pour une app d'épargne
Projet personnel. Concevoir de bout en bout une application de gestion de dépenses et le système qui la fait tenir, des tokens jusqu'aux écrans.
Year :
2026
Industry :
Fintech
Client :
projet personnel, produit fictif
Project Duration :
1 mois
Probleme :
Les applications de budget montrent surtout ce qui a déjà été dépensé. Le constat arrive trop tard pour changer quoi que ce soit, et la culpabilité fait le reste. Beaucoup d'utilisateurs décrochent après quelques semaines.
Quand la gamification apparaît dans ce secteur, elle reste souvent posée par-dessus. Des points, des badges, une série à ne pas casser, sans lien réel avec le comportement financier.
J'ai lancé FLUX pour traiter les deux sujets ensemble. Aider quelqu'un à comprendre où part son argent, et lui donner envie de commencer à mettre de côté.
L'objectif : Concevoir le produit de bout en bout, du système jusqu'aux écrans.
Avec une contrainte que je me suis imposée. Tout devait être variabilisé, sans valeur en dur nulle part. Couleurs, espacements, rayons, typographies, organisés en primitives et en tokens sémantiques, avec les guidelines qui vont avec. Le but était qu'un développeur puisse reprendre le fichier sans venir me demander pourquoi ce bouton fait 24 de padding.
Solution :
Une architecture de tokens à deux niveaux. Les primitives portent les valeurs, les tokens sémantiques portent l'intention. Sur un bouton primaire, rien n'est écrit en dur. action-brand pour le fond, text-on-brand pour le label, spacing-24 et radius-full pour la forme.
Autour, les guidelines qui rendent le système utilisable par quelqu'un d'autre. Couleurs, typographie, rayons, grille, et règles de composition des composants.
Une bibliothèque organisée en huit familles. Navigation, cartes et modales, graphiques et données, champs et recherche, catégories, chargements, branding, onboarding et authentification.
Le travail le plus utile a porté sur les états. Le champ de saisie en compte neuf, du repos au chargement, en passant par lecture seule, succès et erreur. Les squelettes existent en six tailles. Les écrans vides sont traités en trois cas distincts, absence de données, recherche sans résultat, et erreur.
Puis les écrans, montés avec cette bibliothèque. La connexion bancaire, où l'utilisateur voit ce qu'il autorise avant de l'autoriser. L'écran principal, où part l'argent. L'ajout et la catégorisation d'une dépense. La projection, avec simulateur d'impact et scénarios. Et la mécanique de série, qui récompense la régularité plutôt que la performance.
Défi :
Un système rigoureux au service d'un produit qui doit rester engageant. Mal posée, la rigueur tue le second.
L'autre difficulté portait sur la couche sémantique. Nommer une couleur bleu-500 ne coûte rien. La nommer action-brand oblige à décider ce que fait cette couleur dans le produit, partout, avant de l'utiliser. Le travail se fait en amont, et chaque raccourci se paie plus tard.
S'ajoutait le contexte bancaire. Une app qui se connecte à des comptes doit expliquer ce qu'elle fait des données avant de demander quoi que ce soit.
Résultat :
Le projet est en v1. Le design system tourne autour de 50 à 60 % de maturité, et je préfère donner ce chiffre plutôt que de le présenter comme fini.
Ce qui est en place. Une couverture de tokens quasi complète sur les couleurs, une quarantaine de familles de composants, les guidelines associées, les icônes migrées sur Phosphor, et une décomposition atomique documentée dans le fichier. Les écrans clés sont montés avec la bibliothèque, pas dessinés à côté.
Ce que je ferais autrement. Mes espacements sont nommés par leur valeur alors que mes couleurs sont sémantiques. spacing-16 dit combien, pas pourquoi. Sur un produit qui grandit, cette asymétrie finit par coûter cher, et je reprendrais cette couche en premier.
Ce que je retiens. Un design system se juge au moment où on l'utilise. Monter les écrans avec ma propre bibliothèque a révélé des manques que des semaines de composants isolés n'avaient pas montrés.
Plus de projets
UI / UX Design
FLUX, un design system complet pour une app d'épargne
Projet personnel. Concevoir de bout en bout une application de gestion de dépenses et le système qui la fait tenir, des tokens jusqu'aux écrans.
Year :
2026
Industry :
Fintech
Client :
projet personnel, produit fictif
Project Duration :
1 mois
Probleme :
Les applications de budget montrent surtout ce qui a déjà été dépensé. Le constat arrive trop tard pour changer quoi que ce soit, et la culpabilité fait le reste. Beaucoup d'utilisateurs décrochent après quelques semaines.
Quand la gamification apparaît dans ce secteur, elle reste souvent posée par-dessus. Des points, des badges, une série à ne pas casser, sans lien réel avec le comportement financier.
J'ai lancé FLUX pour traiter les deux sujets ensemble. Aider quelqu'un à comprendre où part son argent, et lui donner envie de commencer à mettre de côté.
L'objectif : Concevoir le produit de bout en bout, du système jusqu'aux écrans.
Avec une contrainte que je me suis imposée. Tout devait être variabilisé, sans valeur en dur nulle part. Couleurs, espacements, rayons, typographies, organisés en primitives et en tokens sémantiques, avec les guidelines qui vont avec. Le but était qu'un développeur puisse reprendre le fichier sans venir me demander pourquoi ce bouton fait 24 de padding.
Solution :
Une architecture de tokens à deux niveaux. Les primitives portent les valeurs, les tokens sémantiques portent l'intention. Sur un bouton primaire, rien n'est écrit en dur. action-brand pour le fond, text-on-brand pour le label, spacing-24 et radius-full pour la forme.
Autour, les guidelines qui rendent le système utilisable par quelqu'un d'autre. Couleurs, typographie, rayons, grille, et règles de composition des composants.
Une bibliothèque organisée en huit familles. Navigation, cartes et modales, graphiques et données, champs et recherche, catégories, chargements, branding, onboarding et authentification.
Le travail le plus utile a porté sur les états. Le champ de saisie en compte neuf, du repos au chargement, en passant par lecture seule, succès et erreur. Les squelettes existent en six tailles. Les écrans vides sont traités en trois cas distincts, absence de données, recherche sans résultat, et erreur.
Puis les écrans, montés avec cette bibliothèque. La connexion bancaire, où l'utilisateur voit ce qu'il autorise avant de l'autoriser. L'écran principal, où part l'argent. L'ajout et la catégorisation d'une dépense. La projection, avec simulateur d'impact et scénarios. Et la mécanique de série, qui récompense la régularité plutôt que la performance.
Défi :
Un système rigoureux au service d'un produit qui doit rester engageant. Mal posée, la rigueur tue le second.
L'autre difficulté portait sur la couche sémantique. Nommer une couleur bleu-500 ne coûte rien. La nommer action-brand oblige à décider ce que fait cette couleur dans le produit, partout, avant de l'utiliser. Le travail se fait en amont, et chaque raccourci se paie plus tard.
S'ajoutait le contexte bancaire. Une app qui se connecte à des comptes doit expliquer ce qu'elle fait des données avant de demander quoi que ce soit.
Résultat :
Le projet est en v1. Le design system tourne autour de 50 à 60 % de maturité, et je préfère donner ce chiffre plutôt que de le présenter comme fini.
Ce qui est en place. Une couverture de tokens quasi complète sur les couleurs, une quarantaine de familles de composants, les guidelines associées, les icônes migrées sur Phosphor, et une décomposition atomique documentée dans le fichier. Les écrans clés sont montés avec la bibliothèque, pas dessinés à côté.
Ce que je ferais autrement. Mes espacements sont nommés par leur valeur alors que mes couleurs sont sémantiques. spacing-16 dit combien, pas pourquoi. Sur un produit qui grandit, cette asymétrie finit par coûter cher, et je reprendrais cette couche en premier.
Ce que je retiens. Un design system se juge au moment où on l'utilise. Monter les écrans avec ma propre bibliothèque a révélé des manques que des semaines de composants isolés n'avaient pas montrés.