
- Même problème
- Déjà posée plusieurs fois
- Pas sûr
Je pense que j'observe pas mal le niveau d'ouverture des gens avec qui je collabore. Ça se voit immédiatement quand quelqu'un est très directif, du style "Je veux que tu fasses ABC et c'est tout. Je ne veux pas savoir ce que tu penses de D". Ça se ressent très vite. Si tu peux estimer,peut-être sur un spectre, l'ouverture des gens avec qui tu travailles, c'est un très bon début. Il faut savoir où tu te trouves si tu veux bouger. Puis par la suite, savoir ce qui est important pour ces gens-là. Je pense que l'idée, c'est toujours d'apporter de la valeur dans un premier temps. Si tu apportes de la valeur, les gens ont l'impression que tu peux transposer ce même exercice à un autre sujet. C'est comme des stars qui deviennent connues en chantant et qui font une marque de vêtements. Pour une raison ou pour une autre, c'est crédible pour les gens qu’ils sont compétents aussi dans ce domaine. C'est un biais que l'on a mais dans un premier temps je pense qu'il faut déjà bien faire, peut être avec le peu que tu as et ensuite demander : "Est-ce que vous êtes satisfait avec ce que je fais là ? Je pense que je pourrais être encore plus utile sur tel ou tel sujet". Sincèrement, c'est ma façon d'approcher le truc. Vraiment, sans sournoiserie, sans manipulation. J'essaye vraiment d'aider. Quand c'est sincère et quand c'est présenté comme ça, les gens te voient moins comme quelqu'un de louche ou qui cache des choses. Je pense que je peux aider et que ce serait du gâchis de ne pas m'écouter, en tout cas même deux minutes sur telle ou telle chose. D'expériences en expérience tu as ces parties que tu grappilles pour avancer. Mais je pense qu'il faut vouloir aider. Il faut être sincère et vouloir être utile. C'est un état d'esprit qui doit t’animer ! Et il ne faut pas se laisser être emporté dans la direction du vent.
Il y a un exercice incontournable que je réalise à chaque projet et qui a une valeur inestimable. Je suis entrain d’écrire un article justement à ce sujet, donc j’essaierai d’être clair et concis, puis je joindrai un lien vers l’article complet si nécessaire. Cet exercice est une version modifiée du KWHL Chart. Un tableau utilisé en phase préparatoire de recherche pour mettre à plat ce qu’on sait ( Know), ce qu’on veut savoir ( Want), comment nous allons l’apprendre ( How), et pour finir ce que nous avons appris ( Learned). C’est plutôt simple, dans un premier temps, je vais collecter de la donnée secondaire (données existantes, effort de recherche précédents et leurs apprentissages, …) Après avoir consommé cette donnée, je vais faire un bilan sur ce que l'on sait, ce que l'on ne sait pas, j e vais essayer de le faire avec toutes les personnes impliquées dans le projet. Le fait de dire à voix haute ce qu’on sait et ce qu’on ne sait pas, injecte une bonne dose d'humilité dans l’équipe. A partir de ce moment tout le monde part sur un même pied d'égalité, et on peut admettre les choses qu'on ne connaît pas, sans peur d’être jugé. Ce bilan de connaissances, je le considère comme étant ma responsabilité et ça rejoint le premier sujet dont on parlait, à savoir le fait de posséder un sujet ou de prendre la responsabilité de quelque chose. J'estime que c'est à moi de réunir et de guider. Je le vois comme ça le rôle de product designer ou de designer en général. Quand c'est possible, je le fais avec des personnes de l'analytics, du business, tout ceux qui font partie du product management ... Tous ceux qui détiennent une connaissance sont les bienvenus. Par contre, quand ce n'est pas possible, je pars d'un document et puis après ça va partir en mail et en requête de données. J'essaye de rédiger des questions et ensuite de les envoyer. Pour les questions j'essaye de ne pas demander de données trop spécifiques. J'essaye de poser des questions en premier lieu afin de laisser les gens qui travaillent avec moi réfléchir. Par exemple : "Je veux telle donnée précisément, je veux tels chiffres...". En lisant la question "Est-ce que cette fonctionnalité est utilisée ?", chez quelqu’un ça peut déclencher encore d'autres questions que moi je ne me serais pas posées. Une personne pourrait penser à d'autres metrics, d'autres choses intéressantes à relever ou d'autres questions à poser encore à quelqu'un d'autre. En recherche, rien ne vaut une question bien posée ! La quantité et la qualité d’information qu'on peut tirer d'une bonne question est magique ! Je pense que c'est très important de laisser l'intelligence des gens avec qui on travaille nous aider. Au final je pense qu'ils détiennent une info qu'on n'a pas. C'est bien pour ça que l'on travaille ensemble et parfois on peut passer à côté de choses si on est trop spécifique dans nos demandes.
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.
"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.
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 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.
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 :
“L’UX et SAFe” est un sujet intéressant à maitriser. Lorsqu’on travaille avec les grandes entreprises, il y a de fortes chances qu'elles fonctionnent sur ce modèle. Je ne pense pas avoir la solution parfaite, mais à force d’avoir travaillé dans ce mode et avec les retours de mon équipe chez Whitespace, je commence à trouver des astuces qui nous permettent de mieux fonctionner ensemble. SAFe (Scaled Agile Framework), pour la parenthèse, est un cadre de travail qui permet de mettre en place une méthode de développement Agile à grande échelle dans une entreprise. Il fournit une structure pour coordonner et synchroniser les équipes travaillant sur des projets complexes et de grande envergure en utilisant des pratiques agiles telles que Scrum et Kanban. C’est toute une orchestration de cadences, avec de grands rassemblements (PI planning), différents “streams”, un “release train” pour faire du “continuous delivery”, etc. Ça part sur de bonnes bases. Le souci, comme d'habitude, et comme avec la méthode Agile en général, c'est que le rôle de l'UX n'est pas prévu à la base comme élément intégré. Donc à chaque fois, c'est la même question: Donc nous sommes obligés de définir notre rôle : on explique qu'o n va faire de la recherche, créer des wireframes et prototypes, les tester avec les utilisateurs, et collaborer étroitement avec les équipes durant le développement.. Cela demande beaucoup de travail d'éducation de notre côté pour obtenir l'acceptation, voir le respect, des autres membres du projet (ou programme). Quels sont les défis et comment peut-on les gérer? Dans un projet récent, il nous a fallu beaucoup de discussions pour faire comprendre qu’il faut définir les éléments transverses avant de se lancer dans la conception et le développement des diffèrents produits (qui font partie d’une même famille). Donc : sont essentiels pour ne pas se retrouver dans un chaos total. Typiquement dans SAFe, cette idée existe pour l’architecture technique mais pas pour le design. Une solution est donc de se rapprocher du Solution Architect et s’intégrer dans le “Architectural Runway”. Pour se faire comprendre, il est important d’utiliser le “language” SAFe et Agile, qui sont par ailleurs bien documentés. Dans le contexte d’un large programme, nous avons pu rajouter le “usability testing” pour la “DoR” (Definition of Ready) d’une feature, et d’avoir un “UX QA” comme “DoD” (Definition of Done) pour une story - donc, en d’autres termes, injecter une approche UX dans un monde Agile. Préparer les features et stories en amont nous permet de faire des mini tests agiles si nécessaire avec les utilisateurs et de faciliter la vie des développeurs, en leur donnant un cadre bien structuré. Cet argument est en général assez convaincant, il faut juste utiliser des mots clés comme “efficacité” et “qualité.”1.UN STREAM TRANSVERSE POUR LE DESIGN
2.LA MAITRISE DU VOCABULAIRE
3.TRAVAILLER 2-3 SPRINTS EN AMONT
Lorsqu'il s'agit de créer du sens et de travailler sur des challenges, je pense que l'élément clé est de se créer un réseau de personnes avec lesquelles collaborer. Au-delà des outils, ce sont les relations interpersonnelles qui sont essentielles. Parfois, nous avons l'impression de ne pas avoir beaucoup de contrôle sur ce réseau, mais la meilleure façon de l'aborder, selon certaines approches du design, est de créer un espace propice à la collaboration. Cet espace de collaboration permet aux gens de poser des questions auxquelles ils n'oseraient pas normalement répondre. C'est un temps précieux pour partager des idées, des concepts et pour s'aligner sur les objectifs réels. Un concept intéressant que j'aime utiliser est celui de voir les problématiques et les challenges comme des îles ou des archipels. Le sensemaking est un moyen de créer du sens et d'aligner les efforts vers une direction commune. Les objectifs viennent ensuite, une fois que nous avons pris les décisions liées à cette direction. Lorsque j'aborde un nouveau projet, je n'utilise pas encore d'outil spécifique, car j'arrive souvent au milieu de projets déjà en cours. Cependant, je suis conscient qu'il existe un réseau de personnes dans l'entreprise qui possède des connaissances que je n'ai pas au départ, et qui m'offrent cette opportunité d'accéder à ces informations. Il n'y a rien de révolutionnaire dans cette approche, c'est un peu comme réaliser une cartographie des parties prenantes. Lorsque nous arrivons quelque part, que ce soit dans une nouvelle entreprise ou au début d'un projet, nous avons accès à des personnes qui peuvent nous orienter et nous indiquer qui détient quelles connaissances dans le domaine sur lequel nous agissons. La différence avec le sensemaking et la cartographie des parties prenantes, c'est que cela va au-delà des personnes internes à l'organisation, cela peut également inclure des clients et d'autres parties prenantes externes. L'idée est de créer un espace commun, qu'il soit physique ou virtuel, où les gens se rencontrent régulièrement et échangent des informations. Au début, il peut y avoir de l'ambiguïté, mais au fur et à mesure, nous clarifions ce qui est flou et ce qui est clair. Nous voulons créer un sens commun de la situation et des actions à entreprendre. Ensuite, nous mettons en place les actions nécessaires pour progresser dans cette direction. C'est là que nous utilisons des outils plus formels pour atteindre nos objectifs. Cependant, nous conservons une approche informelle pour tirer parti des avantages que seule une conversation autour d'une tasse de café peut offrir. Dans une cafétéria, nous en apprenons souvent bien plus sur un projet que ce qui est présenté lors d'une réunion officielle. L'aspect informel permet de véhiculer des informations précieuses que nous ne pourrions pas obtenir autrement.
J'ai réalisé que l'un des conseils qu'on m'a déjà donné, mais qui est difficile à entendre quand on débute, c'est d'être patient. C'est une qualité qui s'acquiert avec le temps, celle de savoir prendre son temps et comprendre que les choses arrivent à leur moment, pas nécessairement quand on les attend. Je sais que cela peut sembler vague et générique, mais je n'ai pas de conseil spécifique à donner, car j'ai toujours été curieux et je pense que c'est essentiel. Il est important en tant que designer de s'intéresser à d'autres domaines que le design, d'explorer ce qui se passe ailleurs et de voir comment cela peut enrichir notre propre travail. Personnellement, je suis un idéaliste qui a appris à être pragmatique. J'ai toujours eu cette volonté de faire les choses d'une certaine manière, en cherchant une certaine perfection ou du moins quelque chose qui s'en rapproche. Il y a une beauté dans cette tentative d'atteindre un idéal, et c'est ce qui me motive depuis le début. Cependant, j'ai aussi appris à être pragmatique et à comprendre ce que nous pouvons réellement accomplir en travaillant avec les autres. Cette compréhension pragmatique est le fruit de mon expérience sur le terrain, car j'ai réalisé que les choses prennent du temps et que chaque personne réagit différemment à ce que nous apportons. Au fil du temps, j'ai appris à semer des graines ici et là, et à voir ce qui en ressort vraiment. Cela me rapproche de l'idéal que je souhaite atteindre. J'ai appris à être patient, à comprendre qu'il n'y a pas de solution optimale ou de moyen parfait pour parvenir à quelque chose. L'essentiel est de s'engager dans le processus d'essayer, car c'est là que réside l'intérêt. Au début, j'avais du mal à comprendre pourquoi il était si difficile de concrétiser mes idées, malgré ma compréhension du travail d'équipe. Mais au fil du temps, ma patience et ma perception de la capacité des autres à assimiler l'information et à l'appliquer dans leur quotidien ont évolué. Ces qualités ne sont pas innées, mais elles se développent avec la pratique. On apprend à connaître les réactions des gens, leur façon d'absorber l'information, et cela varie énormément d'une entreprise à une autre, d'une équipe à une autre. Il n'y a pas de méthode universelle. Parfois, tout se passe naturellement avec une équipe. Les choses se mettent en place facilement et tout le monde est sur la même longueur d'onde. Dans certaines entreprises, des changements peuvent sembler évidents une fois qu'ils sont mis en place, et on n'a pas besoin d'en faire davantage. Cependant, il y a aussi des moments où des blocages surviennent, pour diverses raisons, justifiables ou non. Dans ces cas-là, semer des graines peut être une stratégie utile. On ne sait pas quand elles vont germer ni à quoi elles vont aboutir. Il est important de se rappeler que nous avons peu de contrôle sur le résultat final. Ce qui compte le plus, c'est de tendre vers une direction intéressante, de rester pragmatique. L'un des défis de la culture actuelle du design est que nous sommes si immergés dans nos processus et nos outils que nous oublions souvent de les contextualiser. Sur le papier, tout semble évident. Les processus et les outils du design nous semblent évidents. Mais la réalité du terrain et des autres personnes avec lesquelles nous travaillons est différente. Chacun a ses propres objectifs, impératifs et méthodes. C'est là que la curiosité joue un rôle important. En s'intéressant à d'autres domaines que le design, en sortant de notre bulle, nous prenons du recul et nous comprenons mieux les autres. Nous sommes conscients de leurs impératifs et de leurs processus, et de l'importance que cela revêt pour eux. Ce n'est pas seulement une question d'humilité, mais aussi de chercher à partager quelque chose de commun. Lorsque nous parvenons à créer du sens ensemble, nous sommes tous gagnants, car nous avons tous appris des choses que nous ne connaissions pas auparavant.
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.
Par contre, quand tu arrives par en bas par des managers , eux ils ne sont pas forcément récompensés pour les comportements que toi tu souhaites. Puis les comportements nécessaires chez eux pour jouer aux jeux auxquels tout le monde joue, c’est pas forcément ceux qui toi, t’aident. Donc ce n'est pas simple parce qu'ils ont commencé à tout censurer. Beaucoup de censure. Tout le monde est capable d’ouvrir le parapluie en boite, et tu cours le risque que les insights se transforment en torpilles entre rivaux. Pour détecter ce genre de situations, il faut que tu poses des questions sur la structure du projet. La structure de l’équipe. Si à un moment ils disent: “A non non non, on va faire les choses dans notre coin et le présenter à la fin par nous même”. Alors là tu sais qu’il faut que tu te couvres, car tu commences à être en mode agence qui bosse pour un autre client interne (donc risque de doubles retours) Il faut très vite se mettre d’accord pour que tu ne sois pas responsable de ce qui se passe à la fin, et anticiper le problème du storytelling: “Comment tu pitch cela au-dessus ?”
Quand j’interviens avec mes clients, je demande toujours : La réponse est systématique, ah les 3 ! En fait, les trois sont toujours ensemble. Dans ce contexte, il y a un élément qui est toujours difficile à gérer, c'est la partie de la hiérarchie qui fait partie du projet, mais qui aimerait intervenir le plus tard possible. C'est le meilleur moyen que tout le monde soit déçu. Il faut trouver des moyens et c'est contextuel à chaque intervention, d'essayer d'avoir en tout cas des infos sur le contexte, des acteurs avec qui tu parles. Donc, en stratégie de design, on prend les briefs et les requêtes clients comme étant toujours une des composantes de l'information disponible. « One element in the knowledge space » comme dirait sans doute VanPatter. Et on va le challenger… Moi, je fais toujours des twins ethnography. Il me dit: « Tu peux éteindre l’enregistreur ? ». Et là je découvre ce qui se passe. Parfois même, il dit « Non, tu peux laisser, ... ». J’explique comment j'appréhende les entretiens pour obtenir ces choses-là. Les gens leurs font confiance parce qu’ils savent qu'elles, elles ne bullshit pas. Si tu veux que ça marche, tu fais comme elles disent ;) J’essaie aussi d’être le plus vague possible avant l’entretien, c’est parfois un petit mail qui dit “ ça sera anonyme.” Puis quand on commence je dis : “Voilà moi j’anonymise tout, je me fous de qui fait quoi, c’est un système qui me parle, 2 – vous pouvez voir mes notes 3- à tout moment, vous pouvez éditer ce que je vous ai dit et je vous l’enverrai” Comme sur le terrain quand tu prends une photo des gens, tu le leur donne après. (C’est important, le safety des gens qu’on interview.) Après je leur dit on vous envoie le transcript si vous voulez. Aujourd’hui, il n’y a jamais eu quelqu'un qui m'a demandé le transcript. Et on ne m’a jamais demandé d’éditer. Mais en faisant cela, tu crées un cadre dès le début. Quand j’allais interviewer les migrants, j’allais toujours regarder le village où ils sont nés, où ils ont grandi, en Google Earth tu zoomes. En fait, le participant rentre dans une relation où ce n’est plus une interview, on n’a pas l’impression que quand on lui pose une question, il doit gamberger, il s’agite.. . Tu peux en détendre l'ambiance. Ce n'est pas une enquête de police. Il ne faut jamais dire que ce n'est pas une enquête de police, il ne faut surtout pas. Donc de cette manière j'ai des gens qui me déballent des gros trucs durant les entretiens. Après, j'ai la réputation de ne pas faire de censure et de de ne pas bullshiter et d’être piquant dans ma manière de parler des problèmes. Ce qui fait que les gens me font confiance. Ils n’ont pas envie de jouer ave c moi. La double ethnographie permet de voir un peu comment tu compares l’interne et l’externe. En dessous de 12 entretiens ça ne sert à rien car je vais creuser des questions profondes. Des questions où il y a du change, de la stratégie et du design quand ils sont d’accord sur les 3 dimensions. Je creuse les représentations du futur : Je vends ces entretiens comme étant l’effet Ikéa, c'est-à-dire, il y a un vrai plus, c’est que ces stakeholders à qui on est allés poser des questions “Qu’est-ce que vous en pensez? “ Ils se sentent impliqués, du haut de leurs expériences et de leur compréhension des marchés et des différentes divisions. Ils ne sont pas dans une logique défensive ni de stratégie, ils sont vraiment là pour, je leur dis “C’est de l’outil collaboratif, j’ai besoin de votre point de vue, ça m’intéresse. “ Donc il y a une manière très participative de travailler. Après, je ne te cache pas que dans toutes les boites, si le CEO n’est pas respecté, admiré, considéré comme un bon capitaine, il n’y a rien qui fonctionne. Je faisais un truc quand je rencontrais les gens, je leur disais «Je vous demande de dessiner une pyramide à 3 couches » Par exemple, quand tu vas dans une entreprise, c’est bien de demander une salle d'interview où il y a un whiteboard. Très, très vite, tu veux commencer à suggérer “Dessine le moi”. Ça, ça aide vraiment beaucoup. Très vite, le stakeholder il peut prendre le stylo et te le dessiner ce dont il parle et tu vas vachement apprendre. C’est peut-être là où le designer en recherche, il est avantagé et que ça devient intéressant. Par exemple, j’ai 0% de mes clients qui ont été capables de me donner un org chart (Organigramme hiérarchique). En fait je pense que dans les entreprises il n’y en a plus. Parce que ça change tellement souvent. C'est tellement en mouvement.
Une fois lors d’un projet j’ai eu la mauvaise expérience d’être avec des stakeholders qui ne prenaient pas le temps de suivre le projet et d’intéragir. La feature team devait avancer, les designers devaient avancer, et il y avait d'autres personnes qui mettaient la pression pour que ça avance. Si l’on disait à quelqu’un : non je n’avance pas. Politiquement parlant, ça n’allait pas passer. Évidemment à la fin, on a eu le fameux : Donc au dernier moment : Si je devais éviter cette erreur de nouveau je ferais pro-activement ces actions pour me protéger: Comme ça, Si la personne au bout de 3 mois elle réapparaît alors qu’elle zappé tous les workshops et dit : “Ben c’est pas comme ça que je voyais les choses,” Tu peux répondre: “ Ben oui, mais nous on a avancé, tu peux voir sur tous les e-mails que je t’ai envoyés que je demande des créneaux donc maintenant le truc va sortir comme ça. S’il faut tout changer au dernier moment parce que tu es chief machin truc et que tu nous mets la pression, on va un petit peu changer la marge. “ Mais aussi ne pas avoir peur de dire : “C’est comme ça que ça va sortir ou alors ça ne sort pas, on annule le truc. Mais nous, nos horaires c’est 9-18h30, on ne travaille pas le week-end.” Bon là ce sont des conseils pour se protéger, mais il faut éviter d’en arriver là. Si une partie prenante n’a pas le temps il faut : Moi il y a aussi un truc qui, en même temps, qui va dans les conseils que j’aurai bien aimé recevoir, qui est totalement lié à ça, c’est qu’on n’a pas dans la majorité des écoles de design ou formations qu’on a eues, c’est la négociation et la communication. Comment tu fais pour communiquer, tout ce qui est assertivité, communication non violente, négociation. Je trouve que tout ça, c’est essentiel et dans ce genre de cas, tu sais comment être factuel et dire que : “Je comprends que tu ne sois pas satisfait, parce que ce n’étais pas ce que tu attendais, en revanche, comme tu peux le voir, il y a eu 8 mails de ma part et 4 Slack pour te demander des points que je n’ai pas eus, ou on avait besoin de ça pour avancer donc voilà maintenant l’état des choses. Comment peut-on faire toi et moi pour éviter que cela ne se reproduise la prochaine fois ?” Puis surtout, ne pas prendre les choses personnellement. Un conseil également que j’ai eu d’un pote qui m’a dit : “Le boulot, ce n’est que le boulot” Tu vois quand la personne en face elle a envie de continuer à monter les échelons, elle se met la pression, les meetings back to back, à travailler jusqu’à 23h, week-end machin et tout, c’est son truc. À un moment, si elle s’énerve cette personne là parce qu’un truc s’est mal passé, je pense qu’il y a cette histoire de cadrage encore. Bien se protéger au fur et à mesure. Donc si la personne fait du silence, nous on ne veut pas faire du silence, mais au contraire on continuer à faire du feed-back genre : “Tiens, voilà en fait sur tel projet, voilà où j’en suis.” La personne le sait et toi tu es protégé. Factuellement tu dis : “Moi, ça fait trois mois que je te parle, toi tu ne me réponds pas, donc voilà où on en est. “ Si la personne s’énerve ben tu vas le laisser s’énerver comme un spectacle finalement. Il faut être factuel et honnête et le truc avance tout seul. Je pense qu'il y a des solutions meilleures que celle là et je pense que des head of auraient des tricks très particuliers. (commentez si vous avez des REX) Je veux montrer qu’au bout d’un moment, il faut faire du bon boulot priorisé sur l’essentiel, prendre un peu de recul et se protéger avant tout.
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 »
En tant que manager comment montrer la valeur de notre équipe d’UX writer grâce au KPI ? On veut montrer que c’était l’UX Writer qui a eu un impact, et pas juste un ressenti que les gens autour ont bien aimé cette collaboration. Mais quelque chose d’un peu plus chiffré. Mon expérience me dit que souvent que ça ne va pas être forcément grâce à une nouvelle fonctionnalité sur laquelle on va travailler, mais c’est plutôt d’identifier les endroits existants de l’expérience qui n’étaient pas optimales et de réécrire quelque chose comme une push notif, où l’on voit qu’un comportement change derrière. En tant que manager, c’est super important car ne pas montrer l’impact, tu ne fais pas grandir ton équipe.
Connais-tu l'Atomic Research ? C'est une méthodologie de structuration de la recherche sur 4 niveaux :
Outre la structure qui apporte de la clarté, cela permet également de justifier plus facilement de la valeur des remontées :
Tu vas donc pouvoir avoir progressivement une arborescence permettant de prioriser les Recommandations qui découlent du plus d'Idées, de Faits et d'Expériences et qui ont donc le plus de valeur (je simplifie un peu car toutes les expériences n'ont pas forcément la même valuer intrinsèque).
Du coup, quand tu présentes tes Recommandations par ordre d'importance, tu peux facilement la justifier avec tout ce qu'il y a derrière : "la Reco 1 est prioritaire car elle découle de ces 2 Insights. Ces derniers viennent des 5 Faits suivants qu'on a collectés en menant X, Y et Z (les Expériences)".
Et dans certains cas, surtout au début de tes recherches où tu auras peu d'Expériences, tu vas avoir des Recommandations assez hypothétiques. C'est normal et c'est l'occasion d'itérer. Tes recommandations principales deviennent tes hypothèses de recherche pour tes prochaines Expériences et iront nourrir le modèle pour obtenir de nouveaux Faits qui découleront sur des Idées puis des Recommandations : ça en renforcera certaines que tu avais déjà et ça permettra d'en découvrir de nouvelles.
Je pense que ça dépend de l’organisation de ton équipe et de la capacité de l’équipe de recherche à faire de la recherche. Parfois il y a trop de recherche à faire pour le nombre de researchers en place et ça devient essentiel d’avoir d’autres “people who do research” (PWDR) comme des Product Managers. Dépendament du contexe, c’est pas nécessairement une mauvaise chose.
D’un côté, il y a quelque chose de cool à ton histoire. Le PM est intéressé, il a l’air de vouloir faire de la recherche, d’aller chercher des données pour prendre ses décisions. Et pour moi c’est exactement là que tu dois jouer tes cartes. Apprendre à parler le même langage business que lui, et prendre ça comme une opportunité de l’éduquer sur la validité des résultats qu’il va recevoir en leadant la recherche. Ultimement, un PM va vouloir faire de la recherche pour quoi? —> Pour prendre des bonnes décisions produit. Si les résultats sont mauvais, ses décisions le seront tout autant.
C’est plate à dire, mais c’est nécessaire d’expliquer que sa recherche ne sera/n’est pas valide et d’expliquer les raisons pourquoi. Je pense que c’est important de s’affirmer comme la personne experte de son domaine et d’amener le PM à te voir comme son partenaire plutôt que son exécutant. Cette dynamique-là est aussi entre nos mains comme UXR.
J'aime beaucoup ce retour d'expérience et ta question, car elle fait écho à l'expérience de nombre de UXR. J'ai observé cette évolution et je crains qu'il ne soit trop tard pour faire retour arrière. La pression venant de la hiérarchie n'aide pas: les PM sont invités (pressés) de connaître les utilisateurs, de comprendre les dynamiques d'achat et de conversion.
Dans ce contexte, il me semble qu'il ne te reste qu'une chose à faire: te positionner de façon stratégique. Mais avant toute chose, je m'interrogerais sur ce qui fait que tes PM te court-circuitent:
Se pourrait-il qu'ils craignent que faire appel à un UXR les ralentisse? Ont-ils une pression de leurs stakeholders et des KPIs reposant sur le nombres d'utilisateurs auxquels ils ont parlé?
Dans la situation actuelle, la collaboration est quasi-nulle et tout le monde en pâtit (toi surtout, car tes collègues ne semblent pas être conscients de leur incompétence). Pour rétablir l'équilibre et te permettre de te positionner comme référence en terme de UXR, il va te falloir:
Une stratégie qui a bien fonctionné pour moi a été de me positionner comme un chef de projet de recherche. Ma première initiative a été d'aligner nos objectifs communs: cela m'a permis de ré-établir la communication et de mieux comprendre ce qui les amène à "envahir" sur mon terrain. Une fois que nous nous étions mis d'accord sur un point commun, il était temps d'établir les "frontières" de nos domaines de compétences.
Nous avons alors établi de grands axes de recherche et j'ai pu leur démontrer les forces et faiblesses de leur approche. Ici, mon rôle était celui d'un consultant: je comprenais leur objectif et leur proposais des activités efficaces et correspondant à leurs capacités.
En parallèle, j'établissais mon propre plan de recherche plus "foundational" et stratégique, et renforçais ainsi ma position. Les PM avaient un guide et des méthodes établies et adaptées leur permettant de "mener" des activités de recherche indépendamment — je les ai coaché pour leur permettre d'obtenir des résultats satisfaisants. Mais en aucun cas je n'ai cédé mon expertise: j'ai simplement pivoté vers un travail de fond, de gestion de l'insight.
Idem pour l'analyse: établie un score de qualité de la data. Si celui-ci n'est pas atteint, la data n'est pas valide et devra être écartée. Montre leur de façon très concrète les conséquences néfastes d'un mauvais insight (impact financier, réputation, etc.)
Enfin, propose leur de te soumettre leurs questions en amont, avant même de penser à mener des entretiens: peut-être as-tu déjà les réponses à leurs questions: passe d'un statut réactif (je dois faire de la recherche sur leur demande) à un statut pro-actif (tel et tel insight vous permet de prendre une décision informée). Tu peux aussi te joindre à leur sprint planning ou aligner ton research backlog sur le product backlog.
Ceci n'est pas une solution magique, mais pourrait te permettre de rétablir le dialogue et te sécuriser ta position.
Le PM c'est juste un marketeux déguisé... pas de research qui ne soit organisée, conçue, menée à bien, et exploitée par quelqu'un hors de l'équipe Research&Design... Chacun sa spécialité. Ce n'est pas la sienne. En début de projet, avant ou pendant le kickoff, rappel des roles et responsabilités de chacun. on met les pied dans le plat et les points sur les i. mais on attend pas d'avoir commencé.
Merci ! belle piqûre de rappel - C'est dans ma liste de lecture depuis bien trop longtemps. Je serais curieux d'avoir ton REX et pourquoi pas une anecdote de comment tu te prépares à ce genre de discussion en amont et comment tu as mis en pratique le livre.
Je vais l'acheter de ce pas!
@Mathieu Baudonnat j adore !!!❤️
@Alexis Gérôme j adore merci !!! Je realise que dans les entreprises très silotées le sujet d alignement des stakeholders et de partage de connaissances est complexe.
Et je vais me manger cette remarque tant que je n arriverai pas à avoir l ensemble des interlocuteurs clés en cadrage... je ferai un post mortem là dessus😉
@Antoine RIGAUDIAS Oui je connais l'UX fund, c'est un exemple intéressant de 2015-2016. A voir ce que ça donne aujourd'hui.
On n'a pas la même lecture de l'article. Niveau contexte, ça fait un an que les UX font face à des layoffs, des restrictions de budget et une introspection venant de plusieurs figures C-level des US (Ex research Director Meta et d'autres..). En gros on a fait du mauvais boulot, et on n'a pas réussi à prouver notre valeur.
Et c'est ça justement le bas du problème, et le postulat de ces dernières années. Advocate, advocate, être utile, et les budgets viendront.
La majorité des équipes se positionnent de base comme devant se justifier comme stratégie, et en réalité se démènent de répondre à toutes les demandes des autres équipes.
Cela amène à une réduction de la qualité de notre travail, et comme Marévéry le dit si bien à habituer les équipes à une certaine médiocrité en termes de recherche. (en gros ca devient la new normal)
En réalité, l'auteure interviews des managers qui ont fait le contraire et où cela à marché.
Partir d'un point de départ où ton temps est précieux, car la qualité de ton travail n'est pas remise en question est un rappel important en termes de mentalité en ce moment.
Après il faut dire non, savoir argumenter , communiquer etc.. Cela ne veut pas dire être difficile à travailler, mais communiquer un certain standard en terme de qualité de travail.
Ce n'est pas la seule solution disponible, mais c'est au moins une piste solide. L'ayant vu autour de moi, cela amène plus de résultats que l'auto-flagellation.
Je sais pas si tu as vu passer l'article sur l'UXfund, les gens qui ont créé un portefeuille d'actions boursières dont le seul critère d'achat etait la maturité en design... en quelques années +450% et des brouettes. j'essayerai de le retrouver.
Pour cet article, je serais moins catégorique que toi peut etre.
il faut etre pret a demontrer et ca demande du travail... mais ce que je lis entre les lignes dans cette article, c'est que dans les exemples cité la personne n'a ni priorisé une initiative particulière pour démontrer une fois son impact réellement, elle a essayer de tout faire en meme temps, ni géré sa ressource (elle meme en fait) efficacement, en refusant également de travailler sur des sujets pour lesquels les conditions de réussite n'étaient pas réunis.
il faut aussi savoir refuser des collabs, meme en interne, et créer du fomo en meme temps qu'on démontre par ailleurs... je suis pas tout a fait en accord avec sa démarche, meme si sur le fond, elle a raison.
Etre placé en situation de tjs devoir démontrer et justifier, c'est aussi une technique manipulatoire qu'il faut savoir désamorcer. et qund on est junior on ne sait pas forcement le détecter, et le contrer. Ca montre a quel point la maturité, en design, comme dans l'entreprise, peut créer un contexte favorable ou non. Totalement raccord avec les conseils en fin d'article effectivement, mais je pense que ce genre de contexte s'installe souvent quand on est jeune dans sa pratique, moins quand on prend de la bouteille :)
Merci de tes retours @Michael BAEYENS. L'IA peut effectivement aider à proposer des tags mais cela reste très basique je trouve et l'IA n'est pas encore en mesure de prendre correctement le contexte pour tagger efficacement. A ce jour, je n'ai trouvé rien de mieux que d'avoir un responsable global des tags qui s'assure de la cohérence des tags et qui va fusionner / renommer / harmoniser les tags mis par les autres membres de l'équipe.
Il m'arrive par provocation de répondre : "Maintenant on en à la preuve ;) "
Super question Amandine :)
J'avais posté une ressource que j'avais vu passé sur l'un des biais qui peut influencé ce genre de commentaire: L'effet rebond.
Donc une partie peut être expliquée par le fait que c'est une défense psychologique de la part de stakeholders pour dénigrer un peu la recherche et faire passer le sujet comme quelque chose de simple, alors qu'en fait c'était pas le cas.
C'est souvent le symptôme de deux choses.
Après il y a le cas où tout simplement l'UXR n'a pas fait son boulot de lier des liens forts avec ses stakeholders , connaître leurs priorités etc et passer à côté de ce qu'il devait préparer. Donc il y a toute la notion de relations pro.
Hello oui en effet, on est passé par les memes étapes et avons du créer des moments d’échanges inter produit pour coordonner les tags. Le but de ces tags est de pouvoir regrouper les facts lorsqu’on filtre pour affiner la recherche. Et le risque c’est naturellement qu’un tag en vale un autre, rédigé par qqun d’autre qui a le même sens mais qui est soit un synonyme. Nous avions aussi recours à la responsabilité d’un seul humain pour parcourir tous les tags et les rapprocher. Avec Coda tu peux désormais tirer parti de l’ia pour faire ces rapprochements. Pour ce qui relève du macro / micro à l’usage il n’y a pas de vrai problème selon moi. Puisque les tags servent à identifier les facts qui pourraient nourrir la réflexion peut importe que tu tri par mobile app ou par iOS. Tout dépend de ce que ru recherche. Est ce que tu cherche un comportement généraliste sur le mobile ou un comportement iOS ? Quelque soit le cas tout doit être taggué. À nouveau ce travail est rébarbatif à la main mais peut être soutenu par l’ia qui te soumet des tags en proposition
@Mike Winnington c'est un super début pour montrer une valeur très concrète de votre travail ! J'ai hâte de savoir comment ça évolue :)
Hi @Marie-Anne Chaloupecky,
Désolé pour la réponse tardive, je viens de la voir à l'instant.
Actuellement, on essaie de tacler notre dette contenu et pour ce genre de projet, pour que ça devienne pas une montagne de travail, on a décidé de prioriser les sujets qui déclenchent un taux de contact élevé au CS.
Notre KPI principal sera donc l'évolution de ce taux suite aux changements. On sera ensuite capable de mesurer l'argent économisé puisqu'on sait combien coûte chaque contact en moyenne.
D'autres KPI pour ce projet sont "time on task" (enfin le temps passé pour accomplir l'action) et le "taux décrochage".
On aura pas encore les résultats dans le cadre de ce projet, mais j'ai hâte !
Hi Mike :)
Quels sont vos KPIs actuels ?
Comment est-ce que l'entreprise mesure son succès ? Est-ce qu'on peu appliquer cette logique sur le travail des UX writers ?
Je peux juste te parler de mon expérience car je pense que ça dépend un peu des valeurs et des métriques de chaque entreprise.
Chez Booking.com il y a eu un changement radical de la perception du travail des UX writers à partir du moment où l'on a commencé à noter rigoureusement et publier les effets des changements en A/B testing. On a pu prouver notre valeur par toute une panoplie de métriques différents allant de la conversion net (avec prise en compte des annulations) jusqu'au nombre de contacts au CS (customer service) à propos d'un certain sujet (par exemple pour un problème de paiement par carte bancaire).
Ceci a non seulement permi de montrer la valeur de notre travail, mais aussi de travailler de manière très stratégique, car on a rapidement commencé à identifier ce qui fonctionnait bien ou non.
Mais on a pu faire tout ça grâce aux outils de A/B testing devéloppés en interne, et je sais que toutes les entreprises n'ont pas ça, et toutes n'ont pas la possibilité de faire du A/B testing de qualité.
Donc on peut réfléchir à d'autres métriques. On peut se baser par exemple sur les dropout rates (taux de décrochage ? Sorry for my Franglais), ou alors les contacts CS si c'est possible de leur ajouter un t