Un conseil que j’aurais voulu avoir au tout début de ma carrière est de prendre le temps, de savoir prendre le temps dans un démarrage de projet, produit ou toute problématique.

On est toujours dans une course au livrables, au rythme des plannings, des contraintes... et on ne travaille pas forcément bien comme ça ! Le risque est de traiter la mauvaise problématique !

Finalement, on peut prendre son temps, c'est même mieux. C'est juste une question d’approche, de communication, une manière d'aborder les choses différemment et de mieux les cadrer. Il faut prendre le temps de parler de la bonne problématique et non du livrable final !

Ce n'est pas toujours évident parce que les parties prenantes ont besoin de voir des choses notamment en phase de recherche. Ce n'est pas tout de suite palpable ce que l'on fait en tant que ‘UX Researcher’ donc il faut rassurer ! surtout dans le cadre d’une organisation qui n’a pas l’habitude de ce type d’approche ou de méthodologies.

Il faut prendre le soin de communiquer

• Les différentes étapes de nos activités et le pourquoi de celles-ci
• Qui l’on va intégrer et pourquoi
• Ce que ça nécessite comme niveau d'investissement (temps, ressources, etc.) 

Je prends le temps de partager cette vision dès le départ, pour ne pas créer un effet déceptif et donner des points d’étapes pour échanger sur les apprentissages… même si ça reste sur du court terme et assez spécifique il faut le faire, sur du long terme le partage de vision peut-être beaucoup plus macro.

J'ai une expérience avec ce cas récemment où l'on m’a demandé pourquoi je commençais par traiter ce point alors que leur objectif premier était autre, notamment pour ce projet, l’objectif premier de mes commanditaires était de fournir une GED (outil de gestion documentaire) aux collaborateurs.

Comme on manque d'apprentissage et d'expérience sur cette partie GED , et que l’identification des problèmes auxquels nous voulions résoudre n’était pas claire, j’ai proposé de commencer plutôt par un pilote sur lequel nous pourrions apprendre des usages et des problématiques que rencontrent l’utilisateur ; ça reste un produit utilisable sur lequel nous pourrions en récolter au fur et à mesure des données qui seront essentielles pour la bonne évolution du produit qu’ils souhaitent déployer. 

Comme ce type de livrable (le pilote) ne répondait pas suffisamment à un produit fini, il a été difficile de le faire accepter par l’ensemble des parties prenantes.

C'était une approche nouvelle et ce n'était pas évident, ce n'était pas ce qu'ils avaient en tête. Donc, forcément, il y a plus de discussions et il faut réussir à expliquer pourquoi on fait ça, avec les bons arguments qui feront ‘écho’ aux problèmes qu’ils essaient de résoudre.

Je prends donc le temps d'expliquer et je me suis rendu compte que la répétition était importante pour un apprentissage de l’approche également.

Je vais jusqu'à une Roadmap du projet, une vraie vision, ce que l'on va faire, des personnes qu'on va impliquer et des ressources dont j'ai besoin. Ça passe évidemment par le budget, la validation juridique, la logistique (réservation de salles, outils et licences, etc.)