chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
161 résultats
Selection
  • #astuce 138
EN LIEN AVEC VOTRE SÉLECTION
  • 138
  • 26
  • 26
  • 15
  • 14
  • 13
  • 12
  • 11
  • 10
  • 10
  • 10
  • 9
  • 7
  • 6
  • 6
  • 6
  • 6
  • 6
  • 5
  • 5
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 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
  • 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

  • ·
  • ·
  • 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 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
  • 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
  • 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
  • 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
  • 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.

  • 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.

    • MC Casal · Head of Digital Transformation | CX-UX (UXMC NN/g) · il y a 1 an
    • 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
  • 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
  • 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
  • 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 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
  • 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
  • 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
  • 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 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
  • Mes leviers pour améliorer la maturité Design Ops en interne.

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

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

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

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

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

    Nous faisons un constat initial sur:

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Les 3 conseils que j’ai eu et qui m’ont été utiles avant de me lancer en freelance

    Un premier conseil que j'aurais aimé avoir, c'est de savoir que parfois on a des moments de creux en freelance. Ce n’est pas grave et c’est normal, il faut apprendre à gérer ces moments-là. 

    Un autre conseil que plusieurs personnes m’ont donné, c’est : 

    “Si tu ne sens pas une mission, n’y va pas.” 

    Ce qui peut arriver, c’est que tu te retrouves dans la mission, pour laquelle tu n'étais déjà pas très motivée, et à un moment il y a de la friction, ça se passe mal. À ce moment-là, il faut quand même terminer la mission, tu es mandaté pour ça, et là, ça va être long pour toi et pour ton énergie. 

    Tu peux toujours arrêter la mission bien sûr, mais même là on n’est déjà plus dans un scénario pas idéal. 

    Et pour peu que tu aies fait un effort sur ton TJM parce que dans le cadre de la négociation, tu as baissé ton prix, tu vas te retrouver à un moment où tu vas te poser des questions sur toi, te demander : “Pourquoi j’ai fait ça ?” 

    C’est important de raisonner en termes d’effort/effet pour nos missions aussi, et on revient sur le premier conseil de la gestion des creux. Accepter des périodes de creux, ou parfois de dire non à une mission, c’est aussi garder son énergie pour faire quelque chose d’autre qui aura plus de valeur pour soi.

    Ce n’est pas forcément de la valeur financière d’ailleurs, cela peut aussi être te former pour acquérir de nouvelles compétences, refaire ton portfolio ou tout simplement prendre du temps après une grosse mission.

    Donc, le 2ème conseil que je dirais c’est de ne pas avoir peur de dire non à une mission ou à un client quand on ne le sent pas.

    Surtout que la réalité du travail en freelance est que les missions peuvent arriver et se débloquer très vite. On ne peut rien avoir et puis d’un coup, on va avoir une demande et là pour le coup, il faut vraiment réagir vite, et être dispo à ce moment-là est un plus.

    Enfin, dernier conseil bâteau et pourtant important à rappeler, il faut bien cultiver son réseau. Beaucoup de choses passent par le bouche à oreilles, les recommandations, les opportunités de projets. J’en avais déjà conscience avant, et je pense que m’en suis encore plus rendue compte maintenant dans mon expérience de freelance.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les personas et les feedbacks des étudiants, des outils d’optimisation de l’enseignement

    En termes de gestion d’étudiants, c’est marrant, parce que tu as des personas d’étudiants , des typologies et des pattern que tu retrouves d’une promotion à l’autre.

  • Tu as le profil “à convaincre”, celui qui te regarde quand tu arrives au début du cours, type : "Montre-moi ce que tu vaux, prouve-moi que ça va être intéressant d’être là et que ça va m’apporter quelque chose d’assister à ton cours”. 
  • Il ne te le dit pas comme ça, mais tu vois dans ses yeux qu’il faut que tu fasses tes preuves. Au début, ça m’a un peu interpellée parce que ce n’est pas du tout ma personnalité, donc c'était marrant de me retrouver face à cette réaction. Mais si ton cours a un vrai apport, ce profil-là est vite rassuré et embarqué. 

    J’ai plutôt la chance d’avoir eu des promotions d’élèves cools, ils vont être bien les futurs UX. ;)

    En termes de situation d’enseignement plus complexe à gérer, une année j’ai eu une promotion à laquelle j’avais donné un travail d’interviews à réaliser dans le cadre d’un cours de User Research.

    Le cours et le travail sont arrivés en parallèle d’autres rendus dans leur cursus, ce qui a généré énormément de travail supplémentaire pour eux, et en doublon avec un autre projet pour lequel ils devaient faire des interviews aussi.

    Ils m’ont remonté le point à l’issue d’un cours et nous avons dû, avec le référent de la filière, rediscuter du programme et réadapter le contenu des cours sur deux axes :

  • On a resolidarisé le cours avec leur projet de semestre, et on a plutôt positionné plus en amont le cours de user research avec le fait qu'il soit collé à leur grand projet. 
  • On a changé l’objectif du cours pour qu’il vienne plutôt comme support théorique pour qu’ils puissent appliquer la discipline dans leur grand projet de semestre. J’évalue ensuite l’application de la théorie à leur pratique et je ne leur donne pas de sujet complet à traiter en supplément.

    Sur le coup, ce n'était pas un moment agréable, parce que j’ai dû réajuster tout le programme de ma journée en live, mais ça a été très riche d’enseignements et ça nous a permis d’identifier les points à réajuster et de les rétablir.

    J’ai aussi fait le constat que quand ça fait des années qu’on travaille dans un domaine, et qu’on s’adresse à des étudiants, o n a tendance à oublier que pour eux, c’est la première fois qu’ils font l’exercice, et que forcément ils vont mettre plus de temps, ils vont s’éparpiller, ils vont faire des essais, des erreurs, ils sont là pour ça. 

    Maintenant j’ai bien retravaillé les briques de mon cours, je leur demande un peu moins mais mieux pour qu’ils puissent prendre plus de temps d’intégrer les notions et assurer une qualité d’apprentissage plus élevée.

    Et finalement, ces feedbacks des étudiants ont été extrêmement précieux car les deux promotions d’après, le modèle choisi a très bien fonctionné. Une nouvelle fois, l’intégration de feedback des utilisateurs finaux du cours ont permis de bien améliorer l’expérience et l’efficacité de ce module de cours et de son contenu.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Enseigner l’UX, les différences entre le présentiel et le distanciel

    L’enseignement en école ou en université est un vrai challenge humain. Finalement, beaucoup de notions et de connaissances passent par le lien que tu arrives à développer avec ta classe. C’est marrant parce que c’est un peu de la continuité de notre métier de user researcher, il y a des similitudes. 

    Ce que je trouve le plus difficile, c'est l’enseignement à distance. C’est plus difficile de sentir l’énergie de la classe, alors qu’en présentiel je vois à quel moment ils décrochent.

    Je peux m’adapter au rythme et au besoin de la classe sur le moment. 

    Si je commence à perdre leur attention parce que ça fait une heure et demie qu’on est en train de parler de théorie, là je vais faire une pause, ou je vais les motiver, leur dire : “Courage, on fait encore cinq minutes et après on coupe et on relâche tout.” 

    Avoir cet échange-là quand tu es à distance c’est beaucoup plus difficile. 

    Si tu présentes des slides, déjà, ça prend une partie de ton écran, tu vois quatre ou cinq vignettes à côté, ce sont généralement les plus motivés, ceux qui ont leur caméra, le reste de la classe, les 14 autres, tu ne sais pas dans quel état ils sont, tu ne sais pas s'ils sont encore devant leur ordi, s’ils t’écoutent ou pas, s’ils sont en train de chatter avec leurs potes. 

    Après c’est leur problème à eux d’écouter ton cours ou pas, en tout cas, mais c’est ton rôle à toi de leur donner de l’énergie et de t’adapter à leur contexte du moment, et c’est quelque chose de plus difficile à distance je trouve. 

    J’ai trouvé quelques techniques pour faire réagir tout le monde, pour les faire participer au cours, pour dynamiser la séance, je fais beaucoup plus d’icebreakers, d’échauffements aussi. Ce sont des points sur lesquels je suis plus vigilante à distance par rapport au présentiel. Les quelques techniques que j’utilise :

  • Faire un ice breaker en démarrage de cours, et je vois vraiment la différence avec ceux pour lesquels je n’en fais pas. Le dernier cours que j’ai fait cette semaine par exemple, je n’ai pas eu le temps de faire un ice breaker dans le timing et tu sens que tu ne leur as pas insufflé le même niveau d’énergie. Même sur une classe de 19 élèves, en dix minutes ou un quart d’heure, tu as fait un ice breaker donc je pense que ça vaut le coup d’investir ce temps-là pour le reste du cours, pour leur expérience. ;)
  • Anticiper les questions de logistique. Je leur envoie un message la veille pour leur rappeler les horaires, leur donner mes coordonnées et les motiver, leur rappeler aussi que je vais leur demander de mettre leur caméra. C’est important de les préparer suffisamment en avance pour qu’ils ne se retrouvent pas devant le fait accompli le matin, à mettre la caméra alors qu’ils sont en pyjama, il faut aussi qu'ils soient prêts. C'est un niveau d'engagement aussi qu’on demande aux étudiants. Cela permet de les soulager de toutes les petites frictions type ‘où est le lien de connexion ?”, “à quelle heure est le cours ?”, etc. 
  • Être prêt avant le démarrage du cours. Je me connecte toujours 5-10 minutes à l’avance aussi et ça permet de discuter avec eux, les plus ponctuels ou ceux qui viennent d’arriver tôt,
  • Des pauses régulières, même si ce n’est que cinq ou dix minutes pour qu’ils rechargent leur batteries, pour qu’ils aillent se faire un café, fumer une cigarette. 
  • Travailler le cours de manière interactive et interagir avec eux un maximum. À distance, la concentration n’est pas la même, donc pour contrebalancer cela je leur pose beaucoup de questions au niveau du cours, je les fais réagir, participer. Et lorsqu’on travaille des exercices, qu’il y a des rendus, je leur fais faire des feedbacks au groupe qui présente. 

    Ce sont des techniques que j’ai développées de mon côté, et je serais curieuse d’en échanger et d’en apprendre de nouvelles !

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Bien préparer son atelier pour gagner en efficacité et sérénité

    Quelques astuces et écueils à éviter

    Les must have pour préparer un atelier, c’est :

  • Définir tes objectifs d’atelier : ce pourquoi tu fais un atelier et ce que tu veux obtenir comme résultats en sortie de cet atelier.
  • Ton timing : le déroulé doit être timé pour un atelier efficace. Pour être sûr que ton programme est réaliste et que tu auras le temps de traiter toutes tes étapes. Un atelier ne s’organise pas de la même manière si tu as trois heures ou si tu as une journée complète, il faut vraiment que ton format et ton contenu soient adaptés à ton contexte de projet pour rentrer dans le temps prévu, et timé pour pouvoir garder ton cadre et atteindre ton objectif d'atelier.
  • Les participants de ton atelier : savoir qui seront tes “utilisateurs” d’atelier. Connaître ta cible va te permettre de mieux gérer ton groupe sur le moment et aussi préparer des contenus adaptés, par exemple tu ne fais pas les mêmes ice breakers ni les mêmes exercices à des directeurs de banque pour un atelier stratégique versus à des employés pour l’optimisation de leur outil. Comme pour les projets, tu t’adaptes à ta cible concevoir tes ateliers. Tu t’adaptes en termes de discours également. 
  • Tes supports d’atelier : bien les préparer en avance pour être zen le jour J et te concentrer sur l'animation et la facilitation de ton atelier.

    Pour moi, tout doit être prêt avant que tu arrives en atelier, pour te faciliter la vie en animation et t’assurer de sortir avec les résultats que tu veux après l’atelier. 

    Que tout soit calé en amont afin que le jour de l’atelier, tu sois plus qu’ en écoute et en facilitation est primordial, parce que ça va être ça le cœur de ton job.

    Les ateliers passent hyper vite, il faut que tu puisses accompagner les gens, ceux qui n’ont pas compris un point de consigne, que tu puisses bien écouter ce qui se dit pendant l’atelier et bien décrire tout ce qui s’y passe afin de le transformer par la suite. 

    D’où l'importance que tout soit prêt et que tu arrives en atelier en ayant en tête ce avec quoi tu veux sortir de l’atelier, pour pouvoir réorienter au besoin.

    Une astuce si tu ne sais pas comment définir les objectifs de l’atelier, tu peux te poser ces questions : 

  • Comment cet atelier va servir le projet ? Pour quelle(s) raison(s) ? 
  • Quelles sont les étapes d’après ? De quels éléments ai-je absolument besoin pour avancer sur la suite ?
  • Où on en est sur les étapes d’avant ? Est-ce que je suis prêt à restituer l’intégralité de mes éléments.

    Ensuite, une dernière erreur à éviter c’est vouloir participer et être facilitateur en même temps de l’atelier. 

    J’ai vu quelqu'un le faire et je pense que c’est très difficile comme posture, voire pas souhaitable. 

    Parce que déjà, c’est extrêmement énergivore d’animer un atelier, alors vouloir faire l’atelier et en même temps d’accompagner les gens c’est vouloir faire 2 activités avec 2 objectifs différents en 1 fois. 

    Tu ne peux pas diviser les groupes en sous-groupes (car tu participes). Donc lorsque quelqu’un n’a pas compris tu es obligé de réexpliquer pour tout le monde. Tu es moins adaptable à la situation, tu ne peux pas aller aider un groupe et laisser le tien de côté, donc tu ne peux pas ajuster le travail d’un groupe au besoin, et aider à prendre la bonne direction.

    C’est une posture trop complexe d’être engagé et détaché en même temps, le risque est de ne pas pouvoir mener à bien ton atelier et de Je le déconseille, il vaut mieux avoir une posture claire.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les Icebreakers que j'utilise le plus au quotidien

    Chez Whitespace, on utilise pleins d’icebreakers et on a commencé à assembler une base considérable d’idées originales. Comme nous facilitons beaucoup d’ateliers de Design Thinking, d’innovation, de team-building, etc., nous les utilisons constamment. 

    Dans le monde d’icebreakers il y a de toutes sortes, et il faut surtout se poser la question du “pourquoi” avant d’un choisir un au hasard.

    Le besoin devra guider le choix, par exemple, faire connaissance, infuser de la créativité, amener de l’énergie, aborder une thématique spécifique, etc.

    Cela dépend aussi du nombre de personnes, des conditions (en ligne, hybride, ou en présentiel), et du contexte culturel. 

    Voici quelques-uns de mes favoris :

  • Les cartes d’émotions peuvent être utilisées de différentes manières : pour exprimer les émotions du moment ou pour faire un “mood board” pour une nouvelle application. Ça marche bien à tous les coups et peut démarrer des discussions très intéressantes.
  • Zombie Cats : Excellent quand on crée des sous-groupes. On leur demande de trouver 2 choses en commun et cela va créer le nom du groupe. 
  • Les extra-terrestres ont débarqués… - et ils sont sympa, mais ne parlent pas notre langue. Il faut donc expliquer un sujet (par exemple un produit, ou la société dans laquelle on vit) en utilisant des symboles ou des images. Les possibilités sont vastes, et il faut juste se lancer et ne pas avoir peur.  Par exemple, j’avais affaire à un groupe de statisticiens et “data scientists” et je me demandais si les “Zombie Cats” allait bien passer.  En plus, j’avais rajouté une variante où l’on demande à chaque groupe de mimer leur nom aux autres groupes. C’était un grand succès, et les Sunny Pancakes et Spicy Hikers ont gardé leurs identités durant les trois jours du workshop. Dernier conseil: Expliquer le pourquoi, en particulier si les participants sont du côté plutôt séniors ou analytiques.  Par exemple, “nous allons jouer aux légos pour tester notre esprit d’équipe”.  Pour plus d’infos, voir un article à ce sujet: 

    https://www.whitespace.ch/insights/blog/icebreakers-relevant-fun/

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Réaliser des test utilisateurs avec des non-voyants.

    Nous avons réalisé des tests ergonomiques avec des non-voyants dans le cadre d’une évaluation d’accessibilité pour le nouveau site des Nations-Unies à Genève.

    C’était la première fois que j’entreprenais des tests avec des non-voyants et c’était fascinant comme expérience. 

    Dans le passé j'avais regardé des clips où on voyait comment les gens utilisent des logiciels spécialisés, comme JARS, mais je n’avais jamais observé en “live” comment ça se présentait. 

    Voici quelques observations :

    1.Scanner les pages avec les Headers HTML

    Lors du test j’étais vraiment surprise de voir la rapidité à laquelle ils naviguaient. Ils utilisent l’HTML, en général les H2, pour scanner les pages à une vitesse hallucinante. 

    Cela nous apprend que c'est très important de bien coder les pages et de faire vraiment attention aux titres qui ont un vrai sens et sont assez parlants. 

    2.Attention aux ALT tags

    Un autre élément intéressant est l’idée reçue que les ALT tags doivent être renseignés à tout prix. C'est faux. 

    Cela dépend du contexte.

    Si c'est une image purement décorative, il ne faut pas mettre un ALT tag. Dans ce cas, c'est mieux de le cacher ou d'avoir les guillemets vides afin d’ignorer le tag. 

    Par contre, on risque de créer de la confusion si on l’affiche. Par exemple, s'il y a une petite icône décorative suivi d’un lien du même nom, la personne qui va écouter ne va rien comprendre. Au fait, les utilisateurs non-voyants sont très attentifs aux détails, car ils ne veulent pas louper des informations importantes.

    Par contre, si on utilise des images ou des icônes pour la navigation, il faut évidemment avoir un ALT tag car c'est essentiel, sinon ils ne peuvent pas naviguer. 

    C'est un des problèmes qu'on avait vus lors des tests car le footer contenait des liens vers les réseaux sociaux mais sans ALT tags sur les icônes. A corriger donc !

    Dans le monde du design et de la technologie, on a souvent des idées préconçues sur nos raisonnements pour bien faire. En voulant trop bien faire, on peut créer des problèmes.

    Il faut trouver le juste milieu et connaître les “best practices”.

    3 . Attention à l’utilisation des balises ARIA

    Il y a des balises spécifiquement conçues pour les lecteurs d’écrans, ARIA. Ils permettent par exemple de mettre en évidence des sections sur une page, comme le menu principal. 

    À l'occasion des tests, une personne ne comprenait pas ce que voulait dire “Breadcrumb” (le fil d’ariane) parce que finalement c'est un terme technique. 

    Il y a donc beaucoup de choses à prendre en considération.

    Pour finir, un petit bonus :  Est-ce que l’ouverture d’un nouvel onglet pour ouvrir un pdf nuit à l’accessibilité ? Suite à un débat que j’ai eu avec un développeur, j'ai voulu tester ce point en particulier et j’ai découvert qu’au contraire, cela permettait de naviguer plus facilement, pour autant que le PDF soit accessible !

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Bien intégrer le processus UX avec SAFe (et autres cadres de travail agiles)

    “L’UX et SAFe” est un sujet intéressant à maitriser. Lorsqu’on travaille avec les grandes entreprises, il y a de fortes chances qu'elles fonctionnent sur ce modèle. 

    Je ne pense pas avoir la solution parfaite, mais à force d’avoir travaillé dans ce mode et avec les retours de mon équipe chez Whitespace, je commence à trouver des astuces qui nous permettent de mieux fonctionner ensemble.

    SAFe (Scaled Agile Framework), pour la parenthèse, est un cadre de travail qui permet de mettre en place une méthode de développement Agile à grande échelle dans une entreprise. Il fournit une structure pour coordonner et synchroniser les équipes travaillant sur des projets complexes et de grande envergure en utilisant des pratiques agiles telles que Scrum et Kanban. 

    C’est toute une orchestration de cadences, avec de grands rassemblements (PI planning), différents “streams”, un “release train” pour faire du “continuous delivery”, etc. 

    Ça part sur de bonnes bases. Le souci, comme d'habitude, et comme avec la méthode Agile en général, c'est que le rôle de l'UX n'est pas prévu à la base comme élément intégré. 

    Donc à chaque fois, c'est la même question:

  • Comment est-ce qu'on vous intègre dans tout ça?
  • Et vous faites quoi au juste?

    Donc nous sommes obligés de définir notre rôle : on explique qu'o n va faire de la recherche, créer des wireframes et prototypes, les tester avec les utilisateurs, et collaborer étroitement avec les équipes durant le développement..

    Cela demande beaucoup de travail d'éducation de notre côté pour obtenir l'acceptation, voir le respect, des autres membres du projet (ou programme).

    Quels sont les défis et comment peut-on les gérer?

    1.UN STREAM TRANSVERSE POUR LE DESIGN

    Dans un projet récent, il nous a fallu beaucoup de discussions pour faire comprendre qu’il faut définir les éléments transverses avant de se lancer dans la conception et le développement des diffèrents produits (qui font partie d’une même famille). Donc : 

  • un concept de navigation globale,
  • un Design System avec les éléments de base, les composants et templates, et 
  • des règles de contenu et d’interaction

    sont essentiels pour ne pas se retrouver dans un chaos total. 

    Typiquement dans SAFe, cette idée existe pour l’architecture technique mais pas pour le design. Une solution est donc de se rapprocher du Solution Architect et s’intégrer dans le “Architectural Runway”. 

    2.LA MAITRISE DU VOCABULAIRE

    Pour se faire comprendre, il est important d’utiliser le “language” SAFe et Agile, qui sont par ailleurs bien documentés. 

    Dans le contexte d’un large programme, nous avons pu rajouter le “usability testing” pour la “DoR” (Definition of Ready) d’une feature, et d’avoir un “UX QA” comme “DoD” (Definition of Done) pour une story - donc, en d’autres termes, injecter une approche UX dans un monde Agile. 

    3.TRAVAILLER 2-3 SPRINTS EN AMONT

    Préparer les features et stories en amont nous permet de faire des mini tests agiles si nécessaire avec les utilisateurs et de faciliter la vie des développeurs, en leur donnant un cadre bien structuré. Cet argument est en général assez convaincant, il faut juste utiliser des mots clés comme “efficacité” et “qualité.”

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

  • Créer des espaces collaboratifs au-delà de vos outils.

    Lorsqu'il s'agit de créer du sens et de travailler sur des challenges, je pense que l'élément clé est de se créer un réseau de personnes avec lesquelles collaborer. Au-delà des outils, ce sont les relations interpersonnelles qui sont essentielles.

    Parfois, nous avons l'impression de ne pas avoir beaucoup de contrôle sur ce réseau, mais la meilleure façon de l'aborder, selon certaines approches du design, est de créer un espace propice à la collaboration.

    Cet espace de collaboration permet aux gens de poser des questions auxquelles ils n'oseraient pas normalement répondre. C'est un temps précieux pour partager des idées, des concepts et pour s'aligner sur les objectifs réels.

  • Cela peut être structuré, comme de nombreux outils de design ou d'innovation qui se concentrent sur des aspects concrets tels que des produits ou des indicateurs clés de performance.
  • Mais cela peut aussi être informel, avec une discussion libre pour donner du sens à un terme ou à une notion abstraite, sans nécessairement rechercher une définition absolue, mais plutôt une définition acceptée par toutes les parties impliquées dans un contexte donné.
  • Jongler entre ces deux aspects, à la fois formels et informels, permet de créer du sens.

    Un concept intéressant que j'aime utiliser est celui de voir les problématiques et les challenges comme des îles ou des archipels.

  • Les personnes impliquées dans ces îles sont celles qui sont directement confrontées aux problèmes que nous essayons de résoudre. Pour trouver les meilleures solutions, il ne suffit pas de se fier uniquement à un guide préexistant, mais de se tourner vers les personnes locales, celles qui connaissent le mieux la situation. Ils peuvent nous donner des conseils, des astuces et des informations spécifiques à leur contexte.
  • C'est pourquoi créer un réseau est si important, car ces personnes peuvent nous fournir des informations cachées que nous ne connaîtrions pas autrement. En tant que designers, en créant ce réseau, nous facilitons l'accès à la connaissance, ce qui nous permet de prendre de meilleures décisions et de concevoir de manière plus efficace. L'idée de l'île symbolise cette approche, en donnant une forme métaphorique à notre processus.

    Le sensemaking est un moyen de créer du sens et d'aligner les efforts vers une direction commune. Les objectifs viennent ensuite, une fois que nous avons pris les décisions liées à cette direction.

    Lorsque j'aborde un nouveau projet, je n'utilise pas encore d'outil spécifique, car j'arrive souvent au milieu de projets déjà en cours. Cependant, je suis conscient qu'il existe un réseau de personnes dans l'entreprise qui possède des connaissances que je n'ai pas au départ, et qui m'offrent cette opportunité d'accéder à ces informations.

    Il n'y a rien de révolutionnaire dans cette approche, c'est un peu comme réaliser une cartographie des parties prenantes.

    Lorsque nous arrivons quelque part, que ce soit dans une nouvelle entreprise ou au début d'un projet, nous avons accès à des personnes qui peuvent nous orienter et nous indiquer qui détient quelles connaissances dans le domaine sur lequel nous agissons.

    La différence avec le sensemaking et la cartographie des parties prenantes, c'est que cela va au-delà des personnes internes à l'organisation, cela peut également inclure des clients et d'autres parties prenantes externes.

    L'idée est de créer un espace commun, qu'il soit physique ou virtuel, où les gens se rencontrent régulièrement et échangent des informations. Au début, il peut y avoir de l'ambiguïté, mais au fur et à mesure, nous clarifions ce qui est flou et ce qui est clair.

  • L'idée est de formaliser uniquement ce qui est nécessaire pour progresser vers notre objectif.
  • Nous réalisons quels sujets sont les plus importants, et c'est à ce moment-là que nous utilisons des outils plus formels pour définir des objectifs concrets, tels que la création d'un produit.
  • Cependant, nous maintenons également un aspect informel, car la formalité peut biaiser notre approche et nous limiter à un seul type d'objectif sans savoir s'il est réellement adapté à notre contexte.

    Nous voulons créer un sens commun de la situation et des actions à entreprendre. Ensuite, nous mettons en place les actions nécessaires pour progresser dans cette direction.

    C'est là que nous utilisons des outils plus formels pour atteindre nos objectifs. Cependant, nous conservons une approche informelle pour tirer parti des avantages que seule une conversation autour d'une tasse de café peut offrir.

    Dans une cafétéria, nous en apprenons souvent bien plus sur un projet que ce qui est présenté lors d'une réunion officielle. L'aspect informel permet de véhiculer des informations précieuses que nous ne pourrions pas obtenir autrement.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Curiosité et patience comme vertu en tant que professionnel

    J'ai réalisé que l'un des conseils qu'on m'a déjà donné, mais qui est difficile à entendre quand on débute, c'est d'être patient.

    C'est une qualité qui s'acquiert avec le temps, celle de savoir prendre son temps et comprendre que les choses arrivent à leur moment, pas nécessairement quand on les attend.

    Je sais que cela peut sembler vague et générique, mais je n'ai pas de conseil spécifique à donner, car j'ai toujours été curieux et je pense que c'est essentiel. Il est important en tant que designer de s'intéresser à d'autres domaines que le design, d'explorer ce qui se passe ailleurs et de voir comment cela peut enrichir notre propre travail.

    Personnellement, je suis un idéaliste qui a appris à être pragmatique. J'ai toujours eu cette volonté de faire les choses d'une certaine manière, en cherchant une certaine perfection ou du moins quelque chose qui s'en rapproche.

    Il y a une beauté dans cette tentative d'atteindre un idéal, et c'est ce qui me motive depuis le début. Cependant, j'ai aussi appris à être pragmatique et à comprendre ce que nous pouvons réellement accomplir en travaillant avec les autres. Cette compréhension pragmatique est le fruit de mon expérience sur le terrain, car j'ai réalisé que les choses prennent du temps et que chaque personne réagit différemment à ce que nous apportons.

    Au fil du temps, j'ai appris à semer des graines ici et là, et à voir ce qui en ressort vraiment. Cela me rapproche de l'idéal que je souhaite atteindre. J'ai appris à être patient, à comprendre qu'il n'y a pas de solution optimale ou de moyen parfait pour parvenir à quelque chose.

    L'essentiel est de s'engager dans le processus d'essayer, car c'est là que réside l'intérêt. Au début, j'avais du mal à comprendre pourquoi il était si difficile de concrétiser mes idées, malgré ma compréhension du travail d'équipe. Mais au fil du temps, ma patience et ma perception de la capacité des autres à assimiler l'information et à l'appliquer dans leur quotidien ont évolué.

    Ces qualités ne sont pas innées, mais elles se développent avec la pratique. On apprend à connaître les réactions des gens, leur façon d'absorber l'information, et cela varie énormément d'une entreprise à une autre, d'une équipe à une autre.

    Il n'y a pas de méthode universelle.

    Parfois, tout se passe naturellement avec une équipe. Les choses se mettent en place facilement et tout le monde est sur la même longueur d'onde. Dans certaines entreprises, des changements peuvent sembler évidents une fois qu'ils sont mis en place, et on n'a pas besoin d'en faire davantage. Cependant, il y a aussi des moments où des blocages surviennent, pour diverses raisons, justifiables ou non.

    Dans ces cas-là, semer des graines peut être une stratégie utile. On ne sait pas quand elles vont germer ni à quoi elles vont aboutir. Il est important de se rappeler que nous avons peu de contrôle sur le résultat final.

    Ce qui compte le plus, c'est de tendre vers une direction intéressante, de rester pragmatique.

    L'un des défis de la culture actuelle du design est que nous sommes si immergés dans nos processus et nos outils que nous oublions souvent de les contextualiser. Sur le papier, tout semble évident. Les processus et les outils du design nous semblent évidents.

    Mais la réalité du terrain et des autres personnes avec lesquelles nous travaillons est différente. Chacun a ses propres objectifs, impératifs et méthodes. C'est là que la curiosité joue un rôle important. En s'intéressant à d'autres domaines que le design, en sortant de notre bulle, nous prenons du recul et nous comprenons mieux les autres. Nous sommes conscients de leurs impératifs et de leurs processus, et de l'importance que cela revêt pour eux.

    Ce n'est pas seulement une question d'humilité, mais aussi de chercher à partager quelque chose de commun. Lorsque nous parvenons à créer du sens ensemble, nous sommes tous gagnants, car nous avons tous appris des choses que nous ne connaissions pas auparavant.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Superbe deck sur ce qui tue la recherche en interne et ce qui la rend "Killer".
    Dans son deck l'auteur explique 4 erreurs à éviter et 4 astuces pour rendre votre research meilleure avec un jeu de mot en "Killing research" et "Killer research" wikihero-image-id: 1063 Lien du deck. Lien du post Linkedin et comments
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pour le recrutement évitez les case studies à la maison et privilégiez le live challenge.
    Je ne suis pas vraiment fan des cas de design envoyés à domicile. Pourquoi ?  Parce que tu les fais tout seul Je ne sais pas si quelqu'un t'a aidé Si tu as utilisé des ressources, etc.   Le candidat peut prendre beaucoup plus de temps passé que demandé Personnellement, je préfère les cas de conception en direct, où on peut te regarder résoudre un défi. Ça peut sembler difficile, mais en réalité, c'est de plus en plus courant et beaucoup plus simple qu'on ne le pense. Chez Datadog, nous avons de nombreux entretiens et cette phase de défi de conception est réalisée deux fois dans le processus d'embauche. Ainsi, nous devrions être accrédité pour pouvoir mener des entretiens. Il y a un défi très spécifique, très technique, et il y a aussi un défi de création d'un prototype sur un tableau blanc pour un produit où tu dois proposer des améliorations. Nous leur demandons de ne rien préparer, juste de se présenter avec des questions. Ils peuvent travailler dans n'importe quel outil avec le designer qui va guider l'entretien côte à côte. Pour cet entretien, nous n'avons pas trop de questions spécifiques. Il faut juste s'assurer qu'à la fin, le candidat a un tableau blanc avec un premier sketch, même ci c’est très moche. En revanche, c'est très instructif, car on peut vraiment voir comment la personne réfléchit, comment elle trouve des solutions et relève le défi.  Nous pouvons poser des questions et demander au candidat "pourquoi cette décision ?" ou “Je vois cela comme une contrainte - qu'est-ce que tu en penses ?” Observer comment le candidat travaille dans son fichier Observer les questions qu’il/elle pose  Observer le processus design Il y a des candidats qui ont beaucoup d'idées, qui parlent beaucoup, mais qui ont du mal à les mettre en pratique dans l'outil. Cela permet également de détecter de belles surprises.  Récemment, nous avons été surpris parce que le portfolio d'un candidat était magnifique. Cependant, lors d'un de ces exercices, il n'arrivait pas à mettre ses idées sur papier et il nous a avoué qu'il ne pourrait pas créer un produit de zéro à un sans la collaboration et l'aide d'autres designers.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon template pour réaliser des One on One simple avec son équipe.
    En tant que manager d'équipe, j'ai trouvé une astuce qui m'aide à rester organisé : j'utilise un document Google Docs où je prends régulièrement des notes, et je les partage également avec les membres de mon équipe. Cela nous permet d'écrire des notes sur des sujets passés ou des sujets à discuter dans la semaine. J'ai instauré des réunions individuelles hebdomadaires obligatoires avec chaque membre de mon équipe, ce qui est différent de ma précédente entreprise où ces réunions étaient irrégulières.  Je prends ces réunions très au sérieux, en particulier avec mes collaborateurs directs. Pour moi, c'est essentiel de leur demander comment ils se sentent, comprendre leur blockages et comprendre leurs wins pour les célébrer L'idée du document Google Docs m'est venue l ors de mes visites chez le médecin. C'est un peu comme aller chez le médecin et avoir un suivi régulier. Parfois, je rentre chez le médecin et il me dit : "OK, mais la dernière fois que vous êtes venue, il y avait cela, etc." C'est assez détaillé.  On oublie tous les détails, et il est important de prendre des notes pour ne pas oublier à long terme. Faire un check-in hebdomadaire avec chaque membre de mon équipe permet de mieux se souvenir de ce qui a été discuté précédemment. Par exemple, si un designer me dit : "La dernière fois, j'ai eu des problèmes sur ce projet", je sais que la semaine suivante, je pourrai demander : "Est-ce que ça va mieux pour XYZ ?"
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment savoir si j’ai assez bossé un design ? Le processus que j'ai suivie.
    Le processus de design est à la fois passionnant et exigeant, car la quête de perfection est constante.  Toutefois, au fil du temps, j'ai appris à privilégier la manière dont j'arrive à la solution finale plutôt que le temps que j'y consacre.  Pour moi, un bon design doit être complet, cohérent, utilisable, de haute qualité et efficace, c’est ce qui me donne confiance dans mon processus de design.  Lorsque je suis confrontée à un blocage, j'utilise une checklist. En dernier recours, je m'engage dans des sessions de pair design avec mes collègues de chez Datadog, car nous sommes une grande équipe de plus de 100 designers, et il y a toujours quelqu'un avec qui échanger.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment définir le niveau de gamification où vous voulez aller ?
    Pour définir le niveau “juste” de gamification, on essaye de mixer différentes approches.  Soit on va faire des entretiens avec les utilisateurs et on pose quand même des questions sur tout ce qui est motivation, afin de le connecter avec une grille de lecture des leviers d’engagement. Même si ce n'est pas parfait, ça permet d'avoir une première lecture quand on fait les persona, puisque du coup, on les refait en général pendant le sprint (souvent, c’est un peu hors sol même si, nos clients ne sont pas les plus éloignés par rapport aux utilisateurs.)  Puis, on a effectivement la possibilité de faire des questionnaires. Notamment notre questionnaire sur les 9 leviers d’engagements. On a travaillé avec un doctorant en gamification pour affiner le questionnaire, voir un peu des tendances, etc. Normalement, on aura une publication scientifique sur le questionnaire. C’est une publication qui présentera un peu comment on l'a conçu et quels sont les résultats qu'on en tire.
    Ensuite, on mixe un peu ces différents résultats et on essaye de les confronter aux utilisateurs (que ce soit dans le sprint via des tests de prototypes, que ce soit via de la recherche utilisateur, avec des entretiens ou des questionnaires, ou que ce soit avec des tests plus poussés avec un prototype plus qualitatif, tout dépend du projet et de ses enjeux). Quelque chose que je rappelle souvent c’est que :  Le niveau de gamification qui est optimal, ce n'est pas mettre le plus de gamification possible.  Même sur des leviers d'engagement, ce n’est pas mettre le plus de tels leviers d'engagement possible, mais il faut trouver justement l'équilibre qui va par rapport à tes utilisateurs.  Je regarde souvent ce qui se passe dans le monde des jeux qui fonctionnent sur le marché. Il y en a beaucoup qui fonctionnent avec des lootBox (quand tu obtiens une récompense, tu ne sais pas laquelle tu vas avoir.) C’est plutôt une boîte surprise. Et c'est assez utile pour générer de l'engagement.  C'est-à-dire qu'au lieu d'avoir les joueurs qui disent :  “Il faut trois boîtes pour avoir la récompense que je veux, là potentiellement, ce sera une, ce sera dix, ce sera cent.”  On ne sait pas.  C’est un truc qui génère quand même de l’engagement dans la durée pour les jeux et ça reste assez efficace. En tant qu’observateur tu pourrais dire que ça fonctionne bien. Et si on pousse plus loin le concept? Si les gens aiment bien cet effet de surprise aléatoire, il n’y a plus qu'à y aller à fond. C'est ce qu'a fait un jeu qui s'appelle Magic Legend.  En termes de gameplay, c'est un peu comme Diablo, et ça se passe dans l'univers des cartes Magic avec un mix de licence assez sympa du jeu, sauf qu’en fait les concepteurs se disent : “ Comment on fait pour gagner le maximum d'argent? “ Ils vont y mettre toutes les techniques un peu sales pour gagner de l'argent, notamment dans des LootBox. Ils ont poussé le truc tellement loin, avec tellement d’éléments aléatoires et peu de chances de gagner ce que tu voulais, qu’au final, je crois que 2 ou 3 mois plus tard, ils ont annoncé qu’ils arrêtaient le jeu et qu’ils allaient devoir rembourser les achats, parce qu’en fait ça sentait trop l’arnaque pour les joueurs et donc personne ne jouait. Les utilisateurs se disent : “ Ce n’est pas ça qu'on veut.”  Je pense souvent que c'est un peu ça la question : “Un peu d’aléatoire, c'est cool. Trop, ce n’est pas cool.”  Du coup, la question, c'est à quel niveau c'est OK ? Eh ben ça dépend de l’utilisateur pour chacun de ces éléments de gamification, il faut choisir le bon niveau.  – Et c’est là que la base de connaissance méthodologique est clé. (comme notre méthode Fidbak où on s’intéresse aux utilisateurs, qu’on prévoit des tests, etc.) Je donne un exemple:. Hier, je faisais une formation pour des formateurs sur comment travailler la gamification.  Parmi les gens qui sont venus, il y en a plein qui s’attendaient du coup à ce qu’ils découvrent une boîte à outils de jeu: Avoir tel levier d’engagement pour telle situation Mais non, ce n’est pas comme ça que ça fonctionne. Lors de la formation je leur ai expliqué que justement que l’on ne va pas parler de jeu. On va parler de gamification, mais pas directement de jeu. C'est typiquement le genre de personnes qui, généralement, va avoir beaucoup de mal à se poser sur ces questions d'objectifs, de persona, etc.  Dans ce que j’observe c’est le genre de personnes qui veulent juste vouloir avoir son jeu.  Par exemple, je les choque lorsque je dois leur dire “Il y a des gens qui aiment bien jouer en ayant de la compétition, et d'autres qui n’aiment pas.”  Parce que jusqu'à maintenant ce qu’ils connaissaient dans les jeux, c’était la compétition.  Mais si dans certains jeux il y a de la compétition, il y a plein d’autres qui n’en n’ont pas.  Pour nous, c'est important de recadrer un peu ces éléments de méthode et de problèmes. Ensuite, on fait assez souvent bouger la méthode qu'on travaille pour les clients parce que justement, il y a besoin de l’adapter à différents types de contraintes.  On a l'impression que c'est linéaire, mais en réalité c’est complètement itératif, on passe notre temps à évoluer sur plein de points différents, à faire des tests, etc.  Ce sont des choses que les gens ont un peu plus de mal à appréhender.  Pour l'instant, on est plutôt contents de notre méthodo « sprint », mais on continue d'affiner un peu ce que ça ne fait pas si longtemps que ça qu’on fait des sprints sur la gamification et qu’on rencontre toujours des cas particuliers. C’est aussi ça qui rend le sujet aussi passionnant.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Utilisez les ateliers pour forcer la communication avec clients (internes/externes)

    Un projet qui m’a marqué dans ma carrière fut celui d’une refonte de site qui s’est “mal passé” et qui a marqué un tournant dans ma manière d’approcher les projets. 

    La situation de départ était assez positive:

  • On avait pas mal de budget pour faire de la recherche utilisateur
  • Le cadre d’intervention était assez large, on pouvait faire pas mal de choses sur une refonte d'un site Web qui était assez vieux. 
  • J’étais avec d'autres personnes que je connais bien du métier 

    Il y avait des gros problèmes d'engagement, il fallait répondre à 200 questions, et dans ces questions, il y avait une sorte d’auto-audit sur tes pratiques professionnelles etc. 

    Bref, ce n’était pas fun. Les gens ne le faisaient pas. 

    Donc on a vraiment passé beaucoup de temps à travailler sur la refonte du site Web et voir ce qu’on peut améliorer. Les échanges qu'on a pu avoir avec à la fois les utilisateurs potentiels et des partenaires sur le sujet ne collaient pas avec l’objectif du site. 

    En réalité les gens n’avaient pas le temps, et encore moins le temps au moment où ils devaient l'utiliser. 

    Du coup, un point que les utilisateurs et les partenaires nous ont remontés était qu’il y avait beaucoup de gens qui avaient envie de se former sur le sujet de l'auto-évaluation. 

    On a donc orienté ce besoin-là et on a proposé des choses autour de l’apprentissage gamifié pour que les pros puissent se former dans la durée. 

    Ainsi, quand ils arrivent au moment où ils ont besoin /envie de s’autoévaluer, ils ont déjà toutes les connaissances. 

    Sauf que, notre client n'avait pas du tout suivi le sujet. 

    Ce qui s’est produit c’est qu’il a même complètement rétropédalé sur d’autres suggestions qu'on avait pour améliorer l’expérience utilisateur et donc sur l’auto-évaluation où nous avions beaucoup investi.

    Au final, on a dû faire une quasi-refonte à l'identique du site Web, alors qu’on avait passé un temps incroyable à repenser le projet pour qu'il soit plus performant et engageant.

    Cet épisode m’a forcé à revoir le processus de travail avec ce client. 

  • À l’époque, on avait des réunions avec nos clients de temps en temps, et on leur partageait tous les dossiers sur lesquels on travaillait. 
  • Sauf que le client et la personne qui gérait le projet pour le client, ont eu des soucis de communications entre eux, et le client n'a pas suivi ce que l'on a fait. 
  • Du coup, on s’est retrouvé avec quelque chose qui était un peu différent de ce qu'ils imaginaient au départ, d’où le rétropédalage final.

    Aujourd'hui pour éviter que cette situation se reproduise j’ai quelques pistes mais c’est encore un sujet où je ne suis pas encore parfaitement certain. (donc ouvert à vos suggestions dans les commentaires)

    Une piste que je développe beaucoup, sont les ateliers collaboratifs .

  • Le fait d'impliquer un peu plus l'opinion des parties prenantes sur ces phases de réflexion est bien mieux, même si ce n’est pas facile à organiser.
  • Quand on fait des ateliers collaboratifs, on aide vraiment les différentes parties prenantes à s’impliquer dans le projet, partager leurs idées, les faire évoluer et quand on tranche sur un sujet, on sait pourquoi. 

    Ça réduit vraiment les risques de perdre la confiance du client. De façon plus spécifique sur la gamification, mon jeu de cartes les Gamifi’cartes (un jeu d’idéation avec des contraintes sur la gamification) aide vraiment les néophytes à avoir des idées de gamification, et donc ils se les approprient également beaucoup plus. C’est vraiment rare de faire un projet sans les utiliser avec nos clients désormais.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Lancez-vous avant de commencer à être indépendant.De cette manière vous construisez des bases avant

    Quelque chose que j’aurais voulu commencer plus tôt avant de me lancer comme indépendant aurait été de commencer plus tôt et montrer les choses que je faisais en cours de route.

    Pas forcément se lancer dans le sens, lancer son activité directement, mais plutôt : 

  • Commencer à prototyper des choses plus tôt
  • Commencer à pratiquer plus tôt ce que je voulais faire
  • A poster sur LinkedIn plus tôt

    Au final, il y a un moment où tu réalises que plus tu commences tôt, plus tu as déjà des bases sur lesquelles construire. 

    Tu pourrais avoir posté du contenu sur un sujet avant de te lancer dans une activité, de cette manière tu as déjà un peu d'audience, tu as déjà des gens qui disent qu'ils aiment tel ou tel truc par rapport à ce que tu fais, par rapport à la façon dont tu le racontes, ou ce genre de choses. 

    Il y a quelques années, je me disais en fait que la plupart des potes que j'ai vu galérer à trouver du taf, ben c’est des gens qui ne faisaient rien que chercher du taf. 

    Ceux qui ont trouvé facilement en fait, c'est justement ceux qui faisaient d’autres choses, qui faisaient du networking, qui allaient aux évènements, qui faisaient du bénévolat, qui étaient actifs. 

    C'est peut-être un truc que l’on n ’apprend peut-être pas assez. Par exemple quand, j'étais à l'université, on n'apprenait pas ça. 

    Avoir quelqu'un d'autre qui dit “C'est comme ça aussi que ça marche, et ça va t’aider un peu plus d’être acteur “ aurait été plus intéressant.

    Par exemple, le nombre de personnes qui publient régulièrement sur LinkedIn est autour de 1% des utilisateurs.

    Du coup, si tu fais simplement ça, tu te démarques complètement des autres.

    Pas forcément par rapport à la question qu'est-ce que tu publies, est-ce que c’est intéressant ou pas, mais simplement, ça peut aider à se différencier un peu, que ce soit pour trouver un job ou des clients ou pour trouver des partenaires.

    Je pense qu’il y a plein de façons d'agir. 

    Ma copine, par exemple, s'est investie dans une Asso pour de la construction d'isolation en paille en Île-de-France parce que c'est un sujet qui l’intéressait et qui est en lien avec ses études.  Plus tard, quand il y a une boite qui a cherché un consultant sur la construction en paille (alors que ça n’existe quasiment pas en France) ils cherchaient quelqu'un d’expérimenté, et il lui a suffi de dire que ça faisait plus d'un an qu’elle était bénévole dans cet Asso, et elle a eu le job.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Evolution et objectifs de mes livrables.

    Le Covid m'a amené à changer mes livraisons. Le prototype du début, c'était un Kanban dans notion.

    Le client recevait un Kanban un peu comme une espèce de site web très visuel, un Pinterest avec un découpage de toutes les différentes sections. Mais c’est pas du tout assez accessible pour un client corporate qui n’a pas Notion, qui ne connaît pas le Kanban et qui n’a pas envie d’ouvrir et de fermer le truc. 

    Donc très vite, j’ai pivoté sur Miro, et je me suis fabriqué petit à petit des gros building blocks, en vrai des datawalls. 

  • En fait, j'ai une partie de ma recherche que j'appelle le Codex, qui est toutes les sources auxquelles je fais référence, de manière presque académique, des notes, des codes hyper faciles, des liens pour tout retrouver. Tout sur ce quoi je suis tombé dans le Codex. 
  • Puis dans Google doc, la navigation de côté est super bien faite, ça marche sur mobile, et il y en a qui aiment bien lire et qui trouvent ça cool, ils se baladent dedans. J’en fais un espèce de executive summary d’une douzaine de pages que je mets vraiment à la fin de la recherche.

    À partir de ça, tu peux tout fabriquer le reste : 

  • Ça sera des sticky notes, 
  • Des moodboards dans des canevas bien structuré  
  • Mon trend radar
  • Ma recalibration. 

    À la fin, quand j’ai livré, tu as un sprint qui est prêt. J’ai fabriqué des canevas qui permettent de framer tes grandes questions de recherche. 

    Puis en fait tu vas aller chercher dans la recherche les briques dont tu as besoin pour fabriquer ton framing de recherche et ça te donne des grandes avenues dans lesquelles tu peux faire ton idéation. 

    En fait, mon job to be done, je travaille dans le business de l’orientation. 

  • Je ne fais pas assez la différence dans notre métier entre la créativité et l’imagination. 
  • Moi je viens pour t’aider à développer ces représentations intérieures, un peu comme le champ intérieur chez les musiciens. 
  • Tu peux entendre ta propre voix quand tu penses mais tu peux chanter à l’intérieur de toi. Donc la visualisation est super importante pour comprendre des situations qui ne nous affectent pas L’imagination, ce n'est pas juste un truc de rêveurs créatif pour imaginer du Mobius.

    Non, non, non. Sherlock Holmes a besoin d'imagination pour faire des inférences, de l’inductif. 

    On dit que l'imagination c’est breach the gap between the known and the unknown. 

    C'est ça ma mission.

    Donc je veux fabriquer ce datawall qui ça être très riche et en plus, je rajoute des principles design qui sont propres à la recherche. 

    Ce qui fait que je vais te donner toute une série d’équipements, d’instruments qui vont maintenant t’aider pour aller monter ta montagne et je t’ai envoyé sur la bonne piste, tu as ton matos et tu ne retrouves pas au point zéro à fabriquer ton sprint, où tu vas tu vas systématiquement sacrifier la profondeur de l'investigation à la justesse pour la vitesse et la visibilité.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Gérer les questions politiques internes avec des clients complexes.
    Il y a deux types d'entrées dans les projets. LA VOIX DU haut Desfois, tu rentres par un VP, et là tu peux très vite choper le CEO. Parce que c’est un VP. Tu vois quand tu as un Exécutive Vice President, marketing sale, ça se passe bien. Même si des fois, le CEO il n’a pas envie. Mais là, si tu rentres par le haut, c'est plus facile.  Dernièrement, j'ai fait une étude en Suisse allemande, j'avais un client qui voulait savoir pourquoi son produit internationalement connu, ils faisaient des millions, ses ventes, mais ça ne marchait pas en Suisse Allemande.  Il faut aller chercher, il faut trouver, je suis allé sur le terrain. Et quand tu livres, le CEO en face et en 20 minutes le gars il dit : “C’est bon, c’est bon OK, elle est morte, on change, GO” Ça, c’est génial. La voix du bas

    Par contre, quand tu arrives par en bas par des managers , eux ils ne sont pas forcément récompensés pour les comportements que toi tu souhaites. Puis les comportements nécessaires chez eux pour jouer aux jeux auxquels tout le monde joue, c’est pas forcément ceux qui toi, t’aident. 

    Donc ce n'est pas simple parce qu'ils ont commencé à tout censurer. Beaucoup de censure. Tout le monde est capable d’ouvrir le parapluie en boite, et tu cours le risque que les insights se transforment en torpilles entre rivaux. Pour détecter ce genre de situations, il faut que tu poses des questions sur la structure du projet. La structure de l’équipe. Si à un moment ils disent: “A non non non, on va faire les choses dans notre coin et le présenter à la fin par nous même”. Alors là tu sais qu’il faut que tu te couvres, car tu commences à être en mode agence qui bosse pour un autre client interne (donc risque de doubles retours) Il faut très vite se mettre d’accord pour que tu ne sois pas responsable de ce qui se passe à la fin, et anticiper le problème du storytelling: “Comment tu pitch cela au-dessus ?”

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Conseil: Achetez des belles ethnographies - Cairn Info par exemple

    Dernièrement, j'ai vu « Ethnographie sonore des Oasis », super bouquin, je l’ai dévoré. 

  • En fait, tu vas découvrir une manière d'écrire qui est très proche des anthropologues, qui est dans les sciences sociales et de la société. 
  • Il y a un point de vue et une manière de faire des métaphores. On va parler de texture chronologique, on va parler de ce qui charpente, ce qui vertèbre. 
  • On va toujours aller chercher la matérialité en fait. On est dans la matière. On va utiliser du langage de la matière et moins du langage des idées. 

    Ça, c'est important d'aller lire des gens qui écrivent vachement bien, parce que toi, t'es en train d'essayer d'apprendre à écrire.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon astuce: Développer son sens de l’imaginaire
    Moi, à la base, je suis pur introspectif . Donc si on me fiche la paix, si je suis tout seul, ça me va. J’ai dû apprendre à aller vers les autres.  Le principal conseil que je donnerais à un designer, c'est d’imaginer, le design comme une conversation. Avant toute chose, c’est les mots avant les visuels.

    Il faut être capable pour collaborer avec les autres, qu'ils designers soient ou non, mais de pouvoir parler. 

    Ca veut dire quoi? 

    Ça veut dire observer un metteur en scène qui donne un feedback à un acteur. C’est dans cette capacité créatrice de pouvoir utiliser du langage pour parler de design. Par exemple, Loris Olivier, le typographe qui a créé les typographies de Whispers & Giants, c’est la personne dans ma carrière avec qui les échanges de ce type sont les plus riches et les plus imagés.

    Il est fabuleux. Comme disait notre ami Romain, il n’aime pas que les lettres mais il aime aussi les mots.

    « Tu vois le coude, il est trop haut on dirait qu’il penche », parce qu’ on a des corps, on est des corps. 

    On ne peut pas faire sans, nous sommes des créatures qui sommes incarnées. 

    Moi, je conseille à tous les designers que je coache de regarder des making of de films et particulièrement ceux de Ridley Scott. 

    Parce que c'est une machine de travail qui s'entoure de gens extrêmement compétents, parce que lui, il torche des films à une vitesse incroyable. Par exemple, Prometheus.

    Les making of de films de science-fiction, où il y a des monstres, où il y a un monde imaginaire où il y a des monstres, Mate painting, où il y a des créatifs qui viennent fabriquer les cuillères, il y a tout à fabriquer.

  • Entre eux, ils doivent se mettre d'accord.
  • Pour qui ils designent
  • Dans quel monde
  • Quelle culture. 

    En fait, c'est un très bon terrain d’entrainement, parce que tu n’es pas en train de parler d'une application pour réserver un avion.

    Ça va beaucoup plus mobiliser des capacités d'imagination, de visualisation intérieure, et c'est ça qui est très, très important dans le design, c’est de pouvoir dire :

    «Écoutes, c'est pas un barba papa qu’on est en train de faire, c’est plus un Pokémon. “

    Si tu as les deux références, tu comprends qu’il y en a un qui est polymorphe, et l'autre qui peut être permutable, et tu as besoin d’aller chercher ces métaphores, ces analogies. 

    Parce que le cerveau humain fonctionne comme ça.

    Après, c’est la capacité à comprendre que plus tu vas te confronter au terrain et découvrir les autres, plus tu vas t’aider à te connaître toi-même.

    Cette connaissance de toi-même va t’aider déjà à comprendre tes biais, il y a des trucs qui t’énervent, il y a des constructions à toi qui viennent de ta famille, donc c’est un bon terrain pour pratiquer cette position.

    Être capable de comprendre que les gens ils sont là où ils sont parce que généralement, c’est le contexte autour d’eux qui font qui ils sont. 

    Le plus grand biais humain aujourd’hui, c’est l’erreur d’attribution fondamentale. Biais cognitifs sur lesquels sont construit le libéralisme, le capitalisme et la bourgeoisie. 

    La méritocratie, c'est l'idéologie qui va naître de ce biais.

    “C’est un biais où on va avoir tendance à suramplifier des raisons qui sont internes aux personnes, leur personnalité, c’est une espèce d’essence qui émanent d’eux, leur caractère, qui ils sont, on fait ce qu’on est. Et puis de complètement réduire l'impact du contexte extérieur.”

    Et à ce biais-là, il faut aller chercher Spinoza qui dit 

    « La liberté, c'est l'ignorance des causes qui nous déterminent. »

    Donc, c'est important d'apprendre à lire les rapports entre les gens comme aujourd'hui. Il y a une grande critique dans le HR de la fétichisation des skills, des compétences, comme s’ils étaient à l'intérieur des gens, comme des essences. 

    Alors que toute forme de compétence est toujours née d’une réalité de relation. 

    On est des créatures sociales. Ça veut dire que si tu parles, si toi et moi on parle le français, c’est que gamins, on nous a parlés Français et que plus tard, on a appris une langue, et ça nous a permis d’en apprendre une autre. 

    Donc si tu n’es pas socialisé au sens humain, c’est que tu es un Mowgli avec des loups.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Provoquez le système de recherche. (cad se mettre dans des situations d’observation naturelle)

    Un conseil que j’aurais aimé avoir serait de faire encore plus d’observations / immersion.

    Donc vraiment en mode éponge et de ne pas hésiter à provoquer le système pour qu'il réagisse, et voir comment en sortant un peu du cadre, les choses changent. 

    Je m’explique:

  • Maintenant quand je vais à un interview, je viens souvent une heure en avance et je dis que je me suis trompé. Je gagne une heure d’observation.
  • Je vais oublier un truc dans la salle où il y a eu l’entretien puis je vais y revenir.Je passe par le concierge ou je me trompe de sortie. Je fais tout ce qu’il ne faut pas faire. 

    Donc en fait, ça me permet de sentir déjà les choses en dehors du protocole qui a été prévu pour moi.            

    Ensuite, deuxième conseil ; et ça je le donne beaucoup aux jeunes aujourd’hui ; 

  • C’est que tu dois tout le temps être dans le “inquiry mode”
  • C’est-à-dire que dès que tu as une interaction avec une caissière, quelqu’un au pressing, pour acheter un sandwich ; tu peux poser des questions. 

    Parce que déjà, c’est vachement sympa de s'intéresser à l’autre.

    Le beau temps – il fait chaud – il fait froid, c’est déjà un super ice breaker. Et je me serais conseillé d’aller plus vite vers les questions de type

  •   « Oui, il y a plein de sandwichs, mais je me demande c’est lequel que vous vendez le plus et celui que vous vendez le moins ? Et vous vous préférez lesquels ? »..
  •  « C’est quoi le client le plus bizarre ? ». 

    Et en fait, à force de faire ça tout le temps, tu te focalises plus sur les outliers, tu comprends vraiment que tout n’est pas des courbes gaussiennes, il y a beaucoup de Pareto. 

    En fait, la force du design, c'est d'aller là où il y a des trucs bizarre.

    Il faut affûter ta capacité à être attentif vis-à-vis des éléments de langage, les mouvements du corps, le regard des gens, où ils posent les choses, et de tout temps pratiquer ça. 

    D'aller chez Ikea le samedi, et s’asseoir dans un canapé, et juste manger du comportement humain, être très décentré dans l'observation. 

    Te balader, faire le type naïf qui pose une question juste pour voir ce qui se passe, pour apprendre à être dans cet engagement. 

    Parce que quand tu vas aller en recherche, parfois tu as très peu de temps, mais tu peux dire 

    « Y a pas mal de trucs qu’on me demande ici, ça me fait penser à des choses. Je suis déjà allé un peu creuser dans ce espaces là. ». 

    Puis, tu sais comment aller très, très vite pour choper des insights.

    Donc ça veut dire, là moi où j'habite, les grosses écoles, où il y a des jeunes de 12-14 ans, c’est ça que je veux étudier, ils sortent de l’école à quelle heure à quelle heure, je serai dans leur bus avec mes enfants aussi, je blend in.

    J’écoute, je regarde, je mange.

    Il faut être capable de faire ça, parce qu’il existe un autre problème lors des interviews, c 'est que la façon de s’occuper en amont d’une interview structure énormément ce qui va se passer en entretien. 

    Avoir cette capacité à le rendre le plus spontané possible et que la personne n'ait pas l'impression d'être interviewé, c'est la clé. 

    C'est des techniques, que j'ai essayé de maîtriser pour casser les appréhensions de la personne qui arrive à l'entretien en se posant pleins de questions:

     « Est-ce que je vais me faire virer ? Qu’est-ce que ce mec essaie de savoir? ». 

    Je cherche à éviter au maximum la méfiance d’un participant qui serait presque sur la défensive. Il y a des manières de faire, et c’est d'avoir cette capacité, qu’il faut développer: l'observation. C’est surtout, je dirais à pratiquer en vacances, dès que l’on voyage, dès que l’on se confronte à du nouveau, à de l’inconnu. 

    C'est là où tu pourras le plus observer des gens.

    Pour résumer mon conseil ca serait ça:

  • immersion – observation
  • Et pas que l’interview, souvent trop scriptée.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Rendre les livrables actionnables
    Je vais séparer deux types de livrables. Il y a les phases exploratoires et les phases plus évaluatives. Sur les phases exploratoires: je pense que ce qui rend actionnable le livrable c'est principalement la manière dont il a été construit avec la personne qui va l'utiliser après. En l'occurrence pour prendre l'exemple de comment nous travaillons aujourd’hui versus il y a un an c’est toutes les phases sont toujours faites à deux parce que c'est plus agréable, on réfléchit mieux, c'est soit du design, de la recherche, product. Avant l'idée c'était de mettre deux personnes qui connaissent très bien leur discipline pour obtenir un résultat encore meilleur : deux researchers, deux PM] ...... deux designers Et on s'est rendu compte que deux researchers, ils étaient à 8/10 de leurs capacités, ça ne faisait pas pour autant 16 ! Ils savaient un peu les mêmes choses, ils pouvaient s'aider, c'est toujours mieux de rebondir l'un avec l'autre mais en fait c'est plus utile d'avoir quelqu'un qui est "lead" et ensuite quelqu'un qui est impliqué mais pas lead, en l'occurrence un "pm” qui va récupérer ce qui s'est passé en explo pour l'utiliser derrière. C'est le côté "transmission humaine", ça fait une bonne partie du travail pour bien réutiliser le livrable ensuite. Maintenant ce n'est pas toujours possible et on obtient un livrable qui va devoir être utilisé et des détails qui vont devoir être transformés. À ce moment-là, ce qui détermine la qualité c'est de se demander à quelle question on répond, de reprendre les objectifs produits de départ Par exemple :   "on veut améliorer la conversion entre telle et telle partie"  "on sait qu'il y a tel problème", "c'est destiné à tel user" "on a besoin de comprendre ce qu’ils font à un moment donné  "ceux qui convertissent, pourquoi ils convertissent", etc.  Une fois ces questions posées, et avec ce qu'on a appris, quelles sont les différentes réponses qu'on peut donner ? Dans le travail "produit" ensuite on sera facilement capable de notifier que toutes les réponses ne répondent pas aux mêmes questions, que toutes les questions ne se valent pas puisqu'il y a des choses qui sont plus ou moins au début ou à la fin du flow. Ça permet de faire un tri pour prioriser derrière. Une fois qu'on a l'organisation, il y a la qualité même des informations. Il y a 2 choses : 1) Il faut donc avoir la capacité d'écrire quelque chose de précis. Je ne suis évidemment pas parfait, mais je pense que j'ai amélioré cet aspect et j'estime qu'il faut y passer plus de temps. Il faut se relire, se faire relire aussi, parce qu'évidemment on est toujours clair pour soi-même, mais ça ne veut pas dire qu'on est clair pour les autres. Lorsqu'on présente les choses, si quelqu'un ne comprend pas, demander à l'autre ce qu'il a compris. Comment peut-on trouver une manière de réécrire les choses ensemble ? pour s’assurer que c’est clair. Si on énonce quelque chose qui n'est pas clair, il ne faut pas s'étonner après que le produit ne suive pas. De la même manière si l'insight, il est compris de quatre manières différentes par quatre personnes différentes, il y a un moment où ça ne marchera pas. Il faut s'appliquer pour écrire des choses qui sont claires, si on n’en est pas capable, faire un dessin, un miro...se débrouiller pour donner une représentation la plus proche de ce qu'on a appris à travers un langage écrit, imagé etc.; La dernière chose c'est d'arriver à bien connecter ça avec la réalité de ce que le user nous a dit, pas de l'illustrer parce que c'est ce qui va incarner les choses.  Il y a le côté clarté et aussi le côté puissance de l'insight. Et la puissance elle naît de la vidéo, du verbatim qui montre que  “ Ah oui, ça c’est un truc super fort, où si l’on est capable de s’appuyer dessus, ca fera vraiment une différence “ Ou  “Si c’est un truc un peu cool, que tout le montre trouve intéressant, mais où l’on sait que demain cela ne fera pas de différence”
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le mid-mortem en plein milieu de la recherche pour faire le point et ré-aligner l'équipe
    Quand tu es dans un rôle de prestataire pour un client ce n'est pas toujours facile de lui dire que c'est fini, alors qu'on a pas vraiment fini.... Il faut que la discussion porte sur les choses essentielles, sur ce qu'on a appris et où on veut aller. Cela devient intéressant et on peut mettre une autre phase en place, prendre des décisions. Pour éviter cet écueil-là, je vais vous donner un exemple par lequel on est en train de passer avec un client; On a mis en place une phase de recherche relativement exploratoire avec 2 persona de départ qui sont draft....mais qui nous aident à avancer. En faisant des interviews concernant des produits existants on se rend compte que certains sont plus proches de la cible. Donc là on fait une pause, on a commencé un petit doc d’analyse. On reprend les objectifs de départ pour débriefer ce qu'on a appris, les profils et on a pu déterminer la top liste de la cible à moyen ou court terme.  La question que l’on discute avec le client est donc : “Qu’est-ce que l’on fait par rapport à ça ?” “Comment est-ce que l’on continue la phase ?”  La difficulté étant que parfois il y a des informations écrites qui existent qui sont un peu floues et des informations connues, informelles qui sont plus précises. C'est toujours un peu le problème dans des entreprises qui n'ont pas forcément une culture forte de l'écrit et des documents bien faits.  On va passer du temps à réapprendre les mêmes choses, car des collaborateurs les connaissent, mais l'organisation elle-même ne les a pas apprises. Ce travail de bien les transmettre, bien les écrire et bien les utiliser demande parfois une nouvelle phase de recherche qui n'aurait pas eu lieu d'être si le travail avait été bien fait dès le départ.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Conseil: Passez plus de temps à comprendre les autres pour transmettre l’information
    Je pense que la première chose qui m'aurait aidé au tout début, c'est de passer plus de temps non pas à faire de la recherche, mais à comprendre les autres Stakeholders qui sont principalement le produit, le design, éventuellement, des c-level dans les entreprises.  Parce que souvent c'est plus difficile d'être un bon transmetteur de l'information qu'un bon collecteur. En fait un researcher il fait ce métier parce qu'il aime bien collecter les informations, parce qu'il a un esprit d'analyse, etc.  Par contre, il n'est pas forcément naturellement bon transmetteur de l'information, alors que c'est une étape cruciale dans son métier puisqu'une bonne partie de la valeur de son travail se trouve ici.  Et pour bien transmettre des informations, ce n'est pas nécessaire d'améliorer tellement sa practice de researcher mais il est nécessaire par contre de comprendre qui sont les skakeholders.  Comment réfléchissent-ils ?  Quels sont leurs problèmes aussi ?  Parce qu'ils sont toujours en train de courir après le temps, de résoudre des problèmes qui ne sont pas suffisamment clairs, ils sont tout le temps en train d'essayer de matcher la technique avec leur mission produit. Une fois que l'on comprend ça, on comprend mieux dans quoi on s'inscrit et on peut délivrer des insights qui ont plus de valeur, éventuellement participer aussi aux phases de stratégie produit, d’idéation, de définition de l'expérience, de l'UX... et apporter beaucoup de valeur. En fait, je pense que ça devient très vite vertueux, parce que soi-même on comprend mieux comment ça marche, donc on travaille mieux. A l'inverse des personnes qui cultivent la valeur de la recherche quand ils sont en train de faire du design, du produit, ils sont plus demandeurs. Voilà ça je pense que cela m'aurait aidé dès le départ. Samantha Davis qui est la Head of Research chez Zoopla et qui intervient dans Cousto, a fait une bonne partie de son intervention sur la "no tada" research, le tada faisant référence au researcher qui arrive au bout de trois mois et qui dit " tada voilà j'ai des super insights maintenant débrouillez-vous pour faire un bon produit ! ".
    En fait, pour bien réaliser cette phase-là, il faut impliquer les personnes.  Comment est-ce que l'on peut vraiment faire concrètement et qui impliquer ? Je pense que quand on lance un cycle de Research, on a développé nos produits par exemple, ça marche sur une cible, on va transformer pour aller chercher un nouveau marché. C'est un gros travail qui va durer plusieurs semaines, voire plusieurs mois. Il est important d'impliquer tout le monde au moins dans la communication : le produit, le design, les sales, les opérations, etc. Des personnes qui vont avoir la vision de la manière dont l'entreprise en tant que système fonctionne, avec des compétences différentes et qui vont devoir être "owner" de la solution le jour où elle existe. C'est aussi cela l'écueil du researcher, il n'est pas "owner" de la solution, il doit transmettre cet ownership, il est “juste” en charge de comprendre qui sont les users, comment ils fonctionnent.   Il faut ensuite les impliquer dans des phases, participer à des interviews, participer à la définition du research plan.  Pour ce qui concerne leur implication dans l'analyse je pense qu'il faut faire attention parce qu'ils n'ont pas forcément les compétences pour le faire. Il ne faut pas jouer aux apprentis researchers mais les impliquer pour leur poser des questions, leur montrer qu'ils font partie de la manière dont on analyse les données.  Ensuite ils peuvent par exemple co-présenter les insights, illustrer eux-mêmes avec les researchers ce qui a été appris. Finalement il faut que ce soit un travail collectif piloté par le researcher et non un travail individuel où le researcher arrive et dit à la fin " tada ! " C’est en ça que c’est contre-intuitif, car on nous dit qu’il faut aller vite, il faut faire les choses bien, alors que ça peut être des barrières à la diffusion de la recherche. Donc par exemple, laisser quelqu’un d’autre faire une interview ne sera pas exactement aussi bien faite que si je l’aurais faite. Mais le bénéfice d’avoir impliqué cette personne peut-être supérieur à ce que l’on a perdu vis-à-vis de l’exactitude de la recherche.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ma vision de ce qu’est un livrable actionnable

    Le livrable actionnable, déjà c’est un livrable qui pose des questions, et c’est un livrable qui est incomplet.

    Par incomplet j’entends un livrable qui ne tire pas toutes les conclusions à la place des autres expertises, qui laisse la place au marketing, aux dev, au legal, de venir ajuster et compléter ce livrable au moyen d’un workshop de restitution qui leur posera des questions. 

    Parce que c’est un livrable qui se co-construit au fur et à mesure de comment tu le présentes. 

    Déjà, c’est présenté sous forme de workshop,et pas présenté sous forme de Powerpoint. (Bien que Powerpoint puisse être un outil complet de ces présentations.)

    Quand tu penses aux lightning talks qui ouvrent normalement les design sprint, la plupart sont des Powerpoint. 

    Mais ce sont des choses qui posent des questions, et c’est un moment où tu prends du temps pour arrêter tout le monde et faire franchement des exercices avec tout le monde de :

    “Bien, voilà, on vient de présenter ça, maintenant, vous, selon les priorités de votre équipe, dans tout ce qu’on vient de présenter, quels sont les 3 points saillants, les priorités, puis faire du dot voting. “ Ensuite, à partir de là, prendre des décisions sur ces fameux points qui ont été priorisés. 

    Donc un livrable actionnable c'en est un où les personnes qui devraient recevoir la présentation d’un livrable, avec une étape de préparation avec les PO, les PM, on se dit : 

  • “Voilà, on va présenter les résultats dans deux semaines, donc comment on le rend actionnable ?
  • Quelles sont les questions qu’on va poser aux gens ?
  • À quel moment est-ce qu’on arrête la présentation pour faire un exercice, pour que les gens s’investissent et se disent en plein milieu de la présentation :
  • “ Bon ben, tel point est super important, tel point on arrête d’en parler. Et c’est un livrable du coup qui est complètement malléable.” Ce n’est au final qu’un support de workshop.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Conseil – mieux collaborer avec les équipes

    Mieux collaborer avec les équipes c’est d'abord commencer par le cadrage:

  • Tu as tout le cadrage de façon collaborative dans l’ensemble où chacun vient poser ses objectifs, ses limites, et avoir tout un process de product design qui passe chaque étape du process avec l’étape de validation par l’ensemble des dev, l’équipe marketing, etc
  • Savoir à quel point tu peux justement déranger l’équipe marketing, les dev. Mais se mettre d’accord sur ça. Se mettre d’accord sur un process établi, qui est répétable sur l’ensemble des projets, et pas en termes de :
  • Il faut qu’on mette en place telle méthode, telle méthode, parce que parfois un projet, ces méthodes-là n’ont aucun sens. 

    Juste que chaque phase ait un état d’esprit et des objectifs, et que ce soient ces objectifs et ces états d’esprit qui se découlent ensuite en méthodes à l’intérieur. 

    Surtout de dire : "Là, il faut que untel soit au courant de ça, pour telle chose, il faut absolument qu’on collabore avec untel et untel. "

    Donc faire participer les gens sur tout le process de design et faire des livrables systématiquement actionnables. 

  • Arrêter les livrables très Powerpoint simplement, mais des livrables où tu as les PO, PM,Dev qui en prennent connaissance et qui puissent construire avec cette connaissance au fur et à mesure du workshop. 

    Par exemple:

  • “Donc, on est allés voir les utilisateurs, voilà, je vais distribuer à chacun des phrases-clés, des verbatims, On se les partage, on les distribue.” 
  • “Voilà les fiches utilisateurs, on construit ensemble leur journey. “

    Même si toi, en tant que user researcher tu connais le vrai journey, mais le faire co-construire par les personnes pour qu’elles se mettent à la place et qu'à la fin, ce n’est pas toi qui sois venu dire : 

    “Voilà le journey qu’il y a eu. "

    Mais plutôt :

    "En fonction de ce qu’on a entendu, de ce que je vous rapporte maintenant comme verbatim, co-construisons ensemble le journey / le persona”

    Moi en tant que researcher, je vais modifier ça ou ça pour vous mettre un peu sur la bonne piste, mais que chacun vienne co-construire le truc au fur et à mesure. “

    Et ça, il faut le faire à toutes les étapes. Que ce soit par exemple sur la restitution de research, que ce soit sur le how might we ou que ce soit sur l’idéation. 

    De prendre du temps aux gens, et ne pas avoir peur de leur prendre du temps.

    En fait, ne pas avoir peur d’être chiant avec les gens. 

    Ne pas avoir peur et se dire : 

    “Attends, le dev ils ont des trucs à faire, et je ne peux pas trop aller l’embêter, je ne vais pas mettre un workshop à ce moment-là. “

    Non, je pense qu’il faut vraiment en mettre. Il faut faire venir les gens et il faut qu’on arrête en tant que designer de présenter de façon très : 

  • “Voilà les résultats.” (Bon ça, il va falloir le faire de temps en temps.) 

    Mais éviter le trop descendant systématiquement, et impliquer les gens, leur poser des questions, les faire poser des questions, les faire réagir, les faire travailler. 

    Comme je disais, il faut que ce design collaboratif, soit 40% de notre taff, il soit porté par les autres. 

    C’est une espèce de co-design qu’on met en place, donc maintenant il y a aussi 6 to 1 et ce genre de méthodes. 

    Mais ça, il ne faut pas avoir peur de le faire, même si à la fin, on ne prend pas en compte ce que les gens ont communiqué. Le simple fait de les avoir intégrés, que les gens soient venus tirer des traits avec nous, ils savent qu’ils ont participé au design, que leurs contraintes et besoins ont été prises en compte.

    Si à la fin on voit ce qui en sorte qu’on se dit : 

    “Ça, c’est de la merde, je ne le prends pas en considération, “

    Hé bien c’est tout à fait OK, on peut le jeter. C’est notre travail.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Se protéger et rester factuel avec les parties prenantes qui n'ont pas le temps !

    Une fois lors d’un projet j’ai eu la mauvaise expérience d’être avec des stakeholders qui ne prenaient pas le temps de suivre le projet et d’intéragir.

    La feature team devait avancer, les designers devaient avancer, et il y avait d'autres personnes qui mettaient la pression pour que ça avance.

    Si l’on disait à quelqu’un : non je n’avance pas. Politiquement parlant, ça n’allait pas passer. 

    Évidemment à la fin, on a eu le fameux : 

  • “Ah, mais c’est pas comme ça que je voyais le truc.” 

    Donc au dernier moment :

  • “Ça il faut changer, comme ci, ça il faut changer comme ça.”

    Si je devais éviter cette erreur de nouveau je ferais pro-activement ces actions pour me protéger:

  • Communiquer ce qu’on a compris du brief, s’assurer que notre compréhension est bien en phase avec le brief initial, s’assurer que ce brief a du sens point de vue du design et qu’il est en phase avec notre stratégie design.
  • Parler surtout aux autres qui ont aussi des communications avec ces stakeholders, soit les dev qui ont probablement aussi eu une redescente de besoins, les PO, les PM et les autres designers. 
  • Se construire ainsi aussi une représentation de: Qu’est-ce qui est attendu des personnes qui sont dans l’équipe. ?
  • Puis avancer, tenir la personne au courant régulièrement : 
  • Voilà où on en est
  • voilà où je suis
  • voilà ce que je fais
  • voilà où je vais
  • voilà le next step. 
  • Et toujours poser la question, j’ai besoin qu’on se voit. 

    Comme ça, Si la personne au bout de 3 mois elle réapparaît alors qu’elle zappé tous les workshops et dit :

    “Ben c’est pas comme ça que je voyais les choses,” 

    Tu peux répondre:

    “ Ben oui, mais nous on a avancé, tu peux voir sur tous les e-mails que je t’ai envoyés que je demande des créneaux donc maintenant le truc va sortir comme ça. S’il faut tout changer au dernier moment parce que tu es chief machin truc et que tu nous mets la pression, on va un petit peu changer la marge. “

    Mais aussi ne pas avoir peur de dire : 

    “C’est comme ça que ça va sortir ou alors ça ne sort pas, on annule le truc. Mais nous, nos horaires c’est 9-18h30, on ne travaille pas le week-end.”

    Bon là ce sont des conseils pour se protéger, mais il faut éviter d’en arriver là.

    Si une partie prenante n’a pas le temps il faut :

  • La tenir informée de l’avancée
  • Lui rappeler ses engagements, ses responsabilités, l’inviter aux workshops,
  • S’assurer avec des communications concises qu’elle a tout ce qui lui faut pour savoir où on en est.

    Moi il y a aussi un truc qui, en même temps, qui va dans les conseils que j’aurai bien aimé recevoir, qui est totalement lié à ça, c’est qu’on n’a pas dans la majorité des écoles de design ou formations qu’on a eues, c’est la négociation et la communication. 

    Comment tu fais pour communiquer, tout ce qui est assertivité, communication non violente, négociation. 

    Je trouve que tout ça, c’est essentiel et dans ce genre de cas, tu sais comment être factuel et dire que : 

    “Je comprends que tu ne sois pas satisfait, parce que ce n’étais pas ce que tu attendais, en revanche, comme tu peux le voir, il y a eu 8 mails de ma part et 4 Slack pour te demander des points que je n’ai pas eus, ou on avait besoin de ça pour avancer donc voilà maintenant l’état des choses. Comment peut-on faire toi et moi pour éviter que cela ne se reproduise la prochaine fois ?” 

    Puis surtout, ne pas prendre les choses personnellement.

    Un conseil également que j’ai eu d’un pote qui m’a dit : 

    “Le boulot, ce n’est que le boulot” 

    Tu vois quand la personne en face elle a envie de continuer à monter les échelons, elle se met la pression, les meetings back to back, à travailler jusqu’à 23h, week-end machin et tout, c’est son truc. 

    À un moment, si elle s’énerve cette personne là parce qu’un truc s’est mal passé, je pense qu’il y a cette histoire de cadrage encore. Bien se protéger au fur et à mesure. 

    Donc si la personne fait du silence, nous on ne veut pas faire du silence, mais au contraire on continuer à faire du feed-back genre : 

    “Tiens, voilà en fait sur tel projet, voilà où j’en suis.” 

    La personne le sait et toi tu es protégé. Factuellement tu dis : 

    “Moi, ça fait trois mois que je te parle, toi tu ne me réponds pas, donc voilà où on en est. “ 

    Si la personne s’énerve ben tu vas le laisser s’énerver comme un spectacle finalement. Il faut être factuel et honnête et le truc avance tout seul.

    Je pense qu'il y a des solutions meilleures que celle là et je pense que des head of auraient des tricks très particuliers. (commentez si vous avez des REX)

    Je veux montrer qu’au bout d’un moment, il faut faire du bon boulot priorisé sur l’essentiel, prendre un peu de recul et se protéger avant tout.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pour bien prioriser, il faut comprendre qui veut quoi

    Un deuxième conseil que j’aurais aimé que l’on me donne c’est de bien comprendre qui veut quoi autour de moi dans les personnes avec qui je bosse. 

    Par exemple, les autres leads , la boîte, mes designers: qui a besoin de quoi ? 

    Là où je priorise et là où je vois les pourcentages d’efforts à mettre, c’est en fonction de qu’est-ce que ces personnes veulent, et de quoi ils ont besoin. 

    Ainsi que de mon côté, ma team, moi personnellement, et le design: 

  • Quelles sont nos priorités ? 
  • Quelles est notre vision et nos ambitions ?
  • Je ne me focalise que là-dessus. 

    Si c'est un livrable sur un benchmark stratégique ou sur un atelier d’idéation qui va nous ouvrir la stratégie d’un produit, on peut sortir avec énormément d’idées et énormément d’insights. 

    Au lieu d’être exhaustif, je vais me dire : 

  • Les personnes avec qui on a mis en place ce job, eux, de quoi ils avaient besoin ? 
  • Quel était leur objectif ? 
  • Quelles étaient les objectifs de ce workshop ? 
  • Moi en tant que designer et lead, qu’est-ce que je veux communiquer comme image ? 

    Et en fait je ne me focalise que là-dessus, et je me rends compte qu’il y a énormément de petites choses où j’aurai pu me dire : 

    “Ça peut éventuellement être super intéressant, et ben je le zappe. Si ça peut juste être “éventuellement” intéressant, c’est que ce n'est pas dans un des objectifs de ces personnes, donc je ne vais pas perdre de temps là-dessus.” 

    Finalement, ça permet de passer un gros coup de râteau sur pas mal de choses. 

    Donc je fais un peu aussi de mapping interne: 

  • Qui est impliqué ?
  • Qu’est-ce qui est important pour eux ?
  • Qu’est-ce qui est important pour moi ? et je me focalise vraiment là-dessus. 

    Surtout, là où avant j’aurai pu me dire : Je vais présenter un truc bien abouti, je me rends compte que ça me desservait énormément de le faire.  Car présenter quelque chose de final à quelqu’un qui attend du collaboratif ça n’encourage pas la discussion. La personne n’a plus rien à dire, on passe à côté des échanges et de l’intelligence collective.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX de workshop pour comparer la vision des équipes terrains et du management.

    Lorsque je prends un projet je ne démarre pas si je n’ai pas tout ce dont j’ai besoin parce que je sais que je vais avoir du travail supplémentaire plus tard dans le projet.

    Donc, pour être sûr que j’ai bien le contexte je fais un workshop avec que les parties prenantes sur la vision du projet/produit.

  • Je trouve ça très sympa parce que ça me permet d'avoir une idée de comment les gens pensent qu’ils travaillent.
  • J'aime beaucoup démarrer avec le start with why qui a été utilisé par Steve Jobs et théorisé par Simon Sinek. 

    J’approche le workshop comme cela: 

  • Je propose une prochaine réunion,
  • Je me déplace, dans laquelle on réunit les cadres et des gens du terrain. 
  • En amont je fais valider le workshop avec la direction afin qu’elle ait bien en tête les objectifs du workshop 

    J’ai un exemple récent dans une société qui me vient à l’esprit.

  • À la fin de l’exercice, nous avions trois services ( commercial, SAV et production).
  • Le workshop a permis de mettre en lumière que chaque service proposait une offre différente aux clients. C’est très révélateur pour l’entreprise, cela permet d’avancer vers un projet commun et de corriger le tir.  

    Faire ce workshop était clé pour pouvoir retravailler l’offre actuelle et décider comment en développer une nouvelle. 

    Lorsque l’on observe ce genre de décalage entre l’ambition du client et la réalité des équipes, (et que c’est un gros décalage) on sait que les missions vont prendre du temps et nous pouvons ré-orienter nos efforts d’accompagnement.

    Pour moi ce workshop permet :

  • D’assainir les bases et de déterminer dès le départ sur quoi on va construire demain.
  • D’avoir une ambition commune et partager avec toutes les parties prenantes nous aide ensuite dans le déroulé de nos missions. Il est primordial de remettre les gens du terrain dans la boucle afin de pouvoir ensuite analyser la data sans avoir une overview de la situation. 

    Typiquement sans ce workshop je n’aurai pas compris le décalage qui existait entre la vente, la production et le suivi des projets. Quoique je produise cela n’aurait pas été accepté par l’ensemble des parties prenantes et j’aurai donné l’impression de ne pas avoir compris le but de l’entreprise.

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

    • Commentaires

    • ·
    • ·

    Groupes

    • Vision de l'enfant
      Vision de l'enfant

      Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs etc sur la Vision de l'enfant.

      30 membres
    • Vision de l'adulte
      Vision de l'adulte

      Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la vision de l'adulte.

      15 membres
    • Basse vision
      Basse vision

      Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la basse vision.

      16 membres
    • Vision et sport
      Vision et sport

      Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la vision et le sport.

      18 membres
    • Réglementaire & Juridique
      Réglementaire & Juridique

      Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la situation réglementaire et juridique de notre domaine.

      15 membres
    • Travail et vision
      Travail et vision

      Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur le travail et la vision.

      16 membres
    • Evénements
      Evénements

      Un groupe pour discuter et échanger sur les prochain événements ENVIS.

      8 membres
    • Prévention
      Prévention

      Un groupe pour poser vos questions et partager vos astuces, ressources, outils, et actualités sur la prévention.

      12 membres
    • ENVIS
      ENVIS

      Posez vos questions à l'équipe et suivez directement l'actualité de Wikihero.

      8 membres
    • Solutions optiques
      Solutions optiques

      Groupe pour échanger et s'entraide sur le sujet des solutions optiques.

      12 membres
    • Facilitation
      Facilitation

      Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, et retours d'expériences sur la facilitation d'ateliers, de réunions.

      5 membres
    • Stratégie UX
      Stratégie UX

      Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet de la stratégie UX.

      13 membres
    • Enseigner l'UX
      Enseigner l'UX

      Un groupe pour fédérer tous ceux qui enseignent l'UX afin de partager vos questions ressources et astuces.

      9 membres
    • Management UX
      Management UX

      Dans ce groupe posez vos questions et partagez vos astuces, ressources, outils, jobs et plus encore sur le sujet du management d'équipes UX.

      12 membres

    Hashtags

    • #astuce
      Lorsque vous partagez une astuce sur n'importe quel sujet.
    Groupes