chargement des résultats

Postes

  • ·
  • ·
  • Design Leadership Starter Guide
    Jenifer Bulcock (Ex-UX research manager - Cerebral • Better) nous partage quelques retours terrains de sa carrière sur ce qu'est le leadership, et le chemin pour y parvenir. (Si c'est vous but) https://www.linkedin.com/pulse/design-leadership-starter-guide-jenifer-bulcock/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon REX en tant que VP Design chez Vestiaire Collective.
    Deux ans se sont écoulés depuis mon arrivée chez Vestiaire Collective.  Mon rôle a évolué de manière significative. J'ai réussi à bâtir une équipe grandissante, passant de deux jusqu’à douze membres.  J'ai établi des processus de resourcing et gestion de projet design, intégré une vision plus stratégique dans le travail des designers au quotidien, orchestré la collecte de données et recherche utilisateur pour des décisions éclairées, et mis en place une nouvelle discipline de recherche utilisateur pour l’entreprise, au-delà de l’équipe Produit.  Mon poste, avec le temps, s’est orienté vers plus de lobbying, où je pousse les projets chers au design dans notre roadmap, tout en questionnant ceux qui s'éloignent de la vision.  Mes interactions avec les vice-présidents produits des différents collectifs visent à aligner nos visions et nos approches. Désormais, je suis beaucoup plus impliqué dans la roadmap.  Ensemble, nous construisons notre feuille de route produit en collaboration avec plusieurs tribes, en plaçant le design en tant que moteur clé. La recherche, qui confirme ou réfute les données que je possède, soutient mes arguments. Nous adoptons une approche centrée sur l'impact, en collaborant étroitement avec nos équipes techniques pour concevoir des solutions qui démontrent rapidement leur valeur. Même si des projets proviennent de la direction ou de sources spécifiques, notre objectif est de prouver la valeur progressivement.
    Il arrive que certaines idées ne parviennent pas à maturité si elles ne montrent pas leur valeur au fil du temps. 
    Par exemple, une initiative impliquant beaucoup de ressources et n'aboutissant qu'à un résultat avec impact estimé mineur à peu de chances de réussir.  Plus nous avons de participants et d'expertises impliqués, plus il est crucial de mettre en avant nos compétences spécifiques, plus nous avons besoin de prendre du recul avant de nous lancer. J’attends des leaders tech, design, data et business, de nous remettre en question si nos décisions ne sont pas vraiment alignées sur nos objectifs à long terme.  C'est une pratique courante au sein de notre équipe de direction et parmi les vice-présidents.  Par exemple, un membre de l'équipe technique peut remettre en question notre approche de design en raison de considérations budgétaires.  Nous nous efforçons de définir des objectifs de vision clairs pour nos projets, tout en équilibrant les petits pas vers l'objectif final et la nécessité de prouver la valeur avec des versions évolutives. En résumé, le rôle du design et de la stratégie dépasse largement la création d'interfaces attrayantes. Nous agissons comme des catalyseurs pour toute l'entreprise, défendant des projets qui comptent et remettant en question ceux qui ne sont pas alignés.  La recherche, les indicateurs clés de performance et la collaboration sont des éléments essentiels pour accomplir cette tâche complexe.  Cette dynamique s'applique à tous les domaines du design. Parfois, nous devons travailler sur des projets qui ne correspondent pas à nos convictions, mais c'est dans ces moments-là que notre capacité à construire des solutions centrées utilisateur joue un rôle cléEn fin de compte, c'est cet équilibre subtil qui me permet de naviguer avec succès dans le monde complexe de la C-suite et de créer un impact durable pour l’organisation.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur réalisée lors d’une prise de poste.
    Il y a quelques années, j'ai été confronté à un défi de taille : repenser un flux complexe lors de mes premiers mois dans une nouvelle organisation.  Le projet était déjà en gestation lorsque je suis arrivé et j’ai repris le bébé à bras-le-corps. Vous savez, le genre de flow qui vous donne des maux de tête dès le départ.  Les problèmes étaient évidents, mais en tant que designer, je me suis engagé dans une refonte sans une boussole claire basée sur les indicateurs clés de performance (KPI). Nous avons cherché à créer une expérience utilisateur exceptionnelle en combinant intelligemment des patterns éprouvés.  Nous avons effectué des analyses comparatives, benchmarks etc.. mais nous savions que copier les autres ne résoudrait pas nos problèmes. Cependant, à mesure que nous progressions, la vérité nous a rattrapés.  Le projet était colossal, nécessitant un investissement massif en temps et en ressources. (1 an et demi de dev) Une révélation nous a frappés :  Était-ce vraiment nécessaire ?  Le jeu en valait-il la chandelle pour gagner quelques points de pourcentage dans les taux de conversion ? Si le problème initial de conversion n'était pas si grave et que les ressources nécessaires étaient disproportionnées, pourquoi redesigner tout le flux ?  Un moment d'introspection s'est imposé. Nous aurions dû identifier les problèmes spécifiques du flux et envisager des améliorations ciblées. En fin de compte, ce projet s'est avéré être un éléphant trop imposant à avaler.  Les ressources, le temps et l'argent investis ne justifiaient tout simplement pas la poignée de points de pourcentage gagnés.  Nous avons compris que la prémisse initiale était erronée, et que refondre un flux complexe est une tâche délicate.  Il faut bien plus qu'une légère défaillance pour justifier une refonte complète.  Si quelque chose fonctionne déjà relativement bien, il est difficile de justifier une transformation radicale. En somme, retenez ceci : une refonte majeure doit reposer sur des bases solides.  Il faut vraiment que quelque chose soit cassé pour justifier une telle entreprise.  Si ce n'est que partiellement brisé et que les résultats sont satisfaisants, optez pour des ajustements tactiques plutôt que de plonger tête baissée dans une refonte monumentale.  Concentrez vos ressources sur des projets plus urgents et célébrez les succès tels qu'ils sont, sans chercher à tout réinventer.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Vous voulez convaincre vos stakeholders? Oubliez la data!
    Ça peut paraître fou pour une UXR que j'ose ce type d'affirmation, n'est-ce pas? Aurais-je renié ma seule et unique source de vérité? Pas du tout! Mais j'ai appris à l'utiliser à bon escient! Récemment, j'ai eu le plaisir d'enregistrer un podcast avec deux expertes en génération d'insights, qui ont la particularité, en dehors d'être des professionnelles averties, de s'intéresser à la partie plus quantitative des données. Pendant une petite demi-heure, nous avons exploré un sujet parfois difficile à appréhender pour les UXR: le data storytelling, ou l'art de "narrer" vos données (je sais, c'est beaucoup moins sexy en français). En somme, le principe du storytelling n'est pas de présenter un argumentaire béton sur la base de données irréfutables, ce qui peut causer l'effet inverse (réactance) chez nos stakeholders, mais bien plus de les amener à s'interroger, à appréhender une autre vision des choses, basée sur les données récoltées par la recherche. La nuance peut être minime, mais influencer est beaucoup plus porteur, sur le long terme, que de convaincre. De notre discussion sont ressortis plusieurs éléments intéressants : Nous ne sommes pas rationnels, aussi il est inutile et même contre-productif de faire appel à la raison de nos stakeholders. Pour les convaincre, il faut d'abord avoir acquis leur confiance : pour ce faire, jouez la carte de l'authenticité ! Trop de data tue la data : less is more. Attention à la charge mentale, notre but est de distiller de l'information, pas de les assommer. Oubliez le camembert !! Le diagramme, pas le fromage... Bien que populaire, il n'aide pas forcément à véhiculer un message clair et intelligible : choisissez le bon graphique pour communiquer le bon message. Attention aux couleurs : rappelons-nous que le daltonisme touche 8% de la population masculine ! Assurez-vous que les couleurs que vous employez sont accessibles et visibles pour tous. Dans le doute, n'oubliez pas d'utiliser des labels clairs et descriptifs: cela vous aidera aussi à contextualiser les données. Utile, crédible, accessible, attractive, vous l'aurez reconnu, il s'agit bien de l'UX de la data ! Avant de préparer un argumentaire basé sur des données, qu'elles soient quantitatives ou qualitatives, assurez-vous de bien cerner les attentes, motivations et modèles mentaux de votre audience. En somme, pensez au pouvoir de la narration : le storytelling ne se limite pas à votre portfolio, il est également votre allié dans vos pitchs, présentations et rapports de recherche. La vidéo du podcast n'est pas encore publique, mais elle es disponible sous ce lien :) Toute une histoire...
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur de débutant que j'ai commise tôt dans ma carrière.
    À cette époque, j'étais encore relativement novice, avec moins de deux ans d'expérience, et par mon manque de séniorité, je ne suis pas allé secouer le contexte dans lequel je me suis retrouvé. À l'époque, je travaillais chez EDF, alors que le marché de l'énergie s'apprêtait à s'ouvrir à la concurrence. Notre mission était de créer des interfaces pour les auditeurs énergétiques, équipés de leurs ordinateurs portables, prêts à rencontrer nos clients industriels.  Leur rôle ? Simuler la consommation énergétique de l'entreprise, en prenant en compte chaque détail, des compresseurs aux tapis roulants, du chauffage aux réfrigérateurs.  En collectant ces données, nous pouvions proposer des solutions pour réduire les coûts, tandis que nos concurrents se contentaient d'offres standardisées, incapables de personnaliser leurs propositions. Nous nous sommes lancés, une équipe hétéroclite de designers et d'experts en énergie. Nous avons conçu des formulaires, imaginé des interfaces, puis nous sommes passés au stade des essais. Cependant, notre première erreur fut de ne pas placer l'utilisateur au centre de notre réflexion.  Nos experts en énergie, aussi compétents soient-ils, ont façonné un plan qui semblait parfait sur le papier, sans jamais consulter les auditeurs qui devaient utiliser notre solution sur le terrain.  Et...nous n’avons pas testé nos interfaces pour nous assurer de leur validité dans le contexte de l’audit. Notre passion pour le projet a pris le dessus, nous n'avons pas cherché les retours des clients sur leurs besoins spécifiques en matière de simulation.  Nous avons créé une interface esthétiquement séduisante, des icônes élégantes, des fonctionnalités de drag & drop, même des icônes custom élaborées avec soin lors de week-ends entiers.  Mais nous avons omis de nous poser les questions essentielles :  Le drag&drop est-il vraiment pratique ou utiliser le clavier aurait été plus simple ?  La hiérarchie visuelle est-elle adaptée au modèle mental des utilisateurs ? Aujourd'hui, je travaille dans le secteur du e-commerce de la mode.  Se mettre dans la peau d'un acheteur en ligne est plus simple comparé à comprendre les défis d'un auditeur énergétique. Pourtant, cette erreur persiste : négliger l'utilisateur et présumer que nous détenons toutes les réponses. Comment j'éviterai de reproduire cette erreur Avec le recul, j'aurais dû m'asseoir avec ces auditeurs énergétiques, ces pionniers qui redéfinissent leur profession.  Comprendre leur point de vue aurait été inestimable :  Comment percevaient-ils leurs visites clients ?  Quels étaient leurs besoins réels sur le terrain ?  À cette époque, il n'y avait pas de modèle établi. Néanmoins, un simple ordinateur portable ne suffisait peut-être pas.  Peut-être avaient-ils besoin d'autres outils ou de notes à portée de main ? J'aurais cherché à sonder ces experts pour extraire des informations vitales. En outre, j'aurais exploré le côté client. Trouver des entreprises intéressées par notre service aurait pu offrir une perspective précieuse.  Les clients pouvaient avoir une vision différente de ce que les auditeurs souhaitaient réellement. Peut-être préféraient-ils une version simplifiée ?  Ou au contraire, une version plus détaillée ? Peut-être étaient-ils plus intéressés par les rapports que par la visite en elle-même ?  L'objectif aurait été de dialoguer avec les deux parties pour concevoir une expérience répondant aux besoins de tous.
    De nombreuses entreprises qui n'ont pas les designers comme utilisateurs adoptent cette approche. Prenons Doctolib, par exemple. Ils encouragent leurs employés à consulter régulièrement des professionnels de la santé et à partager leurs expériences pour améliorer leurs services.  C'est, selon moi, la clé : rechercher activement des informations, se glisser dans la peau de l'utilisateur pour concevoir des solutions qui répondent véritablement à leurs besoins.
    Une autre dimension de cette erreur est la tentation de complexifier les choses. Nous avons tendance à pousser les limites de la complexité pour créer des solutions plus attrayantes, plus élégantes, supposant qu'elles fonctionneront mieux, sans garantie. C'est une erreur que je répète fréquemment, mais c'est aussi une erreur que je m'efforce de commettre sciemment.  Je sais que je tends à suivre les modèles établis avec mes équipes, mais chaque fois qu'une situation nouvelle ou inhabituelle se présente, je m'interroge sur une approche différente, une solution alternative. Dans mes débuts en tant que designer, dans le tumulte des années 2000, j'ai eu la chance de travailler sur des projets innovants, où nous créions à l’époque de nouveaux patterns.  Aujourd'hui, créer une application repose souvent sur des briques existantes. Pourtant, je continue de me demander : n'y a-t-il pas une voie non tracée ?  C'est un exercice risqué, source d'erreurs potentielles, car il peut nous conduire à ajouter des options complexes, exotiques, exigeant temps et réflexion, sans garantie de succès. Pourtant, je m'autorise souvent à prendre des patterns apparemment inapplicables et à les adapter à notre contexte.  Parfois, cela fonctionne de manière surprenante, ajoutant une touche d'originalité à l'ensemble.  Mais nous les testons systématiquement et ces solutions moins conventionnelles se distinguent parfois lors des tests, surpassant les schémas plus classiques.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX de Rémi Guyot sur le fait de devenir manager: 5 Learnings qu'il aurait voulu savoir.
    L'ex CPO de Blablacar partage 5 learnings intéressants sur le fait de devenir manager, et l'impact que cela a sur votre travail. Pour avoir lu quelques livres sur le sujet ils sortent des sentiers battus et cela vaut la lecture. https://mindfooled.substack.com/p/5-weird-things-new-managers-wish
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX : UX Researcher junior, comment s'insérer sur le marché du travail ?
    Hello,  Il y a quelques temps, Alexis a organisé un atelier de discussion sur l'insertion des juniors UXR dans le marché du travail. J'ai proposé d'en faire un écrit.  Après un travail conséquent, voici notre article (co-rédigé avec Emilie Marillat puis relu par Seb Lénelle et Alexis Gérome). En espérant qu'il vous sera utile :)  ----- Tout d’abord, si tu es junior avec moins de 5 ans d’expérience, sache que le marché du travail est pourri et que tu n’es pas seul. ❤️ La recherche d’emploi ou de missions est un travail sur le long terme qui peut te demander 6 mois voire 1 an d’efforts. C’est aussi une question de timing (rencontrer la bonne personne au bon moment par exemple). Voici quelques conseils qui t’aideront à t’insérer au sein du marché du travail. 1. Quantifie tes succès et l’impact de ton travail Avant de te mettre en marche sur le chemin de la recherche d’emploi, fais le point sur l’impact de ton travail, des différentes activités que tu as pu mener, des équipes avec lesquelles tu as collaboré, de ce que tu as aimé ou moins aimé. Par exemple : ”J’ai travaillé avec l’équipe Produit, l’équipe R&D et l’équipe de direction”. “J’ai rencontré XX utilisateurs au cours des entretiens”. “J’aime construire des questionnaires et utiliser le langage R pour analyser les données pour faire de la fouille”. ”Je n’aime pas le laxisme quand il s’agit de RGPD et d’éthique”. “J’ai animé XX ateliers”. PS : tes expériences peuvent être liées de près ou de loin au poste visé. Par exemple, si tu as fait de l’animation de groupe dans un contexte différent (même hors entreprise; dans des assos, dans ton club de sport, …) ou que tu as analysé un problème ou développé des recommandations ne les mets pas de côté ! Ces expériences montrent que tu es capable prendre des initiatives et des responsabilités et aussi que tu sais être empathique envers les autres (et pourquoi pas des utilisateurs potentiels ?). Au fur et à mesure, tu vas pouvoir regrouper tes activités pour les écrire en une version quantifiée pour ton CV. Voici un exemple :
    Tableau : Comparaison avant / après de la description du poste
    2. Travaille ton portfolio Tout comme le CV et la lettre de motivation, le portfolio est l’occasion idéale de montrer que tu as réalisé des projets. Il permet de montrer comment tu comprends le “pourquoi”, la raison d’être de l’UX. Ne le mets pas de côté car il permet à certains recruteurs de passer le pas quand un profil n’a, par exemple, pas l’expérience requise de l’annonce. Tu peux réaliser ton portfolio sur Notion, Behance ou créer ton site personnel pour y mettre ton portfolio. Pour chaque projet décrit, présente ce qu’on t’a demandé de faire. Tu peux préciser également quelle équipe avait besoin de ta recherche, quels étaient les résultats communiqués à l’équipe et quelles contraintes avaient les équipes. Explique pourquoi tu as utilisé cette méthode et présente les résultats de la méthode. Par exemple, tu peux montrer les impacts tels que le NPS, le temps passé, les impacts business (si tu n’as pas accès au budget, tu peux parler des impacts sur les utilisateurs ou le nombre d’utilisateurs interviewés ou des métriques que tu aurais pu regarder si tu avais eu accès). En bonus, rajoute les objectifs: ce que ça t’a apporté à toi, ce que ça a apporté à l’entreprise et tu peux aller plus loin en présentant ce que tu aurais pu faire SI … (tu avais plus de budget ? plus de temps ?). Il faut montrer le processus, le cheminement par lequel tu es passé dans le cadre de ton projet. Dans un portfolio, 3 à 4 projets qualitatifs, sur lesquels tu es fier·e d’avoir travaillé, suffisent. Si jamais tu n’as pas de projets d’entreprise, inspire-toi de tes expériences passées et plus précisément des compétences acquises et valorise-les. Tu peux également te mettre à tenir un blog pour donner ton avis sur les tendances, partager des sujets qui te passionnent (les jeux vidéos) et faire le lien avec l’UX. 3. Garde et montre ton travail en entretien Tu es certainement lié·e par le secret professionnel à ton ancienne entreprise avec un contrat de confidentialité. Ce fameux bout de papier où il est difficile de comprendre et savoir quoi dire et ne pas dire. Cependant, n’hésite pas à garder des traces de tes travaux au-fur-et-à-mesure des projets auxquels tu participes (les réunions, workshops, artefacts) et ton propre journal de bord du projet. Ainsi, tu pourras flouter / masquer les éléments confidentiels (avec Adobe Acrobat pro par exemple), modifier certains aspects comme la couleur, changer le nom de l’entreprise (précise tout de même les caractéristiques de cette entreprise). Utilise aussi des multiplicateurs, base-toi sur les moyennes du secteur. Tu peux même mettre un mot de passe sur ces fameux travaux ou ne les partager uniquement en pdf, sur demande, pour tes entretiens. 4. Pose des questions à la communauté pro Les offres visibles dans la recherche d’emploi ne représentent que la partie visible de l’iceberg ! En réalité, le réseau permet d’obtenir de meilleures offres, peu importe ta séniorité. Dans un premier temps, demande-toi quelles sont les personnes qui apprécient tes compétences. Tu peux démarrer une discussion et leur poser des questions que ce soit sur eux-mêmes, sur le secteur d’activité ou le type d’entreprise, etc. C’est l’occasion de montrer que tu es curieux·se et motivé·e. Ne sois pas insistant pour autant. Poser des questions est d’ailleurs plus efficace que de demander un job. Comme dit l’adage : “Quand tu poses des questions, on te donne un job. Quand tu demandes un job, on te donne des conseils”. Vous pouvez intégrer des Slacks du métier afin d’échanger avec d’autres designers, on a : French Designer Club French Designer Éthiques The Cacatoes Theory - Product Design UX Flupa France Design System France C’est aussi une occasion d’être au courant des prochains meetups à venir, de suivre des annonces de jobs avant une fiche de poste officielle et de pouvoir échanger avec le recruteur ou le salarié et en savoir plus sur l’entreprise. Pour être mentoré·e et échanger avec tes pairs, il y a ADP List qui permet de contacter et échanger avec des Designers du monde entier et français venant de grandes entreprises et de l’écosystème des startups (Microsoft, Uber, Booking, Accenture, Mercedes …) . Cela permet d’avoir des feedbacks sur son book, poser des questions sur le métier et tout autre aspect pour s’améliorer. 5. Multiplie les occasions de faire grandir tes expériences et tes connaissances avec le mode “Projets” Il y a des solutions pour continuer à te former, apprendre, murir. Tu peux aussi rejoindre des projets associatifs via la plateforme “Jeveuxaider.gouv”. Tu trouveras tout type d’aide bénévole, mais aussi des besoins de refonte de site web ou de médiation numérique, accompagner les personnes en difficulté avec le numérique. Tu également la possibilité de participer à des Hackathons à une problématique autour du numérique. Des grandes entreprises comme Orange (ici) ou des organisations publiques comme le Ministère des Transports (ici) ou île-de-France Mobilités (ici) ont organisé des Hackathons afin de répondre à des problématiques actuelles. C’est une belle occasion de mobiliser ses compétences de designer, d’intelligence collective pour travailler avec des personnes que l’on ne connait pas, plus ou moins sensible à l’UX, mais aussi une opportunité d’agrandir son réseau professionnel. N’hésite pas à regarder selon un secteur qui t’attire : la mode, l’e-commerce, l’écologie, l’éducation, etc. On peut trouver des meetups à venir sur Linkedin, Maddyness ou Meetup. Ou bien, tu peux créer ton side project qui va produire de la valeur pour toi, pour la communauté Wikihero ou même pour la société. Il peut naître grâce à un besoin, une passion ou une envie de monter en compétence sur une problématique : UX Research, savoir coder, maitriser Webflow ou Figma. Cela permet de montrer ta capacité d’adaptation, de te former en continu, de nourrir et démontrer ta curiosité. Dans un contexte d’internationalisation des entreprises/startups, il est important de travailler son anglais afin d’échanger dans un environnement avec des collègues ou clients anglophones. Pour améliorer ton anglais, tu as différentes options qui s’offrent à toi. La première est d’utiliser une application comme Duolingo pour apprendre du vocabulaire ou acheter un cahier d’exercices de grammaire pour perfectionner tes bases (il faut de la discipline et de la pratique !). Comme toutes disciplines, mélange ton entraînement à de la pratique. Tu peux par exemple maximiser ta pratique orale de l’anglais en te rendant dans des cafés des langues de ta ville ou trouver une personne qui parle anglais et qui souhaite apprendre le français en ligne. Si ces options te semblent compliquées, alors fais-toi des monologues à toi-même en anglais. En plus de parler oralement, tu peux améliorer ta compréhension orale et ton oreille en écoutant des podcasts ou des séries, des films en anglais (et ça te permet souvent d’entendre les séduisantes voix des acteur·trice·s et leurs accents). Tu peux travailler ta compréhension écrite et ton vocabulaire professionnel en achetant tes livres de Design ou en lisant des articles de veille en anglais (les livres sont souvent moins chers en langue originale). Enfin, tu peux travailler ton écrit en publiant tes posts linkedin en anglais ou en traduisant ton portflolio en anglais. Une fois que tu seras suffisamment confiant·e, utilise ton anglais pour échanger sur les bonnes pratiques research avec d’autres professionnels. La recherche utilisateurs est un sujet plus mature dans d’autres pays comme les Etats-Unis et le Royaume-Uni. 6. L’art de “savoir se vendre” Le chemin que tu as parcouru jusque-là, les actions que tu as menées constituent ton histoire. Ces actions sont réinterprétables pour servir ton objectif professionnel. Par exemple, si tu t’es engagé dans de l’associatif pour aider à utiliser le numérique auprès des personnes en difficulté, tu peux t’en servir en montrant que tu es d’autant plus sensibilisé aux questions d’accessibilité que tu as pu découvrir dans cette expérience. Tu es là pour construire ta collaboration avec l’entreprise. Démontre-leur grâce aux pans de ton histoire que tu es la personne la mieux placée pour obtenir ce poste et résoudre leur problème. Dis les choses en te donnant justement du crédit. Ton travail a contribué à toucher un investissement ? Ton travail a contribué à augmenter les ventes du produit ? Utilise le “Je” et parles-en. Cela permet de démontrer ta capacité d’analyse. Raconte une histoire qui fait sens pour toi et pour la boîte ou l’agence dans laquelle tu postules. Pour ce faire, commence par te demander les qualités que tu aimerais que les recruteurs connaissent à ton propos ainsi que ce qui te démarque des autres candidats. Connais également ton “Pourquoi” : “pourquoi tu te lèves ?”, “pourquoi tu veux aller travailler ?” et “pourquoi tu veux être UX Researcher ?”. Demande-toi aussi quelles sont tes valeurs, celles que tu souhaites défendre, celles que tu apprécies ? En répondant à ces questions, tu vas pouvoir structurer ton discours sur ce que tu as à offrir et comment tu l’as déjà fait, que tu as toujours fait ça. Puis comment tu comptes grandir en tant que UX Researcher. Ce travail sur la marque personnelle est particulièrement apprécié des recruteurs car ils aiment les discours structurés et impactants. Par ailleurs, tu peux aussi parler du concept du mentorat inversé. Tu as des connaissances que n’ont pas certains séniors dans l’entreprise et que tu peux transmettre. Ce concept a principalement émergé dans les entreprises lors de l’arrivée des nouvelles technologies au bureau. Les jeunes diplômés ont pu aider des employés plus séniors à maitriser l’ordinateur ou des fonctionnalités, des nouveaux langages ou des logiciels. Cela a été bénéfique pour les séniors qui ont appris de nouvelles connaissances techniques mais aussi pour les juniors qui ont pu apprendre les bonnes pratiques liées au poste ou à l’entreprise. Demande-toi si tu n’as pas déjà pu aider des collègues ainsi. As-tu pu apporter un nouveau regard dans un projet, une discussion ? Tu l’auras compris, le mentorat inversé est bénéfique pour le junior et le sénior. Si le sujet t’intéresse et que tu souhaites aller plus loin, tu peux aussi candidater à l’organisation “one young world” qui fait des jeunes des leaders en les mettant en lien avec les haut-placés des entreprises pour les conseiller sur des thématiques. 7. Déplace-toi et échange avec les professionnels Si un secteur ou une entreprise t’intéresse, il ne faut pas hésiter à se connecter avec le Lead of Design, Head of Design d’une entreprise afin de faire part de ton intérêt pour l’entreprise et d’en savoir plus sur des éventuels recrutements à venir. On peut en savoir plus sur l’organigramme de l’entreprise disponible sur le site ou sur Linkedin de celle-ci. Tu peux te baser sur des informations comme des récentes levées de fonds ou rachat par une entreprise, suivre une entreprise dans un milieu en forte croissance par exemple. On peut trouver ces informations sur Linkedin, Maddyness, le site de l’entreprise ou les sites d’actualités de l’éco-système des startups. Il y a aussi la possibilité d’aller à la rencontre des équipes lors de salons professionnels sectoriels, salons autour de la tech, de l’innovation et des startups. Tu peux faire une liste des exposants et donc, les entreprises qui t’intéressent sur le site du salon. Une fois que tu as listé ces entreprises, renseigne-toi sur leur produit et service afin de préparer un speech pour échanger avec l’équipe le Jour-J. N’hésite pas à préparer un CV papier, recueillir le nom d’une personne de l’équipe produit à qui envoyer votre candidature ou le nom de l’interlocuteur avec qui tu as échangé afin de montrer ton intérêt et appuyer ta candidature. Il faut être patient, souriant, bien se présenter et ne pas se laisser décourager par les refus. Si tu es en contact avec ton ancienne école et bénéficie d’une bonne expérience durant ton parcours (alternance, side project, compétitions gagnées), n’hésite pas à leur proposer de donner des cours ou d’être jury lors de compétitions/hackathons ou soutenances de fin d’année. Reste à l’affut des événements, conférences, meetups du métier afin d’être en veille constante. C’est l’occasion d’agrandir ton réseau professionnel, échanger avec tes pairs, avoir des conseils et pourquoi pas, trouver une opportunité ! Tu peux utiliser Linkedin, Slack autour du Product Design, meetups permettent de suivre les prochains meetups à venir. Il y a notamment Frontguys qui organise des conférences tous les mois (à suivre via Linkedin ou directement via Meetup). Afin d’agrémenter ta candidature et souligner ta motivation, tu peux aller chercher des informations supplémentaires sur une entreprise via les podcasts ou webinaires disponibles où interviennent leurs collaborateurs sur différentes thématiques. En podcast, on peut citer : Design JourneyDesign Master ClassSalut les Designers de l’Agence LunawebDesign + de Laurent GallenParlons Design de Romain Penchenat ou encore Quote - UX Research de Roxane Lacotte. Tandis qu’en webinaire, on peut citer les chaines suivantes : La ProductConfLa Grande OurseFriends of FigmaLe laptopDigidopFlupaThe Product CrewThe Design CrewJoin MaestroNoéThiga. C’est aussi une occasion d’apprendre de nouvelles compétences, de dénicher de nouvelles informations et de rester en veille du secteur.
    En posant une pierre à la fois, tu réussiras à te construire une place au sein du marché du travail. Ne te décourage pas, construis ta chance, ne l’attend pas et comme disait Clément Marot : “Tout vient à point à qui sait attendre”.
    Cet article est l’objet de la discussion organisée par Alexis Gerome, fondateur de Wikihero, ce mercredi 13 septembre 2023. Je remercie l’ensemble des participants d’avoir partagé des conseils précieux. Je remercie grandement Alexis Gerome et Seb Lénelle pour les conseils et la relecture de cet article. Un énorme merci à ma co-rédactrice Emilie Marillat qui a apporté, avec elle, les actions à forte valeur à mettre en place sans plus tarder ainsi que les références à suivre sans modération.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Attention au mix de langue dans vos interfaces
    Je tombe souvent sur des interfaces qui comportent des éléments en français et en anglais. C'est un signe d'un laisser-aller. Si vous estimez que c'est anodin, n'oubliez pas que tout le monde n'est pas bilingue. Certains utilisateurs vont certainement être perdus. Ex : cette page de commande en français, mais pour une raison inconnue, le bouton de validation du panier est en anglais. wikihero-image-id: 1168
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment j'ai pu récupérer 25 000e de facture en attente sur un projet qu'il fallait stopper !
    Rex de Romain Hetzel sur le danger que représente une nouvelle personne Lead dans l'entreprise pour vous en tant que freelance. A prendre en compte lors de vos missions :) wikihero-image-id: 1163 Vu sur linkedin
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment utiliser l’approche hybride IA générative et réseau conversationnel pour créer un chatbot ?
    Dans cet article, je partage mon retour d'expérience sur la conception d'Alix, un chatbot pour les aidants de malades d'Alzheimer. J'y présente une approche innovante combinant : La co-conception avec les utilisateurs finaux pour créer une expérience conversationnelle intuitive L'IA générative (GPT) pour plus de liberté, tout en contrôlant les réponses générées La protection des données comme pilier éthique Cette approche holistique, inspirée du marketing et des neurosciences, permet de créer des chatbots à la fois éthiques et performants. Je montre comment appliquer concrètement ces principes à chaque étape du processus de conception. Un cas pratique pour les designers soucieux de développer des chatbots vraiment centrés sur l'humain et détaché de la hype actuelle. N'hésitez pas à me poser vos questions sur la conception de chatbots éthiques. https://medium.com/@lydie_cd/case-study-comment-utiliser-lapproche-hybride-ia-g%C3%A9n%C3%A9rative-et-r%C3%A9seau-conversationnel-pour-cr%C3%A9er-1308da691d51
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Utiliser GPT-4 dans votre processus de recherche UX pour vous aider dans l'analyse
    Voici un petit REX comment nous avons utilisé GPT-4 pour nous aider à faire l'analyse de 55 retours utilisateurs. https://medium.com/xband/optimisez-la-recherche-ux-avec-gpt-4-pour-une-conception-adapt%C3%A9e-aux-aidants-dalzheimer-1a447d75129c
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment gérer une situation de charrette en tant que freelance ?
    Pour une mission, selon les cas on a généralement soit un bon de commande pour un nombre de jours donné pendant une durée donnée, soit pour un forfait global. Au cours de la mission, il arrive parfois qu'une situation d'urgence se présente obligeant l'équipe à se mettre en charrette pour tenir les délais de livraison. Quand on est freelance, c'est une situation parfois délicate à gérer. Comment réagir ? Car une situation de charrette témoigne d'un problème d'organisation dans le projet ou d'un besoin qui n'avait pas été initialement exprimé. Il est donc normal que cela ait un coût pour le client final. Si possible, il est toujours préférable d'avoir un contrat signé avant la mission (soit via votre agent de freelance, soit en direct avec le client) indiquant qu'en cas de travail après 20h, les jours fériés ou les weekends, le TJM sera automatiquement majoré de 30% par exemple. S'il n'y a pas de mention dans le contrat, personnellement je trouve qu'on a quelques options : Expliquer au client que ce n'était pas prévu dans le devis initial et valider un complément de X€ pour cette charrette avant la charrette. Expliquer au client que ce n'était pas prévu dans le devis initial et acter que c'est un geste commercial que vous faites pour assurer la bonne conduite du projet. Refuser. Avez-vous d'autres manières d'approcher cette situation à partager ?
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment bridger le gap entre vision de la stratégie et l’execution ?
    Une vision en tant que telle, ça ne sert à rien, si elle n’est pas diffusée et appliquée. L’UX est aussi responsable de la formalisation et de la diffusion de ta vision. Un atelier de vision se finit généralement avec les 3 questions suivantes : Est-ce que ta vision cooptée par les managers?  Comment va-t-elle être communiquée ?  Comment s’assurer que tout le monde va la lire et la mettre en oeuvre?  Du coup tout le travail de communication d'accompagnement post vision, il est aussi important que le que le travail de vision lui-même Derrière, il faut aussi produire les assets de cette vision-là.  Le plan d'action l'offre les piliers  la marque la charte éditoriale la charte graphique du produit Tu produis. Tu ne laisses pas la vision errer comme ça.  Tu produis aussi des guidelines qui permettent de vérifier que ta vision est bien appliquée. Par exemple, si tu mets dans les valeurs de ta marque qu’elle est accessible. Tu dois aussi spécifié comment tu la rends accessible et en faire des guidelines. Par ta charte graphique, tu spécifies le contraste visuel que tu es prêt à avoir pour etre visible par le plus grand nombre. Dans ta charte éditioriale, tu peux aussi spécifier que tu ne veux pas de mots tout en majuscules parce que les majuscules sont moins faciles à lire que les minuscules ( les lettres sont moins facilement discriminées). Une fois que tu as précisé tout ça, tu as une checklist que les équipes de conception vont pouvoir appliquer. On va beaucoup charter..  Et je sais qu’il y a un débat sur la créativité et la liberté d’expression créative. Est-ce que ce formalisme ça ne nuit pas à la créativité des gens ? Mais non ! Au contraire, ton espace de créativité est délimité par des droites infinies (tes valeurs), avec une cible au loin qui est ta vision et tu fais ce que tu veux dedans. Non seulement on décide plus sur du "j'aime, j'aime pas", mais sur des critères que tout le monde peut comprendre. Ça change la vie !  En fait, souvent les directeurs créatifs te disent "Merci” car cela peut les sortir d’une errance où ils se croient 100% libres mais au toutes leurs propositions sont critiquées…. Alors que là tu amènes un cadre où on rationalise en fait un processus d'intention. Et le créatif ensuite il fait ce qu'il veut. N’oublions pas qu’une vision reste une vision ! Parfois, tu es challengé sur ta vision et c'est OK.. La vision, c'est un modèle à dix ans, si tu peux la faire changer dans deux ans c'est OK.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: les ateliers de visions
    J’ai appris à optimiser et parfois à “hacker” les ateliers de vision.  Il peut m’arriver de passer beaucoup de temps à préparer l’atelier de vision. En général, je fais des interviews ou des enquêtes "pré-vision", quand l’entreprise est mature et stable, l’atelier n’est plus qu’une formalisation collective du contenu que je connais déjà en avance. Et c’est tres bien comme cela, on rentre dans le détail, on reformule, on peaufine.  Quand l’entreprise est moins mature, cette phase préparatoire me permet de déceler les incohérences, les tensions et parfois meme les guerres de territoires et donc à les désamorcer lors de l’atelier. La préparation en amont est pour moi est une très bonne façon d'éviter des écueils. Mes Learning principaux  1. La méthodologie.  Ne pas s’enfermer dans une méthodologie trop figée. Il faut la connaître et la maîtriser pour la préparer ; créer des templates. Mais ensuite, on laisse aller là où c’est important, ne pas s’éterniser sur les points qui font consensus : on s’adapte !  Plus on connait la méthode, plus on peut anticiper les oublis et les incompréhensions. quand je vais travailler sur “les forces de l’entreprise”, je sais qu’ils vont avoir tendance à oublier des aspects (la communauté, l’équipe, …) et ne parler que du produit. Alors je mets les oublis récurrents dans le template !  2. La préparation en tant que facilitateur. Il faut à mon avis avoir fait l'exercice dans sa tête pour anticiper ce qu’on va potentiellement te répondre pour argumenter du tac au tac. Quand tu dis que la bienveillance est une valeur, tu lui montres que ce qu'il a fait à ce moment là, ne correspond pas du tout à la bienveillance.  “Est-ce que ça veut dire que tu ne fais plus ce genre d'action ou est-ce que ça veut dire qu'on change ces valeurs ?”  Donc tu prépares ton pitch avant même que la vision ait pu avoir lieu. Tu n'as pas de mal à aligner en fait. Très souvent, ça peut m'arriver d'être à plusieurs facilitateurs. Il y en a qui s'occupent des post-it et puis moi je m'occupe de l'argumentaire.  Si je délègue cette partie à quelqu'un, c'est qu'il est entraîné et formé à l'outil.  La préparation je pense que c'est la meilleure chose pour éviter les écueils, sur un travail de vision, de stratégie.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Erreurs basiques en travaillant avec de la donnée.
    Je suis fille de prof de maths, donc les nombres c'est un peu ma LV2 ! J’adore travailler avec de la donnée et les représentations statistiques comme les ACP, dendrogrammes, AF.  En général, dans la donnée, tu as deux possibilités : tu veux absolument savoir une chose par la data ou alors l'attitude opposée, c'est d’aller explorer librement cette immense base de données.  Tu peux vite te perdre dans les deux. Parce qu'en fait chaque donnée que tu vas collecter, tu peux la croiser avec d'autres données. Potentiellement tu as une infinité de paramètres à aller creuser.  Les 2 erreurs les plus communes que j’observe sont celles-ci:  Tu peux te perdre dans ce que tu recherches (excès de curiosité, pas de recherche guidée).  Tu peux être trop directif (et te couper d’énormément d’information utile). 
    La data te donne l’impression que” plus tu en fais mieux c'est”. Tu commences à explorer, tu fais des stocks.  C'est important de stocker, de séquencer le projet parce qu'il y a un moment donné tu peux saturer ! tu peux savoir tellement de choses… et tu veux tout savoir.  Donc il faut se discipliner et être organisé. Sinon ça peut vite être le vrac dans ce que tu vas chercher derrière. Et d’un autre côté, il ne faut pas avoir peur de la data, parce que je sais qu'il y a une arithmophobie croissante dans le monde de l'UX.  Quand j'entends des influenceurs UX dire "moi je n'aime pas le quanti et de toute facon je ne sais pas faire"... ca m’interroge car je me demande si on peut encore faire de la user research aujourd'hui sans faire de quantitatif, sans comprendre les chiffres et sans utiliser la data. J’aurais peur d’être obsolètes d'ici à quelques années.  Et puis, aujourd’hui, beaucoup de choses sont automatisées, tu peux très bien faire des stats sans connaitre les formules complexes : Il faut savoir à quoi sert la donnée et ce que veulent dire les statistiques que tu vas récolter. J'adore particulièrement bosser avec les avis clients. Parce que l'exploration des datas ne sert pas juste quand tu as fini le produit et que tu l'as testé.  C'est après en post achat, ce que tu analyses. Parce que si tu veux vraiment faire des guidelines solides, il faut s’appuyer sur ton produit. Souvent l'UX va s'arrêter au moment où il a fait un premier test et basta. C'est comme faire la moitié du travail. Et que fait-on du reste ? Donc oui les avis clients c'est quand même un bon kif. A force d'en faire, ça devient un automatisme. Amener de la donnée dans son travail d'UX La première étape évidemment, ça va être de créer ou de trouver la data. Et la bonne nouvelle, c’est qu’aujourd'hui il y en a partout et sur tous les sujets. Entre les avis, l’UGC, les parcours, … Alors franchement si on ne trouve pas...je me dis qu’il est temps de faire un tour chez l’ophtalmo.   Il y a toujours de la donnée disponible. Si on me rétorque que le produit n'existe pas encore et qu’il est unique, et bien tu vas voir ce que fait la concurrence. (concurrence élargie: pour ceux qui n’ont pas de concurrents “directs”). On peut aussi créer sa propre donnée.  Une fois que la donnée est récupéré il est souhaitable de s'entourer d'un data scientist compétent. Le travail en binome va commencer. On va déméler et donner du sens au données.  Pour les plus motivées et ceux qui sont à l’aise avec R, Anaconda, Python.. Ils peuvent être autonomes.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment j'évalue si la boîte est mature pour mon poste.
    J’utilise la matrice de Keikendo pour situer rapidement le niveau de maturité en UX.  Je m’interroge également sur plusieurs aspects.  Quel budget pour l’UX? (si il est faible, c’est mal barré) Quel rattachement hiérarchique? (si le CEO est mon N+6 c’est mal barré) Quel objectif/KPI pour le pole UX?  Est-ce que tous les produits sont testés?  Etc Mais parfois les entreprises font miroiter une grande maturité UX pour attirer des profils séniors. Alors en plus de ces questions, je fais comme avec mes utilisateurs : je ne me fie pas à ce qu’on me dit ! je ne m’intéresse qu’aux actions. Qu’est-ce que l’entreprise a fait de concret? Que dit-elle à ses utilisateurs?  Que disent les utilisateurs de l’entreprise?  Et puis, je regarde, j'observe.  Et même si c’est contradictoire pour la scientifique que je suis, il m’arrive de me fier à mon ’intuition. Je sens vite quelque chose dans mon corps, comme si il m’avertissait, qu’il me dit “Ding dong”.  Quand ça sonne faux, je pose directement la question :”pourquoi vouloir faire de l’UX? "pourquoi vouloir m’employer ? pourquoi moi en particulier ?"  Tant que je n’ai pas le “vrai” pourquoi, la vrai raison, alors je n'y vais pas.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les promotions ne sont pas attribuées au mérite.
    L’erreur de débutante que j’ai faite, je crois qu’on est nombreux à la faire : c’est de croire que le monde de l'entreprise serait méritoire. Que si je travaillais bien, que j’atteignais mes objectifs, alors cela aurait un impact positif sur ma carrière.  Les premières années je travaillais jusqu’à 75h par semaine ! (oui j’ai beaucoup d’énergie et je m’investie beaucoup professionnellement), je voulais surpasser les objectifs qu’on me fixait.  Je travaillais tellement que je n’avais plus le temps de prendre de pause café, je mangeais à mon bureau et travaillais de chez moi en rentrant le soir. Au final la promotion attendue a été donnée à un autre (plus junior) mais qui passait du temps avec les patrons (dans les petits papiers) et faisait la promotion des projets de l’équipe…pendant que je faisais mon travail (et une partie du sien car il prenait du retard). Ça m’a fait un choc ! Je crois que ça été un déclic pour plus travailler ma communication ! Je pensais que tu progressais au mérite et que c'était fair-play. Je pense que c'est la plus grosse erreur que j'ai faite.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Ne jamais accepter le “C’est mieux que rien”
    Un autre de mes conseils serait de ne jamais accepter le "c'est mieux que rien". Quand tu es dans une entreprise et que tu exprimes le besoin de 30 utilisateurs et qu'on te répond, que tu as le budget pour 5 utilisateurs... Je ne pense pas que la meilleure idée soit de faire un test dégradé.  Parce que les gens vont s'habituer à des choses de moins bonne qualité. et le jour où tu vas me demander un budget pour 30, ils ne vont pas comprendre… puisque tu as toujours fait avec 5.  Pour moi les choses sont assez simples :  Si tu n'as pas le budget pour faire une bonne étude, tu ne la fais pas.  Si tu n'as pas les moyens pour faire un bon prototype, tu ne le fais pas.  Je pense que c'est une hygiène de l'UX à s'appliquer. Si tu n'as pas les moyens, tu ne le fais pas tout simplement.. Le "c'est mieux que rien",en réalité ca devient vite “pire que tout”. Autant assumer un parti pris plutôt que de faire les choses à l’arrache..  Quand j'entends "oui mais on ne peut interroger que nos amis, ils sont dans la cible"... mais es-tu sur de cela? Ne vont-ils pas être influencés dans leur réponse parce qu’ils te connaissent et connaissent ton entreprises? Serais-tu prêt à parier que le comportement de tes amis et ceux du client final seront le même?  Alors oui, certes, tu vas donner l'illusion que tu as fait quelque chose mais tu ne sais pas si au fond le résultat sera sur ton futur utilisateur.  Je vais plutôt essayer de négocier :  “tu as 1000€ pour cette étude, alors la seule chose que je peux te dire c'est si les utilisateurs vont apprécier ton logo.  Voilà ce que tu pourras savoir. Mais si tu me donnes 10 000€, je pourrai te dire si ton site sera un succès ou pas.  Pour le coup, je fais en sorte que mes études soient le moins chères possible, mais toujours avec des prestataires compétents. Je suis dans une optique d'optimisation, d'efficacité opérationnelle... Il faut être parfois être inventif pour tenir le budget.  Et si ca ne passe toujours pas et bien… dans ces cas-là, sinon je suis désolée mais je ne le fais pas. Ils peuvent passer par une agence externe, se débrouiller autrement, mais moi en tout cas, je ne le ferai pas. J'ai mieux à faire de mon temps que de réaliser un test qui ne sert pas à prédire le futur comportement de l’utilisateur parce qu’il a été mal fait.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Détaillez les limites de l'étude.
    Chez Decathlon, on faisait beaucoup de tests. On faisait des corrélations entre les notes du tests et la note d'avis client. En général, on testait un produit et des mois après le produit sortait. On savait à l’avance si ça allait être bien ou pas. Cette manière a toujours bien marché. On avait un très bon modèle prédictif. Cela reste une modélisation et parfois tu as des surprises : par exemple tu as des gens qui ne sont pas prévus dans ta cible initiale et qui achètent quand même ton produit.  Parfois tu as des éléments tels que le covid ou la guerre en Ukraine etc. qui viennent faire bouger ce que tu attendais en termes d'usage, et aussi tu peux être en retard ou en avance.  Donc avec toutes ces inconnues, ce qui est important, c’est lorsque tu remets un rapport, tu expliques les limites de ton étude.  Une fois que tu fais ça, tu es rarement contesté, car tu as su prédire. Mais si tu n'as pas précisé quelles étaient les limites, tu as en vendu du rêve, attention au retour à la réalité. Je suis très attentive à ça : "Attention, c'est basé sur du déclaratif. Attention, cette étude a été réalisée pour la France et n'est pas valable ailleurs".  Je crois que dans toutes nos études on devrait expliquer nos limitations.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment répondre à cette demande: "Est-ce que les gens utiliseront ce produit ?"
    Déjà il faut se poser la question de l'utilisabilité avant de parler d’utilisation. Pour l’évaluer - l'utilisabilité- je préfère amplement utiliser une grille experte répétable et reproductible plutôt que des interviews ou des tests. Comme elle se base sur des critères mesurables : Elles ont une très bonne interjuge : , c'est-à-dire que deux UX différents vont donner la même évaluation sur une interface. Ce qui n’est pas le cas avec d’autres critères qui sont habituellement enseignés.  Je prends un exemple : ”le site prévient les erreurs de l’utilisateur” est assez subjectif , alors qu’évaluer s'il y a “Moins de 5 typo dans une même page” l’est un peu moins.  Il y a énormément de grilles qui sont disponibles et qui sont de bonne qualité. Une fois que j’ai fait la grille, je peux tester les zones avec des utilisateurs qui ont été mis en doute par l’audit.  Je préfère également donner des guides de conception (des guidelines), plutôt que de faire du test U à répétition. Je pense qu'il n’est pas toujours nécessaires de tester pour se rendre compte qu'une couleur n'était pas lisible sur une maquette parce que le contraste n’est pas suffisant. Pour revenir au sujet de base, sur l’utilisation, afin de savoir si une plateforme va être utilisée ou pas, il faut le faire sur une étude quantitative et idéalement en comparatif. On va proposer plusieurs solutions (donc notre préféré mais aussi au moins une idée bien naze) pour être de mesurer une différence d’appréciation. On pourra alors dire que: “L’utilisation sera de X %”. Toute fois, il ne s’agit que du déclaratif et il peut y avoir un écart énorme entre la réalité, c’est pourquoi on préfère avoir du comparatif “l’utilisation sera de X% de plus que l’autre idée”  Une des choses que je fais beaucoup, c'est que lorsque quelqu'un vient me voir pour une demande de faire étude. On va passer beaucoup de temps à clarifier sa question de recherche en utilisant la méthode des 5 pourquoi. Quel est le vrai but de cette étude? En fait, je vais énormément challenger l’objectif et l’impact de mes études, parce que j'ai fait d'études qui ne servent à rien. Donc, je continue, je continue, je continue jusqu’à ce que je sois sûre que l’étude servira à prendre une décision. (si ce n’est pas le cas je dis non)  Et si j’ai encore un doute sur l’utilité de l’étude, il m’est arrivé de “hacker” la conversation en donnant un résultat au hasard.  Parmi les outils que j'ai à la maison, j'ai la "eight ball" (elle dit “maybe, yes, no, …”), et j'ai aussi un dé à 60 faces. Quand j'ai quelqu'un qui vient, qui me pose une question, ça peut m'arriver par provocation, de lancer l'un des deux.  Moi : La réponse c’est 51 %". Dans ce cas-là qu'est ce que tu fais avec cette donnée-là ? Lui: “Je veux quand même faire mon produit.” Moi:  Alors pourquoi veux-tu faire une étude ? “ Cela m’aide à savoir s'il est nécessaire de lancer l’étude… ou pas.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ne croyez jamais que vous avez compris l'utilisateur.
    Je donnerai ce conseil à un débutant : ne jamais croire que tu as compris l'utilisateur.  À partir du moment où tu penses que tu as compris l'utilisateur, c'est que tu as arrêté d’essayer de le comprendre. Si jamais dans la boite où tu travailles, un UX ou un PO te sort “je connais l’utilisateur”. C'est qu'il a arrêté le process de reflexion. Parce que la compréhension de l'utilisateur c'est un process continu et ce n'est pas quelque chose de figé. J’ai tendance à penser que quand tu es UX et qu'il y a un truc que tu crois savoir faire parfaitement, c'est que tu as perdu ton discernement. Si tu crois que tu as trouvé la méthodologie parfaite que l’on peut appliquer dans tous les cas et contextes : c’est une illusion. Chaque étude a ses limites.  J'ai quinze ans de carrière derrière moi, j'ai plus de 300.000 utilisateurs qui ont répondu à mes questionnaires et 700 études différentes... Il n'y a pas une fois où je ne me fais pas relire par un pair. Je reste vigilante. Car le jour où on croit qu'on est “bon” ou qu’on a “compris”, c'est qu'on a arrêté de bien travailler. En résumé, le secret c'est d’être à l’aise avec les incertitudes et avec le fait qu’on ne peut pas tout savoir. C’est une remise en question permanente, et pour cela il faut s’armer d’un bon esprit critique.  Quand on me demande ce que pensera l’utilisateur du produit, ma réponse préférée est “ça depend!” car je n’ai pas la science infuse et l’humain n’est pas trivial ni rationnel dans ses décisions qui dependent du contexte, de sa personnalité, de son humeur, de son expérience passée…   D’ailleurs cet esprit critique est valable pour son travail mais il est aussi de mise pour le reste. Et notamment ce que l’on peut apprendre en expérience utilisateur. Il y a des livres et des auteurs aujourd'hui qui sont cités comme des références... Franchement ? Vous êtes sûrs ? Le domaine de l’UX n’est pas épargné par les “fake news” et les contre-vérités. Il y a aussi des influenceurs en UX qui avancent des propos méthodologiques tout à fait contestables (voir contre-productives). Malheureusement, cela a un impact sur les plus juniors. Il y a des juniors qui arrivent avec des méthodologies hasardeuses...parfois on se demande où ils ont appris ça ! Parfois les méthodes sont supers mais sont appliquées … dans le mauvais contexte.  Si je prends un cas précis, c'est le mythe du test avec cinq utilisateurs. Le junior va faire un test sur cinq personnes et c'est suffisant pour lui. Il donne même une note (“le site a 7/10”). Alors j'explique que c’est statistiquement pas possible ni suffisant pour donner une note. Si je change mes 5 testeurs aurais-je la meme note? Certainement pas. Il me répond "c'est Norman qui a dit ça !" et je lui réponds : "Et alors ?".  Il n'a pas compris le contexte dans lequel c'était dit (5 personnes pour détecter une majorité des défauts, certainement pas pour faire une évaluation !) et ce n'est pas parce que c'est tu as une personne que tu as sacralisée qui te dis une chose que c'est vrai. Je sais que ce n’est pas sa faute : il y a beaucoup d’écoles qui enseignent l’UX avec des niveaux très hétérogènes. Je vois parfois des professeurs qui ont des parcours "surprenants" considérant les matières qu'ils enseignent. Et aussi quelques autodictactes qui, certes ont le mérite d’avoir appris seuls, mais dont les méthodologies me font parfois hérissées les poils.  Méfiez-vous de ce que vous avez appris, ayez un regard critique sur la profession, et entourez-vous de pairs de confiance.  Je vous raconte ma petite histoire pour exemplifier cela. Mon tout premier test c'était pour choisir un vélo pour les femmes urbaines à Paris. Je n’avais jamais conduit de test avant ce jour. J’ai passé mes vacances d’été à lire des bouquins pour apprendre à le faire correctement. J'ai ingurgité des dizaines de bouquins en analyse sensorielle, en marketing pour préparer mon étude.  Alors on a produit des vrais vélos, qu’on a mis dans une vraie situation (dans un magasin) avec de vraies testeuses (recrutées). J'ai vu que statistiquement il m'en fallait 200. Donc ca nous a couté cher. Mais je voulais faire cela bien. Pas question de déroger sur la qualité de l’étude. Surtout que c’était une premiere !  Comme je l’avais vu dans les livres, j’ai posé plusieurs questions à mes testeuses.  Quelle est leur couleur préférée ?  Parmi les vélos, quel est celui qu'elles prendraient ?  Et le cas échéant, quel est celui qu'elles achèteraient ?  Si on vous en offre un lequel vous prendriez?  Et en fait, quelle que soit la question que je posais, je n’ai jamais eu la couleur qui s'est le plus vendue Ça m'a ennuyé ! Il y avait un vrai problème. A quoi servent mes études si elles ne permettent pas de prédire le résultat !?! Il y a eu un décalage énorme entre la méthode et le résultat des ventes. Et c’était embêtant parce qu'on a sorti l'artillerie lourde et c'est un test qui nous a coûté cher et qu’on avait passé des mois à préparer. Et pour rien. Ça m'a mis un gros coup de pied au derrière sur le fait qu'il y avait peut-être d'autres choses à aller chercher.  Alors j’ai repris les banc de la fac (pour comprendre ce qui se passent dans la tete des gens) et j’ai déployé un arsenal de technique implicite pour palier à l’absence de fiabilité du déclaratif.  Je peux en citer plusieurs :  1. La biométrie. Car le corps sait ce qu’il se passe bien mieux que notre propre introspection. Il ne trahit pas. Il réagit à chaque stimuli.  2. La data. Grâce à elle, Facebook arrive à mieux prévoir ce que l'on va faire que …nous-même ! Il sait si on va aimer telle ou telle publicité grâce à des algorithmes qui analysent chaque jour des millions d’utilisateurs. C'est quand même assez flippant. 3. La psychométrie. C'est l'art de mesurer la personnalité des gens. On va aussi développer des questionnaires qui doivent être extrêmement de bonne qualité, robustes. Grâce à eux, on peut mesurer des aspects de la psychologie des utilisateurs. En fait, j’utilise régulièrement ces trois outils que sont la biométrie, la data et la psychométrie pour essayer d'aller un cran plus loin sur la recherche utilisateur. Mais j’ai encore beaucoup à apprendre. Je suis actuellement des cours en Psychologie Evolutionnaire et en Linguistique.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Un conseil que j'aurais voulu avoir plus tôt: Trouver des mentors.
    Le premier conseil que j'aurais aimé recevoir plus tôt : c'est de s’entourer d'experts ou de mentors. Car il ne faut pas croire que c'est parce qu'on a lu des livres ou qu’on a un diplôme, que cela va suffire à être bon dans son métier ! Après mon diplôme, j’ai mis deux ans avant de commencer à m'entourer de mentors. J’essayais de tout faire toute seule. Quelle perte de temps ! Et même aujourd’hui en tant que sénior, j’ai encore besoin d’avoir des pairs et des personnes plus expertes que moi ! c’est indispensable.  Mon conseil serait : dès qu'on arrive dans une entreprise pour une mission donnée (et c'est valable pour tous les jobs), il faut regarder les gens qui ont des compétences que l’on n’a pas. Définir ce qu'on aimerait être sur quoi on voudrait bosser. Cela peut être sur un sujet technique (UX, UR) mais aussi des soft skills (comme par exemple la communication). Tu auras toujours besoin d'avoir des gens qui supervisent ce que tu fais parce que tu as vite fait de décrocher, de t'égarer, d'appliquer des méthodologies qui ne sont plus adaptées. Pour trouver cette personne, on peut se poser deux questions : Quelle personne réussit dans mon entreprise? Quelle personne représente un modèle pour moi?  Tu peux ensuite lui demander son aide pour progresser en lui demandant :"Est-ce que ça t'embêterait, de temps en temps, de me donner des feedbacks sur mon travail? Ou de me donner des conseils pour progresser ? ou que je puisse te regarder pratiquer au quotidien ?".  Il ne faut pas culpabiliser de demander car, même de l’autre coté, c'est aussi une belle occasion de se challenger ! Quand j’ ai pu être dans la situation de mentor, le mentee (novice) te pose souvent des questions pertinentes ! Cela m’arrive souvent de me dire "c'est pas vrai ! pourquoi je n'ai pas pensé plus tôt à faire ce truc-là ?". c'est une relation qui est gagnant-gagnant : Le mentee va progresser de manière récurrente et le mentor va aussi être challengé dans ses méthodes.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Obtenir des tâches plus stratégiques et aller au-delà de son rôle.

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Faire un bilan de connaissances du projet

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le pouvoirs des Checklists

    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:

  • Je vais toujours faire une sorte de curation de l'existant
  • Faire une liste de la cible, des choses comme ça et je vais merger les deux en une checklist. 
  • J'essaye de toujours avoir une checklist, par exemple de tous les composants, de tous les états d'une page, de tous les états d'un service, de tous les statuts possibles, d'un système. 

    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.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • Erreur: Prendre trop de temps pour se séparer des personnes non performantes.
    Il est important d'éviter l'erreur de prendre trop de temps pour se séparer des personnes non performantes.  Les échecs les plus importants que j'ai observés sont souvent liés à un manque de courage de la part des manager de se séparer des personnes qui ne sont pas à la hauteur de leur travail.  En effet, ce sont toujours les erreurs humaines qui peuvent nuire à une entreprise. Parfois, je constate que des clients recrutent la mauvaise personne, même dans des domaines différents du mien, et cela me fait réaliser l'impact financier et énergétique que cela peut avoir sur l'entreprise.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Inspirez vous des design reviews et créez des research review

    Ce qui manque actuellement et ce que j'aimerais voir se développer, c'est une culture de challenge entre les chercheurs, similaire à celle des designers.

    Les chercheurs sont souvent un peu solitaires. 

    Il y a UN chercheur et DES designers. Du coup nous commençons à mettre cela en place en interne, avec les différentes équipes UX dans les différents pays. 

    Nous organisons des moments dédiés où nous discutons d'outils et de méthodes.

    Tout comme il y a des revues de design, nous mettons en place des revues de recherche où nous pouvons présenter nos sujets de recherche aux autres. 

    Il m'arrive encore aujourd'hui de mettre un mois, voire un mois et demi, avant de bien comprendre certains sujets sur lesquels je travaille. 

  • Au départ, je ne comprends pas ce que le PM me demande, il n'y a pas de maquettes, pas de contexte sur le projet. 
  • Je tourne en rond, et finalement, tout se débloque lorsque je demande l'avis d'un collègue qui jette un regard extérieur sur le sujet. 

    C'est là que tout devient clair :

    "Ah, en fait, tu pourrais le faire comme ça." 

    Dans certaines entreprises l'écosystème peut être très complexe, avec de nombreux services différents, et cela peut être nébuleux. 

    Nous nous efforçons de créer des workflows pour guider nos démarches. Ainsi, lorsqu'il s'agit de mener une discovery, nous savons comment procéder, et lorsque nous réalisons des tests, nous avons une méthodologie à suivre.

    C'est pourquoi il est essentiel d'avoir des modèles prédéfinis pour nous aider à structurer et à standardiser notre travail, et les research reviews en font parties.

  • Anonyme Research ops · il y a 5 mois
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pour augmenter votre impact de researcher comprenez l’organisation où vous travaillez

    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 ?

  • La stratégie, etc.
  • Quel est l’impact attendu

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Etude qualitative, entretien exploratoire. La phase de préparation est clé !
    Je suis très compétente en méthodologie qualitative et les entretiens exploratoires, car c'est mon domaine d'expertise. Une astuce que j'ai apprise dès le début, c'est que la phase de préparation est d'une importance cruciale pour mener efficacement des entretiens exploratoires.  Il y a une idée préconçue qui m'agace et que l'on entend souvent : "Il ne faut surtout rien dire, rien regarder pour arriver neutre sur le sujet." C'est la première erreur que l'on apprend à éviter lors d'études en sociologie.  On ne peut jamais être totalement neutre, notre regard sera toujours biaisé.  La clé est de reconnaître ce biais et de s'en affranchir. Ainsi, en lisant, en posant des problématiques, en formulant des hypothèses, on s'assure qu'au moment d'être sur le terrain, on est capable de reconnaître ce biais et de dire :  "Ah, ce que je vois, c'est un regard biaisé", et on en est conscient.  Si on ne se prépare pas, tout est biaisé, mais on ne sait pas ce qui est vrai ou faux. Donc, pour moi, la réussite d'un bon entretien exploratoire passe par une phase de documentation.  C'est quelque chose que peu de personnes font. Prendre le temps de lire un peu de contenu scientifique ou même du contenu marketing sur le sujet permet d'avoir des premières pistes de réflexion, un point de référence. Une fois que cela est fait, on construit le protocole d'entretien en se basant sur les hypothèses que l'on souhaite étudier par la suite.  Les erreurs à éviter sont justement d'induire des réponses en prétendant être neutre. Plus on est armé et préparé pour l'entretien, plus on peut être certain que cela sera un échange ouvert où l'on saura laisser la personne s'exprimer sans trop intervenir.  Bourdieu dit qu'un sociologue est quelqu'un qui regarde avec ses yeux, tout comme un photographe prend une photo ou un peintre peint un tableau.  Ainsi, il transcrit une réalité vue à travers son regard.  Cependant, si ce regard reste complètement subjectif, sans être encadré, il devient inexploitable. L'erreur est de croire que la naïveté ouvre toutes les possibilités, alors qu'en réalité, pour moi, cela réduit considérablement la portée de l'étude.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX restructurer une équipe et bien la positionner en interne.
    J'ai commencé à diriger des équipes à la fin des années 90, et si je devais donner un conseil à un nouveau manager, ce serait de lire le livre intitulé "First 90 Days". Ce livre vous aidera à établir le cadre nécessaire pour gérer une équipe, car il existe une différence entre le leadership et la gestion. 

    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

  • L'une des premières choses à faire lorsque vous prenez les rênes d'une équipe, c'est de comprendre sa réputation au sein de l'écosystème.
  •  Ensuite, il y a un travail à faire en interne de l'équipe. C'est un travail qui prend du temps et qui va au-delà des problématiques professionnelles.

    Vous devez d'abord évaluer rapidement les flux de travail et la dynamique de l'équipe : 

  • Est-ce que les membres de l'équipe s'entendent bien entre eux ? 
  • Qu'est-ce qu'ils font ensemble ?

    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 : 

  • une section dédiée à l'UX
  • une équipe UI avec un product manager travaillant avec l'équipe IT
  • un pôle de design visuel

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • N’assumez pas que vos collègues et clients savent ce qu’est l’UX !

    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 :

  • Ce que nous faisons,
  • Comment nous le faisons, et
  • Comment nous pouvons les accompagner sur ces sujets.

    C'est toute la notion d'advocacy, et cela a des répercussions sur votre carrière :

  • Les gens refusent de payer pour votre expertise
  • Ils vous confondent avec d'autres professions
  • Ils ne savent pas exactement où vous intervenez.

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX, comment je travaille avec les développeurs.
    Dans mon expérience professionnelle, j'ai remarqué un paradoxe intéressant : j'ai généralement trouvé plus facile de collaborer avec des développeurs back-end qu'avec des développeurs front-end. Les développeurs front-end sont très impliqués dans le flux de travail d'un projet, et ils ont souvent leur propre vision de l'UX, de l'accessibilité, etc. Ils possèdent une expertise que de nombreux UX designers n'ont pas, mais ils ont tendance à être très attachés à leurs propres idées concernant les interactions, le JavaScript et ce qui est ou n'est pas bénéfique pour l'utilisateur. En ce qui concerne les développeurs back-end, j'ai trouvé leur approche de travail très intéressante. Malheureusement, ils sont souvent considérés comme une priorité moindre dans un projet, et leurs contributions arrivent généralement en fin de processus.  Cependant, j'ai adopté une approche pour remédier à cela dans chaque nouveau projet : Établir un cahier des charges et des exigences très précis pour le front-end, accompagnés d'une documentation approfondie. Cela permet de fournir aux développeurs front-end un maximum d'informations dès le départ. Travailler en collaboration avec les développeurs back-end dès le début du projet. Les développeurs front-end ont souvent des idées bien définies sur l'UI et les interactions, tandis que les développeurs back-end sont avides de connaissances et ont un état d'esprit plus ouvert.  En travaillant ensemble dès le début, les développeurs back-end peuvent apporter des connaissances, des idées et des propositions qui sont plus ouvertes à la discussion que celles des développeurs front-end. Quoiqu’il arrive il est essentiel d'inclure les développeurs front-end et back-end dès le début du projet, lors de la phase de réflexion et de stratégie.  Trop souvent, cette phase stratégique néglige l'apport des développeurs back-end, alors qu'ils ont souvent des idées pertinentes à partager.  Par exemple, lors de la définition des objectifs du projet, des objectifs commerciaux et des objectifs des utilisateurs, il est crucial de prendre en compte les implications du back-end. Pour éviter les problèmes, il est important d'impliquer les développeurs back-end dès le début et de rapidement préciser aux développeurs front-end que les décisions relatives au front-end seront définies par la recherche, la stratégie et les objectifs commerciaux. En ce qui concerne la gestion de projets, j'ai utilisé différentes approches pour m'aligner avec les développeurs.  Par exemple, j'ai souvent utilisé un document Google Docs pour suivre les annotations, en organisant le contenu par chapitres et thématiques (stratégie, recherche, etc.). Cela fonctionne bien lorsque le budget est limité. Une autre approche que j'ai mise en place avec mon équipe il y a deux ans consistait à créer un document structuré de la même manière que le site web et ses pages.  Cela nous a permis de développer une refonte complète du site en ayant un document qui correspondait à chaque section du site. Ce document, qui était accessible aux équipes IT, front-end et UX, nous a permis de contribuer les résultats de nos recherches. L'idée était que lorsqu'une personne consultait le moteur de recherche interne, elle savait qu'il existait un document dans la structure qui était un Google Doc regroupant toutes les informations pertinentes. Ce document contenait des informations provenant à la fois du front-end et du back-end. Pour moi, les documents liés à l'UX doivent être vivants et évolutifs. Le cahier des charges, qui est la référence principale, renvoie à des documents externes tels que les personas, les prototypes, et d'autres éléments importants à détailler. En résumé, pour optimiser la collaboration avec les développeurs front-end et back-end, il est essentiel d 'inclure ces deux parties dès le début du projet et de clarifier rapidement les responsabilités et les décisions.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • La liste de mes red flags en entretiens. Quand dire non et pourquoi !
    Le conseil que j'aurais aimé recevoir plus tôt est de vraiment comprendre et évaluer l'entreprise dans laquelle vous envisagez de travailler, quel que soit votre domaine d'intérêt ou votre profession. Cette prise de conscience a émergé au cours des dernières années, bien qu'elle ait commencé il y a une quinzaine d'années. Ces deux ou trois dernières années ont été particulièrement déterminantes pour moi. Dans la pratique, cela signifie ne pas se concentrer uniquement sur le prestige ou la renommée de l'entreprise. Il est essentiel d'approfondir et de se demander : "Est-ce que cette entreprise va réellement m'apporter quelque chose sur le plan humain et professionnel, dans ma carrière ?"  Un exemple concret : on m'a récemment proposé un poste de direction dans une agence réputée.  Après plusieurs entretiens et une réflexion approfondie, j'ai finalement décliné cette offre, même si elle aurait pu potentiellement changer le cours de ma carrière.  Il est crucial de ne pas choisir un poste uniquement en fonction de la notoriété de l'entreprise, du nom ou du salaire qui peut sembler attractif. Il faut aller au-delà de ces aspects et évaluer la culture d'entreprise ainsi que la manière de travailler. Par exemple, il est important de se demander si mes compétences seront correctement reconnues au sein de l'entreprise ou de l'agence.  Pour éviter de prendre des décisions "aveugles", je pose des questions sur la culture produit et la culture d'entreprise.  À mon stade de carrière, les questions relatives à l'organisation produit ne sont pas forcément les plus importantes.  En effet, il est possible de rapidement évaluer s'il existe une véritable culture de l'expérience utilisateur (UX) à l'intérieur de l'entreprise et de comprendre leur manière de travailler. Cela se reflète dans les projets qu'ils réalisent. On peut également obtenir des indications en posant des questions simples telles que : "Comment collaborez-vous avec les équipes de développement ?" En général, il est possible de déterminer rapidement si l'entreprise a une culture de l'agilité, de l'UX et de la recherche UX. Ensuite, il y a un deuxième niveau de questions axées sur l'équilibre entre la vie professionnelle et personnelle. Le premier conseil est de ne jamais poser ces questions aux ressources humaines, mais plutôt d'en discuter avec les personnes avec lesquelles vous allez travailler.  Demandez-leur de décrire une journée typique et à quelle heure ils terminent leur travail le soir, par exemple.  Lorsque j'ai refusé le poste précédemment mentionné, un élément m'a particulièrement interpellé. Il s'agissait d'un poste de co-direction avec deux autres directeurs. Durant les entretiens, j'ai observé que la femme semblait extrêmement stressée, au bord du burnout, tandis que son collègue était un véritable "workaholic".  Ce constat était un signal d'alerte pour moi, car il est difficile d'avoir trois personnes en co-direction, au même niveau, avec des approches du travail aussi divergentes : une personne obsédée par le travail une autre en proie au burnout  et une troisième qui par exemple, l'importance accordée à la distinction entre travail et vie privée.  Mon expérience m'a montré que ce genre de situation est très malsain, car cela commence petit à petit et glisse rapidement vers une surcharge de travail, créant ainsi un cercle vicieux. Lorsque vous écoutez attentivement lors des entretiens, vous pouvez déterminer la culture d'entreprise.  Malheureusement, ces petits détails sont souvent négligés lors de ces conversations. Il ne s'agit pas nécessairement de poser des questions précises, car vous devez adapter vos questions en fonction de la personne en face de vous. Dans mon cas, leurs réactions n'étaient pas mauvaises lors de l'entretien, mais j'ai pu ressentir une certaine urgence, une inquiétude.  C'est à ce moment-là que j'ai pu dire : "Non merci, ce n'est pas pour moi." Lors de l'entretien, les principaux signaux d'alerte concernant l'organisation des produits que je fuis sont liés à la structure.  Où se situe l'UX ?  À qui est-il rattaché ?  Quelle est son importance ?  Par exemple, si l'UX est intégré au département informatique (IT), c'est un signal rédhibitoire pour moi.  Le deuxième cas est lorsque l'UX est intégré au marketing. Cela pose moins problème, mais c'est tout de même embêtant.  Enfin, les flux de décision sont un autre aspect crucial.  Qui prend les décisions finales ?  C'est ce que l'on appelle la gouvernance, et vous devez poser des questions à ce sujet pour savoir qui valide, par exemple. Pour moi, ce sont les résultats de la recherche qui doivent être validés, et non pas le PDG ou le responsable hiérarchique.  Je reviens donc à la question fondamentale : "L'UX est-il réellement intégré et fait-il partie de la culture de l'entreprise ?" Lorsque l'UX est relégué au département informatique ou au marketing, j'ai eu moins de problèmes à travailler avec des personnes du service marketing qu'avec celles du service informatique. Les détails tels que les méthodologies utilisées, la qualité de la recherche effectuée, etc., sont des éléments qui peuvent être améliorés et sur lesquels les personnes sont prêtes à apprendre. Ce sont également des raisons pour lesquelles vous êtes embauché. En résumé, il est primordial de comprendre la culture et la manière de travailler d'une entreprise avant d'accepter un poste. Ne vous laissez pas séduire uniquement par la renommée de l'entreprise ou les avantages financiers. Posez des questions sur la culture d'entreprise, collaborez avec les personnes avec qui vous allez travailler, et soyez attentif aux signaux d'alerte concernant l'équilibre entre vie professionnelle et personnelle, ainsi que l'intégration de l'UX dans la structure de l'entreprise. En fin de compte, il est essentiel que l'UX fasse réellement partie de la culture de l'entreprise pour garantir une expérience de travail satisfaisante.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Lorsque vous négociez en direct avec un client, baisser son prix n'est pas la fin du monde.
    Je discutais la semaine dernière avec une freelance qui était head of et à finalement décidée de se lancer. On parlait de clients, intermédiaires, lorsqu'elle à dit que quelque chose de très vrai. "Si je travaille en direct avec un client, je préfère baisser mon TJM pour avoir le contrat plutôt que d'avoir un TJM plus haut et ne pas avoir le contrat, ou devoir travailler avec un intermédiaire." Après plus de 2 ans et demi en free, je n'avais pas trop réfléchi sur ce sujet mais je dois admettre qu'en réalité travailler en direct avec son client est toujours plus gratifiant que passer par des intermédiaires. A long terme il y a plus d'avantages d'avoir réussi à avoir mis un pied dans la porte plutôt que pas. (ca depend de la négociation évidemment). Surtout en cette période de conjoncture économique plus tendue niveau cashflow pour toutes les entreprises.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Comment la recherche utilisateur à un impact sur les processus organisationnels

    J'ai relevé un défi que j'ai réussi à relever avec succès : faire évoluer les pratiques de recherche sur la production d'éléments monétisables (rex ici)

    En démontrant qu'il était possible d'obtenir des résultats exploitables plus tôt, cela est devenu un processus standard. Ainsi, des tests utilisateurs axés sur la monétisation dans les jeux doivent maintenant être effectués avant la sortie du jeu.

    Ces tests ont entraîné des changements dans la façon dont la production crée les éléments de monétisation, à la fois en termes de planification et de livrables. 

  • Nous avons entamé des discussions avec les designers sur les types de matériel expérimental nécessaires pour effectuer ces tests.
  • Par exemple, nous encourageons les concepteurs à créer des prototypes plus tôt et à mettre en place un flux de production permettant des itérations et une anticipation, afin de maîtriser les coûts.
  • D'autre part, la recherche utilisateur permet de modifier l’approche des designers et des producteurs quant au processus créatif.
  • Ce qui est paradoxal dans cette histoire, c'est qu'il n'est parfois même pas nécessaire de mener des recherches utilisateurs.
  • Les concepteurs, en créant des prototypes, sont déjà capables de détecter et de résoudre 70 % des problèmes par eux-mêmes.
  • En revanche, si une approche plus traditionnelle en cascade avait été utilisée, avec une spécification détaillée, une construction et une finalisation tardive, rien ne fonctionnerait lors de l'interconnexion de tous les éléments.

    Ainsi, la recherche utilisateur contribue à modifier le flux de travail de manière significative. Ce qui est intéressant, c'est que historiquement dans le domaine des jeux, la recherche intervient à la fin du processus. 

    Dans d'autres industries, la recherche utilisateur peut être présente dès le début mais absente à la fin, cela dépend du contexte. 

  • Historiquement, dans notre cas, nous provenons du contrôle de qualité (QC). Nous utilisions des tests effectués par les développeurs eux-mêmes, et souvent ce sont les éditeurs qui assuraient le contrôle de qualité. Les éditeurs intervenaient à la fin du projet pour valider et décider si le jeu serait publié ou non.
  • Nous avons entrepris de remonter le processus jusqu'à la phase de pré-conception. Je pense que dans les milieux créatifs, l'expérimentation est souvent limitée à des essais internes, et le produit n'est exposé au public qu'à la fin. Il s'agit d'une mentalité spécifique qui freine notre progression en termes de conception et de prototypage plus précoce.

    J'ai beaucoup réfléchi à ce problème où la recherche est réalisée en amont mais pas à la fin, ou à la fin mais pas en amont, et cela m'a amené à réfléchir aux types d'informations et d'observations que vous pouvez fournir en fonction de la phase du projet.

  • Pour les demandes de type prospective ou portant sur l'intention, nous réfléchissons en termes de risques, d'opportunités et de limites. Cependant, pour que cela se produise, les concepteurs (ou autres parties prenantes) doivent être ouverts à cette mentalité. Cela permet d'anticiper, mais pas de prévoir exactement.
  • Pour les demandes d'évaluation, nous procédons à des tests pour déterminer ce qui fonctionne et ce qui ne fonctionne pas, et nous cherchons à comprendre pourquoi. Pendant longtemps, la narration dans les jeux n'était pas testée. C'est pourquoi nous avons commencé à travailler sur un projet visant à montrer qu'il était possible de tester des extraits de scripts, des scènes coupées et à réaliser des montages vidéo pour évaluer la compréhension de la narration.

    En conclusion, pour réussir à faire évoluer la production, il est essentiel de proposer en tant que chercheur des méthodes et des idées d'observations potentielles. Ensuite, il faut co-construire avec les concepteurs dans leur exploration du design et leur processus créatif.

    Pour donner un contre-exemple où la recherche est très présente en amont mais moins à la fin, je pense à l'industrie automobile et à d'autres domaines fortement axés sur l'ingénierie. 

    Dans ces cas-là, les recherches se concentrent davantage sur les neurosciences et les aspects scientifiques, comme la conception des cockpits et la charge cognitive. 

    Malheureusement, il y a moins de recherche effectuée après l'implémentation.  Il suffit de regarder la tendance des écrans tactiles. Il faut quinze étapes pour effectuer une action qui était auparavant réalisée avec un simple bouton, et l'on se demande pourquoi ils n'ont pas testé cette conception jusqu'au bout. Parfois, l'esthétique prime. Dans ces cas-là, on réalise que la recherche utilisateur peut être très présente en amont, mais moins après l'implémentation. Dans notre domaine, c'est l'inverse : la recherche est très présente lors de l'implémentation, mais beaucoup moins en amont, lors de la phase de conception.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX, sur l’utilisation de la biométrie et de l’eye tracking.

    Dans la continuité de mon doctorat en neurosciences, j'ai rejoint Ubisoft en 2014 en tant qu'expert en données biométriques pour les playtests. Pendant plusieurs années, ma principale mission a été de déterminer comment intégrer les outils de neurosciences tels que l'eye-tracking, l'activité cardiaque et l'électrodermale dans les playtests quotidiens. Mon objectif était de définir quelles mesures utiliser, quelles données collecter et dans quel but. J'étais également responsable de la réalisation de ces tests avec ces outils.

    J'aimerais maintenant partager des cas où l'utilisation de l'eye-tracking est pertinente, ainsi que ceux où ce n'est pas le cas.

    Par exemple, pour les menus, l'eye-tracking n’est pas le plus utile. Il n'y a pas de contrainte de temps, et c'est un point essentiel à prendre en compte pour décider d'utiliser ou non l'eye-tracking.

    L'eye-tracking permet d'observer l'attention, ce qui est d'ailleurs une pratique courante en neurosciences. L'attention correspond aux priorités que notre cerveau attribue à différents objets visuels, car il ne peut pas tout traiter en tant qu'information. L'avantage de l'eye-tracking est qu'il nous permet de savoir sur quoi l'utilisateur se concentre au lieu de ce qui était souhaité. À partir de là, nous pouvons déduire les changements visuels à apporter pour attirer l'attention où nous le souhaitons.

    Dans le cas des menus, l'utilisateur.trice est généralement fixé devant son écran et dispose de tout le temps nécessaire pour visualiser les éléments. Dans ce cas, d'autres méthodes de recherche utilisateur sont plus appropriées pour évaluer la validité d'un menu.

    Les menus ne présentent pas de défis visuels, mais plutôt des défis de compréhension et d'architecture de l'information. L'eye-tracking n’est donc pas le meilleur outil pour étudier l'utilisateur dans un menu, sauf dans des cas spécifiques de sites web avec des aspects marketing.

    Pour évaluer l'utilisabilité d'un site web, l'eye-tracking n'est pas nécessairement idéal non plus comme pour un menu sauf si on s’intéresse aux premières secondes et “au côté appealing du site web”.

    Le recueil verbal des pensées à voix haute (think aloud) combiné aux tâches de l'utilisateur et aux retours d'expérience suffisent généralement.

    En utilisant cette approche, l'utilisateur peut expliquer ce qu'il a fait, comme dans cet exemple : "Tu m'as demandé de chercher des sandales sur un site de vente en ligne. J'ai cherché, mais je n'ai pas trouvé la barre de recherche. Ensuite, dans le menu arborescent, je ne savais pas où trouver les sandales."

    Ces informations peuvent être obtenues sans avoir besoin de l'eye-tracking.

    L'eye-tracking est plus pertinent lorsque l'enjeu est de capter l'attention de l'utilisateur dans les cinq premières secondes, notamment pour des marques prestigieuses comme L'Oréal ou Chanel. Dans ces cas-là, les concepteurs peuvent chercher à attirer l'attention de manière spécifique sur leur site web afin de créer une expérience utilisateur émotionnelle qui retiendra l'utilisateur. Dans de tels cas, l'eye-tracking devient pertinent plutôt qu’un test avec de la verbalisation à voix haute.

    Mais alors dans quel contexte utiliser l'eye tracking?

    Il s'agit de situations où il y a un défi visuel, un défi visuo-attentionnel lié à la surcharge cognitive. 

    Un excellent exemple est lorsque vous êtes aux commandes d'un avion ou dans un cockpit de voiture, où il y a des enjeux de sélection d'objets. 

    Dans de telles situations, l'utilisateur ne peut pas être interrompu pendant qu'il effectue ses tâches. Verbaliser la tâche briserait complètement sa concentration visuelle, en raison de la charge cognitive et des considérations sociales, rendant le "think-aloud" impossible. C'est là que l'eye tracking devient pertinent.

    Les décisions doivent être prises rapidement et il ne faut pas manquer d'informations visuelles cruciales.

    En utilisant l'eye tracking dans ce contexte, on peut observer : "Cette information a pris la priorité alors qu'il n'a pas vu ce retour visuel important, et sa réaction a été erronée, ce qui a entraîné son échec." 

    Ou encore :

    "Il était concentré sur un autre retour visuel qui est apparu simultanément, il y a eu un problème de synchronisation entre les deux, ce n'est pas bon."

    En ce qui concerne les échantillons en eye tracking (car on me pose souvent la question), nous n'avons pas besoin d'un nombre plus élevé de personnes par rapport aux tests utilisateurs, car nous ne faisons pas d'analyse quantitative. 

    Si, par exemple, sur six personnes, aucune ne remarque l'objet visuel que nous souhaitions qu'elles voient, et qu'elles regardent toutes ailleurs de la même manière, six personnes suffisent pour détecter un problème de conception et de design. 

    Cependant, il y a des moments où l'on s'oriente davantage vers le marketing et où l'on s'intéresse davantage à la science visuelle, tels que l'ordre d'observation des objets, ce qui attire le plus l'attention, ou sur quel objet le regard se fixe le plus longtemps, traduisant une préférence. 

    Dans ce cas, 12, 16, 24, voire 32 utilisateurs peuvent être nécessaires. 

    Cela relève davantage de l'analyse quantitative, avec l'utilisation de cartes de chaleur et le calcul du pourcentage de temps passé dans certaines zones, par exemple. Cependant, cela devient plus avancé.

    Dans la plupart des cas, je réalise des études qualitatives en utilisant l'eye tracking, tout comme je mène des analyses comportementales. L'utilisateur est placé devant une page web avec sa souris et explore de gauche à droite, tout comme moi je le fais avec l'eye tracking.

    Ce que je dis sur l’eye-tracking n’est pas vrai pour toute la biométrie, d’ailleurs en ce qui concerne l'activité cardiaque et l'électrodermale, il s'agit d'autres outils utilisés pour d'autres raisons, principalement pour mesurer l'état cognitif. Honnêtement, aujourd'hui, nous n'avons pas encore bien compris comment les utiliser efficacement. C'est encore un domaine complexe qui nécessite des recherches et développements supplémentaires. 

    En revanche, l'eye tracking est une mesure directe et fiable. Vous obtenez le point central du regard de l'utilisateur, sans perte de données, même si l'utilisateur porte des lunettes. Vous pouvez même utiliser des lunettes spéciales, telles que les Tobi Glasses, qui sont parfaitement adaptées aux commutateurs et aux jeux mobiles, offrant une précision suffisante pour l'ergonomie cognitive. 

    En gros, l'eye tracking est fiable, à condition de rester dans une certaine plage de précision et de ne pas s'intéresser à des objets visuels trop petits.

    L'avantage de l'eye tracking réside dans le fait que c’est une mesure directe du point central du regard de l'utilisateur, contrairement à l'activité cardiaque, électrodermale ou EEG, qui sont des mesures indirectes. 

    Par exemple, dans l'activité électrodermale, nous observons les réactions physiologiques qui sont elles-mêmes influencées par des états cognitifs. Il existe de nombreuses cascades entre ces mesures et les états cognitifs eux-mêmes, ce qui entraîne une grande quantité de bruit dans les données. 

    La fiabilité de la mesure pose donc problème et vient la question : “qu'est-ce que je mesure réellement dans l'activité électrodermale ? “

    De plus, ces mesures sont très sensibles aux mouvements, donc si l'utilisateur effectue des mouvements avec les mains ou si des artefacts de mouvement sont présents, cela génère beaucoup de bruit et entraîne des pertes de données.

    En conclusion, bien que les mesures physiologiques comme l'activité cardiaque et l'électrodermale offrent une donnée continue et quantifiable, elles sont souvent bruitées, ce qui rend leur interprétation et leur transformation en retours exploitables difficiles. C'est un défi que je n'ai pas entièrement réussi à relever avec l'activité cardiaque et l'électrodermale, mais j'espère que d'autres personnes y parviendront à l'avenir.

    De plus, pour avoir de l’impact avec des données de user test, il est important de prendre en compte le contexte dans lequel se trouvent les designers, leur background et leur façon de réfléchir, et malheureusement ils ne sont pas toujours enclin à correctement rationaliser une expérience d’un point de vue émotionnelle qui permettrait à la biométrie d’apporter un regard intéressant sur les intentions de design.

    En tant que chercheur, il est essentiel de réfléchir à la manière de communiquer ces informations et de s'assurer qu'elles ne tombent pas dans l'oreille d'un sourd. Lorsque vous parlez d'émotions positives, il est possible que ce soit la première fois que l'équipe aborde la question des émotions dans son projet, ce qui peut susciter des réactions de surprise : 

    "Ah bon ? Des émotions ? Comment ça, des émotions ?"

    Cela soulève une fois de plus le défi de la recherche utilisateur. Le niveau de maturité de l'équipe de conception et de rationalisation conditionne jusqu'où votre recherche peut aller et à quel point elle peut être prise en compte dans le processus de conception. 

    Il est essentiel d'établir un dialogue ouvert et de sensibiliser les concepteurs à l'importance des émotions dans l'expérience utilisateur afin de permettre une intégration plus approfondie de ces éléments dans leurs projets.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Si vous vous positionnez dans l’UX writing faites vos recherches pour savoir combien vous valez
    Quand j’ai commencé, j'aurais voulu avoir une idée un peu plus précise de ce que sont les salaires dans les équipes UX.  Parce que mon parcours relève de la fac en Langues et pas d'une école donc je n'étais pas préparée aux salaires de designer et je pense que je me suis longtemps sous-vendue.  C'est mon impression ces dernières années mais l'UX s’ouvre de plus en plus à des profils universitaires qui n’ont pas la connaissance des tarifs dans le privé.  En recherche, pas mal de personnes qui arrivent de la sociologie ou de l'anthropologie. L’UX writing, c'est très atypique, il n'y a pas une formation qui y mène et pas de préparation aux attentes salariales.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Faire ses preuves: Une nouvelle discipline va nécessiter des aménagements pour l’équipe
    C’est la question de l’intégration à des équipes qui se pose. Toute discipline de l’UX a des KPIs et c’est très sain à condition d’arriver dans une équipe ouverte à nos méthodes de travail. D’après moi, c'est un peu un piège dans lequel on tombe souvent dans les métiers de l'UX lors de la construction d’une équipe. On nous fait venir dans une entreprise pour faire des choses, potentiellement dans le cadre d'une transformation digitale dans les grands groupes.  Il faut à la fois qu'on fasse les choses et qu'on prouve pourquoi on ne les fait pas comme avant, tout en essayant d'entretenir de bonnes relations avec des collègues qui faisaient les choses “à l'ancienne.”  Cette situation-là, elle est pratiquement insoluble.  Cette question doit être en cours de résolution quand on arrive. Si en arrivant, on doit continuer à prouver pourquoi on est là, ça installe sur le moyen terme, une ambiance de travail assez délétère.  De mon expérience, ça force à se demander, fondamentalement, qu'elle est notre valeur ajoutée. Tu peux un peu tâter le terrain en entretien d'embauche, et arriver à savoir si: On vient te chercher avec une vision un peu restreinte de l'UX writing, où on va s'attendre à ce que, en te donnant des écrans finis, toi tu relises et que tu harmonises. Ce qui n'est pas passionnant et pas le plus intéressant de ce qu'on a à proposer.  Ou s'il y a un questionnement un peu plus profond sur ces sujets-là.  Ou bien encore s'il n'y a pas encore le questionnement, si tu peux aussi accompagner l'entreprise sur ce terrain-là.  Finalement, avec l'expérience, tu arrives assez facilement à voir où on t'imagine et où tu vas pouvoir aller.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Evaluer la maturité UX d’une équipe et savoir un peu où on met les pieds.
    Pour éviter des tensions dans le travail, on peut vouloir rejoindre une entité UX plus mature. Ce sont souvent des personnes qui savent qu'elles ne vont pas t'attirer en te disant "Rien n'est prêt et j'ai besoin de toi" qui te recrutent. Néanmoins il me semble qu'il y a des questions assez concrètes à poser.  Demander, par exemple, quels sont les objectifs annuels ou trimestriels selon le fonctionnement de l'équipe des leads ? Déjà, tu mets un peu les pieds dans le plat...  Tu peux poser des questions sur les KPIs contenus. Cette question fonctionne mieux s’il y a déjà une équipe d'UX writers. Et c'est rare ! Particulièrement dans l'écosystème français. Donc si tu poses cette question-là et que ça bafouille en face, ça ne veut pas forcément dire que ça va être nul. Mais le développement donne une bonne idée des préjugés que tu vas devoir combattre. Tu peux aussi demander concrètement combien il y a de Tribes et quels sont les objectifs de recrutement en contenu. Si tu vois que le projet est de n’avoir qu’une personne pour l'UX writing et qu'il y a sept ou huit Tribes, ça devient compliqué. En plus s'il n'y a pas d'objectifs de recrutement, ça veut dire que tu vas te retrouver avec la relecture d'écran déjà finalisée. Et tu risques d’avoir du mal à évoluer vers une inclusion dans le cycle de design.  Tu peux aussi demander comment est gérée la traduction, s’il existe des données sur les langues qui génèrent plus de revenus. La pire réponse, c'est "les PM se débrouillent". Alors là, tu comprends que les PM font de leur mieux, mais qu'en fait iels ne se débrouillent pas. Évidemment tu ne demandes pas ça au premier entretien avec les ressources humaines, mais ça donne une bonne idée.  Tu peux aussi aller chercher le ou la Head Of ou Lead sur LinkedIn pour chercher à comprendre la structure et son ancienneté.  C'est sûr que si l'équipe UX a six mois et que l'entreprise à une dizaine d'années, ça donne une bonne idée des tensions qu'il peut y avoir en interne.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Lors d’une prise de poste, identifiez et collaborez avec ceux qui faisaient l’UX writing
    Je pense qu'il faut embarquer tôt toutes les personnes qui jusque-là faisaient des tâches qui vont nous être réservées. Sinon, sans ça, le défi est d’affronter de la résistance. Donc essayer d'identifier les personnes qui faisaient le contenu. Tu as plusieurs typologies. De manière un peu mécanique, tu as la personne qui le faisait, et ça l'embêtait. C'est souvent les PM. Ils adorent nous voir arriver. Les designers entrent aussi souvent dans cette catégorie-là. L'autre catégorie qui est un peu plus compliquée à gérer, c'est les personnes du marketing qui adorent écrire pour le produit, mais qui souvent le font avec une approche marketing qui ne s'accorde pas avec des besoins produit. Et ça, c'est un peu plus compliqué à rattraper.  Donc il faut essayer de leur expliquer ce que tu fais, pourquoi tu vas le faire. Il ne faut pas les challenger directement sur l’écriture. On se dit à ce moment-là tu rentres dans une querelle entre ancien monde, nouveau monde.  La réponse que tu reçois la plupart du temps, c'est "Oui, mais on a toujours fait comme ça"C'est très difficile d'en sortir sans dévaloriser le travail qui a été fait jusqu'à présent. Ce travail a bien sûr été fait en toute bonne foi. La personne du marketing qui s'occupait de rédiger le produit n'était pas là pour torpiller le produit ! J'ai remarqué qu'on s'en sort plus facilement en parlant de problématique d'internationalisation ou d’accessibilité. On va avoir une copie en anglais et on va dire "Là ça marche très bien, mais regarde le site en allemand".  Là souvent les gens tombent de très haut en allant voir le site sur des langues qui sont moins synthétiques. Cette technique permet de mettre en avant le fait qu'il va falloir choisir des éléments signifiants et actionnables plutôt que de récupérer des promesses marketing. Selon les objectifs de la boite pour laquelle tu travailles en termes d'accessibilité, ça peut être un levier intéressant de mettre en exergue les lacunes du contenu qui n'est pas conforme aux problématiques d'accessibilité.  Souvent, les personnes du marketing à ce moment-là se découragent un peu et te refilent le bébé tranquillement. Cela permet d'éviter de les aborder frontalement en leur disant "maintenant c'est moi !", en prenant le risque qu'elles s'y accrochent.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX sur l’internationalisation du contenu.
    Les langues et cultures étrangères ne vont pas s’adapter à votre produit. Une chose qui ne va pas fonctionner, c'est de laisser des personnes natives d'une langue, traduire l'interface simplement parce qu'elles sont internes.  La traduction c'est un métier. Souvent, les personnes qui travaillent dans des start ups ou des grands groupes ont une appétence vers l'international, elles utilisent énormément d'anglicismes et vont les garder dans la copie finale alors que le reste du pays ne s'exprimera pas forcément comme ça. Déjà pour la génération de tes parents, la langue qu'on parle en interne dans une équipe startup, c’est pas clair… et potentiellement, ces personnes-là, selon le projet, ça peut être ta clientèle. Donc c'est un vrai sujet d'aller trouver des personnes professionnelles et ensuite, autant que possible, d'identifier soit une agence, soit des freelances, mais en tout cas d'avoir des points de contact fixes, de ne pas varier en permanence les personnes qui traduisent, c'est assez crucial.  Ensuite, essayer de ne pas tirer les prix vers le bas parce que tu vas trouver des agences peu scrupuleuses qui paient très mal leurs équipes. Si tu as une petite connaissance des métiers de la traduction, tu te rends compte que ça ne peut pas marcher.  Les pros facturent au mot et ont intérêt à traduire le plus vite possible. Si tu lui envoies des docs pour un petit projet, peu prendront le temps de lire pour passer à un autre projet.  Donc si tu as vraiment besoin de briefer, tu paies à l'heure et tu fais une réunion pour expliquer le projet. Soit tu prends des freelances avec qui tu vas avoir une relation sur le long terme, et à ce moment-là, ils vont investir un peu plus de temps pour te garder. Mais quand tu passes par une agence, il y a forcément une énorme perte de connaissance entre ce que tu dis à l'agence et les modifications. En résumé, il faut essayer d'avoir un peu une connaissance de ces métiers-là et on a besoin que les heads of voire les C level fassent preuve de curiosité pour cet aspect du Produit au même titre que pour le dév. Les facs françaises forment des linguistes qui sauraient faire ça très bien si les entreprises savaient où les chercher. On a un problème pour intégrer ces savoir-faire dans des équipes UX ou des équipes produit. On se retrouve avec des ouvertures de pays qui ratent complètement sans que le niveau de connaissance des processus de traduction et localisation progressent. Chez Sendinblue, j’ai poussé pour le recrutement d'une personne à temps plein qui devait s’occuper de ça et nous aider lors du lancement des projets à faire un glossaire (un élément clé du design system) qui va servir à préparer la traduction autant du côté marketing que produit.  Souvent on a le marketing qui vend un produit en lui donnant un certain nom, mais au sein d'une équipe produit, et bien, depuis le début, le projet porte un autre nom.  Pour illustrer tu te retrouves avec le marketing qui va te vendre des pommes, et une fois que tu es dans le produit, c'est des oranges. Maintenant, comment tu vas trouver tes fruits si en plus sur la langue que tu utilises, il y a une ambiguïté et un seul mot pour dire pomme et poire ? C'est un vrai sujet et c'est un sujet pour lequel il faut investir un peu dans peu de temps. La bonne nouvelle, c'est qu'un glossaire, c'est certes du temps mais ce ne sont pas des outils incroyables non plus.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Gérer une équipe d’UX writer.
    Il commence à y avoir en France des équipes contenu. C’est très positif, mais comment ça se passe ? Je pense qu'il y a plusieurs façons d'aborder la chose.  D'une part, je pense qu'il faut être patiente. Évidemment il faut faire avancer les choses, mais dans l'écosystème de la tech en France, tu arrives dans des équipes qui n'ont aucune connaissance ou alors très superficielle des problématiques du contenu et de l'internationalisation. Donc il va falloir poser des jalons progressivement, mais tu ne peux pas arriver directement et avoir des exigences hyper élevéesAprès, il y a des fois où je pense que la chose la plus importante, c'est d'apprendre à dire "non". Être capable de dire "Je ne veux pas travailler sur tous les projets en même temps, toute seule, et arriver en bout de course et faire de la relecture"Refuser de rendre une version appauvrie de ce qu'on aurait pu faire.  Toi, tu sais que la version est appauvrie, mais du côté PM et de toutes les autres personnes, ils voient déjà une grosse amélioration dans ce que tu as fait. Si tu acceptes facilement de travailler comme ça, il n'y a pas vraiment de raison que ça change.  Au début, il faut que tu fasses tes preuves en acceptant des projets qui ne sont pas gérés de manière optimale et en même temps, à un moment donné, il faut passer à une intégration en amont dans le cycle design.. Et cette bascule-là n'est pas évidente à faire, en fait, et elle est presque plus facile à faire s'il y a des projets sur lesquels tu n'arrives pas complètement à éviter la catastrophe. Parce que si tu passes ton temps à mettre des rustines sur des pneus complètement crevés, on ne va jamais changer de pneus !
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX - faire de la recherche sur le contenu. Aller plus loin que les test utilisateurs.
    Ce qui me semble un plus intéressant à faire, c'est de la recherche dans les phases de discovery et d'aller essayer de récupérer la terminologie qu'utilisent les différentes catégories de personnes qui constituent ta cible. Pour moi ça me semble assez central. Parce que si tu construis tout un projet pour te rendre compte qu'en fait les mots les plus centraux de ton produit ne sont pas intelligibles, tu ne vas pas pouvoir le rattraper.  Il y a des techniques de sociolinguistique pour essayer de faire utiliser la "terminologie personne" sans utiliser toi-même les mots pour éviter de les influencer. Il faut construire des scénarios pour aller récupérer cette terminologie-là.  Ensuite tu as des card sorting pour classer des concepts, pour voir comment ils sont regroupés. C'est intéressant !  Tu peux aussi poser de manière très basique des questions que tu te poses à toi-même.  Par exemple, quelle est la différence entre un ·e lead et un ·e client ·e ? Là tu vas pouvoir voir à quel moment, dans un cycle d'achat, on passe d’un mot à l’autre et si ça correspond à ce que tu as mis en place.  Avec un card sorting et des questionnaires construits de manière rationnelle, on s'en sort bien et on arrive à mapper un peu l’écosystème cognitif de la clientèle, idéalement dans plusieurs langues. En tout cas, si je peux conseiller de se pencher là-dessus, on fait remonter des sacrées pépites où tu te rends compte que des termes clés de ton produit, les personnes ne les comprennent pas.  Par exemple c’est très commun d’être dans une situation où le produit existe depuis des années, qu'en interne tout le monde utilise un mot et e n fait ce mot-là n'est pas compris par les clients.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon REX de freelance: Le savoir administratif est important

    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. 

  • Lorsque tu es dans une grande structure, il faut convaincre beaucoup de gens. Il faut avancer et être remboursé à long terme. 
  • Alors que là, c'est une autre histoire. Tu tombes sur quelque chose, si t'as bien géré tes fonds, tu as un budget que tu réinvestis dans ton activité ou de la formation. 

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment tester la monétisation d’un jeu / produit avant son lancement

    La monétisation est un aspect crucial, souvent négligé, qui nécessite de se poser la question fondamentale de la valeur ajoutée pour l'utilisateur. 

  • Est-ce que ce que vous prévoyez de vendre apportera une réelle plus-value à son expérience ? 
  • La valeur ajoutée peut revêtir différents aspects, tels que l'utilité, le social, l'émotionnel, etc. 

    Il est donc essentiel de prendre en compte ces différents aspects.

    Lorsque le design est défaillant et que l'expérience monétisée ne s'harmonise pas du tout avec l'expérience centrale existante, cela pose problème. 

    Comment tester cela ?

  • C'est un processus relativement simple. Vous mettez votre design entre les mains des utilisateurs et vous les faites tester votre produit, votre service, votre service client, en bref, tout ce que vous souhaitez proposer. 
  • Vous évaluez ensuite dans vos boucles de design si l'élément monétisé apporte une valeur en termes d'expérience utilisateur par rapport à votre offre de base.

    L'objectif de la recherche était de déterminer si les éléments monétisés s'intégraient dans le cadre suivant : 

  • étaient-ils attrayants
  • bien réalisés ?
  • adaptés au design ? 
  • En termes de valeur étaient-ils équitables par rapport au marché ? Il est très important de tenir compte des benchmarks du marché car c’est comme cela que les utilisateurs réfléchissent.

    Du côté méthodologique, nous avons d'abord pris en compte les attentes des utilisateurs et évalué la situation sur le marché. 

    Ensuite, nous avons procédé à des tests d'expérience utilisateur, une étape cruciale. Nous avons simulé, fait tester et recueilli les impressions des utilisateurs pour qu'ils puissent se projeter dans l'expérience principale. 

    Si les utilisateurs.trices n’arrivaient pas à utiliser la feature monétisée, cela signifiait que cela n'avait aucune valeur. Nous avons ensuite mené des entretiens plus précis sur certaines boucles d'expérience en fonction des éléments testés. Nous avons également organisé des groupes de discussion pour évaluer la perception sociale des joueurs.

    Les groupes de discussion étaient particulièrement utiles pour anticiper les réactions sociales potentielles ou les retours négatifs des joueurs (éviter un backclash). Ces groupes recréent des atmosphères sociales qui permettent de détecter les potentielles sources de problèmes ou, inversement, les éléments positifs qui pourraient se développer grâce à l'émulation sociale. Nous avons mené plusieurs entretiens en groupe, entre trois et cinq, pour observer les dynamiques et les réactions des participants.

    En conclusion, il est important de comprendre que les résultats que nous livrons mettent en liumière des risques-opportunités, et non sur des conversions ou des estimations de ventes. 

    Voici le framework , il s'agit d'identifier : 

  • les risques et les opportunités
  • De situer les éléments monétisés par rapport à l'expérience principale
  • De déterminer leur importance, leur valeur ajoutée et leur pertinence. 

    Nous pouvons ensuite hiérarchiser ces éléments pour aider les monetisation designers à fixer des prix. 

    Les entretiens sont essentiels pour comprendre le pourquoi, les intentions des concepteurs de monétisation. Ils permettent également de challenger ces intentions.

    Pour illustrer ce point, je me souviens d'un cas concret où une équipe envisageait de vendre des couteaux en jeu. 

    Cependant, après des tests approfondis, nous avons réalisé que le design du jeu ne favorisait pas les combats au corps à corps, qui étaient les seuls moments où les joueurs et joueuses pouvaient voir les couteaux. 

    Par conséquent, cette proposition de valeur ne fonctionnait pas, malgré la qualité des animations réalisées. Cette histoire met en évidence l'importance du rôle des chercheurs utilisateurs pour réaligner les idées avec l'expérience centrale du jeu.

    Pour conclure, il est primordial d'inclure des compétences marketing pour compléter le point de vue utilitaire souvent privilégié par les UX researchers. L'inclusion de ces compétences dans la recherche permet de compenser les biais propres aux chercheurs et d'identifier les opportunités de création de valeur pour l'utilisateur.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Acceptez que votre recherche soit instrumentalisée pour trouver du soutien. Mais de la bonne manière

    "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 : 

  • "Pourquoi voulez-vous tester des éléments à vendre alors que le jeu n'est pas encore finalisé ? 
  • Cela va biaiser les résultats, c'est absurde, etc."

    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. 

  • Les designers sont réticents, ce qui complique davantage la situation. 
  • Les acteurs du volet commercial veulent quant à eux conserver leur part du gâteau.

    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. 

  • Il me permet de trouver les bonnes personnes en interne, celles qui peuvent m'aider à réaliser mes projets. 
  • Cela me permet également de mieux comprendre les enjeux politiques en amont grâce à ces discussions. 

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ne vous arrêtez pas aux premières critiques sans avoir rendu tangible votre vision avec un proto

    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 : 

  • d'initier la recherche de mon côté sans en parler à personne
  • Présenter les résultats obtenus en disant : "Regardez, j'ai déjà commencé à travailler sur cela." 

    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.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon REX sur l’implémentation et la restructuration de process UX avec SAFe

    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 : 

  • La partie implémentation et développement qui fonctionne en mode scrum classique avec des sprints de développement, où nous intervenons pour ajuster les éléments de design et gérer les tests utilisateurs en cours de sprint. 
  • En parallèle, nous travaillons sur la recherche et la découverte, qui ne fonctionne pas en sprint car cela peut prendre du temps variable en fonction des besoins et des activités, parfois une semaine, parfois un mois. 

    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. 

  • En terme d’outils nous utilisons principalement Google Sheet pour gérer le backlog de découverte, car c'est plus pratique que des outils traditionnels pour établir les priorités avec différents axes de travail. 
  • Pour les ateliers et la priorisation des différents types d'utilisateurs, nous utilisons Miro, car c'est l'outil déployé chez mon client. 
  • Ensuite, nous résumons les résultats dans Google Sheet pour suivre les étapes, déplacer les éléments dans nos backlogs, et réaliser le design. Pour le design, nous utilisons différentes méthodes en fonction des besoins, comme Figma pour les designs plus complexes, ou des Google Sheets ou Google Docs pour les éléments plus structurés, comme les formulaires. Parfois, nous créons également des prototypes pour les faire tester, mais dans le projet actuel sur lequel je travaille, ce n'est pas nécessaire.

    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. 

  • Nous avons convenu qu'au début, nous aurions un Scrum Master commun pour gérer plusieurs squads
  • À terme, si nous devions multiplier les squads, nous aurions besoin d'un Scrum Master dédié à chaque sous-produit, qui pourrait gérer plusieurs squads, dans une limite de trois maximum. Cela s'explique aussi par le constat que le rôle de Scrum Master n'est pas à temps plein, et qu'il peut être partagé entre plusieurs produits et squads.
  • Cependant, gérer un écart important entre trois squads avec des équipes potentiellement différentes serait difficile à gérer en raison des différences de rythme, de fuseaux horaires et de rituels (notamment pour les daily.)  D’où l’objectif de maintenir une cohérence au sein d'un même produit ou groupe de produits en impliquant les mêmes acteurs dédiés.  Nous avons ainsi synchronisé les moments clés, tels que :  La planification des sprints, en commençant par une planification globale avec le Product Owner (PO) global, puis en se divisant en planifications spécifiques à chaque sous-produit.  De même, pour les rétrospectives, nous commençons par celles de chaque sous-produit avant de remonter au niveau global, afin de toujours garantir une vision transversale.  Les daily stand-ups sont également synchronisées pour maintenir un rythme cohérent.  De plus, si nous avons besoin de lancer des sous-projets, nous appliquons le même principe en adaptant l'échelle de manière appropriée et intelligente, en avançant avec un backlog commun qui se divise ensuite en sous-backlogs par sous-produit, avec une partie dédiée à la découverte et au développement.  Nous avons imposé cette approche, en laissant les équipes discuter des détails de formulation. Au départ, elles étaient réticentes, mais nous avons expliqué que c'était ainsi que nous allions procéder en raison du contexte spécifique du produit.  Pour résumer : Étant donné que les équipes n'étaient pas en mesure de nous proposer une organisation répondant à nos besoins, nous avons pris l'initiative de la créer. Cette organisation correspond à nos besoins actuels, mais nous sommes conscients qu'elle peut nécessiter des ajustements, que nous effectuerons en temps voulu. Nous avons déjà mis en place un modèle adaptable en fonction des KPI’s. Pour plus de rigueur, j'ai également effectué une recherche pour vérifier que cette approche n'était pas uniquement de mon invention, et j'ai trouvé des frameworks similaires, tels que LeSS et LeSS Huge qui correspondent à 95% à ce que nous avons proposé.  Nous avons ainsi pu légitimer notre approche en nous appuyant sur ces références externes.  En appliquant ces principes, nous avons un PO global et des area PO pour chaque zone et sous-produit, avec des domaines de besoins spécifiques.  Cette approche a permis de faciliter l'adhésion des équipes à la stratégie. En effet, nous avions constaté que l es équipes partaient souvent trop rapidement dans la définition du produit sans prendre en compte la stratégie produit et la roadmap.  Même si cela ne correspond pas entièrement à notre modèle actuel, nous estimons que c'est la meilleure approche pour notre équipe et cela nous permet de mieux remonter les besoins des utilisateurs.  Il est également important de noter que les recherches que nous effectuons ne se limitent pas uniquement aux aspects digitaux. En effet, dans notre entreprise, nous ne demandons pas aux équipes de remonter les problèmes liés uniquement au digital. Même si certains aspects ne sont pas digitaux, il est important de les reconnaître, car ils peuvent être transmis aux équipes responsables des processus, des ressources humaines, des infrastructures, de la communication, etc. De ce fait, la phase de recherche, bien qu’officiellement liée à un produit, a une portée plus transverse et nous remontons régulièrement des sujets à d’autres équipes produits (ou même des équipes ne fonctionnant pas sur ce type de modèles). Notre objectif est de travailler de manière globale, holistique et systémique avec toutes les entités, sans se limiter à notre domaine digital. En effet, cette approche va à l'encontre des objectifs mêmes de la transformation.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • L’importance de la recherche sur et avec les parties prenantes.
    Au cours de mes années d'expérience, j'ai observé deux erreurs majeures qui sont fréquemment commises : Ne pas prendre le temps d'aligner ses équipes avant de démarrer Vouloir aller trop vite en prenant des décisions trop rapidement Ces erreurs sont souvent à l'origine des problèmes que nous avons été appelé à résoudre en entreprise. Car après quelques semaines, quelques mois, voire quelques années, la vision de l'équipe s'estompe, l'alignement disparait, et les membres de l’équipe perdent l’envie de travailler ensemble. En réalité, pour créer une équipe forte, il est essentiel que chacun ait sa trajectoire. Travailler seul peut sembler plus facile au démarrage, mais travailler en équipe implique de comprendre les trajectoires individuelles et de parvenir à une vision commune. Erreur 1 : Ne pas prendre le temps d'aligner ses équipes Lorsqu'un projet démarre, il arrive souvent qu'on nous dise :  "Voilà, nous avons lancé ce produit, nous l'avons conçu tous ensemble. Nous sommes vraiment une équipe pluridisciplinaire, mais nous nous posons des questions sur la pertinence du produit. Nous aimerions savoir ce que les utilisateurs en pensent."  À ce stade, nous demandons souvent à interviewer les parties prenantes avant de nous lancer dans le projet.  Nous prétextons vouloir connaître les messages clés qu'ils souhaitent transmettre à travers le produit. Selon leurs réponses, nous leur demandons si ces messages sont bien partagés par tous.  La plupart du temps, ils nous répondent : "Oui !" Mais en réalité, lorsque nous commençons à interroger les personnes, nous constatons qu'aucune d'entre elles ne dit la même chose. Il arrive même que plusieurs d'entre elles disent le contraire.  Ainsi, à la fin de ce processus, nous rassemblons tout le monde et nous présentons ce que personne n'a osé dire seul, afin de réaligner l'équipe.  Un exemple frappant me vient à l'esprit. Il s'agissait d'une grande banque qui nous avait présenté une proposition de valeur, mais celle que l'équipe avait transmise était très différente de celle dont elle nous avait parlé lors du briefing... En fait, cela faisait deux ans que l’équipe travaillait sur ce produit, mais elle n'était pas alignée, ce qui expliquait que le produit soit confus. Les personnes qui avaient proposés telle ou telle fonctionnalité poussaient dans des directions opposées..  Il s’agissait plus d’un amalgame de fonctionnalité, sans un vrai scénario d’usage, ! Ainsi, à un moment donné, il était inutile de lancer le produit sur le marché, car il n’y avait pas de cas d’usage réels.. Ce genre de situation est ce que nous constatons régulièrement dans notre quotidien, alors que finalement, l'UX (expérience utilisateur) n'est qu'une question de posture et d'attention.  Pour éviter cela, il est essentiel de favoriser le partage d'une vision basée sur les besoins concrets du terrain, en écoutant attentivement chacun et en donnant l'opportunité à tous de s'exprimer. Comment y parvenir ?  En menant des entretiens avec les parties prenantes et en offrant un moyen de transmettre cette compréhension interne entre les équipes. 2. Une autre erreur courante est de vouloir aller trop vite et de prendre des décisions hâtives.  Je vois tellement d'exemples autour de moi. Mon conseil est justement d'éviter de précipiter les décisions. Trop souvent, la tentation est grande de prendre des décisions sans réellement ouvrir la discussion et obtenir l'adhésion de tous. Pourtant, ce que j'ai appris, c'est qu'il est illusoire de prétendre avoir pris une décision si elle n'a pas été acceptée par l'ensemble des parties prenantes.  Prendre une décision trop rapidement, c'est comme construire une maison sans avoir posé de fondations solides. À un moment donné, les problèmes surgiront, comme de l'eau qui s'infiltre en dessous ou des fissures dans les murs. Il n'y a pas de secrets. Prenons l'exemple de la définition d'une offre au sein d'une entreprise.  Si cette offre ne couvre pas l'ensemble des besoins de chacun, les personnes ne la présenteront pas spontanément à leurs clients Chacun la présentera de manière différente, voire même contradictoire, parce qu'ils ne l'auront pas vraiment intégrée. Cela arrive fréquemment dans les offres de produits. Une offre de service ou de produit, si elle n'est pas partagée, comprise, assumée et si les personnes ne sont pas convaincues, ne sera pas vendue efficacement.  C'est pourquoi il est crucial de cartographier ces besoins lors d'ateliers avec les parties prenantes. Lors de ces ateliers, il est important de permettre à chacun d'exprimer ses ambitions personnelles, car c'est ce qui compte le plus. Quant au reste, il peut y avoir des personnes qui n'ont pas envie de parler ou de s'exprimer, mais qui ont moins d'ambition ou d'envies personnelles, et elles peuvent néanmoins trouver leur place dans l'équipe."
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mes leviers pour améliorer la maturité Design Ops en interne.

    Ce que je fais pour améliorer la maturité DesignOps en interne est principalement de la pédagogie basée sur des mesures de maturité (j’utilise en général le modèle de Sauro) et une cartographie DesignOps. 

    J'adopte une approche pédagogique via les ateliers pour: 

  • Expliquer les composants d'une stratégie
  • Et comment les mettre en œuvre. 

    (Lors de ces ateliers je ne fais pas toujours de distinction nette entre la recherche et la conception, car dans le contexte dans lequel je travaille, ces deux aspects sont souvent étroitement liés, bien que nous mettions davantage l'accent sur la recherche.)

    Je m'appuie sur un modèle de cartographie matricielle que j’ai mise en place sur la base des définitions du Nielsen Norman Group et que nous suivons tous les mois.

    Nous faisons un constat initial sur:

  • Des axes définis tels que le processus, la capitalisation, le recrutement, le développement des compétences, le leadership, etc.
  • Nous identifions les axes sur lesquels nous voulons nous concentrer pendant le mois.
  • Ensuite, chaque mois, nous travaillons sur ces sujets et nous mettons à jour, faisons évoluer et faisons avancer nos pratiques pour gagner en maturité. 

    En amont, nous avons également travaillé en équipe sur la culture et les valeurs communes de l’équipe.

    Cependant, la partie la plus délicate reste souvent la mesure du retour sur investissement (ROI) de notre travail. 

    Les discussions sont souvent compliquées car certaines personnes considèrent le ROI uniquement en termes d'argent, alors que nous devons parfois mesurer des éléments plus intangibles, tels que le temps économisé, ce qui peut être difficile à quantifier étant donné que nous intervenons souvent en amont du processus. 

    Nous ne pouvons pas toujours calculer de manière précise l'impact de notre travail sur le retour sur investissement, à l'exception d'exemples concrets tels que celui du bouton à 300 millions de dollars mentionné par Jared Spool

    Il est donc difficile de trouver des exemples clairs et immédiats. 

    Cependant, nous continuons à progresser en mettant en place des indicateurs clés de performance (KPI) pertinents pour notre équipe, notamment via la mise en place systématique, pour chaque produit, d’enquêtes de satisfaction qui permettent de mesurer l’impact des changements apportés à chaque release. J’ai pour cela mis en place un modèle d’enquête complet basé sur l’UMUX-Lite (avec calcul du score System Usability Scale (SUS) équivalent) avec un workflow d’analyse en grande partie automatisé. Cela nous fait gagner énormément de temps car il est extrêmement simple et rapide à mettre en place.

    Mais cela ne peut fonctionner qu’après avoir passé du temps à démontrer l’importance et la valeur de ces indicateurs aux parties prenantes internes et externes de l'entreprise, ainsi qu’à nos clients, car souvent ils souhaitent conserver leur “NPS” (Net Promoter Score) qui est souvent mal utilisé, mal compris et surtout très peu pertinent… Bref, c'est souvent la partie la plus difficile et la moins consensuelle, mais nous progressons petit à petit sur cet aspect, avec notamment la mise en place d'un portfolio percutant pour notre équipe, à la fois en interne et en externe.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Commentaires