Référent UX produit sur un SaaS de GMAO nautique utilisé par +15 000 utilisateurs. Structuration des parcours, arbitrages sous contraintes terrain et cohérence web/mobile — pour un outil qui fonctionne avec des gants, du soleil et zéro droit à l'erreur.
Product Designer
2021 – aujourd'hui
Web & Mobile
4 dévs · 1 UX
BoatOn est un logiciel SaaS de gestion de flotte maritime utilisé par des capitaines, équipages et gestionnaires. Les utilisateurs doivent gérer maintenance, journal de bord et conformité réglementaire dans des conditions peu propices au numérique.
L'usage est majoritairement terrain : extérieur, stress, temps limité, faible tolérance à l'erreur. L'enjeu UX principal est de réduire la charge cognitive et les erreurs humaines, tout en respectant des contraintes réglementaires strictes.
De la plaisance aux lycées maritimes — 7 ans de construction produit.
Journal de bord difficilement utilisable sur mobile
Alertes réglementaires incompréhensibles
Parcours trop longs pour des actions critiques
Rupture d'expérience entre web et mobile
Seul designer sur le produit, j'interviens comme référent UX produit auprès du PO et de l'équipe de développement. Mon rôle dépasse la conception d'écrans : je contribue aux décisions produit, j'arbitre les compromis UX/tech/réglementaire, et je porte la vision d'usage de bout en bout.
Seul designer sur le produit, j'ai mis en place un process structuré de bout en bout — du feedback terrain à la mise en production. Chaque fonctionnalité passe par 5 étapes documentées, pour assurer la traçabilité des décisions et réduire les allers-retours avec les dévs.
Pipeline complet — de la réception du feedback à la présentation des retours utilisateurs, avec les rôles impliqués à chaque étape.
Les retours arrivent du terrain (capitaines, gestionnaires), du support et de l'équipe. Je les centralise dans Notion, les priorise avec le PO, puis rédige un brief fonctionnel complet : contexte, cas d'usage, règles métier et critères d'acceptation.
Brief fonctionnel — Notion
Avant de toucher Figma, je modélise chaque parcours en diagrammes Mermaid. Chaque nœud de décision, chaque cas limite est documenté. Je valide la logique avec le PO et les dévs avant de concevoir le moindre écran.
Workflow — Validation d'une tâche (Mermaid)
Je conçois les écrans dans Figma, organisés par flow. Chaque page porte le nom du brief correspondant. Les maquettes sont présentées à l'équipe, itérées, puis passées en « Ready to Dev » avec specs et versionning intégré.
Kanban design — Suivi des features
Le planning de rotation est la fonctionnalité la plus complexe de BoatOn : elle orchestre l'affectation des marins sur les navires, leurs périodes d'embarquement et les relèves. Voici comment j'ai abordé cette feature de A à Z.
Avant de concevoir, j'ai analysé comment les équipages gèrent leurs plannings aujourd'hui. Résultat : des fichiers Excel partagés par email, des logiciels métiers des années 2000, et beaucoup de friction.
Gestion manuelle dans un tableur — pas de vue globale, risque d'erreur élevé, aucune notification automatique.
Outil spécialisé mais complexe, interface datée, pas d'accès mobile, courbe d'apprentissage élevée.
J'ai structuré les besoins en cas d'usage concrets dans Notion. Chaque user story identifie le rôle (gestionnaire, marin, capitaine), la plateforme (web ou mobile) et l'objectif fonctionnel précis.
Cas d'usage — Notion
Avant de passer sur Figma, j'explore les idées au crayon. C'est rapide, jetable, et ça permet de tester des dizaines de pistes en quelques heures. J'utilise un code couleur pour distinguer les vues, les CTA, et les champs de saisie.
Conception pensée d'abord pour le mobile (gants, soleil, connexion instable), puis adaptée au web.
Données pré-remplies automatiquement, validation en un tap par le capitaine.
Alertes compréhensibles avec proposition de correction intégrée.
12 composants de base, enrichis uniquement en cas de besoin réel.
BoatOn a profondément façonné ma pratique du design produit. Concevoir pour des utilisateurs qui portent des gants, travaillent en plein soleil et n'ont aucune tolérance à l'erreur oblige à une rigueur que peu de projets imposent. Chaque écran doit fonctionner du premier coup, dans le pire scénario.
J'y ai consolidé une conviction : un bon design produit ne consiste pas à simplifier l'interface, mais à absorber la complexité métier pour que l'utilisateur n'ait plus à y penser.