Refondre la navigation d'un logiciel de paye
Yeap est un logiciel de paye SaaS pour les cabinets comptables. J'y ai passé deux ans en alternance en tant que Product designer. Cette étude de cas revient sur la refonte de la navigation, menée en cinq jours de design sprint avec trois product designers et un product manager.
Problème
La navigation s'était construite au fil des fonctionnalités ajoutées, sans vision d'ensemble. Naviguer entre les pages clés de l'app (Bulletins, EVP, Absences, fiches salariés) était devenu un parcours du combattant : à chaque transition, les utilisateurs perdaient leur contexte et devaient repasser par la liste pour atteindre l'entrée suivante. D'autres irritants s'étaient accumulés en périphérie : un Master Picker peu visible, un breadcrumb ignoré au profit d'un clic systématique sur le logo.
Mon rôle
Product designer au sein d'une équipe de trois designers et un product manager, j'ai participé à l'ensemble du sprint : interviews, synthèse, idéation, prototype sur Figma, puis tests utilisateurs.
Le sprint
Comprendre (jours 1 et 2) : six interviews ont fait remonter un signal clair : chaque transition entre les pages clés fait perdre le contexte à l'utilisateur. Un atelier de synthèse puis une cartographie de l'existant ont confirmé où ça faisait le plus mal, le retour depuis le bulletin vers le dossier.
Diverger (jour 3) : How Might We puis affinity mapping ont fait émerger quatre axes prioritaires, la navigation entre salariés en tête. Nous avons enchaîné sur un Crazy 8s, huit minutes par question pour esquisser huit directions, avant que chacun développe sa meilleure idée en solution sketch, votée par l'équipe.
Prototyper (jour 4) : nous avons construit ensemble un prototype Figma sur les deux axes les plus votés : navigation entre salariés et entre sections de l'application.
Tester (jour 5) : nous avons retesté les mêmes six personnes que lors des interviews, pour mesurer l'écart entre les difficultés décrites en début de sprint et leur expérience face au prototype.
Fig. 4
Session de test 1, prototype face à un utilisateur interne
Fig. 5
Session de test 2, prototype face à un utilisateur externe
Résultat
Ce sprint a confirmé quelque chose qu'on pressentait : les problèmes de navigation n'étaient pas des problèmes d'interface, c'était un problème de structure. Les utilisateurs ne se perdaient pas parce que les boutons étaient mal placés, ils se perdaient parce que l'app n'avait pas de modèle mental clair.
Ce qui nous a le plus surpris, c'est la rapidité à laquelle les solutions ont convergé : dès les Crazy 8s, deux groupes travaillant séparément avaient dessiné des idées très proches. Cinq jours ont suffi à débloquer des mois d'hésitation : plus de décisions structurantes prises en une semaine qu'en plusieurs cycles de développement classiques.
- Prioriser sous contrainte de temps : la contrainte des cinq jours a forcé à trancher plutôt qu'à explorer indéfiniment.
- Tester tôt, avec les mêmes utilisateurs : revoir les personnes interviewées en début de sprint a permis de mesurer un écart réel, pas une impression.
- La convergence comme signal : quand deux groupes isolés arrivent aux mêmes idées, c'est un signal de direction plus fiable qu'un vote.