chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
520 résultats
Hashtags les plus utilisés
  • 116
  • 59
  • 50
  • 42
  • 25
  • 24
  • 21
  • 19
  • 19
  • 17
  • 16
  • 14
  • 12
  • 12
  • 11
  • 10
  • 10
  • 9
  • 9
  • 7
  • 7
  • 6
  • 6
  • 6
  • 6
  • 6
  • 5
  • 5
  • 5
  • 5
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1

Postes

  • ·
  • ·
  • Cas récent d'amblyopie chez un enfant de 6 ans.
    J'ai récemment reçu en consultation un jeune garçon de six ans, accompagné de ses parents, pour une évaluation de la vision. Les parents étaient préoccupés car ils avaient remarqué que leur fils avait tendance à fermer un œil lorsqu'il se concentrait sur des objets à distance ou lorsqu'il regardait la télévision. Après un examen approfondi, j'ai diagnostiqué une amblyopie dans son œil gauche. L'amblyopie, souvent appelée 'œil paresseux', est une condition où l'acuité visuelle d'un œil est significativement plus faible que l'autre, même avec des lunettes ou des lentilles de contact. Dans le cas de ce garçon, l'amblyopie s'était développée en raison d'une différence non corrigée de réfraction entre ses deux yeux, une condition connue sous le nom d'anisométropie. Pour traiter l'amblyopie de ce patient, j'ai prescrit des lunettes correctrices pour équilibrer la réfraction entre ses deux yeux. En outre, j'ai recommandé un traitement d'occlusion, qui implique de couvrir l'œil sain avec un patch pendant plusieurs heures chaque jour pour encourager l'utilisation de l'œil amblyope et améliorer sa vision. Les parents étaient soucieux de savoir si leur fils récupérerait une vision normale. J'ai expliqué que le traitement de l'amblyopie est le plus efficace lorsqu'il est commencé tôt, et étant donné son jeune âge et l'engagement des parents à suivre le plan de traitement, j'étais optimiste quant à ses chances de récupération. Cependant, j'ai souligné l'importance du suivi régulier et de l'adhésion stricte au traitement pour maximiser les chances de succès. Ce cas illustre l'importance de la détection et du traitement précoces de l'amblyopie pour prévenir les déficits visuels à long terme chez les enfants
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mise à jour de mes découvertes sur mes sujets de recherche de 2023.
    Je suis actuellement impliquée dans une recherche passionnante qui pourrait avoir des implications majeures dans le domaine de la vision. Notre projet porte sur la régénération des cellules ganglionnaires de la rétine, qui sont cruciales pour la transmission des informations visuelles du œil au cerveau. Normalement, chez les mammifères, ces cellules, une fois endommagées, ne se régénèrent pas, ce qui peut entraîner une perte de vision permanente. Notre recherche vise à trouver un moyen de stimuler la régénération de ces cellules chez les adultes. Nous avons récemment fait une percée en identifiant un cocktail de facteurs de croissance et de molécules qui, lorsqu'ils sont injectés dans l'œil, semblent encourager la croissance de nouvelles cellules ganglionnaires. Ces résultats sont encore préliminaires, mais ils sont prometteurs. Nous avons observé une régénération significative dans des modèles animaux, ce qui pourrait ouvrir la voie à de nouvelles thérapies pour des conditions comme le glaucome ou les lésions du nerf optique. Nous travaillons actuellement à affiner notre compréhension des mécanismes sous-jacents à cette régénération. Le prochain pas sera de tester l'efficacité et la sécurité de cette approche dans des modèles plus complexes et, à terme, de planifier des essais cliniques. Il est encore trop tôt pour prédire l'impact clinique de ces découvertes, mais l'enthousiasme au sein de notre équipe est palpable. Nous espérons que nos travaux pourront un jour contribuer significativement à la lutte contre la cécité et les troubles visuels graves. Je suis impatiente de partager davantage de nos découvertes à mesure que notre recherche avance.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • La nouvelle gamme de tonomètres de la marque OptiVision
    Chers collègues, je voulais partager avec vous mon expérience avec la nouvelle gamme de tonomètres de la marque OptiVision. Comme vous le savez, mesurer la pression intraoculaire est crucial dans la gestion du glaucome. J'ai récemment fait l'acquisition de leur dernier modèle, le OptiVision Xpert, et les résultats sont remarquables. Ce qui distingue ce tonomètre, c'est sa précision et sa facilité d'utilisation. Il utilise une technologie de mesure non contact, ce qui est très confortable pour les patients, surtout pour ceux qui sont anxieux ou qui ont des yeux sensibles. J'ai constaté que les lectures sont cohérentes, ce qui est essentiel pour le suivi des patients atteints de glaucome. En outre, le logiciel intégré facilite grandement le suivi des données des patients. Il permet une analyse détaillée et une comparaison facile des mesures au fil du temps. Cela a été un atout pour personnaliser les plans de traitement de mes patients. Je tiens également à mentionner leur service client exceptionnel. L'équipe d'OptiVision a été très réactive à mes questions et a offert une formation complète à mon équipe pour s'assurer que nous utilisions l'appareil de manière optimale. Je recommande vivement ce tonomètre à toute clinique cherchant à améliorer son diagnostic et son suivi du glaucome. Si vous avez des questions ou si vous souhaitez voir l'appareil en action, n'hésitez pas à me contacter.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Traitement de cataracte sur personne âgée souffrant de diabète et d'hypertension.
    Je me souviens récemment d'un cas particulièrement marquant. J'ai eu l'occasion d'opérer une dame de 78 ans souffrant de cataracte avancée. Ce qui rendait ce cas exceptionnel, c'était ses antécédents médicaux compliqués, notamment un diabète de longue date et de l'hypertension. Lors de l'évaluation préopératoire, j'ai accordé une attention particulière à l'examen du fond d'œil et à la mesure de la pression intraoculaire, conscients que ces conditions pouvaient compliquer la chirurgie. J'ai choisi de procéder à une phacoémulsification, une technique moderne qui réduit les risques d'incisions et de complications. Le jour de l'opération, je me sentais concentré, conscient des risques mais confiant dans ma préparation. L'intervention s'est déroulée sans encombre, et j'ai pu retirer la cataracte avec succès. Après l'opération, le suivi de la patiente était crucial. Sa condition diabétique nécessitait une surveillance rapprochée pour prévenir tout risque d'œdème maculaire ou de hausse de la pression oculaire. Quand elle est revenue pour son contrôle post-opératoire, j'ai été ravi de constater que sa vision s'était considérablement améliorée. Elle m'a remercié, les larmes aux yeux, me disant combien cela avait changé sa vie. Pour moi, c'est ce genre de moments qui donne tout son sens à ma profession. Ce cas m'a rappelé l'importance d'une approche personnalisée et d'un suivi attentif, surtout chez les patients âgés avec des comorbidités
    • 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 :)  https://www.linkedin.com/pulse/ux-researcher-junior-comment-sins%25C3%25A9rer-sur-le-march%25C3%25A9-vancompernolle
    • 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 1 an
    • 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
  • 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ées.  Aprè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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Le cadrage, une clé pour la compréhension et la réussite d'un projet
    Il faut toujours commencer par bien cadrer et le faire vivre, car on ne peut pas comprendre une équipe ou un projet sans cela.  D'ailleurs, c'est ce qui m'a donné envie de faire ce métier lorsque j'étais dans une école de design. On nous demandait souvent de créer des produits, sans vraiment nous dire "pourquoi?".  Pour moi, avoir un bon cadrage, c'est avant tout avoir un cadrage qui évolue constamment. Trop souvent perçu comme statique, le cadrage doit au contraire s'adapter aux nouvelles informations qui émergent tout au long du projet.  C'est une question de gestion des attentes et de définition préalable. Pour moi, le cadrage est en réalité un espace partagé où l'on établit les priorités, mais surtout où l'on le revisite constamment. Prenons l'exemple d'un projet que nous avons réalisé récemment, qui a duré un mois avec une étude.  Dès le premier jour, nous écoutons et commençons à organiser les idées.  Au bout d'une semaine, nous avons déjà affiné notre approche Mais c'est souvent pendant la deuxième et la troisième semaine, lorsque nous écoutons les retours des équipes, que nous revoyons nos objectifs et que nous les repriorisons ensemble.  Il peut arriver que nous réalisions que nous ayons oublié un objectif clé, qui se révèle être l'un des plus importants.  Étant donné que nous travaillons beaucoup à distance, nous organisons cela dans une feuille de calcul où nous numérotons les objectifs par priorités et ajoutons des éléments détaillés sur les résultats attendus.  Mais surtout, nous veillons à revisiter constamment le cadrage du projet pour nous assurer que tout le monde est aligné. Lorsque cela se produit, nous pouvons changer l'ordre des objectifs, revoir la formulation, etc.  Pour ma part, j'utilise un google sheet, mais le cadrage peut prendre différentes formes, comme être collé un mur par exemple. Le cadrage s'inscrit dans le même sujet de l'alignement dont je parle dans ce post (lien à ajouter). Par exemple, hier, j'étais au téléphone avec un client avec lequel nous avions rendu une étude il y a un mois.  Nous avions travaillé en flux tendu car ils nous avaient donné seulement une semaine pour réaliser une étude dans 2 pays.  Entre le recrutement et le rendu, nous n'avions que sept jours jours ouvrables.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Créer un cadre bienveillant pour son équipe.
    Voici les principaux éléments que j'utilise au quotidien pour gérer mes équipes : Tout d'abord, je limite les sujets personnels dans mes échanges avec nos collaborateurs, en me concentrant principalement sur les aspects professionnels.  Je m'efforce de rendre clair ce que nous sommes en train de faire actuellement, et comment cela peut bénéficier aux membres de mon équipe à l'avenir. Peu importe si l'équipe change demain, ou si certains membres ne sont plus présents, cela ne pose pas de problème. J'aide également nos collaborateurs à se projeter en leur expliquant, par exemple, comment ce qu'ils apprennent actuellement peut-être une étape vers une trajectoire de carrière fructueuse dans le domaine "produit".  Je leur donne des conseils sur les formations disponibles en interne auxquelles ils pourraient participer. Je suis toujours convaincu q ue si j'aide nss collaborateurs à s'améliorer, nous ferons un plus long chemin ensemble. Après tout, il est inévitable que les individus aspirent au changement et à l'évolution. À un certain moment, lorsqu'une envie de changement se manifeste au sein de l'organisation pour une raison quelconque, on ne peut retenir personne.  Il est simplement impossible d'aller contre le vent, tout comme on ne peut lutter contre l'eau. L'air circule.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX de tests utilisateurs avec des personnes en conditions de handicaps.
    Quand recruter et dans quel objectif Le recrutement de personnes en situation de handicap peut souvent être plus long et complexe que celui effectué pour des tests d'utilisabilité, pour des raisons évidentes. C'est un projet à long terme. Il est essentiel de définir clairement les objectifs et le processus de sélection.  Avant de se lancer dans le recrutement, il est fortement recommandé de procéder à une série d'audits complets de la base de code, de l'application ou de l'interface. Créez une équipe dédiée au projet "Accessibilité" qui comprendra au moins un designer et un développeur web afin de couvrir les exigences techniques. Testez votre code : assurez-vous de l'avoir testé avec des outils d'audit librement accessibles tels que : Wave Web Accessibility Tool Accessibility Developer Tools Lighthouse Axe Contrast Checker pour tester l'accessibilité des couleurs et gérer les contraintes liées au contraste Colour Contrast Analyser Définissez des objectifs clairs et des directives d'accessibilité pour votre application ou produit. Identifiez vos utilisateurs et leurs besoins spécifiques en termes d'accessibilité. Établissez les directives qui doivent être mises en place à l'échelle du produit et déterminez quand elles doivent être appliquées (établissez un plan avec vos développeurs, Product Owners, Project Managers, Business Owners, etc.)
  • Dans notre cas, il s'agissait de tester un flow complet: onboarding (sign-up form) et product discovery avec des utilisateurs de screen readers. Notre hypothèse était que l'on découvrirait des problèmes mais en réalité, le scree-reader ne permettait carrément pas la navigation du formulaire d'onboarding. Les directives étaient: permettre aux utilisateurs de screen readers de créer un compte et de naviguer la page produit.
  • Je rajoute un point que je n'avais peut-être pas abordé: on oublie souvent qu'il n'y a pas qu'un seul type d'outils utilisé par les personnes handicapées: les screen readers ne sont qu'un infime partie de ces outils, la compagne de mon tester par exemple, utilisait les screen magnifiers. C'est ainsi que j'ai découvert une toute autre dimension. Mais ce serait peut-être un article pour une autre fois :) Réfléchissez à la manière d'intégrer et de respecter ces directives : cela peut nécessiter une révision de la base de code ou du design system. Effectuez un audit d'accessibilité interne (voire plusieurs). Adoptez une approche agile : implémentez, testez, révisez, re-testez… Établissez des priorités : élaborez un plan de recherche pour déterminer quels objectifs d'accessibilité doivent être atteints en priorité. Définissez des critères pour évaluer si ces objectifs sont atteints.
  • c'est très basique à ce stade, on s'attendait à des améliorations à faire, mais en fait le code n'était pas accessible. Donc success/failure rate, time on task, perceived difficulty, satisfaction Avant de commencer le recrutement : Assurez-vous d'avoir une équipe projet en place. Établissez des objectifs clairs. Effectuez un ou plusieurs audits internes (ou faites appel à des experts). Élaborez un plan de recherche (quels tests effectuer, quand, avec qui). Mettez en place un processus de sélection pour le recrutement. Dans le cadre d'un test d'accessibilité, l'objectif est de s'assurer que les personnes ayant recours à des supports ou aides (à l'écran ou externes, tels que des lecteurs d'écran, des outils de contraste, etc.) seront en mesure de naviguer sur votre site. Posez-vous les questions suivantes : Quelles actions doivent pouvoir être réalisées sur ce site ou cette interface (par exemple, les flux critiques tels que la connexion ou le processus de commande) ? Quels sont les différents types de handicaps et quels sont leurs impacts sur nos utilisateurs ? Consultez https://theaccidentalally.com/toolkit/ pour plus d'informations. Quels outils ou supports seront utilisés par quels types d'utilisateurs ? Il arrive souvent que, en voulant "inclure" certains groupes d'utilisateurs soumis à des mesures d'accessibilité, d'autres soient exclus. Par exemple, une vidéo peut être un outil formidable pour une personne dyslexique ou ayant une maîtrise limitée de la langue, mais elle sera totalement inaccessible pour une personne sourde. L'ajout d'une transcription ou de sous-titres peut résoudre ce problème facilement. Ne vous concentrez pas uniquement sur les handicaps les plus "visibles" : de nombreux handicaps ne sont pas visibles, tels que la dyslexie, les troubles anxieux, l'autisme ou les troubles cognitifs, etc. Dans mon entreprise par exemple, notre client base est plus âgée. Donc il coule de source de se référer aux déficiences cognitives de chacun à partir de 60 ans (visuelles, auditives) mais il est aussi intéressant de comprendre le background culturel de nos utilisateurs: si une personne dyslexique peut comprendre un texte complexe (un contrat par exemple), alors une personne dont la langue maternelle n'est pas celle du groupe cible local sera plus susceptible de consommer ce contenu avec aisance. Où recruter des personnes pour un test d'accessibilité : Faites appel à des agences spécialisées.(on en a listé certaines ici) Collaborez avec des associations de personnes en situation de handicap. Consultez des experts du design inclusif (une recherche sur LinkedIn peut être utile). Envisagez également un recrutement en mode guérilla, pourquoi pas ? Note : Les personnes en situation de handicap sont généralement ouvertes à s'exprimer sur leurs besoins, mais il est important de ne pas les réduire à leur handicap. De même, il faut éviter de se concentrer sur un handicap spécifique : une personne aveugle peut privilégier certains outils ou aides, tandis qu'une personne sourde aura besoin d'un autre type de support de navigation. La qualité de votre recherche réside dans la diversité de votre panel.
    • merci! Utile
    • Pas utile
    • Pas sûr

    • Commentaires

    Groupes

    Hashtags

    Groupes