Qinaps

LE VRAI DÉFI

Une vraie amélioration, sans toucher aux fondations

Le produit fonctionnait, mais ne donnait pas l'impression d'être un outil cohérent. Les espacements et les couleurs étaient incohérents d'une page à l'autre, un même type d'élément était présenté de deux façons différentes, et plusieurs actions importantes étaient enfouies dans des menus clic droit ou n'apparaissaient qu'au survol. Les utilisateurs ne savaient pas toujours dans quelle vue ils se trouvaient.

Je ne pouvais rien corriger de tout cela en restructurant. Tout le défi était donc une question de levier : trouver les petits changements, uniquement front-end, qui s'additionneraient pour donner un produit cohérent et lisible, et m'assurer que chaque changement recommandé valait réellement la peine d'être développé.

Décisions clés

Auditer tout le parcours avant de changer quoi que ce soit

J'ai parcouru le produit de bout en bout comme un utilisateur, puis j'ai construit une experience map couvrant ses quatre phases principales : initialiser un document, gérer les sous-ensembles, gérer les exigences, et collaborer. Pour chaque phase, j'ai détaillé les objectifs de l'utilisateur, ses actions, les hauts et les bas émotionnels, ce qui fonctionnait déjà, et là où ça cassait. Cela a transformé un vague « rends-le meilleur » en une carte concrète et ordonnée de l'endroit exact où l'expérience échouait, et pourquoi.

Séparer les deux types de problèmes, et prioriser chacun

Tous les problèmes n'avaient pas la même forme. Certains étaient ergonomiques et structurels : actions cachées, impossibilité de savoir dans quelle vue on était, navigation maladroite. D'autres étaient visuels : espacements incohérents, un jeu d'icônes incohérent, des couleurs non systématisées, deux styles de modales différents. J'ai séparé les recommandations en UX/ergonomie et UI, et priorisé au sein de chacune, pour que le client voie la différence entre « ça perturbe les gens » et « ça fait inachevé ».

Pondérer chaque recommandation avec le développeur

C'est la décision que la contrainte a imposée, et celle dont je suis la plus satisfaite. Une liste d'améliorations ne sert à rien si la moitié est trop coûteuse à développer. J'ai donc mené une session de travail avec le développeur et pondéré chaque recommandation sur trois critères : son importance pour les utilisateurs, sa priorité, et son coût d'implémentation côté front-end. C'est cette session qui a transformé une liste de souhaits en un plan réaliste et hiérarchisé, respectant la règle du « aucun changement structurel ».

Investir le budget sur des gains à fort levier et faible coût

Une fois le plan validé, j'ai concentré les changements là où un faible effort achetait une vraie clarté. Les principaux :

• Rendre visibles les actions cachées. Des actions importantes n'étaient accessibles qu'au clic droit ou au survol. Je les ai amenées dans une barre d'outils visible par vue pour que les gens puissent vraiment les trouver.
• Savoir où l'on est. J'ai ajouté un moyen clair de changer de vue, un titre de page pour la vue courante, et un fil d'Ariane pour le workbook et le point de vue, pour que les utilisateurs cessent de se perdre.
• Corriger les modales. Il y avait deux styles de modales incohérents. Je les ai unifiés, corrigé l'ordre des boutons confirmer et annuler, et donné à chacune un titre et un espacement correct.
• Une passe de cohérence. Espacements systématisés à travers les pages, un jeu d'icônes SVG cohérent choisi pour coller au sujet, et des couleurs primaires, secondaires et utilitaires rationalisées.

Aucun de ces changements n'a touché à l'architecture. Ensemble, ils donnent au produit l'impression d'être un seul outil au lieu de plusieurs.

Ce que je ferais différemment

J'impliquerais le développeur plus tôt, dès la cartographie du parcours, plutôt qu'après avoir rédigé la liste complète des recommandations, pour que les contraintes de coût influencent l'audit dès le départ.