Repenser l'expérience utilisateur chez Assia

En 2024, j’aide Assia à revoir l’expérience utilisateur et les interfaces de son outil de gestion pour les mutuelles. J’arrive comme lead designer dans une entreprise qui a une longue histoire, mais qui découvre plusieurs aspects. Le modèle en cascade est de rigueur jusqu’à présent. Les principes agiles de développement seront mis en place avec ce projet. Le fait d’avoir un designer intégré est également nouveau. Des designers externes ont travaillé par le passé, sur certaines briques périphériques. Là, c’est le coeur de ce que vend Assia qui doit être repensé. La tâche est ardue, et excitante. Voici comment je m’y suis pris.

Le squelette du système

En parcourant les tickets qui remontaient des utilisateurs (les gestionnaires des mutuelles, principalement), je me suis rendu compte que leur pratique était prise dans le réseau de contraintes du logiciels. C’est un point critique : la courbe d’apprentissage pour les utilisateurs est particulièrement raide. Le problème, c’est que ce point de douleur n’est pas le fait du métier, mais est en grand partie provoqué par l’interface. Il faut donc supprimer ce glacis de complexité, et rendre la manipulation du système la plus transparente possible.

La complexité de l’interface se superpose à celle du métier

C’est d’ailleurs le problème avec le legacy : un grand nombre de personnes est intervenu avec sa logique propre, et l’interface avant le travail est la conséquence de ces couches de pensées disparates et incohérentes. Certaines choses sont cohérentes et issues du métier, d’autres sont des contorsions dont même les auteurs, s’ils sont toujours disponibles, ont du mal à remonter le fil.

Pour mettre cet héritage encombrant à distance, le premier travail est donc d’identifier les objets du système : pour le moment noyés au milieu du reste, il faut trouver les principaux points d’entrée, ceux qui créent de la valeur pour l’utilisateur. Qui signifie quelque chose dans leur pratique quotidienne. Un travail d’enquêteur auprès des utilisateurs, et auprès des techniciens toujours présents. Le framework ORCA m’a particulièrement aidé sur ce point. Le nouveau produit, en façade, sera différent. Les données, elles, seront les mêmes. Le produit vivra dans les deux mondes (pas trop longtemps, on espère, mais rien n’est moins sûr). Un exercice de tri de cartes permet, ensuite, de dégager une navigation pertinente, sur la base du squelette du système

Comme à cette phase sont jetées très tôt les graines de ce qui deviendra un jour le produit central de l’entreprise, il faut poser des bases de l’interface qui soient solides, et qui ne seront pas remises en cause dans quelques semaines ou quelques mois, et qui puissent subir le poids des années. Au niveau de la navigation, rien que des choses très éprouvées. Et pour la structure interne des vues de l’interface, c’est la phase de recherche de la structure interne qui structure ce travail. Le but : éviter les grands changements de design par la suite (voir le highlight sur le core du design qui change peu voire pas dans [[What If…legacy Software Was a Good Thing by Sophia v Prater Medium]]. Les coups de barre deviendront de plus en plus coûteux.

Encapaciter l’équipe

À ce moment, deux travaux sont menés de front : poser le socle de l’interface, et diffuser les décisions de design.

Des artefacts graphiques sont produits (les fichiers Figma, pour l’essentiel), mais ils ne sont qu’une partie de ce qui sert aux développeurs et aux product owners à créer le produit. il est essentiel que les grands principes s’ancrent fermement à mesure que le développement avance. Les développeurs veulent du concret : tant mieux, un design system est disponible (lien vers le ds).

En traçant des chemins dans la documentation des principes de conception, le design n’est alors plus seulement l’affaire du designer, mais de toute l’équipe

Lors d’un travail où le design s’effectue à mesure que le développement avance (design intégré au cycle Agile, mal), les POs et les développeurs sont accaparés par la production. Mon rôle à ce moment du projet, et de leur donner accès aux bonnes informations. En traçant des chemins dans l’information disponible, mon objectif est de leur faire acquérir des réflexes. Ces réflexes se traduiront par une cohérence des libellés dans les tickets pour les dévs, dans ce qui doit être affiché par défaut, ce qui peut être masqué. Ce partage de la connaissance est essentielle : le design n’est alors plus seulement l’affaire du designer, mais de toute l’équipe. C’est seulement en s’appropriant ces informations que les principes pourront essaimer au sein du produit.

Documenter et communiquer : la plus grande partie du travail

Les modifications sur l’architecture de l’information sont partagées, améliorées, puis diffusées. C’est une phase essentielle du travail : la nouvelle structure est diffusé dans l’équipe, puis, de façon concentrique, dans le reste de l’entreprise. La mise en commun de ce travail est essentielle. À long terme, c’est en partie sur celui-ci que s’appuiera l’entreprise pour développer les briques suivantes du produit.

Il faut pour cela installer une atmosphère de collaboration, et c’est le plus difficile. C’est autant une affaire d’outils que de pratiques. Chacun doit partager l’information dont il dispose, et la mettre à disposition de façon permanente à chacun (et le mail n’est pas un bon outil pour cela) À mon niveau, j’encourage à utiliser tout ce qui permet à chacun d’avoir le même niveau de connaissance du projet : documenter dès que c’est possible, et de façon pérenne. Miro, Notion, Confluence, un wiki, peu importe, tant que l’information est centralisée et sa mise à jour collaborative.

Pour permettre à l’information de passer, le format a également son importance. Tout le monde n’a pas le même rapport aux informations : certains retiennent en lisant, d’autres en regardant une vidéo. Certains ont une mémoire visuelle, d’autres une mémoire auditive. Donc, dès que c’est possible, j’essaie de doubler l’information dans plusieurs formats différents : des images, du texte, du son, de l’image animée.

Un objectif atteint

Mon action se répartit donc, pour synthétiser, autour de ces quatre tâches :

• Comprendre le métier et le contexte
• Produire des idées
• Les polir et les ajuster
• Communiquer ces idées

Aujourd’hui, l’immense majorité des clients qui a pu mettre les mains sur la nouvelle interface est séduite. L’objectif de simplification, ou plutôt de fluidification des tâches des gestionnaires est atteint. Le résultat : une efficacité accrue dans l’accomplissement des tâches, et un effort moins important sur la formation des gestionnaires.