Reconnecter développeurs et utilisateurs avec l’UJM

Pratiquer l’UJM (User Journey Map) pour reconnecter les développeurs aux utilisateurs est une technique permettant de comprendre finement les usages d’un processus et des outils le supportant.

Il existe d’autres techniques qui peuvent aider à reconnecter les développeurs aux utilisateurs. J’ai choisi de présenter ici l’UJM.

Reconnecter les développeurs aux utilisateurs

Les équipes de développement IT sont, dans la très grande majorité des cas, complètement déconnectées de la réalité des utilisateurs ; ceux qui manipulent au quotidien les outils supportant les processus.

Même les équipes pratiquant la Revue de sprint (souvent réduite à une démo) de Scrum ne se confrontent pas vraiment aux utilisateurs. Certes, elles échangent avec des utilisateurs-clés quand ils sont invités à la Revue. Certes, les membres de l’équipe discutent avec le Product Owner pour comprendre le besoin des utilisateurs. Cependant, on reste encore loin de l’utilisateur final.

On trouve facilement une multitude d’exemples de cette déconnexion :

• demander aux utilisateurs de respecter (et de s’en souvenir) un format de saisie alors que l’outil pourrait contrôler les données saisies. Exemple : le nom doit être en majuscule, mais la zone de saisie est alpha-numérique minuscule et majuscule ;
• aller dans le menu Demande d’achat pour créer un nouveau fournisseur alors qu’il existe une rubrique Fournisseur (où est la logique ?) ;
• imposer aux utilisateurs des outils différents selon l’étape du processus de bout en bout (raisonnement product management VS process management) ;
• …

Malgré cela, très peu de personnes vont s’assoir à côté d’un utilisateur (qui est au final le client le plus important) pour comprendre l’usage fin qu’il fait de l’outil (et du processus qu’il doit / devrait respecter).

Un des principes du Lean est de comprendre ses clients (ses utilisateurs). Par conséquent, comprendre veut dire aller sur le terrain des clients / utilisateurs. C’est-à-dire aller là où se passent les choses ; le Gemba en Lean. L’UJM est un formidable outil pour le faire.

L’UJM peut également être utilisé pour amener les manageurs à aller voir sur le terrain. À se confronter à la complexité dans laquelle se trouvent les utilisateurs. Autrement dit, ne plus se cacher derrière des injonctions de type :

• Ils n’ont qu’à suivre les tutos !
• Qu’ils respectent les processus et ça ira mieux !
• Ils ne sont jamais contents !
• …

P.S. : pour moi, la présence de tutos est un révélateur d’une certaine complexité, donc d’une expérience utilisateur peu intuitive.

User Journey Maps

L’UJM est une pratique venant de l’UX (User eXperience) et est, la plupart du temps, utilisée par les UX eux-mêmes. Pour l’expliquer simplement, cette pratique permet de rendre visibles les gestes et l’émotion d’un utilisateur à chaque étape d’un processus.

Néanmoins, il est important de comprendre et de faire comprendre qu’il ne s’agît pas d’un contrôle de l’utilisateur. La finalité doit toujours rester l’identification des irritants de l’utilisateur.

À partir des éléments observés sur le terrain, il est donc possible d’identifier un nombre non négligeable, pour ne pas dire important, d’améliorations simples ou plus complexes pour lever les irritants que rencontre l’utilisateur.

Il existe plusieurs modèles d’UJM disponibles sur Internet. À vous de trouver celui qui vous apportera le plus de valeur pour faire évoluer vos applications.

Pratiquer l’UJM

Pratiquer l’UJM pour reconnecter les développeurs aux utilisateurs est, à mon sens, une solution simple, rapide et efficace.

Toutefois, il n’est pas question d’envoyer un développeur observer un utilisateur sans le former a minima à la pratique de l’UJM. Dans l’idéal, il est préférable de tester avec un développeur motivé. Les utilisateurs sont très réceptifs du moment qu’on leur explique le sens.

Pour avoir un bon UJM, il est important de connaître

• la ou les étapes du processus qui sont observées ;
• le profil de l’utilisateur ;
• les gestes précis réalisés ;
• les problèmes précis rencontrés ;
• l’humeur de l’utilisateur qui viendra renforcer l’observation.

Pour les gros irritants, je demande toujours à l’utilisateur de se projeter dans un monde idéal. Cela lui permet de donner SA solution. C’est l’intégrer dans l’amélioration. Cependant, dans ces cas là, il peut être nécessaire d’aider l’équipe de développement à prendre du recul pour accepter cette solution. Habituellement, c’est souvent l’équipe de développement qui apporte la réponse.

Capter les irritants des utilisateurs, c’est bien ! Les résoudre, c’est mieux ! Tout comme les NPS (Net Promotor Score), le plus important sont les verbatims de l’utilisateur. Pour éviter de le décevoir, il est donc important de traiter rapidement ses irritants en fonction de leur priorité.

En complément, un effet kiss cool remonté par les équipes de développement : elles sont surprises de la précision des informations qu’elles obtiennent avec l’UJM. Habituellement, elles n’ont rien de bien concret à se mettre sous la dent pour améliorer la situation si ce n’est des :

• C’est nul ;
• Ça ne fonctionne pas ;
• À jeter !
• …

En guise de conclusion, l’UJM permet de créer ou recréer la relation entre les utilisateurs et les développeurs. Tout le monde y gagne en satisfaction !