
- Même problème
- Déjà posée plusieurs fois
- Pas sûr
Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet du management d'équipes UX.
Lorsque j'ai été nommé responsable du pôle digital, j'ai été confronté à la gestion d'une équipe. Il faut imaginer que je venais de sortir de l'école et que pendant six mois, j'étais chef de projet, puis tout d'un coup, je me suis retrouvé à devoir manager. J'ai occupé ce rôle pendant les cinq premières années de ma carrière professionnelle. En me plongeant dans l'UX, j'ai dû me confronter à l'aspect humain. Cela signifiait développer des compétences en communication non violente, en empathie et en bienveillance, et me former pour écouter les utilisateurs, savoir quand me taire et poser les bonnes questions. En somme, cela a été une formation sur la façon d'interagir avec les autres, de respecter et de mettre en place des cadres d'échange et d'équipe. Cependant, j'ai dû gérer une équipe alors que j'avais une expérience limitée dans ce domaine, et surtout, je n'étais pas le genre de personne perçue comme "méchante" ou "gentille". Du jour au lendemain, j'ai été informé que mon supérieur hiérarchique était parti et que je devais prendre le relais. Cela s'est produit du jour au lendemain, sans aucun avertissement préalable. Donc, dans toutes les situations où je ne connaissais pas le sujet, où je ne me sentais pas suffisamment mature ou compétent pour y répondre, ma première démarche était de faire des recherches. Je savais que d'autres avaient vécu des expériences similaires, travaillé sur les mêmes sujets, et pourraient au moins me fournir des données pour commencer à construire ma compréhension et m'éduquer sur le sujet. À cette époque, je n'avais pas du tout réalisé ce travail de recherche, probablement influencé par l'idée que les relations humaines sont simples, une question de bon sens, et que tout se passerait bien. Or, la réalité est bien plus complexe et demande une rigueur extrême. Il faut mettre en place des processus pour le bien-être des collaborateurs, mais aussi pour ta propre santé mentale en tant que manager. Malheureusement, tout ne s'est pas déroulé de manière optimale. J'ai dû embaucher quelqu'un que j'ai ensuite dû licencier quelques mois plus tard, une expérience que personne ne souhaite vraiment vivre. À ce stade, on pourrait dire rapidement : "Je ne veux plus avoir à gérer tout cela. Ce n'est pas mon domaine, cela ne me parle pas, je ne veux pas être responsable de la gestion d'équipe de cette manière." Cela demande de prendre des responsabilités, comme dire à quelqu'un qu'il doit partir. Ou bien, cela implique des situations où des personnes avec lesquelles tu t'entends très bien, presque des amis, n'obtiennent pas l'augmentation qu'elles souhaitent parce que ton supérieur ne l'a pas approuvée, et finissent par te dire : "Je vais partir." Tu finis par le prendre personnellement. En réalité, cela te confronte à tes propres lacunes, à ton incapacité à les accompagner correctement et à améliorer leur situation dans l'entreprise. Ces situations sont à la fois dramatiques pour toi en tant que manager et parce que tu ne contribues pas grand-chose. Tu essaies de faire mieux, mais tu as déjà l'impression de faire beaucoup par rapport à d'autres. Je vois d'autres managers dans l'entreprise gérer leur équipe différemment, ce qui indique que j'avais une relation différente avec mon équipe. Cependant, cela restait insuffisant par rapport à l'ampleur du pouvoir que tu as en tant que manager sur la vie des gens, et sur le fait qu'ils se sentent bien ou mal dans leur poste. C'est une responsabilité énorme à cette époque, sur laquelle je n'ai pas cherché à construire ma vision, à mettre en place un cadre, à essayer de proposer un contrat commun pour améliorer les choses ensemble. Pour remédier à cela, aujourd'hui: À l'époque, je ne connaissais rien de tout cela, et je me contentais de penser : "De toute façon, tout se passera bien, nous ne sommes pas des méchants." Évidemment, cette approche était très insuffisante. C'est une leçon que je retiens, car aujourd'hui, lorsque j'exerce un rôle de manager, j'ai beaucoup progressé sur ce point.
La découverte du design operations il y a quelques années a été l'une des grandes trouvailles de ma carrière professionnelle. Cela s'est relié à mes découvertes sur la gestion d'équipe que j'avais faites sur le terrain. Aujourd'hui, je partage avec vous les questions clés que j'utilise quotidiennement dans mon travail. Au premier niveau, il y a les questions immédiates auxquelles il faut répondre dès que vous prenez un poste de manager : Ensuite, pour collaborer et construire quelque chose, j'ai cette liste qui me guide : Il est essentiel d'établir ce lien avec les données, les objectifs et le retour sur investissement, peu importe où nous situons un indicateur clé de performance. Ce qui est intéressant, c'est de comprendre la logique des métriques. Enfin, il y a toute la partie d'évangélisation en interne et de capitalisation sur ces succès qui est essentielle. Il faut du temps pour former une équipe qui fonctionne comme un cœur battant à l'unisson. Une fois que cela est en place, il est important de se concentrer sur la communication du travail de l'équipe. Ce sont les piliers du design operations, et c'est ainsi que j'aborde aujourd'hui la gestion d'une équipe et la création d'une culture. Cependant, cela ne signifie pas que c'est la recette magique pour toutes les entreprises, tous les groupes ou tous les individus. C'est simplement un cadre de travail et une façon de penser, et il revient au manager de s'adapter pour faire évoluer cela en fonction des besoins.
Un leader est celui qui dit : "J'ai une échelle, nous allons grimper un mur et nous devons placer l'échelle à cet endroit précis car c'est le meilleur endroit." Le gestionnaire, quant à lui, veillera à ce que tout le monde monte dans l'échelle au bon moment et dans le bon ordre. Une expérience marquante que j'ai vécue à l'IMD m'a pris deux mois pour mettre en place une équipe qui a ensuite progressé, mais c'était un travail nécessaire. Pour donner un peu de contexte, quand je suis arrivée, l'équipe était quelque peu délaissée. C'était une équipe de sept personnes qui faisait un peu de tout et n'importe quoi : un peu de design, un peu d'UI, un peu d'UX, alors qu'elle était supposé être d'une équipe de designers UX. Ils avaient une manager qui n'était présente que de temps en temps (problèmes de santé), mais à mon avis, elle manquait également d'expérience en matière de gestion d'équipe. Ce que j'ai appris sur le terrain, c'est que le rôle du manager ou du leader est de protéger son équipe des influences extérieures et de sensibiliser à l'impact de son équipe à l'externe. Lorsque j'ai pris mes fonctions, j'ai cherché à comprendre le macrosystème dans lequel je m'insérais. Vous devez d'abord évaluer rapidement les flux de travail et la dynamique de l'équipe : Ensuite, vous prenez chaque personne individuellement et vous les laissez s'exprimer. Vous leur dites : "Je suis là, je ne connais rien. Expliquez-moi comment les choses fonctionnent." Il est important de se mettre dans une position de méconnaissance, ce qui est souvent le cas lorsque l'on arrive dans une entreprise, où l'on ne connaît pas la culture ni la manière dont les choses fonctionnent. L'objectif est d'évaluer deux choses : comment les gens travaillent dans l'écosystème global et comment ils travaillent ensemble. La dernière dimension qui est extrêmement importante, selon moi, est de comprendre ce que les gens attendent de leur travail. Sont-ils motivés par la passion, par l'argent ou par une absence d'alternative ? Une fois que vous avez compris tout cela, la prochaine étape est de communiquer. La communication est extrêmement importante. Vous ne devez jamais cacher à votre équipe ce que vous faites pour eux et ce que vous prévoyez de faire pour eux. Les considérations politiques au sein de l'écosystème ne sont pas leur préoccupation. Cependant, vous devez constamment communiquer avec eux sur les impacts et les changements à venir. Si nécessaire, replacez les membres de l'équipe là où ils seront heureux et épanouis. Je reviens souvent à l'idée des organigrammes, bien qu'ils aient leurs limites. En politique, les gens ont besoin d'organigrammes. Mais dans la réalité, lorsque vous travaillez au sein d'une entreprise ou d'une agence, vous ne devriez pas dire : "Voici ce que nous devons faire, je vais trouver quelqu'un pour le faire." Au contraire, vous devriez dire : "Qui dans mon équipe est capable de réaliser cela ?" Vous partez de l'intérieur et vous évaluez les compétences et les forces de votre équipe. Ensuite, vous pouvez positionner votre équipe en interne en disant : "Voici ce que mon équipe est capable de faire pour vous, et voici comment nous allons le faire." En adoptant cette approche, j'ai réussi à passer d'une équipe de sept personnes à une équipe de quatorze personnes en l'espace d'une année. J'ai réorganisé mon équipe UX en trois sections distinctes : Nous avons dû embaucher de nouvelles personnes car notre équipe était devenue très efficace dans la livraison de projets et nous avons commencé à recevoir de nombreuses demandes. Nous avons réalisé que nous avions d'excellents designers et que nous étions devenus très compétents, ce qui nous a permis de développer nos compétences. Beaucoup de managers et de leaders se concentrent souvent principalement sur la livraison des projets, mais il est essentiel de penser d'abord à l'équipe. Il vaut mieux travailler en priorité sur les personnes qui réaliseront la livraison plutôt que sur la livraison elle-même.
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.
“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
Hier, j'ai fêté mes six mois en tant que manager. Je pense que j’ai eu le double challenge de changer de rôle et de changer de boîte en même temps. Changer de rôle et de changer de boîte en même temps est un double challenge mais cela me forçait à compter sur mon équipe et passer du temps à observer Dans ma tête, j’étais tellement convaincu qu’une réussite professionnelle ne voulait pas dire devenir manager. Lorsque j’ai eu l’opportunité, ça m’a troublé un peu parce que c’était un peu l’inverse de ce que je m’étais toujours dit. Donc, lorsque je passais les entretiens, je me suis concentré à fond sur le changement de rôle et pas assez sur le changement de boite. J’ai pris tellement de temps à réfléchir sur « Est-ce que c’est pour moi ou pas ? » que j’ai oublié que je changeais de boîte. Juste la différence entre la taille des boîtes me prenait du temps à m’adapter et aussi, il faut commencer à créer des relations avec des collègues, ça peut être mon équipe mais aussi des gens d’une autre équipe et tout un nouveau produit à comprendre. L’avantage de ce processus de découverte c’est que ça m’a obligé à ne pas micro-manager car tout était nouveau pour moi. (les nouveaux managers peuvent avoir une tendance de micro-manager certaines choses parce qu’ils ont du mal à lâcher le travail en tant que IC.) Vu que c’était un nouveau produit avec de nouveaux utilisateurs dans un nouveau domaine ; j’ai dû poser des questions aux gens au sein de mon équipe parce que je ne captais rien par rapport à plein de trucs. Avec un peu de recul, c’est peut être même une bonne chose de changer à la fois de rôle et de boîte en même temps. Comme ça je dois vraiment compter sur les gens de mon équipe, et j’ai beaucoup de confiance en eux grâce à ça parce qu’ils connaissent mieux le produit que moi. Ils connaissent mieux certains types d’outils que moi, et ça aide beaucoup. Au fond, je pense que le plus important pendant les premiers mois c’est de prendre le temps d’observer et de ne pas te lancer dedans trop vite. Dès qu’on est vraiment onboardé et que l’on passe le cap de “En onboarding” à “ je suis opérationnel”, c’est hyper dur de revenir en arrière, voir impossible. Après ce temps en observation, il faut avoir un impact, il faut montrer que je suis capable. Basé sur mon temps à observer, j’ai remarqué qu’on pourrait mieux structurer l’équipe, et comment on s’occupait des projets, sur quelles fonctionnalités travailler. J’ai remarqué que l’équipe devrait être un peu plus structurée comme les product designers ou les PM. Eux, ils ont des domaines de produits qui sont assez réduits. En UX writing on est moins nombreux, du coup nous étions 100% transversaux. Mais en fait trop. Nous n’avions pas besoin d’être 100% transversaux non plus. Le fait de prendre du temps à observer, j’ai pu identifier comment: Pour finir, je m’en rends compte aujourd’hui, mais en fait assez naturellement je réalise des cycles d’observations de ⅔ mois où à la fin je vais présenter quelque chose un peu structurel autour de la collaboration entre notre équipe et le reste du produit.