2023–2025 UX/UI · Dev
POS System
Le redesign complet d'un écosystème de trois apps pour la restauration. Parti de rien — littéralement.
Transformer un produit qui marche mais qu'on n'a pas envie de toucher en un écosystème cohérent, désirable et efficace — pour trois utilisateurs aux besoins radicalement différents.
01 Le contexte
Première designer d'un produit qui n'en avait jamais eu
BonApp est une startup lausannoise (family office MGMT) qui édite une solution POS pour la restauration. Quand je suis arrivée, le produit existait déjà, tournait, et avait de vrais clients. À un détail près : personne n’avait jamais fait de travail UX/UI dessus. Pas une maquette, pas une recherche, rien sur Figma.
Le produit fonctionnait par la seule force de sa logique métier — et se passait allègrement de toute considération pour l’utilisateur. C’est là que j’entre en scène, comme première designer de l’équipe.
02 Volet I
Le point de départ
Soyons honnêtes : c'était fonctionnel, mais ce n'était pas pensé pour ceux qui s'en servaient.
L'état des lieux
Interface peu engageante, incohérente d’un écran à l’autre, et une logique d’usage qui demandait à l’utilisateur de s’adapter à la machine plutôt que l’inverse. Pour un produit censé être manipulé à toute vitesse en plein service, ou par un client pressé de payer, c’était un vrai frein à l’adoption.
Je garde ces captures précieusement. Non pas par nostalgie, mais parce qu’elles racontent la moitié de l’histoire : on ne mesure un redesign qu’à l’aune de son point de départ.
Le défi
Comment transformer un produit qui marche mais qu’on n’a pas envie de toucher en un écosystème cohérent, désirable et efficace — pour trois utilisateurs aux besoins radicalement différents ?
Le client, qui veut commander et payer depuis son téléphone sans réfléchir. Le serveur, qui n’a pas trois secondes à perdre en plein coup de feu. Le manager, qui pilote son restaurant et veut tout contrôler d’un coup d’œil. Trois mondes, trois logiques, un seul système qui devait les faire tenir ensemble — sur un produit vivant, en production, où de nouvelles features tombaient régulièrement.
03 Volet II
Trois apps, trois métiers
Trois utilisateurs aux logiques opposées — un seul système qui devait les faire tenir ensemble.
01 Application
Customer — l'évidence comme objectif
Commander et payer depuis son mobile, sans friction et sans tutoriel. La cible, c’est tout le monde : du digital native au client qui découvre qu’on peut payer son café avec un QR code.
L’enjeu était de rendre le parcours tellement évident qu’il ne se remarque pas.
02 Application
Waiter — la vitesse comme contrainte
Celle-ci n’existait pas. L’idée : permettre au restaurant de tout centraliser sur le même système, sans dépendre du fait que le client utilise ou non son mobile. J’ai participé à la définition des features et des requirements.
Concrètement, le serveur peut sélectionner les tables, naviguer dans les menus disponibles, passer les commandes, encaisser, imprimer les tickets et accéder aux transactions. Le tout pensé pour la vitesse : en plein service, chaque tap compte.
03 Application
Manager — le poste de pilotage
Horaires, menu, prix, QR codes, statistiques, transactions, gestion d’équipe. Là où le restaurateur reprend la main sur son établissement.
L’enjeu : rendre lisible une quantité de paramètres considérable, sans transformer l’écran en cockpit d’avion.
04 Volet III
Les décisions clés
Deux moments où le projet a basculé — la création d'un design system, puis l'app Waiter conçue depuis zéro.
01 Décision clé
Créer le design system
Au bout de quelques semaines, un constat : je passais un temps fou à reconcevoir des composants que j’avais déjà dessinés ailleurs. À chaque nouvel écran, on repartait un peu de zéro.
J’ai donc pris l’initiative de créer un design system complet sur Figma. Pas par amour de la méthode pour la méthode, mais parce que c’était la seule façon de tenir trois apps cohérentes en évolution permanente.
L’impact ne s’est pas fait attendre : une vraie cohérence entre les trois applications, un onboarding beaucoup plus rapide pour les nouvelles personnes, moins d’erreurs de design, et une collaboration avec les développeurs nettement plus fluide.
02 Décision clé
Concevoir l'app Waiter
L’app Waiter, c’est mon terrain de jeu de la page blanche. Rien n’existait, tout était à inventer — et c’est sans doute le projet dont l’enjeu était le plus opérationnel.
Le défi central : concevoir un outil utilisable en plein coup de feu. Un serveur qui prend une commande n’a pas le temps de chercher, de réfléchir à la navigation, ou de corriger une erreur de manipulation. L’interface devait disparaître au profit du geste.
J’ai travaillé la définition des features avec l’équipe en partant des contraintes réelles du service : rapidité de sélection, lisibilité immédiate, parcours d’encaissement sans détour.
Le pont design / code
Mettre les mains dans le code
Voici la partie que je n’avais pas prévu d’aimer autant : j’ai mis les mains dans le code, principalement le CSS, en React.
D’abord pour une raison simple — avec un œil de designer, le rendu final était tout de suite plus fidèle à l’intention. Les détails qui font qu’une interface est « juste » se jouent souvent à quelques pixels, et ces pixels-là, autant les régler moi-même.
Mais le vrai cadeau était ailleurs : toucher au code m’a fait comprendre les contraintes techniques de l’intérieur. J’ai appris à concevoir non pas dans l’absolu, mais en fonction de la réalité des moyens dont on disposait pour réaliser les choses. Un design irréalisable est un beau dessin, pas une solution.
Pas celle qui dessine et jette ses maquettes par-dessus le mur en espérant le meilleur, mais celle qui accompagne le produit jusqu’au pixel final.
05 Bilan
Le résultat sur le terrain
Adoption, satisfaction, structure : un produit qui a pris assez d'importance pour qu'on construise une équipe autour.
Résultats
Le produit a été adopté par les restaurants, les clients étaient satisfaits, et on a constaté une réduction des erreurs côté utilisation. On partait de loin — c’est précisément ce qui rend le résultat satisfaisant.
Et un signal qui en dit long : pendant un an et demi, j’étais la seule designer. Puis l’équipe s’est étoffée d’une personne, et je suis devenue officiellement Head of Design. Le travail avait pris assez d’importance pour qu’on structure une équipe autour.
06 Apprentissages
Ce que ce projet m'a appris
Ce projet m’a appris à concevoir pour un produit vivant — qui change, grandit, et n’attend pas que le design soit « parfait » pour avancer. Il m’a appris que les meilleurs designs naissent à l’intersection du désirable et du faisable, et que comprendre le code n’enlève rien à la créativité : ça la rend opérante.
Et il m’a fait passer de designer à Head of Design, c’est-à-dire de « je dessine des écrans » à « je pense un système et j’accompagne une équipe ».
Pas mal, pour un produit qui n’avait même pas de fichier Figma à mon arrivée.
Travaillons ensemble
Le prochain projet, c'est peut-être le vôtre.
luciebelleudy@outlook.com