Bary, 2026
Créer la fonction design d’un site marchand pour transporteurs routiers
Première designer jamais recrutée par l’entreprise, et seule designer sur le produit. J’ai mené la refonte du produit historique de Bary jusqu’à la V2, main dans la main avec le PM pour que les specs et les maquettes racontent la même histoire.
Aperçu
Un site marchand pour les transporteurs, à leur marque
Alice nous a rejoints pour une mission de trois mois. Elle est finalement restée un an, et son travail a profondément transformé Bary. Pour la première fois, je suis vraiment fier de mon produit. Pour un fondateur, ce n’est pas rien.
Bary donne aux transporteurs routiers leur propre site marchand B2B, à leur marque et à leurs prix. Leurs clients, les chargeurs, y obtiennent une estimation instantanée et réservent un transport en quelques minutes, tandis que les transporteurs y gèrent leur back-office : devis, tarifs, clients, facturation et suivi des transports.
Boucler ce cycle était l’étoile polaire de la V2 : un transporteur s’inscrit et configure ses tarifs, et un chargeur reçoit un vrai devis.
Mon rôle
J’étais la première designer jamais recrutée par l’entreprise, et la seule designer sur le produit.
Product designer recrutée
Le poste n’existait pas : je l’ai construit, ainsi que la façon dont le design travaille avec le reste de l’équipe.De bout en bout
De l’architecture de l’information aux écrans livrés, côté chargeurs comme côté transporteurs.Au plus près des specs
J’ai accompagné le PM sur les specs avec des parcours, des cas limites et des prototypes, pour que l’intention arrive intacte jusqu’au développement.
Au-delà des écrans, j’ai mis en place un process de design, défendu le design auprès de la direction, du produit et des développeurs, travaillé avec le Customer Success, le Marketing et les Ventes, et veillé à ce que nous restions proches des vrais utilisateurs.
L’impact
Lors du dernier cycle de tests, chaque testeur a passé une commande de transport sans aide, contre aucun lors du premier.
C’est plutôt simple. Je pense que même moi, je pourrais le faire. C’est très intuitif.
Avant / après
Le tunnel de devis est passé d’une liste d’offres à une estimation claire, en libre-service.
Enjeu
Un produit riche et réglementé, qui avait besoin de fondations design
Bary avait grandi vite et était prêt à confier l’expérience dans son ensemble à quelqu’un. Plusieurs opportunités se dégageaient.
Une place pour chaque objet
La même information pouvait apparaître à plusieurs endroits, chaque objet avait donc besoin d’une place claire.Le quotidien d’abord
Configuration et opérations quotidiennes cohabitaient, et le travail de tous les jours méritait de passer en premier.Specs et design ensemble
L’équipe livrait vite, les specs et les maquettes devaient donc avancer au même rythme pour garder un développement cohérent.
Par-dessus tout ça, la facturation électronique française ne laisse aucune place à l’approximation, le même vocabulaire devait donc tenir sur chaque écran.
Deux thèmes dominaient tous les retours utilisateurs : le tunnel de commande et le module des offres.
Recherche
Faire entrer l’expertise du fondateur et les vrais utilisateurs dans le produit
Discovery
Le CEO connaît le secteur du fret sur le bout des doigts, et je voulais que ce savoir se retrouve dans le produit. J’ai donc animé avec lui un atelier FigJam sur le tunnel de réservation d’un concurrent, et audité le produit existant écran par écran.
À l’écoute des utilisateurs
J’ai mené deux entretiens en direct et analysé six enregistrements de sessions passées, puis synthétisé le tout en thèmes classés par priorité. Le constat était sans appel : le parcours était trop long pour des gens qui commandent chaque semaine.
Sur les autres plateformes, c’est deux écrans maximum et c’est réglé.
Approche
Poser les règles avant les écrans
L’équipe construisait vite, avec de la génération de code assistée par IA. Mon rôle était de poser les invariants une fois pour toutes, pour que la vitesse ne se transforme pas en incohérence.
Les règles avant les écrans
Une place unique pour chaque objet, une navigation guidée par la fréquence des tâches, et un catalogue qui ne porte jamais de prix. Des garde-fous, pas des préférences de style.Design et specs dans la même boucle
Les specs du PM et mes maquettes avançaient ensemble. Quand un parcours coinçait, on corrigeait la règle et l’écran en même temps.Ligne directe, phases claires
Un point hebdomadaire en tête-à-tête avec le CEO pour des retours directs, et un process en trois temps : discovery, design, puis test.
Architecture de l’information
35 wireframes basse fidélité ont cartographié le MVP. La navigation n’utilise que des noms, les tâches les plus fréquentes sont au premier niveau, et la configuration est nettement séparée des opérations quotidiennes. C’est la structure sur laquelle le design system allait se construire.
Prototyper avec Lovable
J’ai construit des prototypes interactifs dans Lovable pour deux raisons : rendre les concepts concrets pour le CEO, le PM et les développeurs, avec quelque chose à cliquer plutôt qu’à décrire, et mettre de vrais parcours devant les utilisateurs avant qu’une seule ligne de code de production soit écrite.
Designs
Repenser le tunnel, le système et le back-office
Une divulgation progressive, pas un assistant verrouillé
Le tunnel de réservation guide pas à pas, sans enfermer dans une séquence rigide.
Un stepper souple
Il avance tout seul, mais chaque étape peut être rouverte à tout moment.Jamais deux fois la même question
Une séparation stricte entre le contact sur place et la personne qui réserve, pour que personne ne saisisse deux fois la même chose.Pourquoi on demande
Un panneau latéral explique chaque demande, pour que les champs denses du fret paraissent sûrs à remplir.
Itérations sur la modale marchandise : une version sombre plein écran face à un panneau latéral plus léger et guidé.
Un système, plusieurs identités
Je n’ai pas réinventé une bibliothèque de composants. J’ai adopté shadcn/ui pour aller vite, puis je l’ai maintenue et enrichie, en ajoutant un theming multi-marques pour que la plateforme puisse prendre l’identité de chaque transporteur. Tout se thématise depuis une source unique et s’adapte du téléphone à l’ordinateur, ce qui a laissé le temps pour les vrais problèmes produit plutôt que pour les bases.
L’autre moitié : le back-office des transporteurs
Des opérations denses, rendues lisibles. Les demandes de devis entrantes, le cycle du devis à la facture, et un détail de transport qui se lit d’un coup d’œil : les écrans où les transporteurs passent vraiment leurs journées.
Résultat
Une colonne vertébrale sur laquelle l’équipe peut grandir
Un MVP rapide
Discovery et livraison du MVP bouclées en quelques semaines, avec le prototype du tunnel prêt pour les tests utilisateurs.
Specs et maquettes alignées
Les maquettes et les specs du PM avançaient au même rythme, ce qui a supprimé l’ambiguïté qui se glissait dans le code.
Des commandes sans aide
Lors du dernier cycle de tests, chaque testeur a passé une commande seul, contre aucun lors du premier.
Une passation propre
J’ai recruté et intégré la personne en interne qui a repris le design du produit.
Le vrai livrable n’était pas un écran. C’était l’ensemble des règles qui gardent une équipe rapide cohérente, et la preuve que le design avait sa place à la table dès le premier jour.