chargement des résultats
J’ai pris conscience de l’importance des Checklists grâce à une erreur que j’ai fait sur un de mes premiers projets. J’étais entrain de présenter mon travail de façon plutôt confiante, quand un Développeur m’a posé une question anodine en apparence sur l’état d’un composant. Et là, j'ai eu le sentiment de me voir à la troisième personne et je me dis "Colbys comment tu as pu oublier ça ?" . C'était une claque galactique ! J'ai essayé de rattraper le coup : " Ah oui, effectivement, c'est quelque chose que j'ai oublié, mais au début, j'avais noté ça quelque part, donc je ferai la modification sans que ça change vraiment tout". Mais en réalité, c'était une grossière erreur de ma part. Aujourd'hui ce que je fais c'est que je fonctionne beaucoup par checklist dans tout ce que je fais. Si je dois faire un redesign par exemple: Ainsi je vais toujours me fier à cette checklist. Donc au fur et à mesure que j'avance, je vais l'ouvrir et je vais checker. Vient enfin le jour de la présentation et je sais que je suis prêt et que je couvre tous les uses case. Je sais ainsi qu'il n'y aura pas de question qui va me mettre K.O. On n'abuse jamais assez des check-lists ! Sur les produits denses en plus, il y a beaucoup de choses à prendre en compte et je pense qu'il n'y a pas de honte à connaître ses limites. C'est nécessaire pour bien faire. La création d’une Checklist Quand je dois partir de zéro sur un projet, je fais de la recherche pour connaître les besoins, les contraintes, … les informations à afficher, dans quel ordre, par priorité. Par contre, si c'est un projet existant, je découpe d’abord l'existant. J'essaye toujours de découper les choses et de les grouper avant d’attaquer la phase la recherche. Je vais prendre l'exemple d'une page car c'est à une échelle réduite et ça aide à visualiser ce que je veux dire . Si je dois redesigner une page, je vais la découper en plusieurs morceaux. Il peut y avoir la navigation d'une part, un fil d’Ariane, la pagination ou un footer. Je vais découper tout ça, leur donner des noms et les grouper. Dans ma checklist, je vais inclure chaque élément qui compose ces bouts de la page ainsi que leurs différents états à prévoir. Par exemple, dans le footer, je vais avoir des liens vers telle ou telle page, peut-être des CGU, … À partir de là, normalement, l'exercice est relativement simple parce qu’au fil de la recherche, quand j’identifie les nouveaux composants à apporter, je les rentre dans cette checklist, il me suffit juste d'un petit tag pour différencier l’existant du nouveau, et voilà ma Checklist est complète et me donne une vue d’ensemble. Ça m'aide à faire du zoning parce que si je dezoome, je sais tout ce qui doit être sur cette page-là. Puis à l’étape de wireframing, je vais zoomer et travailler sur chaque bout de la page individuellement.
Ce que j'aurais aimé au début de ma carrière, c'est que l’on me dise l’importance de mieux comprendre l'organisation dans laquelle on travaille au-delà du produit. Pour comprendre cela il faut comprendre mon parcours. J’ai un cursus universitaire, en sociologie et anthropologie et j’ai bifurqué vers le design à la fin de ma thèse. Quand l’UX est arrivé la double casquette m’a permis de tout de suite être à l’aise. Mais le rôle propre d’UX Researcher, c’est dans mon précédent emploi que je l’ai pris en premier, il y a 4 ans. Lorsque tu es designer tu as l’habitude de travailler sur des interfaces, tu produis des choses. Mais un researcher c’est plus que ça. Il produit de la connaissance, il produit plein de connaissances pour le design mais aussi sur l’ensemble du process produit et c’est hyper important. Je crois qu'aujourd'hui, le sujet sur lequel je suis le plus affûtée, c’est de bien comprendre l’organisation du produit. En arrivant dans mon précédent emploi, j’ai mis du temps à comprendre l’organisation produit. Parce que finalement le researcher est dans le process produit, l’interface entre le PM et le design. J’ai vraiment eu besoin de bien comprendre les process et les rôles de chacun et aussi les interactions entre les équipes Encore aujourd'hui, ce n’est pas forcément toujours facile. L'entreprise dans laquelle je travaille actuellement est une grosse entreprise. L'avantage que j'ai, c'est qu'elle est hyper bien structurée. On a beaucoup de rituels, donc on peut bien voir comment ça fonctionne. Les PM avec qui je travaille qui sont les PM front, nous intègrent dans leurs rituels de dev, et nous, on les intègre dans nos ateliers de construction, de co-conception et de recherche aussi. C'est notre manière, de bien comprendre et connaître la manière dont on travaille les uns et les autres. Parce que souvent comme researcher, tu vas te retrouver dans la situation où on va dire “Vas-y, il faut qu'on ait des insight utilisateurs sur tel sujet” Mais tu ne comprends pas dans quel objectif ça s’inscrit, dans quel roadmap, etc. Maintenant, dans mon équipe, on a construit un template de briefs pour se demander à chaque fois pourquoi on veut faire ce sujet de recherche Quels sont les objectifs business ? Comme ça, on sait bien ce qu'on fait, pourquoi on le fait et comment on rend toute la recherche activable pour les parties prenantes.
L'une des plus grandes erreurs que j'ai commises en tant que responsable d'équipe et experte UX a été de supposer que mes clients connaissaient déjà ce qu'était l'UX, sans rien préparer pour leur expliquer. Nous pensions qu'ils étaient déjà familiers avec le concept, alors qu'en réalité, nous aurions dû partir du principe qu'ils ne le savaient pas et leur montrer comment nous pouvions les aider. Ma vie aurait été bien plus facile si j'avais eu une brève présentation résumant : C'est toute la notion d'advocacy, et cela a des répercussions sur votre carrière : Au sein de l'IMD (Institut de Management et de Design), j'ai lancé une vaste campagne de sensibilisation, car j'ai réalisé que lorsque nous vendions l'UX à nos clients, ils le percevaient simplement comme du design. Depuis lors, l'une des choses les plus importantes que j'ai faites est de sensibiliser les gens à ce qu'est réellement le métier de l'UX, quelles sont les valeurs ajoutées, comment cela fonctionne et comment nous pouvons les impliquer. Je me souviens avoir organisé une série de trois présentations de trente à quarante minutes chacune, où nous avons invité l'ensemble de l'IMD pour leur expliquer. Nous devions dissiper cette confusion persistante : "Ah, vous faites du design ; ah, vous travaillez dans l'informatique ?" Pour bien expliquer l'UX, il n'est pas nécessaire d'avoir des éléments concrets à montrer, mais plutôt de raconter une bonne histoire, en établissant des analogies avec leur travail quotidien. Par exemple, l'un de nos clients internes qui rencontrait le plus de problèmes avec l'outil que nous utilisons actuellement était le secteur de la médiation (travaillant avec le public, notamment les enfants). Ils étaient confrontés depuis plus de dix ans à un problème majeur : la mise à jour de leur CMS interne. À l'époque, il était largement utilisé et considéré comme la référence, mais aujourd'hui, il est devenu obsolète, lourd et extrêmement difficile à optimiser, ce qui freinait toute l'équipe. Lorsque vous sensibilisez les gens, il est important de vous référer à ces problèmes spécifiques qui les affectent au quotidien, et de construire votre histoire autour de cela. Par exemple : "En résolvant ce problème de cette manière, vous n'aurez plus à passer trois heures à recréer des données et à vous épuiser avec votre CMS." L'objectif est de susciter leur intérêt en replaçant ces problèmes dans leur contexte quotidien. Il n'est pas nécessaire de se concentrer sur de grands enjeux, même de petites améliorations peuvent faire toute la différence.
Dans ce post, je vais vous parler de ma méthode de travail pour trouver un équilibre entre la méthodologie agile et UX. Je partagerai également les outils que nous utilisons pour gérer nos backlogs et prioriser nos tâches. En ce moment, je suis très impliqué dans la mise en place d'un nouveau modèle chez mon client pour établir la manière dont nous travaillons. Cela correspond à du “Dual-Track Agile” ou encore une méthodologie de “Product Discovery / Product Delivery”. On n’est pas très loin non plus d’une méthode Shape Up de Basecamp. En gros, nous avons deux axes de fonctionnement parallèles : Nous utilisons une approche plus classique pour la recherche, en gérant un backlog de découverte et en traitant les priorités à l’aide d’un Kanban. Une fois traités, les sujets de recherche testés et validés sont finalisés sous forme de story et quittent le backlog de découverte pour aller nourrir le backlog de développement. Nous intervenons ensuite assez peu dans le flux de développement, uniquement pour les petits ajustements nécessaires en cours de route. Une fois que les éléments sont ancrés, nous gérons les tests et les retours pour nourrir le backlog de découverte. Cela nous permet de travailler sur ces deux modèles en parallèle, avec deux "lignes de production" distinctes sur lesquelles nous travaillons. Ce mode de fonctionnement fonctionne plutôt bien pour nous, mais le plus important à retenir c’est qu’aucun framework n’est parfait. Il faut souvent adapter un modèle au contexte de l’entreprise et du projet / produit sur lequel on travaille car chaque sujet est différent et les équipes ont une culture et une expérience différentes. Si on ne prend pas en compte ce contexte et qu’on cherche à appliquer une méthode, quelle qu’elle soit, au pied de la lettre, c’est le meilleur moyen de se prendre le mur. Auparavant, j'avais tendance à aligner la recherche sur la même cadence que les sprints de développement, mais cela ne faisait que créer une pression inutile. Nous nous retrouvions parfois à la fin des sprints avec des recherches partielles, ce qui n'était pas efficace. Passer à une approche plus classique pour la recherche nous a simplifié la vie et nous a donné une meilleure visibilité sur nos activités. L'équipe de développement a également bien accueilli ce changement, car cela ne perturbe pas trop leurs habitudes de travail, et cela fonctionne donc plutôt bien pour eux. La seule difficulté que nous rencontrons, c'est que nous avons deux backlogs distincts : le backlog de découverte et le backlog de développement. Étant donné que nous travaillons en mode kanban d'un côté et en mode sprint de l'autre, il n'est pas toujours facile de les gérer dans le même outil. Pour vendre cette nouvelle approche, cela a été plutôt complexe et tendu. Le client est en pleine transformation et a mis en place un modèle hybride entre SAFe et le pseudo-modèle Spotify (“pseudo-” car ce modèle n’est pas réellement utilisé chez Spotify), avec des personnes ayant peu d'expérience en agilité, pensant peut-être que certifier les équipes à tout va suffisait à réaliser une transformation Agile... Cependant, ce modèle n'a pas été bien évalué, car ils n'ont même pas encore établi de retour d'expérience sur le MVP avant de le généraliser à d'autres équipes, ce qui est une première erreur. Pour donner un exemple concret de ce qui ne fonctionnait pas, sur un projet en particulier, le coach Agile qui nous accompagnait cherchait à nous imposer ce modèle, car c'était la consigne qu'il avait reçue, même si ce n'était pas du tout pertinent pour le produit sur lequel nous travaillions. Heureusement, avec l'aide de la Product Manager (PM) avec qui je travaille depuis presque un an, nous avons pu proposer une orientation différente pour les squads et la structure du projet : Étant donné que notre produit a des sous-produits avec des équipes techniques et métiers différentes, il était important d'avoir des Product Owners (PO) dédiés à chaque sous-produit, ainsi qu'un PO global pour la vision globale du produit. Nous avons donc dû sortir du modèle officiel qui nous était imposé, ce qui a généré quelques discussions sur le choix des termes, mais pour moi, le wording n'était pas un point crucial. De plus, étant donné que notre charge de travail allait évoluer au fil du temps, avec des petites et potentiellement grandes évolutions à gérer, nous avons mis en place un système évolutif avec une capacité à scaler facilement.
Un conseil que j'aurais aimé recevoir plus tôt dans ma carrière est celui de persister et de m'accrocher sur les projets que je menais, surtout lors des phases très early où les critiques internes peuvent être déstabilisantes. Parfois, j'ai abandonné un peu trop vite face à la pression, ce qui a eu pour conséquence de mettre un terme prématurément à des projets d'innovation prometteurs. Je me rappelle de ces moments où l'étape primordiale était de construire une vision, mais où j'ai été submergé par une avalanche de critiques de la part de mes collaborateurs. Trop souvent, j'ai abandonné le projet en me disant que s'il y avait autant de critiques, cela ne pouvait être une bonne piste à suivre. Mais c'était justement l'erreur à ne pas commettre : s'arrêter aux premières critiques. Il est important de comprendre que les critiques font partie intégrante du processus d'innovation et qu'il ne faut pas les voir comme des obstacles insurmontables. En acceptant cette étape comme faisant partie du jeu, on évite de se décourager trop vite. En effet, à posteriori, j'ai souvent constaté que quelqu'un d'autre avait repris l'idée que j'avais abandonnée, ou que l'idée avait été développée et présentée d'une autre manière. Pour rendre cette étape plus impactante et engageante pour mes interlocuteurs.rices, j'ai appris à travailler davantage en amont mes idées pour consolider ma vision. Outre travailler la communication d'une vision plus claire, une astuce que j'ai apprise est de prototyper très tôt afin de rendre les choses concrètes pour mieux les expliquer. Le prototype a plusieurs avantages: -il envoie un message clair : cela est faisable ! Les parties prenantes sont souvent rassurées de voir des résultats concrets plutôt que de simples idées théoriques. -il permet de mieux se faire comprendre en apportant des éléments tangibles. Ainsi j'ai pu recevoir de meilleurs feedbacks pour affiner mes idées, les faire mûrir et trouver des allié.e.s. -il permet aussi de se positionner en “responsable” de cette conduite du changement en permettant de discuter d’un plan d’action, en montrant que des ressoruces existent. Ainsi, pour gagner en leadership, je me suis fixé comme règle que lorsque je présente une idée même aussi minime qu’elle soit, je l’accompagne toujours d’une ébauche de solution, d’un Mock-up…. D’une base concrète quoi. J'ai également travaillé sur mon état d'esprit pour accepter les critiques sans tomber dans une spirale de négativité qui a tendance à briser la créativité. Les résistances sont souvent bénéfiques car elles nous forcent à consolider notre vision et à proposer des solutions plus solides, mieux construites. Cela nous permettra d'embarquer du monde avec nous, in fine. En somme, il faut apprendre à remercier cette étape de "résistance" qui nous permet de produire de belles innovations. En réalité, après quelques expériences, c'est lorsque nous ne rencontrons pas de résistance qu'il faut s'inquiéter. Pour donner un exemple concret où cela s'est passé récemment, j'ai travaillé sur des échelles de psychométrie pour mesurer l'engagement, un vaste sujet dans l'industrie du jeu vidéo. Pendant trois à six mois, j'ai discuté de cette idée, mais elle a été rejetée avec de nombreuses critiques : cela ne menait pas la recherche utilisateur dans la bonne direction, c'était trop difficile, et cela ne servirait à rien de toute façon. J'ai été confronté à de nombreuses critiques et je n'arrivais pas à clarifier pourquoi je voulais travailler sur ce sujet et quelle approche adopter. Ce que j'aurais dû faire, et ce qui a été fait par la suite, c'était : Malheureusement, une autre équipe a commencé à travailler sur le même sujet et a pris la direction du projet. J'ai fini par rejoindre cette équipe, et c’est d’ailleurs en accompagnant mes idées pour ce projet avec des choses concrètes que j’ai pu rejoindre ce projet. Mais cela a été frustrant de réaliser que j'avais perdu trois à six mois dans des discussions qui au final n'avaient pas fait avancer le projet. Peut-être que l'idée de départ n'était pas si mauvaise après tout.
"Une erreur récurrente à laquelle je suis malheureusement encline à sous-estimer est la dimension politique entourant la recherche utilisateur et l'instrumentalisation des résultats une fois la recherche livrée. Par le passé, j'avais tendance à ignorer ces aspects et à ne pas les anticiper, ce qui m'empêchait de mettre en place des actions pour y remédier. Récemment, j'ai fait face à un problème lié à la monétisation dans les jeux, un sujet majeur dans l'industrie du jeu vidéo. Initialement, la recherche utilisateur ne portait pas du tout sur ce sujet, ce qui a créé des difficultés alors que certains collègues et moi-même nous battions contre de nombreux obstacles. Heureusement, j'avais des alliés en interne pour me soutenir. Normalement, nous testons fréquemment les jeux avant leur sortie. Cependant, dans ce cas précis, nous voulions le tester en amont, avant même d'introduire la dimension monétisation. Malheureusement, j'ai été confrontée à des critiques méthodologiques telles que : Le problème vient du fait que la recherche utilisateur est distincte de la market research. Il existe donc des silos entre le volet Market Research et la recherche utilisateur. J'ai pensé que la monétisation était à la fois une question de design et une question commerciale. J'ai donc proposé de réunir les deux équipes pour travailler ensemble sur cet objectif de monétisation dans les jeux. Mon idée était un peu naïve politiquement parlant. Malheureusement, je me suis heurtée à des obstacles politiques qui ont ralenti mes projets. Certains pensaient fermement que la recherche utilisateur n'avait rien à voir avec le volet commercial et que cela ne faisait pas partie de notre mandat. J'ai rencontré de nombreux blocages et j'ai eu du mal à trouver des interlocuteurs et interlocutrices du volet commercial avec qui développer des méthodologies adéquates. C'était un véritable parcours du combattant pour trouver les bonnes personnes. Heureusement, au milieu de cette tempête, j'ai rencontré quelqu'un qui souhaitait avancer sur le projet et qui était également frustré ces aspects politiques. Cette personne m'a fourni les ressources nécessaires pour mettre en place un prototype et tester les éléments monétisables du jeu avant sa sortie. Nous avons ainsi démontré que la collaboration entre les équipes apportait une réelle valeur ajoutée. Par la suite, lorsque le projet a pris de l'ampleur, nous avons fait preuve d'encore plus d'ambition. Cependant, nous avons encore une fois manqué de soutien hiérarchique en raison des enjeux politiques complexes entourant la monétisation. En tant que chercheur utilisateur, il est difficile de trouver des appuis auprès de mes collègues, car nombreux sont ceux qui ne souhaitent pas intégrer des aspects monétisations dans les jeux. Cela a rendu ma tâche plus difficile et j'ai personnellement beaucoup souffert de cette lutte dans la sphère politique. Je ne disposais pas des bons outils, et c'était un peu frustrant. Étant UXR, j'occupe une position relativement basse dans la hiérarchie, et je n'ai pas réussi à établir un réseau solide d'alliés de poids au sein de l'organisation pour m'aider à faire face à ces défis. Au fil du temps, j'apprends de plus en plus à anticiper ce genre de situations et à sécuriser l'environnement avant de me lancer dans de grands projets. Ainsi, je peux m'assurer d'avancer avec le moins d'embûches possibles. Pour cela, le dialogue informel interdivisionnel est essentiel. En poussant mes projets avec acharnement, j'ai dû affronter les enjeux politiques au fur et à mesure de leur apparition. (ce qui est ingérable sur le long terme. Il faut anticiper et débloquer avant) Finalement, je constate qu'il y a inévitablement une instrumentalisation de la recherche utilisateur, et cela entraîne naturellement des frictions irrationnelles entre les différentes parties prenantes avec lesquelles il faut “ jouer” pour faire bouger les choses.
J'avais prévu d'écrire un petit article sur divers thèmes, notamment celui de la liberté, et ce que j'aurais aimé savoir au début: Ce qui concerne l'administratif. Par exemple comment gérer tout ce qui est rupture conventionnelle ou démission, ce genre de choses. Le savoir administratif est important, il n'est pas à négliger. Des milliers d'euros peuvent se jouer sur une mauvaise décision, donc c'est bien d'être informé et pas juste se lever et dire voilà, je l'ai fait, c'est bon. Quand je veux quelque chose en général je planifie très bien et après je me lance. J'étais consultant avant, j'ai planifié, j'ai démissionné, je suis passé freelance. J'ai réalisé plus tard que si j'avais eu une rupture conventionnelle, j'aurais pu avoir le choix... Parce que tu peux cumuler le chômage de Pôle emploi avec le statut d'auto-entrepreneur. Là où ça aurait été intéressant spécifiquement, c'est que moi j'étais dans un système de facturation de 45 jours fin du mois, ce qui veut dire que je suis payé 60 jours calendaires après l'envoi de ma facture. Donc avoir le chomage dans cette période aurait été d’une grande aide. Heureusement que j'avais prévu quelques mois de réserve avant de passer en freelance. Mais pour ceux qui n'ont pas prévu ou qui n'ont pas pu à cause de la somme qu'ils gagnaient avant, ça, c’est une petite info qui peut tout changer. Ca ne sert à rien d'envoyer ta facture, si d’ici le temps que tu reçoives les sous tu es obligé de vivre sous le pont ! Ce n’est pas génial. Ce genre d'info te permet de faire les choses le mieux possible. En fonction de mon expérience ou des moments de ma vie, j'ai choisi un statut plutôt qu'un autre. Ils ont tous les deux des avantages et des inconvénients et je pense qu'il faut être assez intelligent pour ne pas forcément s'associer ou associer son identité à l'un des deux. Mais simplement se dire "je suis dans une phase de ma vie ou telle chose m'aiderait beaucoup". Je vais aller vers ça, être un peu plus malléable d'esprit et ne pas s'enfermer dans des boîtes sans raison. Ce que j'aime bien dans ce statut de freelance, c'est la vélocité, et la rapidité de décision que tu peux avoir parce qu'il n'y a personne d'autre à convaincre que toi. C'est quelque chose avec lequel j'ai eu un peu de mal quand j'étais consultant parce que je faisais pas mal de veille. J'aime bien tester des choses. Si je tombe sur un outil qui peut me permettre d'aller plus loin ou de faire pareil en moins de temps... Pour moi c'est bon, c'est le budget test ! Si c'est bien, tant mieux, si ce n’est pas bien, j'aurais appris et je partagerai tout ça via un article ou autre. Tu mets la carte et c'est tout ce qu'il faut. Là tu viens d'acquérir un nouveau savoir et c'est ce que j'aime le plus. Alors je ne vais pas nier qu'il y a d'autres avantages, bien sûr, mais ça, c'est vraiment la chose que j'aime le plus.
Une erreur que j’ai commise dans ma carrière était de ne pas identifier les sujets politiques, (internes ou externes), et les motivations de chaque personne liée à ces projets. Je pense qu'il est essentiel de bien comprendre les personnes avec lesquelles je vais interagir au cours d’un projet et de toujours prendre du recul avant de démarrer. Aujourd’hui je suis attentif à : Parfois, il peut arriver de travailler avec des personnes difficiles, voire manipulatrices, qui cherchent à exercer un contrôle excessif sur les projets. Il est donc important de les identifier dès que possible et d'apprendre à naviguer autour d'elles. Pour moi, une approche efficace consiste à écouter mon intuition et à comprendre les objectifs de ces personnes. En comprenant leurs perspectives, je peux mieux travailler avec elles et les amener à contribuer dans la direction attendue, tout en les laissant croire qu'elles mènent la prise de décision. Il est également crucial de bien connaître l'écosystème dans lequel j'évolue. Cela signifie comprendre les autres acteurs impliqués, leurs objectifs et leur niveau de maturité par rapport à mes domaines d'expertise, tels que l'agilité, la recherche et le design. Il peut être judicieux de concentrer ses efforts sur les personnes ou les sponsors les plus favorables à l’approche proposée, plutôt que de perdre du temps avec ceux qui sont fermés au changement. Cependant, je conviens que ce n'est pas toujours facile et que cela demande du temps et des efforts. En tant que freelance, il peut être encore plus compliqué de comprendre les dynamiques internes d'une entreprise. Il peut être utile de collaborer avec des collègues ou des experts qui ont de l'expérience dans ce domaine pour obtenir des conseils et des orientations. Pour résumer, voici comment je m’y prends pour éviter de foncer tête baissée dans les obstacles politiques. Qu'est-ce qui fera avancer cette personne ? Qu'est-ce qu'elle cherche réellement ? Comment est-ce que je peux agir sur ses déclencheurs, ses objectifs ? Afin de remettre les choses de son point de vue, de sa perspective, et essayer de partir de là pour avancer. Ensuite, je cherche aussi à identifier les autres acteurs dans l'écosystème, à comprendre ce qui les motive, quels sont leurs objectifs, et ainsi savoir dans quelle direction je peux tirer pour atteindre les objectifs fixés. Ce n'est pas toujours évident, car je ne suis pas spécialiste dans ce domaine, mais j’ai eu la chance de travailler en étroite collaboration avec un spécialiste avec qui j'ai pu échanger régulièrement et cela nous a permis d’obtenir de très bons résultats. Nous avons travaillé sur une cartographie des parties prenantes pour essayer de visualiser tous les acteurs importants autour de nous, comprendre ce qui les motive, comment ils fonctionnent, s'ils sont en accord avec nos objectifs, s'ils sont matures dans nos domaines d'expertise, tels que l'agilité, la recherche et le design. Pour cela, nous avons notamment utilisé le modèle de saillance des parties prenantes (“Stakeholder Saliency Model”) : 
Stakeholder Saliency Model ( source) Cela nous permet de mieux collaborer avec eux, de savoir avec qui concentrer nos efforts, qui cibler. Si nous constatons que certaines personnes sont totalement réfractaires au changement ou fermées à toute idée, nous ne perdons pas de temps avec elles. Nous cherchons plutôt à obtenir le soutien des sponsors pour faire avancer les choses dans la bonne direction. En ce qui concerne les sponsors, les réactions des gens sont différentes, et nous cherchons à identifier les personnes les mieux placées pour nous aider à progresser dans la direction souhaitée. C'est un travail de fond important, parfois réalisé en coulisses, car ce n'est pas toujours notre mission principale. Cependant, nous le faisons dans l'intérêt de notre mission globale, afin de nous assurer que nous avançons dans la bonne direction. Ainsi, nous avons des objectifs clairs qui nous motivent à accomplir ce travail, même si ce n'est pas toujours facile pour moi, car ce n'est pas ma spécialité. Mon collègue, quant à lui, est davantage spécialisé dans l'organisation de l'écosystème. Cependant, je m'implique de plus en plus dans ces tâches pour répondre aux besoins de notre équipe et c’est un sujet très intéressant et bénéfique pour notre métier. En tant que DesignOps / ResearchOps, c'est ce que nous faisons également au sein de notre équipe : Créer une culture et des valeurs communes, et nous insérer au mieux dans l'organisation. Il est courant de partir d’un modèle de maturité pour évaluer notre niveau actuel, faire un constat et un audit, puis planifier la progression vers des niveaux supérieurs. Pour ma part, j’ai une préférence pour le modèle de maturité de Jeff Sauro. Dans ce cadre, et encore plus lorsqu’une transformation globale de l’entreprise est en cours comme c’était le cas pour l’entreprise pour laquelle j’ai récemment travaillé, ce travail de cartographie des parties prenantes est particulièrement crucial pour identifier les obstacles qui peuvent entraver le développement de l’UX et qui peuvent nous ramener en arrière et qui, au contraire, va pouvoir être moteur dans ce développement et permettre de gagner en maturité. C'est là que la politique entre en jeu. Il est donc essentiel de trouver les bons sponsors et les bons leviers pour nous aider à avancer.
Quelques astuces et écueils à éviter Les must have pour préparer un atelier, c’est : Pour moi, tout doit être prêt avant que tu arrives en atelier, pour te faciliter la vie en animation et t’assurer de sortir avec les résultats que tu veux après l’atelier. Que tout soit calé en amont afin que le jour de l’atelier, tu sois plus qu’ en écoute et en facilitation est primordial, parce que ça va être ça le cœur de ton job. Les ateliers passent hyper vite, il faut que tu puisses accompagner les gens, ceux qui n’ont pas compris un point de consigne, que tu puisses bien écouter ce qui se dit pendant l’atelier et bien décrire tout ce qui s’y passe afin de le transformer par la suite. D’où l'importance que tout soit prêt et que tu arrives en atelier en ayant en tête ce avec quoi tu veux sortir de l’atelier, pour pouvoir réorienter au besoin. Une astuce si tu ne sais pas comment définir les objectifs de l’atelier, tu peux te poser ces questions : Ensuite, une dernière erreur à éviter c’est vouloir participer et être facilitateur en même temps de l’atelier. J’ai vu quelqu'un le faire et je pense que c’est très difficile comme posture, voire pas souhaitable. Parce que déjà, c’est extrêmement énergivore d’animer un atelier, alors vouloir faire l’atelier et en même temps d’accompagner les gens c’est vouloir faire 2 activités avec 2 objectifs différents en 1 fois. Tu ne peux pas diviser les groupes en sous-groupes (car tu participes). Donc lorsque quelqu’un n’a pas compris tu es obligé de réexpliquer pour tout le monde. Tu es moins adaptable à la situation, tu ne peux pas aller aider un groupe et laisser le tien de côté, donc tu ne peux pas ajuster le travail d’un groupe au besoin, et aider à prendre la bonne direction. C’est une posture trop complexe d’être engagé et détaché en même temps, le risque est de ne pas pouvoir mener à bien ton atelier et de Je le déconseille, il vaut mieux avoir une posture claire.
La logistique et le matériel sont souvent des éléments sous-estimés dans l’organisation d’une session de recherche, en particulier lorsque l’on débute. Et c’est d’ailleurs un des feedbacks que j’ai le plus de la part d’étudiants ou débutants, après l’organisation d’une première séance de tests. Le pré-test du matériel est essentiel, surtout si on utilise du matériel pour la séance (prototype, eye-tracking, caméras…). Il y a une fois où j'ai mené des tests utilisateurs et on n’avait pas vérifié le matériel en amont, la caméra ne fonctionnait pas et on n'a pas pu filmer la matinée de tests. Une situation comme ça fait perdre du temps de test, sans compter le stress que ça amène le jour J ! Il y a aussi toutes ces fois où l’on n’a pas assez testé le prototype, ou alors on a rajouté des choses en dernière minute sans tester. Un prototype ou un bout de prototype cassé, et tu peux perdre 5 ou 10 minutes de ton test, ce qui est énorme sur une session d’1h au final. Une autre erreur réalisée était cette fois sur la partie logistique de la session de recherche. Pour cette étude, c’est mon client qui s’était occupé d’organiser les rendez-vous, par soucis de facilité car nos utilisateurs étaient des employés de l’entreprise. Nous ne l’avions pas briefé sur le comment organiser des sessions de recherche, et notamment qu’il fallait prévoir un temps de pause entre chaque session. Et le quart d’heure minimum entre deux interviews ou deux sessions de tests, il est nécessaire ! Nous nous sommes donc retrouvés avec 4h d’interviews programmées à la suite, sans coupure, et chaque rendez-vous était dans une salle et à un étage différent du bâtiment. Nous avons couru entre chaque séance, et ce n’est pas du tout confortable, ni pour nous, ni pour la personne interviewée. Sans temps de battement entre deux rendez-vous, tu n’as pas de marge de manœuvre possible pour gérer les imprévus, les retards, t’installer pour accueillir la personne d’après, et switcher mentalement d’un participant à un autre pour commencer ta session de research “à neuf”. Je pense qu'on ne se rend pas assez compte quand on n’est pas user researcher ou quand on n’a jamais fait de recherche, à quel point la logistique est importante et chronophage. C’est quelque chose également que je souligne beaucoup quand on parle à des débutants, de ne pas négliger cet aspect qui prend quand même assez de temps de préparation parce que mener des séances de recherche c’est un exercice qui prend beaucoup d’énergie, qui demande de la concentration et qui peut être stressant, surtout quand on démarre. Si on peut éviter du stress logistique en plus du stress de mener la recherche, on gagne en sérénité. Donc vraiment préparer et anticiper au maximum, et faire des checklists c’est le secret de la logistique en user research.
Une erreur que j’ai pu faire, c’est peut-être de ne pas abandonner certains combats qui ne valaient pas la peine d’être menés dans des projets. Parfois, un projet rencontre des blocages. Les raisons peuvent être multiples, ça peut-être parce que vous êtes face à des enjeux politiques, parce que le projet vient contrecarrer une stratégie de l’un, empiéter sur le périmètre de l’autre, etc. Ça peut être aussi parce que les gens ne sont pas prêts au changement. Notre travail de designer amène ce type de situations. En concevant ou en optimisant des parcours et des outils, on va parfois amener des changements de process, de tâches, des périmètres,, etc. Et ça, les gens que vous avez en face de vous ne sont peut-être pas forcément prêts à le voir et à le savoir. On peut rencontrer de la résistance face à nous. Et face à la résistance et l'accompagnement au changement, il faut savoir choisir ses combats, car il y a des batailles qui ne valent pas le coup d’être menées. Soit parce qu’on est trop petit face à la situation, soit parce que ce n’est pas la priorité du moment. Tu peux aussi garder cette bataille dans un coin de la tête pour la ressortir plus tard. Parfois, ce n’est tout simplement pas le bon timing et il va falloir être patient pour pouvoir ressortir cet élément au bon moment. Les gens en face de toi ne sont peut-être pas encore prêts à recevoir cette information, il faut parfois savoir laisser le sujet ouvert et y revenir quelque temps après. Ou alors prendre un chemin détourné, en fonction de ce que tu souhaites faire passer, pour amener ta proposition d’une autre manière, la retravailler pour qu’elle soit mieux acceptée. C’est un type de challenge qui est intéressant parce que ça te force à retravailler ta stratégie d’approche, à être créatif pour te sortir des contraintes. Quand tu ne peux pas passer par la porte, parfois tu peux passer par la fenêtre ! Quelques observations pour détecter lorsque les gens en face de toi ne sont pas prêts à aborder ces thématiques : Lorsque la situation se débloque, tu le vois :
Il fut un temps où j'avais tendance à adopter un comportement qui finissait par me décevoir. J'avoue être parfois un peu flemmard. Bien que j'aime fournir les efforts nécessaires, il m'arrive parfois de chercher des raccourcis. Quand j'étais plus jeune, j'espérais trouver des astuces pour simplifier certaines choses. Je pensais qu'il y avait des raccourcis pour atteindre mes objectifs. Cela était étroitement lié à l'idée de patience. Mais j'ai rapidement appris à mes dépens qu'il n'y a pas de raccourcis. Parfois, il en existe, mais généralement, ils ont un coût caché. Ce coût n'est pas immédiatement perceptible. Au final, ce que tu penses économiser en termes d'efforts se transforme souvent en leçons que tu apprends plus tard. Tu réalises que ces efforts étaient nécessaires pour réellement avancer. Je ne veux pas être dogmatique, mais je pense qu'il y a une vertu dans les efforts que nécessitent certaines choses. Au début de ma carrière, je souhaitais avoir plus de responsabilités que ce qui m'était confié, car je pensais que c'était le seul moyen de faire ce que je voulais réellement faire. J'avais cette idée idéale selon laquelle si j'avais le pouvoir de décision, qui était lié à la responsabilité, je pourrais réaliser mes aspirations. Cependant, il est biaisé de penser que la responsabilité entraîne automatiquement le pouvoir de décision. Ce n'est pas toujours le cas. J'étais en quête de ce pouvoir de décision à travers la responsabilité. Cette impatience m'a poussé à parfois aller trop vite. À cette époque, je n'étais pas encore orienté vers la conception d'interfaces ou de solutions numériques, mais plutôt vers la conception de produits physiques et l'architecture. J'espérais pouvoir travailler rapidement sur des projets qui m'intéressaient, alors j'ai accepté de collaborer avec des personnes dans l'espoir d'acquérir cette capacité de prendre des décisions qui m'intéressaient. Finalement, cette volonté d'aller trop vite m'a mis en relation avec des personnes qui, rétrospectivement, n'étaient pas les plus fiables. Ce n'étaient pas des individus recommandables avec qui travailler. Ils avaient l'expérience de lancer de nombreux projets et initiatives pour collecter des fonds, mais ils ne parvenaient jamais à les concrétiser. Cela m'a placé dans des situations problématiques. Lorsque tu es jeune et étudiant, tu peux t'en sortir. Mais lorsque tu commences à te poser, à être en couple et à réfléchir à l'avenir, tu ne veux plus vivre ce genre de situations. Cela change ta perspective. Pendant de nombreuses années, j'ai également dirigé une agence de communication où j'acceptais des clients car leurs projets semblaient faciles à réaliser. Cependant, ces clients ne savaient pas toujours ce qu'ils voulaient, ce qui aboutissait à de nombreux allers-retours et à une course après les paiements. À ce moment-là, tu te demandes si tout cela en vaut réellement la peine. Qu'est-ce que cela t'a apporté ? Plus de problèmes que d'avantages, malheureusement. Finalement, tu apprends. Tu te rends compte que ce genre de situation n'est pas une bonne stratégie. Je vois maintenant que cette recherche de facilité, parfois associée à l'idée de prendre des décisions, s'est retournée contre moi. J'observe également cette erreur chez d'autres personnes plus jeunes dans la profession avec qui je discute. Je ressens l'impression qu'ils doivent faire ces erreurs eux-mêmes pour en tirer des enseignements réels. On peut dire ce que l'on veut, mais j'ai également reçu les mêmes avertissements et conseils. Malgré cela, j'ai agi selon ma propre vision. J'ai subi les conséquences nécessaires pour apprendre. Est-ce si grave que ça ? Parfois, cela peut être grave lorsque cela te met réellement dans une mauvaise situation. Je dirais que c'est dommage. Si c'est évitable, c'est vraiment regrettable. D'une certaine manière, tu apprends. Parfois, tu dois faire tes propres expériences pour comprendre ce qu'il faut faire et ne pas faire.
Lien du deck. Lien du post Linkedin et comments 
Un projet qui m’a marqué dans ma carrière fut celui d’une refonte de site qui s’est “mal passé” et qui a marqué un tournant dans ma manière d’approcher les projets. La situation de départ était assez positive: Il y avait des gros problèmes d'engagement, il fallait répondre à 200 questions, et dans ces questions, il y avait une sorte d’auto-audit sur tes pratiques professionnelles etc. Bref, ce n’était pas fun. Les gens ne le faisaient pas. Donc on a vraiment passé beaucoup de temps à travailler sur la refonte du site Web et voir ce qu’on peut améliorer. Les échanges qu'on a pu avoir avec à la fois les utilisateurs potentiels et des partenaires sur le sujet ne collaient pas avec l’objectif du site. En réalité les gens n’avaient pas le temps, et encore moins le temps au moment où ils devaient l'utiliser. Du coup, un point que les utilisateurs et les partenaires nous ont remontés était qu’il y avait beaucoup de gens qui avaient envie de se former sur le sujet de l'auto-évaluation. On a donc orienté ce besoin-là et on a proposé des choses autour de l’apprentissage gamifié pour que les pros puissent se former dans la durée. Ainsi, quand ils arrivent au moment où ils ont besoin /envie de s’autoévaluer, ils ont déjà toutes les connaissances. Sauf que, notre client n'avait pas du tout suivi le sujet. Ce qui s’est produit c’est qu’il a même complètement rétropédalé sur d’autres suggestions qu'on avait pour améliorer l’expérience utilisateur et donc sur l’auto-évaluation où nous avions beaucoup investi. Au final, on a dû faire une quasi-refonte à l'identique du site Web, alors qu’on avait passé un temps incroyable à repenser le projet pour qu'il soit plus performant et engageant. Cet épisode m’a forcé à revoir le processus de travail avec ce client. Aujourd'hui pour éviter que cette situation se reproduise j’ai quelques pistes mais c’est encore un sujet où je ne suis pas encore parfaitement certain. (donc ouvert à vos suggestions dans les commentaires) Une piste que je développe beaucoup, sont les ateliers collaboratifs . Ça réduit vraiment les risques de perdre la confiance du client. De façon plus spécifique sur la gamification, mon jeu de cartes les Gamifi’cartes (un jeu d’idéation avec des contraintes sur la gamification) aide vraiment les néophytes à avoir des idées de gamification, et donc ils se les approprient également beaucoup plus. C’est vraiment rare de faire un projet sans les utiliser avec nos clients désormais.
Une grosse erreur que j’ai aussi faîte, c’était il y a 6 ans chez Ooreka où il y avait un beau projet et j'avais encore ce truc de : “C’est moi qui suis en lead design, je sais ce qui doit être fait point de vue design.” On a vachement parlé sur le projet avec les PO, les PM, on était chauds. Il y avait des personnes qui étaient essentielles dans le projet. Les rédacteurs, parce que Ooreka c’était majoritairement de la rédaction. (Le site maintenant il est mort. Il est encore là, mais en fait, il n’y a plus l’équipe qui bosse dessus, il n’y a quasiment plus personne. Ils laissent vivre le contenu. Mais c’était un très beau projet à l’époque.) Mon erreur ça a été de penser que le design n’était que l’affaire du designer et ne pas voir cet aspect, d’idéation et de collaboration. C’était de dire : “Je suis designer, c’est mon affaire à moi. (le PO à la limite.) Vous vous êtes rédacteurs et votre tâche c’est de faire de la rédaction. “ Je n’ai jamais mis en place cet aspect de : “On co-construit ensemble, les rédacteurs sont des designers, eux aussi ils ont leurs trucs à donner.” On a trop poussé une version, dont nous étions super contents et il y a eu des clashs avec les rédacteurs. On conservait un peu notre position un peu hautaine, dédaigneuse, tout le temps : “Rédigez quoi, vous êtes rédacteurs.” En retour ils me disaient : “C’est pas comme ça que ça doit être fait.” Et on a fait la sourde oreille. Finalement, tout cela m’a ouvert les yeux et cet aspect de collaboration, de co-conception maintenant c’est essentiel. Il faut vraiment mettre tout le monde à fond. Notre taff, c’est de demander toutes les idées et de prendre celles qui sont bonnes, d’un point de vue ergonomie, d’un point de vue design, et pas faire du consensus, mais arriver à amplifier la richesse de toutes les propositions et des besoins de chacun en un design qui surpasse les attentes. Ne pas se dire que le designer c’est notre affaire à nous le design.
Par exemple, une erreur parcours que j’ai réalisé c’est lorsque que j’ai commencé dans une boîte et après je me suis dis: “Merde, je n’ai rien à faire là” Je suis allé bosser dans des boîtes sur des projets qui finalement ne me ressemblaient pas du tout. J’y suis allé parce que j’étais attiré par le poste ou par le salaire, et finalement une fois dedans, le projet en lui-même ne me bottait pas plus que ça. L’ambiance ne me bottait pas tant que ça. Il y a des trucs que je ne peux pas découvrir juste avant les entretiens. Mais tu vois, rien que le projet, je savais que ça ne le faisait pas. Du coup, un des trucs c’est ne pas aller quelque part pour le salaire ou l’intitulé du poste. L’important c’est le projet et l’équipe. C’est pour eux que tu te lèves tous les matins, si ca ne va pas avec l’un ou l’autre alors le travail ne sera pas plaisant. Donc l’apprentissage que j’ai de cette expérience c’est de prendre du temps pour se faire sa feuille de route personnelle, et de prendre du temps pour se faire un persona de soi-même (par exemple ). Prendre du temps régulièrement aussi pour se dire : Par exemple : “Sur les X années qui sont passées, ça, je ne veux plus jamais le vivre. “ Ce type de situation, je ne veux plus y être, ce type de projet, ce type de futur. Au fur et à mesure, donc au début forcément c’est compliqué de le faire au début quand on est junior on peut se dire ouais, voilà le genre de choses vers lequel je veux aller, et voilà le genre de choses que je ne veux pas aller, et au fur et à mesure on commence à se dire voilà les choses que j’ai aimées et les choses que je n’ai pas aimées. Je pense que c’est essentiel, au fur et à mesure de se dresser sa cartographie, comment est-ce qu’on veut évoluer dans cette carrière. Par exemple quels sont les boulots sur lesquels on doit aller, où on ne doit pas aller. Au moins ça, ça permet de sentir à un moment qu’en tant que free, on est surexposé à ça parce qu’avec toutes les missions qui nous arrivent, les propositions et tout, il y a des moments où tu sens le truc. Tu te renseignes un peu sur la boîte, tu as un premier entretien, tu sens qu’il y a un truc qui ne passe pas. Tu te dis, “ Je ne peux pas y aller.” Mais si on n’a pas fait ce taff de profiling avant, je trouve que c’est beaucoup plus compliqué à sentir. Donc quand tu as tout le profiling qui a été fait, que tu as posé plusieurs fois ces questions tout le long de ta carrière, au bout d’un moment, les projets arrivent, tu les vois et assez rapidement tu te dis : “Ouais, ça, c’est un projet pour moi.” Tu le sens, il y a cette valeur, cette valeur, que je retrouve par rapport à cette proposition-là que j’avais avant. Ou alors tu te dis : “Ça, ce n’est pas pour moi. Il y a des designers qui se plairont dans ce type d’ambiance, dans ce type de projet, ben je leur laisse. “ Surtout, ne pas avoir peur justement de dire non à des projets, et même à des postes. Si quelqu’un cherche vraiment une boîte, ne pas forcément sauter sur le premier truc, ne pas avoir peur de dire non parce que plus tard, quand on a de la chance, on nous proposera vachement de taff. Donc si au début tu te dis : “Il faut vraiment que je saute sur un truc” peut-être qu’il vaille mieux de dire non pour attendre ce qui arrive derrière. Dans la même veine, une dernière chose que je voudrais préciser: il ne faut pas avoir peur de partir d’un projet / boite. J’ai vu des gens extrêmement doués, des ergo qui étaient géniaux en termes de communication et de compétences partir en burn out, ou vivre avec le syndrome de l’imposteur au point que ça en détruise leur vie. Tout ça pour une peur de partir de l’entreprise, alors que les signaux étaient là. Donc si cela vous arrive, n’hésitez pas à partir, vous retrouverez un meilleur endroit.
Il y a eu plein de problématiques, mais je crois que ça a été pour moi l’un des plus beaux défis, et surtout de réussir à le relever, à faire en sorte que tout le monde soit content à la fin. C’était pour un gros site vitrine, qui présentait la marque. Pour présenter la marque, il fallait forcément quelque chose de très qualitatif, luxueux, avec – je déteste ça mais pour le coup, c’était exactement la demande - créer un effet « Waouh ». Ils étaient vraiment dans ce truc-là. Il fallait un site très beau, très épuré. Ils étaient typiquement dans le fameux “texte gris clair sur blanc” que beaucoup trouvaient très élégant mais qui est illisible. On a réussi, on a répondu à leurs demandes en étant accessibles ! Finir par y arriver, rien que ça, c’est déjà super gratifiant. Ce que j'adore sur des projets comme ça, c’est qu’il y a des défis. C’est beaucoup plus intéressant. Plutôt que des projets où il n’y a pas de débats, donc pas défi, sans grosse recherche de solution derrière. J’aime bien devoir dénouer, identifier comment on va faire pour correspondre à tous les besoins, c’est plus intéressant. Pour le coup, je pense que c'est avec ce projet-là justement que j'ai appris la nécessité de sensibiliser et de former. Au départ, il était difficile de trouver comment aborder les équipes. Il a donc fallu que je trouve des moyens pour pouvoir discuter avec eux, en faisant en sorte que la discussion soit agréable et constructive. Ce projet-là m’a permis d’évoluer dans ma façon de faire. Avec eux, je testais des choses que je n’avais pas trop faites avant. Il y a certains trucs qui n’ont pas marché. Par exemple, j'avais eu l'idée de partir dans un atelier audit et co-conception – je n'avais pas fait de sensibilisation et de formation au préalable, rien. Sauf que, quand les gens ne sont pas formés aux sujets, c’est compliqué de travailler dessus. Il faut savoir que la plupart des gens n’aiment pas faire de l’audit. Déjà, je partais sur un truc pas hyper glamour, sur un sujet, l’accessibilité, qu’ils ne connaissaient pas et sur lequel ils avaient des à prioris. Et en plus, ils auditent eux-mêmes, ils voient qu’ils ont fait des erreurs mais ils ne comprennent pas trop pourquoi c’est une erreur parce qu’ils n’ont pas été formés, pour eux c’est la bonne manière de faire. Bref, en tant que consultante, ça, c’est typiquement une erreur. Avant de lancer ce type d’ateliers, il y a des choses à faire pour que ça se passe bien. Ça m’a pris un peu de temps pour le comprendre mais je pense qu’il faut le prévoir, ce temps en amont. Aussi, ce que je ne faisais pas forcément, et c’est la deuxième erreur que je faisais et que je veux rectifier : Prendre le temps Qu’il va y avoir justement de discussion et d’appropriation des équipes. Quand on arrive avec un nouveau sujet, un sujet que les équipes ne connaissent pas, on ne peut pas se dire qu’on va tout révolutionner en une semaine. Il est important de faire comprendre aux équipes ; ne pas débarquer avec les référentiels, par exemple ; en tout cas moi c’est ma manière de faire. Je ne débarque pas avec les WCAG ou les RGAA , qui peuvent paraître être l’Everest. Quand on ne connaît pas, c’est hyper abstrait. Souvent à la fin des formations que j’anime et où l’on a vu plein de choses à faire autour du numérique responsable, je fais un petit atelier : je leur demande « On a vu tous ces critères, chacun si vous en retenez 3 à appliquer dès le demain, vous prenez quoi ? » Chacun sélectionne, et en fait, que je leur propose de mettre en place dans leurs prochains projets et 1 mois, 2 mois plus tard etc je leur demande d’en prendre 3 de plus. Avec cette méthode-là, on sait qu’on ne va pas changer le monde. En revanche, on sait qu’au fur et à mesure, les équipes vont prendre en compte les choses, ça va entrer dans leur process, ça va devenir automatique et ça va se retrouver dans tous les projets après. Finalement, l’impact sera beaucoup plus important, parce que ce ne sera pas juste sur un projet donné mais sur tous projets futurs. On aura pu faire en sorte que chacun s'approprie ces sujets. C’est ce qu’on dit souvent en tant que consultant : « le jour où on n’aura plus besoin de nous, ce sera le rêve ». On en est loin, mais c’est la meilleure des perspectives.
Une erreur que j’ai faîte est au niveau du métier de consultante : c’est de ne pas assez prendre en compte la question de la perception des équipes quand j’arrivais sur une nouvelle mission. Très souvent, on me demande de venir à la fin des projets, quand on se rend compte que le site ou que l’appli n’est plus accessible. En caricaturant un peu, avant j’arrivais avec mon audit et son lot de corrections, les équipes entendaient alors en gros « Vous avez mal fait votre boulot. ». Au début, j’avais du mal à comprendre la résistance que cela créait : On faisait appel à moi. Donc si vous faites appel à moi, c’est que vous avez conscience qu’il y a des choses à améliorer. En réalité, c’était le N+1, le N+2, le juridique, le commercial ou autre qui faisait appel à moi, pas l’équipe. Eux, on vient leur imposer quelqu’un d’externe, donc qu’ils ne connaissant pas, quelqu’un qui ne connaît pas leur projet et ses difficultés et sur un projet qu’ils pensent terminé. Je suis alors “ la méchante inspectrice des travaux finis “. Je déteste maintenant intervenir à la fin des projets, et pour le coup, si vraiment ça doit être le cas, il y a une manière de s’adresser aux gens. Vous n’allez pas leur dire « Vous avez fait un mauvais boulot. ». Ce n’est pas ça, plutôt : C’est que vous n’avez pas été sensibilisé, vous n’avez pas été formé, on va y travailler ensemble. Je fais le parallèle avec par exemple le GRPD, le respect des données : ça, il n’y a pas longtemps, très clairement, tout le secteur ne le prenait pas en compte. C’est la même chose. À un moment donné, il y a une manière de faire pour respecter le GRPD, et il y a une manière de faire en sorte que les personnes en situation de handicap notamment puissent naviguer sur le web. Tant qu’on n’y est pas confronté, tant qu’on ne dit pas qu’une personne non-voyante peut naviguer sur le web, on ne peut pas le prendre en compte. Rien que de passer par cette étape de leur faire comprendre à qui on s'adresse quand on fait d'accessibilité, ça permet d’engager une meilleure collaboration avec une équipe. Leur faire comprendre comment les personnes en situation de handicap vont naviguer avec le Web. Déjà, c'est beaucoup mieux perçu et du coup, ils voient tout de suite l'intérêt. Leur faire comprendre l’intérêt, je pense que c'est essentiel. Mais aussi apprendre, être formé. Dans la plupart des cursus (école, université), il n’y a pas ou très peu de cours sur les sujets du numérique responsable, de l’accessibilité et l’assurance qualité… et quand il y en a c’est très récent. Et enfin, tant qu’on peut, faire appel aux consultant·es de ces domaines, le plus tôt possible dans les projets, même avant les projets, pour avoir un vrai accompagnement. Pour éviter ça aujourd’hui, je fais de cette manière : Déjà, ils comprennent que je ne suis pas du tout là pour leur taper sur les doigts, ni dire qu’“Il y a tout ça qui ne va pas, tout ça à corriger.”. On apprend à se connaître, aussi, et mine de rien, par la suite quand ils me voient arriver avec mes demandes de corrections ça passe beaucoup mieux. Dans ces moments-là, très souvent, il y a beaucoup d’échanges d’expériences des participant·es : « Moi, j’ai tel problème, j’ai un petit cousin, un copain, mon oncle, ma tante, … qui a tel handicap, tel difficulté... ». Et en fait oui, on va bosser pour eux, pour toutes ces personnes qui se sentent parfois ou souvent exclues. Rien que ça, ça motive tout le monde, c’est une bonne raison pour travailler ensemble. J’aime sensibiliser, j’aime discuter avec les équipes. Ensuite, je passe aussi par des petites formations, métier par métier (UX, UI, Dev, rédacteurs, marketing, …), courtes ou plus longues (en général d’une demie-journée à 3 ou 4 jours), que l’on peut caler au début de mon intervention mais aussi en cours de production. Autant que possible, les durées et déroulés de ses formations se déterminent en fonction de mon analyse de projets qu’ils ont fait avant. C’est avec tout ça que je peux enfin accompagner plus sereinement les équipes et pour ça je me base là aussi sur l’analyse du projet : Ça permet de leur dire que « OK, vous faites déjà plein de choses bien, je vous accompagne à améliorer ». En utilisant cette méthodologie, on se base sur les équipes et on leur permet de capitaliser : on va améliorer à l’instant T pour ce projet, mais ça leur permet ensuite de réutiliser ces pratiques sur les suivants. On est dans l’accompagnement et non pour leur dire « Il faut corriger tel truc à tel endroit »
Un conseil que j’aurais voulu avoir plus tôt serait de me faire un peu plus confiance et de plus suivre mon instinct au lieu de vouloir rentrer à tout prix dans des petites cases, certes, elles peuvent être très rassurantes, mais au final elles peuvent aussi freiner nos envies. Un exemple : je suis en situation de handicap, je suis malvoyante. Tout le long de ma scolarité, j’ai entendu quelques profs et certains médecins (heureusement ce n’était pas du tout la majorité) dire : Pour l’anecdote, finalement j’ai fait un Master. À force d’entendre ça, j’avais intégré le fait que ce serait difficile pour moi, que la seule voie viable était d’être salariée en CDI, que je n’aurai jamais un métier stable et que si une entreprise me proposait miraculeusement un CDI, il fallait que je l’accepte sans me poser de question : le CDI c’était mon Graal. Au fond, je suis entré dans ces petites cases en acceptant des postes stables et en sécurité mais je me suis éloignée de ce que je voulais faire. Surtout dans un poste en particulier, les missions étaient correctes mais l’entreprise en elle-même, ses valeurs, ses façons de travailler... ne me correspondaient pas. Je l’ai senti dès le premier jour. J’ai commencé à m’interroger sur ces questions à l'issue de mon Master, je voyais tout le monde partir dans plein de voies différentes que je n’avais même jamais envisagées possible pour moi. J’ai alors commencé à me dire : « Être indépendante, ça peut être sympa aussi », mais j’avais peur, je me répétais « Jamais tu vas y arriver, jamais tu ne vas trouver des clients » Et puis le déclic c’est fait alors que j’étais en CDI, donc en sécurité mais dans cette entreprise où je ne m'épanouissais pas. Des boîtes et des écoles m’ont contacté pour me demander : « Par hasard, tu n’aurais pas un statut Free ? On a besoin de quelqu'un pour animer des formations ». Au fur et à mesure, j’ai eu plus de demandes alors que j’étais toujours en CDI. J’ai fini par me dire : « Pourquoi ne pas me lancer ? ». J’ai sauté le pas et finalement, c’est la meilleure décision que j'ai prise de ma vie pro !
L'une des erreurs que j'ai commises en tant que freelance était de croire que je devais absolument être copywriter ou rédactrice classique. À l'époque, l'UX writing n’était pas encore aussi connu qu’aujourd’hui, donc je n'avais pas vraiment pris le temps de réfléchir et de visualiser toutes mes compétences, tout ce dont j'étais capable et tout ce que j'aimais faire. Après avoir quitté Booking à la suite d'un burn-out, je me suis lancée en freelance. Je manquais d'imagination et d'énergie pour être créative. Je pensais devoir me conformer à un moule déjà existant, alors qu'en réalité, en startup, il n'est pas nécessaire d'avoir une idée géniale que personne n'a jamais eue. C'est bon signe quand d’autres font ce que vous faites, car cela signifie qu'il y a un marché. Mais il ne faut pas avoir peur de faire quelque chose de nouveau si c'est ce que l'on aime et dans quoi on est compétent. Je pensais vraiment devoir faire du copywriting freelance, rédiger de longs textes marketing, alors que je savais que je n'aimais pas ça. Très rapidement, je me suis rendue compte que j'acceptais des missions qui ne me faisaient pas avancer et ne me plaisaient pas. En conséquence, je n'étais pas heureuse, je ne me sentais pas très compétente et je n'avais pas fixé des tarifs élevés. Cependant, j'ai vite réalisé que je devais changer de cap et me dire : J'ai pris les choses en main et je me suis dit : "Qu'est-ce qui me plaît vraiment ? C'est l'UX, c'est travailler avec les gens, l'aspect humain". J'ai simplement commencé à en parler à tous ceux que je connaissais, sans nécessairement avoir un titre ou une définition précise de ce que c'était, ce qui est une autre étape. J'ai parlé de mon expérience à mes amis, à d'anciens collègues, à tout le monde, en disant : "Je suis freelance, j'ai du temps et je recherche des clients". Souvent, quand on débute, on a l'impression de devoir donner l'image d'une personne surbookée, que tout va bien et qu'on n'a jamais de problèmes de clients ou de temps libre. Mais ce n'est pas agréable en réalité. Donc, lorsque l'on dit : "Oui, je suis une professionnelle très compétente et en ce moment, j'ai du temps, je cherche des clients", les clients viennent vers nous parce que nous sommes disponibles. Je pense que l'honnêteté consiste à rester fidèle à ses valeurs, c'est vraiment l'aspect le plus important. Je suis allée sur Google et j'ai recherché "UX writer freelance", mais je n'ai pas trouvé grand-chose. À l'époque, ce domaine n'était pas très connu, et j'hésitais donc à me lancer. En prenant le temps de me lancer et d'oser, j'ai découvert que l'UX writing existait bel et bien, et qu'il y avait une réelle demande pour ce domaine. Parfois, il suffit simplement de changer de vocabulaire ou de voir les choses sous un nouvel angle. J'ai l'impression que c'est une question de mots. Parfois, nous nous retrouvons avec des métiers très novateurs, et nous ne savons pas quel terme utiliser pour les décrire. Nous nous enfermons dans une terminologie spécifique, comme l'UX writing par exemple, alors que finalement, ce n'est pas l'étiquette qui importe le plus. Ce qui est vraiment important, c'est de comprendre ce que les gens recherchent et de pouvoir dire : "Oui, j'ai les compétences nécessaires, peu importe le libellé qu'on leur attribue." Il est essentiel de rester ouvert(e) d'esprit et de ne pas se limiter à des catégories strictes. En comprenant les besoins réels des clients et en adaptant notre discours en conséquence, nous pouvons démontrer notre valeur et notre expertise, peu importe les termes utilisés dans l'industrie. L'essentiel est de se concentrer sur les compétences que nous possédons et sur notre capacité à répondre aux attentes des clients. En adoptant cette approche, nous avons plus de chances de réussir et de trouver des opportunités qui correspondent à nos aspirations professionnelles.
Une autre erreur que j'ai commise dans ma carrière est d'avoir minimisé ma contribution à certains projets. Je n'ai pas clamé haut et fort que j'étais à l'origine de ceux-ci. En fin de compte, je n'ai pas reçu beaucoup de reconnaissance pour ces projets, à part de la part de personnes proches de moi dans l'entreprise. Au sein des équipes qui ont ensuite utilisé l'outil que nous avons créé, je n'ai pas eu l'impression d'être reconnue pour cela. Je mentionne cela, car à cette époque, les UX writers étaient moins bien rémunérés que les autres. Les choses ont beaucoup changé depuis, mais j'ai ressenti un manque de reconnaissance et, en même temps, je n'ai pas non plus beaucoup vanté mes réalisations. Malheureusement, dans ce type de structure, il est nécessaire de mettre en avant nos succès pour obtenir de la reconnaissance, et cela m'embête. Mais il faut se faire remarquer pour ne pas être invisible. En ce qui concerne la reconnaissance, mon conseil serait de bien documenter ce que vous faites, d'écrire l'histoire de vos projets. Prenez le temps de documenter les projets qui vous tiennent à cœur, ceux que vous trouvez intéressants. Parce qu'avec le temps, on oublie, on a du mal à se souvenir des différentes étapes, et il devient difficile de répondre à un manager qui demande ce que vous avez fait ces trois derniers mois. Une bonne documentation fournit une base solide pour justifier votre travail par la suite. Dans chaque entreprise, il y a un système de feedback, et la plupart du temps, nos managers ne sont pas du même domaine que nous et ne comprennent pas forcément les détails de notre travail. Une bonne documentation facilite les choses. Personnellement, j'aime tout ce qui est partagé. Je pense que cela a beaucoup de valeur. Il n'y a pas de secret professionnel dans notre métier (hors data confidentiel), car plus nous partageons, plus nous avançons, tout simplement. Il est donc essentiel de partager. Vous pouvez envoyer une newsletter à vos collègues une fois par mois, mais surtout documentez vos projets et partagez-les en interne. Si vous collaborez avec d'autres personnes, partagez avec elles, en particulier si elles ne sont pas du même domaine que vous. Cela peut les inspirer et ce projet peut prendre une autre dimension. Il y a une vie après. Ensemble, nous pouvons aller plus loin. Finalement, je trouve que c'est une bonne chose, car nous pouvons partager avec l'intention de collaborer, et cela nous donne également de la visibilité sans avoir l'impression de nous vanter pour obtenir une récompense. L'intention n'est pas la même, mais au final, la visibilité est créée. Donc, c'est une situation bénéfique. Dans l'UX writing, de nombreuses personnes disent : En racontant nos projets et en partageant davantage, cela contribue également à une meilleure compréhension de notre métier et de notre démarche.
Pendant des années, notre page de conditions d'annulation de vente était un véritable cauchemar. Elle avait été conçue par un développeur non anglophone et traduite en 43 langues, ce qui rendait son utilisation très complexe. L'équipe locale devait sélectionner manuellement plusieurs conditions et les introduire dans le système en utilisant des bouts de phrases pré-établies. Comme c'était automatisé, cela créait des erreurs et des confusions en cascade. Je détestais cette partie de la page et j'ai décidé de m'en occuper personnellement. J'ai travaillé avec un collègue pour automatiser le système et le rendre plus convivial. Nous avons décortiqué l'outil et avons créé des blocs de phrases pré-établies pour chaque langue, que nous avons appelés des "Lego linguistiques". Nous avons travaillé avec les 43 équipes de langues pour nous assurer que tout avait du sens. Le résultat était incroyable et nous avons pu faire des AB tests sur tout le site. C'était un projet dont j'étais très fière. Cependant, j'ai sous-estimé l'impact que ce projet "extra" allait avoir. Je n'avais pas prévu le temps et la pression qu'il allait nécessiter, ni le nombre de "stakeholders" impliqués. Au début, c'était juste un petit projet personnel que nous faisions sur notre temps libre. Tant qu'il n'était pas priorisé, j'ai dû solliciter les gens en leur demandant de travailler sur des tâches qui n'étaient pas prioritaires, ce qui n'est généralement pas accepté. Mais rapidement, trois équipes ont vu ce que nous avions fait et ont réalisé qu'ils en avaient vraiment besoin. Nous avons dû changer complètement notre façon de travailler, ce qui a été particulièrement difficile à gérer. J'avais déjà la responsabilité de nombreuses autres équipes et des priorités multiples, et cela a provoqué une véritable explosion de stress. Honnêtement, je considère que mon erreur principale a été de sous-estimer l'impact en termes de temps et de pression que ce petit projet allait engendrer. Cependant, j'ai tiré quelques leçons de cette expérience qui auraient pu m'aider à mieux la traverser : Au final, ces moments difficiles font partie intégrante de notre croissance professionnelle. En rétrospective, je ne changerais rien à cette expérience, car elle m'a permis de mûrir et d'apprendre.
Les erreurs à éviter lors de l'organisation et l'animation d'ateliers sont d'éviter de se laisser influencer par les différents parties prenantes sur votre protocole d'animation, ainsi que de bien définir un seul rôle d'animateur. Je m'explique: La trame, le déroulé et le process que je mets en place, je les soumets au commanditaire : En général, il me dit que c'est super. Cependant j’ai vécu des expériences moins fluides. Récemment avec un intégrateur qui faisait aussi du Design thinking. Je voulais l'intégrer pour encore une fois gagner du temps, impliquer dès le départ puisque justement, il croyait y beaucoup. Il se disait mi UX, mi intégrateur. Je trouvais cela intéressant. On anime ensemble pour que je puisse faire un peu le gendarme expert créa et UX et que lui puisse dire attention, ce qu’on est en train de co-créer, c’est super, mais ça ne rentrera jamais dans le budget qu'on a annoncé initialement. Donc, c'était un peu comme ça que j'imaginais. Et malheureusement ça ne se passe jamais comme on l’imagine, il m'a fait faire des exercices (au dernier moment) auxquels je ne croyais pas. Mais par respect de cette collaboration, j’ai cédé, encore une fois. Ça s'est mal passé. Je voulais vraiment que le groupe puisse s'entendre autour d’un seul et unique prototype à la fin. Or, il les a monté les uns contre les autres en leur demandant de créer 2 versions.. Le challenge peut être intéressant de mettre de la compétition entre les équipes. Simplement, en se retrouvant avec deux propositions, il fallait voter, avec des problèmes, de susceptibilité et de hiérarchie, sans parler du temps que cela prend. Ça a été finalement un échec pour moi. Il a fallu que je fasse moi-même un seul prototype à partir de deux, en ménageant la chèvre et le chou. Ma solution ? Je crois qu'il faut bien se répartir les rôles. Si c'est moi qui anime un atelier en tant que lead, alors je suis responsable du déroulé, et c'est moi qui peux à la limite rebondir si je crois qu’on passe trop de temps sur quelque chose et, qui va justement ne pas forcément tout suivre, mais au contraire improviser. L'improvisation, c'est difficile à 2. On peut être amené à se contredire, et apporter de la confusion envers les participants.. En fonction des expertises, bien déterminer les rôles et les types d'ateliers. Là, on n’a fait qu’un, mais si j'avais eu à refaire, je me serais davantage imposée sur le déroulé, sur lequel j'avais bien planché pendant au moins deux jours et je lui aurais laissé peut-être une demi-journée supplémentaire pour challenger, confronter, techniquement, qu'est-ce qu'ils auraient été capables de faire? On l'aurait pensé à deux, mais sur deux temps différents.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs etc sur la Vision de l'enfant.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la vision de l'adulte.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la basse vision.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la vision et le sport.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la situation réglementaire et juridique de notre domaine.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur le travail et la vision.
Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la prévention.
Groupe pour échanger et s'entraide sur le sujet des solutions optiques.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, et retours d'expériences sur la facilitation d'ateliers, de réunions.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet de la stratégie UX.
Un groupe pour fédérer tous ceux qui enseignent l'UX afin de partager vos questions ressources et astuces.
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet du management d'équipes UX.
