chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
106 résultats
Selection
  • #stakeholders 72
EN LIEN AVEC VOTRE SÉLECTION
  • 637
  • 203
  • 148
  • 138
  • 115
  • 98
  • 90
  • 72
  • 71
  • 60
  • 54
  • 47
  • 47
  • 45
  • 40
  • 39
  • 36
  • 34
  • 32
  • 32
  • 30
  • 30
  • 29
  • 29
  • 28
  • 27
  • 27
  • 27
  • 27
  • 26
  • 26
  • 25
  • 24
  • 24
  • 24
  • 23
  • 22
  • 22
  • 21
  • 21
  • 19
  • 19
  • 19
  • 18
  • 17
  • 17
  • 17
  • 17
  • 16
  • 16
  • 16
  • 16
  • 15
  • 15
  • 15
  • 15
  • 15
  • 15
  • 14
  • 14
  • 14
  • 14
  • 14
  • 14
  • 14
  • 14
  • 14
  • 13
  • 13
  • 13
  • 13
  • 13
  • 13
  • 13
  • 13
  • 13
  • 13
  • 12
  • 12
  • 12
  • 12
  • 12
  • 12
  • 12
  • 12
  • 11
  • 11
  • 11
  • 11
  • 11
  • 11
  • 11
  • 11
  • 11
  • 11
  • 10
  • 10
  • 10
  • 10
  • 10
  • 10
  • 10
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 9
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 8
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 7
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 5
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 4
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 3
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 1
  • 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

  • ·
  • ·
  • Quelles sont vos stratégies comme UXR pour appuyer et prouver la validité de vos recherches ?
    Particulièrement pour les recherches et données qualitatives? C'est un point où je me fais souvent challenger, et je cherche des solutions afin de mieux gérer ces situations. Merci !
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Comment délimiter le champ de compétences entre Researcher et PM ?
    Comme UXR, je me pose la question. Depuis que la discovery est devenue tendance et que le mouvement de démocratisation de la recherche est passé par là les PM n'ont plus peur de se lancer sur des projets de recherches, et court-circuiter les UXR (quand il y en a). Ca m'ait arrivé d'être sur des projets où les PM voulaient absolument leader la recherche, réaliser les entretiens mais attendre l'analyse pépère.. Ensuite, lors de l'analyse: le guide était à moitié suivie, les questions biaisés etc etc..  Je suis ok que l'on inclut les profils à participer à la recherche, socialiser le processus etc.; Mais j'observe une dérive forte qui est que l'on perde la main sur le processus, qui réduit la validité des observations, et surtout que l'on soit perçus comme exécutant plutôt que comme  Cette année, un PM est venu vers moi pour me demander : "Fais ce guide d'entretien" à froid. Je lui ai expliqué la démarche derrière, le raisonnement à avoir etc.. et ça l'a découragé.. Bref, tout ça pour dire que la barrière à l'entrée à parler à des utilisateurs est facile à passer, et cette dernière année je suis de plus en plus inconfortable avec les PM car j'ai l'impression que notre perception comme profession s'est dégradée. UXR, comment faîtes-vous pour gérer des PM qui pensent plus à la discovery qu'à leur delivery ? (surtout quand ils le font mal) Merci !
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Un livre qui m'a aidé à mieux performer en tant qu'UXR
    L'UX n'est pas ma première carrière... je viens du côté obscure de la force. Avant d'argumenter pour les utilisateurs, je montais des campagnes de com pour les convaincre d'acheter, et crushais de la data pour convaincre mes stakeholders de débloquer un budget. On pourrait croire que cela m'a bien préparée à la communication avec mes clients et stakeholders. Hélas, à nouveau cheval de bataille, nouveau fossé de communication. Plus on monte en séniorité plus on se confronte à des stakeholders aux opinions bien tranchées, et plus il devient essentiel de désamorcer des situations à fort potentiel "apocalyptique" (ou comment ne pas se mettre toute une équipe à dos faute de s'accorder sur le fait que les deceptive patterns ne sont pas une option...) Mon expérience m'a menée à la conclusion que l'on ne peut pas toujours (ou que très rarement) écarter les très mauvaises idées de nos stakeholders. Pire encore, se lancer dans un argumentaire fourni à grand renfort de données, insights et théories peut avoir l'effet inverse. À court terme, on essuie un échec cuisant, à long terme, on enterre toute opportunité de collaborer. La solution? Savoir reconnaître une conversation "critique" à temps et réagir de sorte à conclure sur un consensus (au pire) voire une relation renforcée et productive (dans le meilleur des cas).  C'est grâce au livre Crucial conversations: tools for Talking When Stakes Are High (qui m'a été recommandé par Sara Logel) que j'ai pu modifier mon approche de ce type de conversations et mieux encore, les appréhender avec sérénité, sachant que je dispose d'outils pour éviter de courir à la catastrophe. Voici quelques leçons apprises: Rester focalisé(e) sur le vrai problème: bien sûr que c'est nase de pousser aux deceptive patterns, mais est-ce vraiment utile de faire remarquer à votre stakeholder que sa stratégie est, au passage, pas bien plus élaborée? Fixer un objectif durable: il n'y a rien de plus satisfaisant que d'avoir raison, mais si cela doit nous coûter notre relation avec un stakeholder, est-ce vraiment une bonne idée pour la suite de notre projet? Comment envisage-t-on la relation UX-Stakeholder dans la durée? Comment la préserver sans trahir ses propres objectifs? Ne pas se laisser envahir par ses émotions: we're only human, after all... il est tout naturel d'être exacerbé(e), mais on ne gagne rien et se laisser guider par la colère. L'antipathie de l'un n'est pas un reflet de notre échec — tout au plus le résultat d'un manque de perspective.  Identifier les signes que notre interlocuteur(ice) se sent menacé(e): on n'écoute pas lorsque nous sommes sur la défensive! Si notre stakeholder se sent mal à l'aise, insecurisé(e), il ou elle ne sera pas en mesure de changer de perspective. Rétablir un environnement sécurisé est essentiel pour permettre le dialogue. Il peut être utile de commencer tout argumentaire par la notion de respect mutuel et inconditionnel. Chercher le point commun: au final, nous avons toujours un objectif commun, ne serait-ce que le succès du projet. En cas de désaccord majeur, il peut être utile de partir d'un point commun puis d'exposer les faits (et seulement les faits) qui mènent à notre conclusion. Dans la même donne, demander à son stakeholder de présenter ses arguments et son schéma de pensée. Ne jamais se fier à son apriori — en somme, faire son travail de recherche pour établir le modèle mental de son interlocuteur(ice). En somme, ce livre regorge de techniques, qui souvent résonnent avec des connaissances bien acquises (empathie, start with why, state the path...) mais qui ne nous semblent pas toujours super évidentes dans ce type de situations à risque. Il a trouvé une place de choix sur ma bibliothèque et peut aussi s'avérer très utile pour établir les objectifs, argumenter un budget, négocier, ou même refuser un projet sans fermer la porte à une éventuelle collaboration future. 

    • merci! Utile
    • Pas utile
    • Pas sûr
  • L'importance de bien cadrer sa discovery: REX de chez Décathlon.
    Webinaire organisé en ligne gratuitement - Jeudi 19 octobre à 13h. REX de la discovery chez Décathlon ride. Lien de l'event: https://www.linkedin.com/events/decathlonride-l-importancedebie7117134337392685057/comments/
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Un article incroyable sur ce que la justification à outrance de notre valeur à comme impact.
    Cela faisait longtemps que je n'avais pas lu un article comme cela. Il vaut le détour et fait du bien dans cet océan d'auto-flagellation que l'on lit ces derniers temps sur notre profession. Et si on arrêtait de justifier notre valeur pour une fois ? Que se passerait-il si nous nous comportions comme étant important pour le business à ce moment ? (Au lieu de vouloir tout faire ?)  https://medium.com/nice-work-from-active-voice/hey-designers-theyre-gaslighting-you-e02e5a4d9cff Pour info, cela fait echo à deux REX hyper importants que Manue Marevery et Alexa Gueguen on partagées. Car cette justification à outrance crée des conséquences négatives. Cela habitue les équipes à une baisse du standard. On essaye de faire tenir la baraque tout seul alors que l'on devrait pousser à l'embauche de collègues.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment la recherche est utilisé à des fins politiques: Un cas concret hors du monde de l'entreprise
    Sujet connexe à la recherche qui m'a fait réfléchir à nos difficultés sur le terrain. Cette vidéo investigation de John Harris montre bien les forces, et les rouages humains lorsqu'une organisation (dans ce cas là un pays) prends des décisions et va tordre le coup aux évidences et choisir les preuves pour être aligné sur son discours. On parle de comment les gouvernement américain à convaincu le pays d'aller faire la guerre en Irak: https://www.youtube.com/watch?v=LP3T_VAkY9o&list=WL&index=9&ab_channel=JohnnyHarris C'est un exemple extrême de politisation. Le niveau de transparence et de processus décisionnels à passer pour un gouvernement est bien plus fort que dans une entreprise. Néanmoins cela montre à quel point comment les renseignements x insights seront utilisés à des fins politiques, et quel est le sort des "lanceurs d'alertes" venant du terrain. En gros vous serez ignorés, ou pire "remerciés". Rien de déprimant dans cela, juste des luttes de pouvoirs à fuir. Lorsque cela arrive ça nous dépasse. Nous n'avons: Ni le pouvoir (et stabilité de la position - rôle est lié à un contrat par ex) ni la crédibilité interne ni la santé mentale de s'engager dans une voie de la vérité (si vous êtes dans le privé par ex) Lorsque cela se passe le mieux à faire est de laisser l'organisation se brûler et faire ses propres erreurs.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment éviter l'effet "On le savait déjà ?"
    J'y réfléchi en ce moment😊
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Quelles sont vos métaphores les plus efficaces en meetings pour parler de Research ?
    On le sait, la research ce n'est pas un sujet facile. C'est complexe, ça fait peur et surtout c'est très opaque comme sujet. Ca veux tout et rien dire pour certains. J'ai observé lors de mes projets qu'une métaphore bien placée permettait d'éclaircir la situation et rendre le contexte de la recherche tangible pour mes clients x stakeholders. Cela permettait aussi de sauver des situations tendue avec des C-level où la vitesse des sujets de conversations est très rapide et expliquer une approche méthodo peuvent leur faire perdre patience.
    Donc je me posais la question, quelles sont vos métaphores favorites et les plus efficaces pour parler de research ? Et dans quel contexte les utilisez-vous ?
    Métaphore 1: L'éléphant et les aveugles qui croient savoir la vérité Image un peu cliché de la recherche mais tellement vrai. Je l'utilise souvent lorsque plusieurs départements x équipes apportent leur vérité sur la situation sans avoir pris en considération d'autres moments clés de la journey. Je l'utilise aussi lorsque j'ai des scopes limités en research, où par exemple on veut m'obliger à étudier un moment clé, sans prendre en compte ce qu'il se passe avant ou après. De cette manière j'essaie de montrer que l'on va penser que l'on détient une vérité alors qu'en fait c'est un bout de vérité d'un morceau beaucoup plus gros. Très utile dans les projets de type plus innovation et lancement de nouveau produit sur un marché. wikihero-image-id: 1129 MÉTAPHORE 2: Le bourré qui cherche ses clés sous le lampadaire J'utilise cette métaphore surtout dans des situations où les équipes mentionnent que personne ne s'est plaint Les typiques: "On n'a jamais eu de feedback dessus. Pourquoi faire de la recherche ?" "Tout marche très bien" wikihero-image-id: 1127 wikihero-image-id: 1128 MÉTAPHORE 3: you don't know what you don't know A utiliser en combinaison des deux autres situations pour visualiser la connaissance lors d'un workshop, ou lorsque vous êtes dans des équipes un peu plus matures en research et qui commence à prendre confiance dans la research. (J'observe qu'après un certain niveau certaines équipes ne cherchent pus à apprendre et croient connaître) Donc lors d'un workshop j'utilise cela avec un tableau d'hypothèses priorisées par niveau de preuves déjà existantes. Dans un Figjam lorsque vous dezoomez cela permet de comparer entre ce que l'on connait et ne connait pas. Très efficace pour rester humble. wikihero-image-id: 1126
    • Même problème
    • Déjà posée plusieurs fois
    • 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: Ne jamais accepter le “C’est mieux que rien”
    Un autre de mes conseils serait de ne jamais accepter le "c'est mieux que rien". Quand tu es dans une entreprise et que tu exprimes le besoin de 30 utilisateurs et qu'on te répond, que tu as le budget pour 5 utilisateurs... Je ne pense pas que la meilleure idée soit de faire un test dégradé.  Parce que les gens vont s'habituer à des choses de moins bonne qualité. et le jour où tu vas me demander un budget pour 30, ils ne vont pas comprendre… puisque tu as toujours fait avec 5.  Pour moi les choses sont assez simples :  Si tu n'as pas le budget pour faire une bonne étude, tu ne la fais pas.  Si tu n'as pas les moyens pour faire un bon prototype, tu ne le fais pas.  Je pense que c'est une hygiène de l'UX à s'appliquer. Si tu n'as pas les moyens, tu ne le fais pas tout simplement.. Le "c'est mieux que rien",en réalité ca devient vite “pire que tout”. Autant assumer un parti pris plutôt que de faire les choses à l’arrache..  Quand j'entends "oui mais on ne peut interroger que nos amis, ils sont dans la cible"... mais es-tu sur de cela? Ne vont-ils pas être influencés dans leur réponse parce qu’ils te connaissent et connaissent ton entreprises? Serais-tu prêt à parier que le comportement de tes amis et ceux du client final seront le même?  Alors oui, certes, tu vas donner l'illusion que tu as fait quelque chose mais tu ne sais pas si au fond le résultat sera sur ton futur utilisateur.  Je vais plutôt essayer de négocier :  “tu as 1000€ pour cette étude, alors la seule chose que je peux te dire c'est si les utilisateurs vont apprécier ton logo.  Voilà ce que tu pourras savoir. Mais si tu me donnes 10 000€, je pourrai te dire si ton site sera un succès ou pas.  Pour le coup, je fais en sorte que mes études soient le moins chères possible, mais toujours avec des prestataires compétents. Je suis dans une optique d'optimisation, d'efficacité opérationnelle... Il faut être parfois être inventif pour tenir le budget.  Et si ca ne passe toujours pas et bien… dans ces cas-là, sinon je suis désolée mais je ne le fais pas. Ils peuvent passer par une agence externe, se débrouiller autrement, mais moi en tout cas, je ne le ferai pas. J'ai mieux à faire de mon temps que de réaliser un test qui ne sert pas à prédire le futur comportement de l’utilisateur parce qu’il a été mal fait.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Détaillez les limites de l'étude.
    Chez Decathlon, on faisait beaucoup de tests. On faisait des corrélations entre les notes du tests et la note d'avis client. En général, on testait un produit et des mois après le produit sortait. On savait à l’avance si ça allait être bien ou pas. Cette manière a toujours bien marché. On avait un très bon modèle prédictif. Cela reste une modélisation et parfois tu as des surprises : par exemple tu as des gens qui ne sont pas prévus dans ta cible initiale et qui achètent quand même ton produit.  Parfois tu as des éléments tels que le covid ou la guerre en Ukraine etc. qui viennent faire bouger ce que tu attendais en termes d'usage, et aussi tu peux être en retard ou en avance.  Donc avec toutes ces inconnues, ce qui est important, c’est lorsque tu remets un rapport, tu expliques les limites de ton étude.  Une fois que tu fais ça, tu es rarement contesté, car tu as su prédire. Mais si tu n'as pas précisé quelles étaient les limites, tu as en vendu du rêve, attention au retour à la réalité. Je suis très attentive à ça : "Attention, c'est basé sur du déclaratif. Attention, cette étude a été réalisée pour la France et n'est pas valable ailleurs".  Je crois que dans toutes nos études on devrait expliquer nos limitations.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment répondre à cette demande: "Est-ce que les gens utiliseront ce produit ?"
    Déjà il faut se poser la question de l'utilisabilité avant de parler d’utilisation. Pour l’évaluer - l'utilisabilité- je préfère amplement utiliser une grille experte répétable et reproductible plutôt que des interviews ou des tests. Comme elle se base sur des critères mesurables : Elles ont une très bonne interjuge : , c'est-à-dire que deux UX différents vont donner la même évaluation sur une interface. Ce qui n’est pas le cas avec d’autres critères qui sont habituellement enseignés.  Je prends un exemple : ”le site prévient les erreurs de l’utilisateur” est assez subjectif , alors qu’évaluer s'il y a “Moins de 5 typo dans une même page” l’est un peu moins.  Il y a énormément de grilles qui sont disponibles et qui sont de bonne qualité. Une fois que j’ai fait la grille, je peux tester les zones avec des utilisateurs qui ont été mis en doute par l’audit.  Je préfère également donner des guides de conception (des guidelines), plutôt que de faire du test U à répétition. Je pense qu'il n’est pas toujours nécessaires de tester pour se rendre compte qu'une couleur n'était pas lisible sur une maquette parce que le contraste n’est pas suffisant. Pour revenir au sujet de base, sur l’utilisation, afin de savoir si une plateforme va être utilisée ou pas, il faut le faire sur une étude quantitative et idéalement en comparatif. On va proposer plusieurs solutions (donc notre préféré mais aussi au moins une idée bien naze) pour être de mesurer une différence d’appréciation. On pourra alors dire que: “L’utilisation sera de X %”. Toute fois, il ne s’agit que du déclaratif et il peut y avoir un écart énorme entre la réalité, c’est pourquoi on préfère avoir du comparatif “l’utilisation sera de X% de plus que l’autre idée”  Une des choses que je fais beaucoup, c'est que lorsque quelqu'un vient me voir pour une demande de faire étude. On va passer beaucoup de temps à clarifier sa question de recherche en utilisant la méthode des 5 pourquoi. Quel est le vrai but de cette étude? En fait, je vais énormément challenger l’objectif et l’impact de mes études, parce que j'ai fait d'études qui ne servent à rien. Donc, je continue, je continue, je continue jusqu’à ce que je sois sûre que l’étude servira à prendre une décision. (si ce n’est pas le cas je dis non)  Et si j’ai encore un doute sur l’utilité de l’étude, il m’est arrivé de “hacker” la conversation en donnant un résultat au hasard.  Parmi les outils que j'ai à la maison, j'ai la "eight ball" (elle dit “maybe, yes, no, …”), et j'ai aussi un dé à 60 faces. Quand j'ai quelqu'un qui vient, qui me pose une question, ça peut m'arriver par provocation, de lancer l'un des deux.  Moi : La réponse c’est 51 %". Dans ce cas-là qu'est ce que tu fais avec cette donnée-là ? Lui: “Je veux quand même faire mon produit.” Moi:  Alors pourquoi veux-tu faire une étude ? “ Cela m’aide à savoir s'il est nécessaire de lancer l’étude… ou pas.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Obtenir des tâches plus stratégiques et aller au-delà de son rôle.

    Je pense que j'observe pas mal le niveau d'ouverture des gens avec qui je collabore. 

    Ça se voit immédiatement quand quelqu'un est très directif, du style "Je veux que tu fasses ABC et c'est tout. Je ne veux pas savoir ce que tu penses de D". 

    Ça se ressent très vite. Si tu peux estimer,peut-être sur un spectre, l'ouverture des gens avec qui tu travailles, c'est un très bon début. Il faut savoir où tu te trouves si tu veux bouger. 

    Puis par la suite, savoir ce qui est important pour ces gens-là. 

    Je pense que l'idée, c'est toujours d'apporter de la valeur dans un premier temps. 

    Si tu apportes de la valeur, les gens ont l'impression que tu peux transposer ce même exercice à un autre sujet. 

    C'est comme des stars qui deviennent connues en chantant et qui font une marque de vêtements. Pour une raison ou pour une autre, c'est crédible pour les gens qu’ils sont compétents aussi dans ce domaine. C'est un biais que l'on a mais dans un premier temps je pense qu'il faut déjà bien faire, peut être avec le peu que tu as et ensuite demander : "Est-ce que vous êtes satisfait avec ce que je fais là ? Je pense que je pourrais être encore plus utile sur tel ou tel sujet". 

    Sincèrement, c'est ma façon d'approcher le truc. Vraiment, sans sournoiserie, sans manipulation. 

    J'essaye vraiment d'aider. Quand c'est sincère et quand c'est présenté comme ça, les gens te voient moins comme quelqu'un de louche ou qui cache des choses. 

    Je pense que je peux aider et que ce serait du gâchis de ne pas m'écouter, en tout cas même deux minutes sur telle ou telle chose. 

    D'expériences en expérience tu as ces parties que tu grappilles pour avancer. Mais je pense qu'il faut vouloir aider. Il faut être sincère et vouloir être utile. C'est un état d'esprit qui doit t’animer ! Et il ne faut pas se laisser être emporté dans la direction du vent.

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

    Il y a un exercice incontournable que je réalise à chaque projet et qui a une valeur inestimable. Je suis entrain d’écrire un article justement à ce sujet, donc j’essaierai d’être clair et concis, puis je joindrai un lien vers l’article complet si nécessaire. 

    Cet exercice est une version modifiée du KWHL Chart. 

    Un tableau utilisé en phase préparatoire de recherche pour mettre à plat ce qu’on sait ( Know), ce qu’on veut savoir ( Want), comment nous allons l’apprendre ( How), et pour finir ce que nous avons appris ( Learned).

    C’est plutôt simple, dans un premier temps, je vais collecter de la donnée secondaire (données existantes, effort de recherche précédents et leurs apprentissages, …) 

    Après avoir consommé cette donnée, je vais faire un bilan sur ce que l'on sait, ce que l'on ne sait pas, j e vais essayer de le faire avec toutes les personnes impliquées dans le projet.

    Le fait de dire à voix haute ce qu’on sait et ce qu’on ne sait pas, injecte une bonne dose d'humilité dans l’équipe. A partir de ce moment tout le monde part sur un même pied d'égalité, et on peut admettre les choses qu'on ne connaît pas, sans peur d’être jugé.

    Ce bilan de connaissances, je le considère comme étant ma responsabilité et ça rejoint le premier sujet dont on parlait, à savoir le fait de posséder un sujet ou de prendre la responsabilité de quelque chose. J'estime que c'est à moi de réunir et de guider. 

    Je le vois comme ça le rôle de product designer ou de designer en général. 

    Quand c'est possible, je le fais avec des personnes de l'analytics, du business, tout ceux qui font partie du product management ... Tous ceux qui détiennent une connaissance sont les bienvenus. 

    Par contre, quand ce n'est pas possible, je pars d'un document et puis après ça va partir en mail et en requête de données. 

    J'essaye de rédiger des questions et ensuite de les envoyer. 

    Pour les questions j'essaye de ne pas demander de données trop spécifiques.

    J'essaye de poser des questions en premier lieu afin de laisser les gens qui travaillent avec moi réfléchir. 

    Par exemple : "Je veux telle donnée précisément, je veux tels chiffres...". 

    En lisant la question "Est-ce que cette fonctionnalité est utilisée ?", chez quelqu’un ça peut déclencher encore d'autres questions que moi je ne me serais pas posées. 

    Une personne pourrait penser à d'autres metrics, d'autres choses intéressantes à relever ou d'autres questions à poser encore à quelqu'un d'autre.

    En recherche, rien ne vaut une question bien posée ! 

    La quantité et la qualité d’information qu'on peut tirer d'une bonne question est magique ! 

    Je pense que c'est très important de laisser l'intelligence des gens avec qui on travaille nous aider. 

    Au final je pense qu'ils détiennent une info qu'on n'a pas. C'est bien pour ça que l'on travaille ensemble et parfois on peut passer à côté de choses si on est trop spécifique dans nos demandes.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pour augmenter votre impact de researcher comprenez l’organisation où vous travaillez

    Ce que j'aurais aimé au début de ma carrière, c'est que l’on me dise l’importance de mieux comprendre l'organisation dans laquelle on travaille au-delà du produit.

    Pour comprendre cela il faut comprendre mon parcours.

    J’ai un cursus universitaire, en sociologie et anthropologie et j’ai bifurqué vers le design à la fin de ma thèse.

    Quand l’UX est arrivé la double casquette m’a permis de tout de suite être à l’aise. Mais le rôle propre d’UX Researcher, c’est dans mon précédent emploi que je l’ai pris en premier, il y a 4 ans.

    Lorsque tu es designer tu as l’habitude de travailler sur des interfaces, tu produis des choses. Mais un researcher c’est plus que ça. Il produit de la connaissance, il produit plein de connaissances pour le design mais aussi sur l’ensemble du process produit et c’est hyper important.

    Je crois qu'aujourd'hui, le sujet sur lequel je suis le plus affûtée, c’est de bien comprendre l’organisation du produit.

    En arrivant dans mon précédent emploi, j’ai mis du temps à comprendre l’organisation produit. Parce que finalement le researcher est dans le process produit, l’interface entre le PM et le design. J’ai vraiment eu besoin de bien comprendre les process et les rôles de chacun et aussi les interactions entre les équipes

    Encore aujourd'hui, ce n’est pas forcément toujours facile. L'entreprise dans laquelle je travaille actuellement est une grosse entreprise. L'avantage que j'ai, c'est qu'elle est hyper bien structurée.

    On a beaucoup de rituels, donc on peut bien voir comment ça fonctionne. Les PM avec qui je travaille qui sont les PM front, nous intègrent dans leurs rituels de dev, et nous, on les intègre dans nos ateliers de construction, de co-conception et de recherche aussi.

    C'est notre manière, de bien comprendre et connaître la manière dont on travaille les uns et les autres.

    Parce que souvent comme researcher, tu vas te retrouver dans la situation où on va dire

    “Vas-y, il faut qu'on ait des insight utilisateurs sur tel sujet”

    Mais tu ne comprends pas dans quel objectif ça s’inscrit, dans quel roadmap, etc.

    Maintenant, dans mon équipe, on a construit un template de briefs pour se demander à chaque fois pourquoi on veut faire ce sujet de recherche

    Quels sont les objectifs business ?

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

    Comme ça, on sait bien ce qu'on fait, pourquoi on le fait et comment on rend toute la recherche activable pour les parties prenantes.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • Comment refuser lorsque tu as été recruté·e pour un boulot d’expliquer pourquoi tu as été recruté•e?

    Ce n'est pas possible de refuser complètement. Surtout que si on est complètement lucide, si tu es en CDI et qu'on te demande de faire ça au début de ton contrat et que tu refuses, tu mets un peu ta période d'essai en jeu. Il faut peut-être poser deux ou trois jalons et après dire "non, ce sujet-là, on l'a déjà couvert, on va arrêter de revenir en boucle là-dessus et puis on va avancer".  J'ai l'impression que c'est un piège dans lequel on est... Que ce soit les designers, les researchers et les UX writers. Les deux dernières catégories étant un peu plus dans ces problématiques là, mais en fait typiquement les devs, on ne leur demande jamais de prouver à quoi sert le code.
    • Même problème
    • Déjà posée plusieurs fois
    • 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
  • 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
  • Quelle est votre description/présentation envers vos stakeholders ?
    Par curiosité car c'est un sujet qui m'intéresse; le positionnement en interne. Comment décrivez-vous votre apport dans une équipe ?  A quoi servez-vous pour le produit ?
    • Même problème
    • Déjà posée plusieurs fois
    • 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.

    • Nicolas MATHIEU · UX-R Manager · il y a 5 mois
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ne vous arrêtez pas aux premières critiques sans avoir rendu tangible votre vision avec un proto

    Un conseil que j'aurais aimé recevoir plus tôt dans ma carrière est celui de persister et de m'accrocher sur les projets que je menais, surtout lors des phases très early où les critiques internes peuvent être déstabilisantes. 

    Parfois, j'ai abandonné un peu trop vite face à la pression, ce qui a eu pour conséquence de mettre un terme prématurément à des projets d'innovation prometteurs. 

    Je me rappelle de ces moments où l'étape primordiale était de construire une vision, mais où j'ai été submergé par une avalanche de critiques de la part de mes collaborateurs. 

    Trop souvent, j'ai abandonné le projet en me disant que s'il y avait autant de critiques, cela ne pouvait être une bonne piste à suivre. Mais c'était justement l'erreur à ne pas commettre : s'arrêter aux premières critiques.

    Il est important de comprendre que les critiques font partie intégrante du processus d'innovation et qu'il ne faut pas les voir comme des obstacles insurmontables. 

    En acceptant cette étape comme faisant partie du jeu, on évite de se décourager trop vite. En effet, à posteriori, j'ai souvent constaté que quelqu'un d'autre avait repris l'idée que j'avais abandonnée, ou que l'idée avait été développée et présentée d'une autre manière. 

    Pour rendre cette étape plus impactante et engageante pour mes interlocuteurs.rices, j'ai appris à travailler davantage en amont mes idées pour consolider ma vision. 

    Outre travailler la communication d'une vision plus claire, une astuce que j'ai apprise est de prototyper très tôt afin de rendre les choses concrètes pour mieux les expliquer. Le prototype a plusieurs avantages: 

    -il envoie un message clair : cela est faisable ! Les parties prenantes sont souvent rassurées de voir des résultats concrets plutôt que de simples idées théoriques.

    -il permet de mieux se faire comprendre en apportant des éléments tangibles. Ainsi j'ai pu recevoir de meilleurs feedbacks pour affiner mes idées, les faire mûrir et trouver des allié.e.s.

    -il permet aussi de se positionner en “responsable” de cette conduite du changement en permettant de discuter d’un plan d’action, en montrant que des ressoruces existent. 

    Ainsi, pour gagner en leadership, je me suis fixé comme règle que lorsque je présente une idée même aussi minime qu’elle soit, je l’accompagne toujours d’une ébauche de solution, d’un Mock-up…. D’une base concrète quoi. 

    J'ai également travaillé sur mon état d'esprit pour accepter les critiques sans tomber dans une spirale de négativité qui a tendance à briser la créativité. 

    Les résistances sont souvent bénéfiques car elles nous forcent à consolider notre vision et à proposer des solutions plus solides, mieux construites. Cela nous permettra d'embarquer du monde avec nous, in fine. En somme, il faut apprendre à remercier cette étape de "résistance" qui nous permet de produire de belles innovations. En réalité, après quelques expériences, c'est lorsque nous ne rencontrons pas de résistance qu'il faut s'inquiéter.

    Pour donner un exemple concret où cela s'est passé récemment, j'ai travaillé sur des échelles de psychométrie pour mesurer l'engagement, un vaste sujet dans l'industrie du jeu vidéo. 

    Pendant trois à six mois, j'ai discuté de cette idée, mais elle a été rejetée avec de nombreuses critiques : cela ne menait pas la recherche utilisateur dans la bonne direction, c'était trop difficile, et cela ne servirait à rien de toute façon. 

    J'ai été confronté à de nombreuses critiques et je n'arrivais pas à clarifier pourquoi je voulais travailler sur ce sujet et quelle approche adopter.

    Ce que j'aurais dû faire, et ce qui a été fait par la suite, c'était : 

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

    Malheureusement, une autre équipe a commencé à travailler sur le même sujet et a pris la direction du projet. 

    J'ai fini par rejoindre cette équipe, et c’est d’ailleurs en accompagnant mes idées pour ce projet avec des choses concrètes que j’ai pu rejoindre ce projet. Mais cela a été frustrant de réaliser que j'avais perdu trois à six mois dans des discussions qui au final n'avaient pas fait avancer le projet. Peut-être que l'idée de départ n'était pas si mauvaise après tout.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment gérez-vous et créez-vous la taxonomie en Atomic research ?
    La taxonomie reste un sujet complexe et délicat à aborder. Nous nous sommes rendus compte qu’il peut être difficile de la rendre réutilisable et efficace, car il faut prendre en compte plusieurs éléments tels que l'outillage, le timing et l'analyse. Premier challenge: Les outils utilisés ne sont pas toujours parfaits. Notamment lorsque différentes personnes sont impliquées dans la création des tags, ce qui peut entraîner des divergences de vision et compliquer la recherche du niveau adéquat entre parties prenantes. Ensuite, vient l’utilisation des tags et l’ajustement entre le macro et le micro. Dans un projet récent, avec une équipe composée de quatre chercheurs designers, nous avons créé un groupe de tags communs avec différentes catégories pour la partie de l'expérience que nous avons traitée.  Par exemple, nous avons créé des tags pour les différentes phases du parcours collaborateur, les moments clefs (“moments that matter”), les besoins, les opportunités, ainsi que pour illustrer les outils ou les processus spécifiques. Pour les tags liés aux moments clefs, nous avons dû effectuer plusieurs itérations. Au départ, nous avions des actions très détaillées, mais cela rendait difficile le regroupement des informations. Nous avons donc dû simplifier en généralisant, parfois trop, parfois pas assez, jusqu’à trouver le juste milieu pour permettre une analyse efficace : il faut trouver le bon niveau de granularité permettant de faire des regroupements et tirer des enseignements, sans pour autant trop généraliser et se retrouver à devoir relire chaque élément pour créer nos insights.  La recherche ayant été menée autour de différents personas, nous avons également dû ajuster au fur et à mesure les tags pour avoir des éléments en commun entre les personas et faire ressortir des enseignements globaux lorsque pertinents.  Bien que ce processus soit itératif et nécessaire, nous aimerions explorer une approche plus simple à gérer et commune à tous les projets, même si nous savons qu'il n'y a pas de solution magique. Pour l’instant, nous nous sommes arrêtés à des catégories communes (avec des couleurs associées permettant de facilement retrouver ses petits d’un projet à un autre).
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Une erreur : Foncer tête baissée dans les projets sans penser à la politique.

    Une erreur que j’ai commise dans ma carrière était de ne pas identifier les sujets politiques, (internes ou externes), et les motivations de chaque personne liée à ces projets. 

    Je pense qu'il est essentiel de bien comprendre les personnes avec lesquelles je vais interagir au cours d’un projet et de toujours prendre du recul avant de démarrer. 

    Aujourd’hui je suis attentif à : 

  • Leurs positionnements
  • Leurs objectifs 
  • et leurs motivations. 

    Parfois, il peut arriver de travailler avec des personnes difficiles, voire manipulatrices, qui cherchent à exercer un contrôle excessif sur les projets. Il est donc important de les identifier dès que possible et d'apprendre à naviguer autour d'elles.

    Pour moi, une approche efficace consiste à écouter mon intuition et à comprendre les objectifs de ces personnes. 

  • Qu'est-ce qui les motive ?
  • Qu'est-ce qui les pousse à agir ? 

    En comprenant leurs perspectives, je peux mieux travailler avec elles et les amener à contribuer dans la direction attendue, tout en les laissant croire qu'elles mènent la prise de décision.

    Il est également crucial de bien connaître l'écosystème dans lequel j'évolue. 

    Cela signifie comprendre les autres acteurs impliqués, leurs objectifs et leur niveau de maturité par rapport à mes domaines d'expertise, tels que l'agilité, la recherche et le design. 

    Il peut être judicieux de concentrer ses efforts sur les personnes ou les sponsors les plus favorables à l’approche proposée, plutôt que de perdre du temps avec ceux qui sont fermés au changement.

    Cependant, je conviens que ce n'est pas toujours facile et que cela demande du temps et des efforts. 

    En tant que freelance, il peut être encore plus compliqué de comprendre les dynamiques internes d'une entreprise. Il peut être utile de collaborer avec des collègues ou des experts qui ont de l'expérience dans ce domaine pour obtenir des conseils et des orientations. Pour résumer, voici comment je m’y prends pour éviter de foncer tête baissée dans les obstacles politiques.  Qu'est-ce qui fera avancer cette personne ?  Qu'est-ce qu'elle cherche réellement ?  Comment est-ce que je peux agir sur ses déclencheurs, ses objectifs ? Afin de remettre les choses de son point de vue, de sa perspective, et essayer de partir de là pour avancer. Ensuite, je cherche aussi à identifier les autres acteurs dans l'écosystème, à comprendre ce qui les motive, quels sont leurs objectifs, et ainsi savoir dans quelle direction je peux tirer pour atteindre les objectifs fixés.  Ce n'est pas toujours évident, car je ne suis pas spécialiste dans ce domaine, mais j’ai eu la chance de travailler en étroite collaboration avec un spécialiste avec qui j'ai pu échanger régulièrement et cela nous a permis d’obtenir de très bons résultats. Nous avons travaillé sur une cartographie des parties prenantes pour essayer de visualiser tous les acteurs importants autour de nous, comprendre ce qui les motive, comment ils fonctionnent, s'ils sont en accord avec nos objectifs, s'ils sont matures dans nos domaines d'expertise, tels que l'agilité, la recherche et le design. Pour cela, nous avons notamment utilisé le modèle de saillance des parties prenantes (“Stakeholder Saliency Model”) :  wikihero-image-id: 1066 Stakeholder Saliency Model ( source) Cela nous permet de mieux collaborer avec eux, de savoir avec qui concentrer nos efforts, qui cibler.  Si nous constatons que certaines personnes sont totalement réfractaires au changement ou fermées à toute idée, nous ne perdons pas de temps avec elles. Nous cherchons plutôt à obtenir le soutien des sponsors pour faire avancer les choses dans la bonne direction.  En ce qui concerne les sponsors, les réactions des gens sont différentes, et nous cherchons à identifier les personnes les mieux placées pour nous aider à progresser dans la direction souhaitée.  C'est un travail de fond important, parfois réalisé en coulisses, car ce n'est pas toujours notre mission principale. Cependant, nous le faisons dans l'intérêt de notre mission globale, afin de nous assurer que nous avançons dans la bonne direction.  Ainsi, nous avons des objectifs clairs qui nous motivent à accomplir ce travail, même si ce n'est pas toujours facile pour moi, car ce n'est pas ma spécialité.  Mon collègue, quant à lui, est davantage spécialisé dans l'organisation de l'écosystème. Cependant, je m'implique de plus en plus dans ces tâches pour répondre aux besoins de notre équipe et c’est un sujet très intéressant et bénéfique pour notre métier. En tant que DesignOps / ResearchOps, c'est ce que nous faisons également au sein de notre équipe : Créer une culture et des valeurs communes, et nous insérer au mieux dans l'organisation. Il est courant de partir d’un modèle de maturité pour évaluer notre niveau actuel, faire un constat et un audit, puis planifier la progression vers des niveaux supérieurs. Pour ma part, j’ai une préférence pour le modèle de maturité de Jeff Sauro. Dans ce cadre, et encore plus lorsqu’une transformation globale de l’entreprise est en cours comme c’était le cas pour l’entreprise pour laquelle j’ai récemment travaillé, ce travail de cartographie des parties prenantes est particulièrement crucial pour identifier les obstacles qui peuvent entraver le développement de l’UX et qui peuvent nous ramener en arrière et qui, au contraire, va pouvoir être moteur dans ce développement et permettre de gagner en maturité. C'est là que la politique entre en jeu. Il est donc essentiel de trouver les bons sponsors et les bons leviers pour nous aider à avancer.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • L’importance de la recherche sur et avec les parties prenantes.
    Au cours de mes années d'expérience, j'ai observé deux erreurs majeures qui sont fréquemment commises : Ne pas prendre le temps d'aligner ses équipes avant de démarrer Vouloir aller trop vite en prenant des décisions trop rapidement Ces erreurs sont souvent à l'origine des problèmes que nous avons été appelé à résoudre en entreprise. Car après quelques semaines, quelques mois, voire quelques années, la vision de l'équipe s'estompe, l'alignement disparait, et les membres de l’équipe perdent l’envie de travailler ensemble. En réalité, pour créer une équipe forte, il est essentiel que chacun ait sa trajectoire. Travailler seul peut sembler plus facile au démarrage, mais travailler en équipe implique de comprendre les trajectoires individuelles et de parvenir à une vision commune. Erreur 1 : Ne pas prendre le temps d'aligner ses équipes Lorsqu'un projet démarre, il arrive souvent qu'on nous dise :  "Voilà, nous avons lancé ce produit, nous l'avons conçu tous ensemble. Nous sommes vraiment une équipe pluridisciplinaire, mais nous nous posons des questions sur la pertinence du produit. Nous aimerions savoir ce que les utilisateurs en pensent."  À ce stade, nous demandons souvent à interviewer les parties prenantes avant de nous lancer dans le projet.  Nous prétextons vouloir connaître les messages clés qu'ils souhaitent transmettre à travers le produit. Selon leurs réponses, nous leur demandons si ces messages sont bien partagés par tous.  La plupart du temps, ils nous répondent : "Oui !" Mais en réalité, lorsque nous commençons à interroger les personnes, nous constatons qu'aucune d'entre elles ne dit la même chose. Il arrive même que plusieurs d'entre elles disent le contraire.  Ainsi, à la fin de ce processus, nous rassemblons tout le monde et nous présentons ce que personne n'a osé dire seul, afin de réaligner l'équipe.  Un exemple frappant me vient à l'esprit. Il s'agissait d'une grande banque qui nous avait présenté une proposition de valeur, mais celle que l'équipe avait transmise était très différente de celle dont elle nous avait parlé lors du briefing... En fait, cela faisait deux ans que l’équipe travaillait sur ce produit, mais elle n'était pas alignée, ce qui expliquait que le produit soit confus. Les personnes qui avaient proposés telle ou telle fonctionnalité poussaient dans des directions opposées..  Il s’agissait plus d’un amalgame de fonctionnalité, sans un vrai scénario d’usage, ! Ainsi, à un moment donné, il était inutile de lancer le produit sur le marché, car il n’y avait pas de cas d’usage réels.. Ce genre de situation est ce que nous constatons régulièrement dans notre quotidien, alors que finalement, l'UX (expérience utilisateur) n'est qu'une question de posture et d'attention.  Pour éviter cela, il est essentiel de favoriser le partage d'une vision basée sur les besoins concrets du terrain, en écoutant attentivement chacun et en donnant l'opportunité à tous de s'exprimer. Comment y parvenir ?  En menant des entretiens avec les parties prenantes et en offrant un moyen de transmettre cette compréhension interne entre les équipes. 2. Une autre erreur courante est de vouloir aller trop vite et de prendre des décisions hâtives.  Je vois tellement d'exemples autour de moi. Mon conseil est justement d'éviter de précipiter les décisions. Trop souvent, la tentation est grande de prendre des décisions sans réellement ouvrir la discussion et obtenir l'adhésion de tous. Pourtant, ce que j'ai appris, c'est qu'il est illusoire de prétendre avoir pris une décision si elle n'a pas été acceptée par l'ensemble des parties prenantes.  Prendre une décision trop rapidement, c'est comme construire une maison sans avoir posé de fondations solides. À un moment donné, les problèmes surgiront, comme de l'eau qui s'infiltre en dessous ou des fissures dans les murs. Il n'y a pas de secrets. Prenons l'exemple de la définition d'une offre au sein d'une entreprise.  Si cette offre ne couvre pas l'ensemble des besoins de chacun, les personnes ne la présenteront pas spontanément à leurs clients Chacun la présentera de manière différente, voire même contradictoire, parce qu'ils ne l'auront pas vraiment intégrée. Cela arrive fréquemment dans les offres de produits. Une offre de service ou de produit, si elle n'est pas partagée, comprise, assumée et si les personnes ne sont pas convaincues, ne sera pas vendue efficacement.  C'est pourquoi il est crucial de cartographier ces besoins lors d'ateliers avec les parties prenantes. Lors de ces ateliers, il est important de permettre à chacun d'exprimer ses ambitions personnelles, car c'est ce qui compte le plus. Quant au reste, il peut y avoir des personnes qui n'ont pas envie de parler ou de s'exprimer, mais qui ont moins d'ambition ou d'envies personnelles, et elles peuvent néanmoins trouver leur place dans l'équipe."
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Sachez abandonner certains combats pour vous concentrer sur les bonnes batailles

    Une erreur que j’ai pu faire, c’est peut-être de ne pas abandonner certains combats qui ne valaient pas la peine d’être menés dans des projets. 

    Parfois, un projet rencontre des blocages. Les raisons peuvent être multiples, ça peut-être parce que vous êtes face à des enjeux politiques, parce que le projet vient contrecarrer une stratégie de l’un, empiéter sur le périmètre de l’autre, etc. 

    Ça peut être aussi parce que les gens ne sont pas prêts au changement. Notre travail de designer amène ce type de situations. En concevant ou en optimisant des parcours et des outils, on va parfois amener des changements de process, de tâches, des périmètres,, etc. Et ça, les gens que vous avez en face de vous ne sont peut-être pas forcément prêts à le voir et à le savoir. On peut rencontrer de la résistance face à nous. 

    Et face à la résistance et l'accompagnement au changement, il faut savoir choisir ses combats, car il y a des batailles qui ne valent pas le coup d’être menées. Soit parce qu’on est trop petit face à la situation, soit parce que ce n’est pas la priorité du moment.

  • Si on est trop petit face à la situation, il va falloir aller chercher les bons sponsors 
  • Si ce n’est pas la priorité du moment, il va falloir faire le deuil de cette optimisation ou de cette brique d’expérience que l’on voulait pour le moment. 

    Tu peux aussi garder cette bataille dans un coin de la tête pour la ressortir plus tard. Parfois, ce n’est tout simplement pas le bon timing et il va falloir être patient pour pouvoir ressortir cet élément au bon moment. 

    Les gens en face de toi ne sont peut-être pas encore prêts à recevoir cette information, il faut parfois savoir laisser le sujet ouvert et y revenir quelque temps après. 

    Ou alors prendre un chemin détourné, en fonction de ce que tu souhaites faire passer, pour amener ta proposition d’une autre manière, la retravailler pour qu’elle soit mieux acceptée. C’est un type de challenge qui est intéressant parce que ça te force à retravailler ta stratégie d’approche, à être créatif pour te sortir des contraintes. Quand tu ne peux pas passer par la porte, parfois tu peux passer par la fenêtre !

    Quelques observations pour détecter lorsque les gens en face de toi ne sont pas prêts à aborder ces thématiques :

  • Les réunions de travail et d’information, est-ce qu’ils se présentent ou est-ce qu’ils esquivent ? 
  • Est-ce qu’ils participent ? Tu le vois s’ils traînent la patte dans tes ateliers ou pas. 
  • Est-ce qu'ils répondent à tes e-mails ? Font-ils en sorte de faire avancer le sujet ?
  • Y a-t-il beaucoup de réactions de résistance, de freins exprimés face à tes propositions ? 

    Lorsque la situation se débloque, tu le vois :

  • Les gens sont motivés et participatifs dans les réunions et les ateliers.
  • Ils vont réaliser des actions sur le projet, ils vont avoir envie de le faire avancer. 
  • Ils vont te demander des nouvelles aussi, vont avoir régulièrement envie d’être informés.
  • Ils sont investis et engagés, ils reçoivent tes recommandations et tes propositions de manière positive et enjouée.
    • 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

  • Être externe dans une entreprise: Mon rex
    Je suis toujours en train d'évaluer si c'est vraiment un bon compromis. C'est une situation un peu spéciale où j'ai l'impression d'être à la fois différent des autres employés et en même temps semblable à eux.  Il y a toujours des rappels qui me montrent que je ne suis pas tout à fait comme les autres, et cela peut être désagréable par moments.  Mais il y a aussi des avantages, notamment le fait que, contrairement à un employé interne, j'ai l'impression d'être davantage écouté sur les sujets d'expertise pour lesquels je suis rémunéré. C'est une sensation étrange, car les compétences que j'apporte ont un coût tangible et concret, alors que le coût d'un employé interne est souvent dissimulé dans la masse, tout comme son expertise Cependant, l'inconvénient est que je suis souvent limité à l'expertise pour laquelle j'ai été engagé. En tant qu'externe, j'ai été embauché pour cela précisément, donc il est attendu que je me concentre sur ces domaines. Dès que je sors un peu de cette zone, même si c'est justifié, j'ai l'impression d'entendre : "Tu es là pour faire de la recherche UX, rien d'autre." C'est donc une limite inhérente à ma position. Il y a des avantages et des inconvénients, tout comme il y en a pour un employé interne. Cela dépend également de l'endroit où l'on atterrit et des personnes avec qui l'on travaille. Certaines situations peuvent offrir plus de liberté que d'autres, mais je pense que c'est une réalité tant pour les externes que pour les internes. Ce qui définit et caractérise ma première relation avec les gens dans l'entreprise, c'est le mandat pour lequel j'ai été engagé. Cela crée une dynamique particulière, presque comme l'effet McKinsey. J'ai travaillé dans de grandes entreprises où certaines personnes voulaient prendre des décisions, mais personne ne les écoutait. Puis, un grand cabinet externe venait et disait la même chose que ces personnes depuis 30 ans, et tout le monde était d'accord. C'est un peu l'effet de l'externe en général, lié à la visibilité des coûts et à l'aura de l'expertise externe sur certains sujets, souvent au détriment de l'expertise interne. Il faut trouver un équilibre entre les deux. D'après mon expérience, j'ai toujours ressenti la responsabilité de créer quelque chose pour les personnes au sein de l'entreprise, quelque chose qui continuerait d'exister même si je partais. C'est une mission qui me tient à cœur, surtout lorsque je sais que je peux quitter un projet du jour au lendemain.  Ce n'est pas forcément une valeur que l'on perçoit autant lorsque l'on est en interne, bien que j'essaie de me l'appliquer, car je ne veux pas être indispensable. Il y a cette phrase : "N'essaie pas d'être indispensable, mais essaie d'être mémorable", et j'essaie de la mettre en pratique en me disant que les gens se souviendront de moi pour ce que j'ai laissé derrière moi, et non pas en se disant : "Oh, si Kevin était là, il ferait quelque chose." Lorsque l'on apporte de vrais changements qui ont un impact significatif sur l'entreprise, on se sent souvent limité dans notre capacité à le faire en tant qu'externe.  D'abord, on est perçu comme un externe, et puis on a souvent des contacts limités au sein de l'entreprise, ce qui peut nous rendre hésitants à aller plus loin.  On se demande parfois s'il est approprié de contacter le PDG ou le directeur technique en tant qu'externe. Donc, même si on nous donne une certaine marge de manœuvre, on ne se sent pas toujours pertinent pour aller plus loin. Ce n'est peut-être pas le cas pour tout le monde, mais c'est un sentiment que j'ai éprouvé, et je ne me suis pas toujours senti à l'aise pour faire certaines choses que j'aurais peut-être faites dans d'autres circonstances.
    • 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
  • 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
  • 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
  • Mieux comprendre le contexte des parties prenantes et mes techniques pour faire cela

    Quand j’interviens avec mes clients, je demande toujours :

  • Sommes-nous sur une intervention design ?
  • Cherchons-nous à orienter une stratégie ? 
  • Ou sommes-nous plus sur du change ?

    La réponse est systématique, ah les 3 ! 

    En fait, les trois sont toujours ensemble. Dans ce contexte, il y a un élément qui est toujours difficile à gérer, c'est la partie de la hiérarchie qui fait partie du projet, mais qui aimerait intervenir le plus tard possible.

    C'est le meilleur moyen que tout le monde soit déçu. 

    Il faut trouver des moyens et c'est contextuel à chaque intervention, d'essayer d'avoir en tout cas des infos sur le contexte, des acteurs avec qui tu parles.

  • Il y en a qui veulent faire avancer leur carrière
  • Certains sont beaucoup plus tendus en CDD
  • Il y en a qui juste après la fin du projet ils changent d’employeur. C’est pas simple.  Ce n’est pas notre mission. Notre mission, c’est d’utiliser ça un peu ça comme un MacGuffin et de voir où ça nous mène. Le MacGuffin est une sorte de prétexte qui va nous emporter dans le scénario, une technique qu’Hitchcock maîtrisait très bien, le nom vient de lui d’ailleurs.

    Donc, en stratégie de design, on prend les briefs et les requêtes clients comme étant toujours une des composantes de l'information disponible. « One element in the knowledge space » comme dirait sans doute VanPatter. Et on va le challenger…

    Moi, je fais toujours des twins ethnography.

  • C’est-à-dire que je vais toujours interviewer à la fois à l'interne et à l'externe, et puis je croise. 
  • Donc les problèmes, les perceptions, les représentations, elles n'existent pas dans des silos. 
  • Je me heurte dans des entretiens, très souvent à des moments où la personne se lève, ferme la porte. 

    Il me dit: 

    « Tu peux éteindre l’enregistreur ? ». Et là je découvre ce qui se passe. 

    Parfois même, il dit « Non, tu peux laisser, ... ». 

    J’explique comment j'appréhende les entretiens pour obtenir ces choses-là. 

  • J'essaye d'obtenir une personne dans la boite qui va être mon recruteur. Et j'essaie de faire en sorte que soit elle qui me boucle les calls avec les stakeholders. 
  • C’est généralement une personne super motivée, j’appelle ça un fixeur, comme sur le terrain. Dans mon expérience, les meilleures que j’ai rencontré étaient des femmes entre 30 et 40 ans, qui ont des enfants, et qui sont super efficace en interne. 

    Les gens leurs font confiance parce qu’ils savent qu'elles, elles ne bullshit pas. Si tu veux que ça marche, tu fais comme elles disent ;)

    J’essaie aussi d’être le plus vague possible avant l’entretien, c’est parfois un petit mail qui dit 

    “ ça sera anonyme.” 

    Puis quand on commence je dis :

    “Voilà moi j’anonymise tout, je me fous de qui fait quoi, c’est un système qui me parle, 2 – vous pouvez voir mes notes

    3- à tout moment, vous pouvez éditer ce que je vous ai dit et je vous l’enverrai” 

    Comme sur le terrain quand tu prends une photo des gens, tu le leur donne après. (C’est important, le safety des gens qu’on interview.)

    Après je leur dit on vous envoie le transcript si vous voulez.

    Aujourd’hui, il n’y a jamais eu quelqu'un qui m'a demandé le transcript. Et on ne m’a jamais demandé d’éditer. 

    Mais en faisant cela, tu crées un cadre dès le début.

  • Dans les techniques d'interview, il faut se faire à l'anglaise au début, small talk.
  • Poser toujours des questions à laquelle les gens n’ont aucune chance de se tromper ou d’avoir des doutes : d’où ils viennent, où ils ont grandi, leur plat préféré etc..

    Quand j’allais interviewer les migrants, j’allais toujours regarder le village où ils sont nés, où ils ont grandi, en Google Earth tu zoomes. 

    En fait, le participant rentre dans une relation où ce n’est plus une interview, on n’a pas l’impression que quand on lui pose une question, il doit gamberger, il s’agite.. .

    Tu peux en détendre l'ambiance. Ce n'est pas une enquête de police. 

    Il ne faut jamais dire que ce n'est pas une enquête de police, il ne faut surtout pas.

    Donc de cette manière j'ai des gens qui me déballent des gros trucs durant les entretiens. 

    Après, j'ai la réputation de ne pas faire de censure et de de ne pas bullshiter et d’être piquant dans ma manière de parler des problèmes.  Ce qui fait que les gens me font confiance. Ils n’ont pas envie de jouer ave c moi.

    La double ethnographie permet de voir un peu comment tu compares l’interne et l’externe.

  • Très souvent, il y a des externes, des gens pour qui ils travaillent, et ça peut être leurs fournisseurs, ou des clients qu'ils n'ont pas réussi à ferrer. 
  • Dans les boîtes, je vais demander d'avoir maximum 50% d’hommes blancs. (C’est déjà dur hein.) 
  • Je demande les employés les plus jeunes, et puis les plus seniors possibles, pour écarter, étirer le truc. 

    En dessous de 12 entretiens ça ne sert à rien car je vais creuser des questions profondes. Des questions où il y a du change, de la stratégie et du design quand ils sont d’accord sur les 3 dimensions. 

    Je creuse les représentations du futur :

  • Comment ils perçoivent leur travail
  • Comment ils perçoivent leur boîte
  • Leur vie etc..

    Je vends ces entretiens comme étant l’effet Ikéa, c'est-à-dire, il y a un vrai plus, c’est que ces stakeholders à qui on est allés poser des questions 

    “Qu’est-ce que vous en pensez? “

    Ils se sentent impliqués, du haut de leurs expériences et de leur compréhension des marchés et des différentes divisions. Ils ne sont pas dans une logique défensive ni de stratégie, ils sont vraiment là pour, je leur dis 

    “C’est de l’outil collaboratif, j’ai besoin de votre point de vue, ça m’intéresse. “

    Donc il y a une manière très participative de travailler. Après, je ne te cache pas que dans toutes les boites, si le CEO n’est pas respecté, admiré, considéré comme un bon capitaine, il n’y a rien qui fonctionne. 

    Je faisais un truc quand je rencontrais les gens, je leur disais 

    «Je vous demande de dessiner une pyramide à 3 couches »

  • Ce qui m’intéresse, c’est l’angle de la pyramide, et ça peut changer par couche, et puis la distance en entre les couches. 
  • Le Covid a complètement décollé le C Level, du middle management. C’est très impactant de ça montrer à des gens.
  • Trouver des exercices de co-création, qui vont faire qu’ils se le font à eux-mêmes et ça s’est fait sans toi, malgré le contexte. 

    Par exemple, quand tu vas dans une entreprise, c’est bien de demander une salle d'interview où il y a un whiteboard.

    Très, très vite, tu veux commencer à suggérer “Dessine le moi”.

    Ça, ça aide vraiment beaucoup. 

    Très vite, le stakeholder il peut prendre le stylo et te le dessiner ce dont il parle et tu vas vachement apprendre. C’est peut-être là où le designer en recherche, il est avantagé et que ça devient intéressant. 

    Par exemple, j’ai 0% de mes clients qui ont été capables de me donner un org chart (Organigramme hiérarchique). 

    En fait je pense que dans les entreprises il n’y en a plus. Parce que ça change tellement souvent. C'est tellement en mouvement.

    • 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
  • 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
  • Erreur: Ne pas assez prendre en compte la perception des équipes existantes

    Une erreur que j’ai faîte est au niveau du métier de consultante : c’est de ne pas assez prendre en compte la question de la perception des équipes quand j’arrivais sur une nouvelle mission. 

    Très souvent, on me demande de venir à la fin des projets, quand on se rend compte que le site ou que l’appli n’est plus accessible. En caricaturant un peu, avant j’arrivais avec mon audit et son lot de corrections, les équipes entendaient alors en gros

    « Vous avez mal fait votre boulot. ». 

    Au début, j’avais du mal à comprendre la résistance que cela créait : On faisait appel à moi.

    Donc si vous faites appel à moi, c’est que vous avez conscience qu’il y a des choses à améliorer.

    En réalité, c’était le N+1, le N+2, le juridique, le commercial ou autre qui faisait appel à moi, pas l’équipe.

    Eux, on vient leur imposer quelqu’un d’externe, donc qu’ils ne connaissant pas, quelqu’un qui ne connaît pas leur projet et ses difficultés et sur un projet qu’ils pensent terminé.

    Je suis alors “ la méchante inspectrice des travaux finis “. 

    Je déteste maintenant intervenir à la fin des projets, et pour le coup, si vraiment ça doit être le cas, il y a une manière de s’adresser aux gens. 

    Vous n’allez pas leur dire « Vous avez fait un mauvais boulot. ».

    Ce n’est pas ça, plutôt : C’est que vous n’avez pas été sensibilisé, vous n’avez pas été formé, on va y travailler ensemble. 

    Je fais le parallèle avec par exemple le GRPD, le respect des données : ça, il n’y a pas longtemps, très clairement, tout le secteur ne le prenait pas en compte. C’est la même chose. À un moment donné, il y a une manière de faire pour respecter le GRPD, et il y a une manière de faire en sorte que les personnes en situation de handicap notamment puissent naviguer sur le web.

    Tant qu’on n’y est pas confronté, tant qu’on ne dit pas qu’une personne non-voyante peut naviguer sur le web, on ne peut pas le prendre en compte. Rien que de passer par cette étape de leur faire comprendre à qui on s'adresse quand on fait d'accessibilité, ça permet d’engager une meilleure collaboration avec une équipe.

    Leur faire comprendre comment les personnes en situation de handicap vont naviguer avec le Web. Déjà, c'est beaucoup mieux perçu et du coup, ils voient tout de suite l'intérêt. Leur faire comprendre l’intérêt, je pense que c'est essentiel.

    Mais aussi apprendre, être formé. Dans la plupart des cursus (école, université), il n’y a pas ou très peu de cours sur les sujets du numérique responsable, de l’accessibilité et l’assurance qualité… et quand il y en a c’est très récent.

    Et enfin, tant qu’on peut, faire appel aux consultant·es de ces domaines, le plus tôt possible dans les projets, même avant les projets, pour avoir un vrai accompagnement.

    Pour éviter ça aujourd’hui, je fais de cette manière :

  • Pour commencer, je demande que l’on me libère minimum 1 heure 30, voire idéalement 3 heures, avec l’équipe afin que l’on discute.
  • On fait connaissance, je leur explique ce que je fais, pourquoi je suis là et on fait des ateliers, des mises en situation, ... J'identifie alors leur niveau de sensibilité et leurs connaissances aux sujets que j’emmène.

    Déjà, ils comprennent que je ne suis pas du tout là pour leur taper sur les doigts, ni dire qu’“Il y a tout ça qui ne va pas, tout ça à corriger.”.

    On apprend à se connaître, aussi, et mine de rien, par la suite quand ils me voient arriver avec mes demandes de corrections ça passe beaucoup mieux.

    Dans ces moments-là, très souvent, il y a beaucoup d’échanges d’expériences des participant·es : « Moi, j’ai tel problème, j’ai un petit cousin, un copain, mon oncle, ma tante, … qui a tel handicap, tel difficulté... ».

    Et en fait oui, on va bosser pour eux, pour toutes ces personnes qui se sentent parfois ou souvent exclues. Rien que ça, ça motive tout le monde, c’est une bonne raison pour travailler ensemble.

    J’aime sensibiliser, j’aime discuter avec les équipes. 

    Ensuite, je passe aussi par des petites formations, métier par métier (UX, UI, Dev, rédacteurs, marketing, …), courtes ou plus longues (en général d’une demie-journée à 3 ou 4 jours), que l’on peut caler au début de mon intervention mais aussi en cours de production.

    Autant que possible, les durées et déroulés de ses formations se déterminent en fonction de mon analyse de projets qu’ils ont fait avant. 

    C’est avec tout ça que je peux enfin accompagner plus sereinement les équipes et pour ça je me base là aussi sur l’analyse du projet : 

  • Ce qu’il y a de plus récurrent comme choses à améliorer
  • Ce qui va être simple à améliorer 
  • Ce qui va le plus avoir d’impact 
  • Ce qu’il y a de plus compliqué à améliorer mais qui aura quand même le plus d’impact. 

    Ça permet de leur dire que « OK, vous faites déjà plein de choses bien, je vous accompagne à améliorer ».  En utilisant cette méthodologie, on se base sur les équipes et on leur permet de capitaliser : on va améliorer à l’instant T pour ce projet, mais ça leur permet ensuite de réutiliser ces pratiques sur les suivants. On est dans l’accompagnement et non pour leur dire « Il faut corriger tel truc à tel endroit »

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur à ne pas faire avec ses parties prenantes - Essayer de les impressionner!
    Je continue de faire des erreurs dans ma carrière, et l’une des plus récentes c’est d’avoir voulu impressionner un chef de projet qui était sur un projet fantastique et qui pouvait nous donner du travail sur les 6 prochains mois. Donc nous sommes partis sur un sondage multi-pays sur 4500 personnes où on n’avait pas le droit à l’erreur et on jouait la crédibilité de l’équipe car cette partie de l’entreprise ne vient jamais nous chercher. C’était donc une étude plutôt tournée marketing, chose que l’on fait moins car l’on devait évaluer la confiance des clients envers la marque marketplace. Le chef de projet est arrivé avec sa méthodologie et son processus clé en main, que j’ai suivi aveuglément. En cours de route, en faisant les questionnaires je me rends compte que le niveau de complexité est beaucoup plus lourd qu’attendu, et que la méthode de ce chef de projet n’allait pas nous donner les résultats escomptés.  Donc j’ai dû faire machine arrière, perdre une demi-journée de travail, (donc petite erreur logistique), et je m’en veux d’être partie tête la première sans remettre en cause la méthodologie, et me poser les bonnes questions. Juste parce que le projet était super intéressant. Un autre apprentissage de cette expérience, c’est de partager ton idée de recherche avec un collègue, un pair en research afin de confronter les idées. Un simple “Qu’est-ce que tu en penses ? “ m’aurait évité d’aller dans le mur. Donc ne jamais hésiter à faire relire à ses collègues, ça fait office de pre-test et c’est très précieux. Lorsque cela arrive, si on vous fait une remarque : Demandez-vous pourquoi je reçois ce commentaire? plutôt que “Qu’est-ce qu’il me dit celui-là ?”
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment évaluer le stakeholder en face de soi.
    Maintenant, lorsque je discute une mission avec un stakeholder j’essaie de détecter si la personne en face de moi est prête de se laisser guider par la main. (En gros si c’est le bon moment pour elle)  Aujourd’hui j’arrive à le sentir, et mon gros apprentissage est que tu ne peux pas amener quelqu’un qui ne veut pas être guidé.   Si tu le fais, cette personne le fera pour les mauvaises raisons et cela se retournera contre toi plus tard dans le projet.  Donc, lorsque je le sens, je propose “Je n’ai pas la science infuse, on va ensemble aller dans cette direction pour ces raisons…” Là, où les gens sont prêts, j’essaye d’être pédagogue et de les rassurer sur le processus et que cela ça va bien se passer, et qu’ils peuvent me faire confiance. Lorsque l’autre côté ne veut pas être guidé, car trop d’enjeux, c’est trop tard, ils sont déjà dans la dernière ligne droite, je ne cherche pas à faire une révolution.  Au contraire je joue avec la situation et je préfère jouer la montre et dire :  “Ok, on va se donner les moyens d’analyser les résultats, et observer quel est l’accueil afin de définir les manières d’améliorer tout cela” Je pense qu’il faut rester humble dans ce genre de situation, et observer quelles hypothèses sont invalidées, ou au contraire validées, car on a toujours des surprises. Mais il faut surtout dépasser le “Eh, je vous l’avais dit, donc vous m’écoutez maintenant ?” Ça ne marche jamais. Mais plutôt se diriger vers : “Tiens, la manière dont on a procédé ne marche pas, il faut péter 80% de ce que l’on a fait pour reconstruire, où il faut faire une V2 rapidement pour ces raisons 1. 2. 3. ” Le plus important c’est de se poser la question: “Où est-ce que je peux appuyer et qui va vraiment faire mal et que si on fait différemment on aura plus d’impact ?”
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Responsabiliser l'équipe sur le rôle de la recherche.
    Le fait de se voir confier ce rôle de ‘UX Researcher’, peut déresponsabiliser le reste de l'équipe sur la récolte d’apprentissages et le traitement de ceux-ci, et ce n’est pas forcément l’idéal ! Il faut responsabiliser l’ensemble de l'équipe produit sur cette phase de Recherche.  Je pense que c'est essentiel de récolter des retours de ses collaborateurs pour améliorer notre travail de restitution. Le partage type de livrables ne suffit pas ! Les collaborateurs ne prendront pas forcément le temps de faire des retours, il faut donc créer cet espace où l’équipe échange, critique et apporte tout élément aidant à améliorer l’avancement de la phase de recherche et les livrables que d’autres collaborateurs peuvent consulter (ils doivent être en mesure de les comprendre). Je pousse un peu lors de ces points que j’organise en poussant la réaction et une demande d’entraide ; ‘je suis bloquée là, qu’en pensez-vous ?...’  Je cible là où je pense se trouve la faiblesse. Cela m'est arrivé d'avoir des collaborateurs qui n'ont jamais le temps, donc je bloque des petits créneaux dans leurs agendas directement qui restent acceptables, j’ai appris cette approche en travaillant avec de plus grands groupes sur lequel le rythme de collaboration peut être très différent que des plus petites structures. Donc l’organisation de points de synchronisation qui s’orientent vers de la production de valeur est très bénéfique et les collaborateurs seront d’autant plus participatifs en identifiant la valeur générée !
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment je communique avec les stakeholders d'un projet.
    Les stakeholders, ces personnes essentielles à la compréhension du projet, de ses besoins et de sa réussite, jouent un rôle crucial. Une relation harmonieuse avec toutes les parties prenantes est la clé pour assurer la qualité du produit final et maintenir une équipe soudée. La communication est le secret de cette bonne entente. Il est primordial d'apprendre à écouter et à s'exprimer lorsque les conditions nécessaires pour livrer le produit final ne sont pas réunies. Dans chaque projet, je veille à ce que les stakeholders expriment clairement leurs attentes et leurs préférences sur la manière dont les choses doivent être réalisées. Ensuite, il m'incombe d'évaluer ce qui est réalisable et ce qui ne l'est pas. Il est donc crucial de pouvoir argumenter mes positions. J'apprécie également l'envoi régulier de messages pour tenir les stakeholders informés de l'avancement et des décisions prises. Il est important de maintenir une communication écrite tout au long du projet, afin de pouvoir y revenir si des changements surviennent et remettent en question les décisions antérieures. Dans tous les cas, il est préférable d'avoir une communication trop abondante plutôt qu'un manque de communication.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Apprendre à savoir dire non comme Freelance
    Après des années en tant que freelance, j'ai rapidement compris l'importance de savoir dire "non". Je dois avouer que lorsque l'on est salarié, il est souvent difficile d'exprimer un refus, car on fait partie d'une structure hiérarchique où il est parfois compliqué de créer une contradiction. Cependant, en tant que freelance, savoir dire "non" est une compétence essentielle à maîtriser.  Toutefois, il y a une différence entre oser dire non et savoir dire non. Oser dire non signifie dépasser la peur de décevoir le client et de ne pas exprimer de refus.  En revanche, savoir dire non, c'est savoir expliquer pourquoi. Il ne suffit pas de simplement refuser, il faut être en mesure de convaincre le client ou le partenaire que c'est la bonne décision. Parfois, dire non est lié à la direction que prend le projet. Lorsque celui-ci ne correspond plus à mes valeurs ou qu'il compromet la qualité du travail que je peux fournir. Je tiens également à souligner que si, pour une quelconque raison, vous décidez de rompre un accord déjà signé, c'est-à-dire d'exprimer votre refus après avoir accepté de travailler sur le projet, il est important d'être direct et honnête.  Expliquez clairement qu'il vous est désormais impossible de livrer le travail dans les conditions initialement convenues. Dans de tels cas, je recommande de trouver quelqu'un qui puisse prendre ma place afin de faciliter la transition.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment monter l’impact de l’équipe et de ta contribution comme UX writer ?

    En tant que manager comment montrer la valeur de notre équipe d’UX writer grâce au KPI ?

    On veut montrer que c’était l’UX Writer qui a eu un impact, et pas juste un ressenti que les gens autour ont bien aimé cette collaboration. Mais quelque chose d’un peu plus chiffré. 

    Mon expérience me dit que souvent que ça ne va pas être forcément grâce à une nouvelle fonctionnalité sur laquelle on va travailler, mais c’est plutôt d’identifier les endroits existants de l’expérience qui n’étaient pas optimales et de réécrire quelque chose comme une push notif, où l’on voit qu’un comportement change derrière. 

    En tant que manager, c’est super important car ne pas montrer l’impact, tu ne fais pas grandir ton équipe.

    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Figure It Out: Getting from Information to Understanding
    https://www.goodreads.com/book/show/49336794
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Livre: You're My Favorite Client
    https://www.goodreads.com/book/show/21423216
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Collaborative Product Design: Help Any Team Build a Better Experience
    https://www.goodreads.com/book/show/46031267
    • merci! Utile
    • Pas utile
    • Pas sûr
  • The Strategic Designer: Tools & Techniques for Managing the Design Process
    https://www.goodreads.com/book/show/11241625
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Crucial Conversations: Tools for Talking When Stakes Are High
    https://www.goodreads.com/book/show/11406473
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Designing the Conversation: Techniques for Successful Facilitation
    https://www.goodreads.com/book/show/16248735
    • merci! Utile
    • Pas utile
    • Pas sûr
  • It's Our Research
    https://www.goodreads.com/book/show/13511299
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Storytelling For User Experience: Crafting Stories For Better Design
    https://www.goodreads.com/book/show/8047208
    • merci! Utile
    • Pas utile
    • Pas sûr

    • Commentaires

    • ·
    • ·
    • Quelles sont vos stratégies comme UXR pour appuyer et prouver la validité de vos recherches ?

      Connais-tu l'Atomic Research ? C'est une méthodologie de structuration de la recherche sur 4 niveaux :

      1. Expériences (experiments) : "On a fait ceci..."
      2. Faits (facts) : "On a trouvé cela..."
      3. Idées (insights) : "Ce qui nous fait penser ceci..."
      4. Recommandations (recommendations) : "Alors on va faire cela..."

      Outre la structure qui apporte de la clarté, cela permet également de justifier plus facilement de la valeur des remontées :

      • Un Fait peut provenir de plusieurs Expériences et aura donc plus de chances d'être important / aura potentiellement plus de valeur qu'un Fait provenant d'une seule Expérience
      • Une Idée peut découler de plusieurs Faits et aura potentiellement plus de valeur qu'une Idée découlant d'un seul Fait
      • Une Recommandation peut découler de plusieurs Idées et aura potentiellement plus de valeur qu'une Recommandation découlant d'une seule Idée

      Tu vas donc pouvoir avoir progressivement une arborescence permettant de prioriser les Recommandations qui découlent du plus d'Idées, de Faits et d'Expériences et qui ont donc le plus de valeur (je simplifie un peu car toutes les expériences n'ont pas forcément la même valuer intrinsèque).

      Du coup, quand tu présentes tes Recommandations par ordre d'importance, tu peux facilement la justifier avec tout ce qu'il y a derrière : "la Reco 1 est prioritaire car elle découle de ces 2 Insights. Ces derniers viennent des 5 Faits suivants qu'on a collectés en menant X, Y et Z (les Expériences)".

      Et dans certains cas, surtout au début de tes recherches où tu auras peu d'Expériences, tu vas avoir des Recommandations assez hypothétiques. C'est normal et c'est l'occasion d'itérer. Tes recommandations principales deviennent tes hypothèses de recherche pour tes prochaines Expériences et iront nourrir le modèle pour obtenir de nouveaux Faits qui découleront sur des Idées puis des Recommandations : ça en renforcera certaines que tu avais déjà et ça permettra d'en découvrir de nouvelles.

      avatar
      Thierry Raguin · Design Strategist / ResearchOps / DesignOps / UXR / UXD · il y a 5 jours
    • Comment délimiter le champ de compétences entre Researcher et PM ?

      Je pense que ça dépend de l’organisation de ton équipe et de la capacité de l’équipe de recherche à faire de la recherche. Parfois il y a trop de recherche à faire pour le nombre de researchers en place et ça devient essentiel d’avoir d’autres “people who do research” (PWDR) comme des Product Managers. Dépendament du contexe, c’est pas nécessairement une mauvaise chose.

      D’un côté, il y a quelque chose de cool à ton histoire. Le PM est intéressé, il a l’air de vouloir faire de la recherche, d’aller chercher des données pour prendre ses décisions. Et pour moi c’est exactement là que tu dois jouer tes cartes. Apprendre à parler le même langage business que lui, et prendre ça comme une opportunité de l’éduquer sur la validité des résultats qu’il va recevoir en leadant la recherche. Ultimement, un PM va vouloir faire de la recherche pour quoi? —> Pour prendre des bonnes décisions produit. Si les résultats sont mauvais, ses décisions le seront tout autant.

      C’est plate à dire, mais c’est nécessaire d’expliquer que sa recherche ne sera/n’est pas valide et d’expliquer les raisons pourquoi. Je pense que c’est important de s’affirmer comme la personne experte de son domaine et d’amener le PM à te voir comme son partenaire plutôt que son exécutant. Cette dynamique-là est aussi entre nos mains comme UXR.

      avatar
      Marianne Carpentier · Senior User Researcher · il y a 3 semaines
    • Comment délimiter le champ de compétences entre Researcher et PM ?

      J'aime beaucoup ce retour d'expérience et ta question, car elle fait écho à l'expérience de nombre de UXR. J'ai observé cette évolution et je crains qu'il ne soit trop tard pour faire retour arrière. La pression venant de la hiérarchie n'aide pas: les PM sont invités (pressés) de connaître les utilisateurs, de comprendre les dynamiques d'achat et de conversion. 

      Dans ce contexte, il me semble qu'il ne te reste qu'une chose à faire: te positionner de façon stratégique. Mais avant toute chose, je m'interrogerais sur ce qui fait que tes PM te court-circuitent:

      • pourquoi insistent-ils pour leader la recherche?
      • pourquoi ne font-ils pas usage de tes compétences?
      • que savent-ils réellement de la recherche UX?

      Se pourrait-il qu'ils craignent que faire appel à un UXR les ralentisse? Ont-ils une pression de leurs stakeholders et des KPIs reposant sur le nombres d'utilisateurs auxquels ils ont parlé?

      Dans la situation actuelle, la collaboration est quasi-nulle et tout le monde en pâtit (toi surtout, car tes collègues ne semblent pas être conscients de leur incompétence). Pour rétablir l'équilibre et te permettre de te positionner comme référence en terme de UXR, il va te falloir:

      • Comprendre leur contexte
      • Communiquer ton constat et proposer une solution 
      • celle-ci doit s'inscrire dans leur contexte/besoins
      • et te permettre de garder la main sur le processus
      • Établir une stratégie de recherche au sein de l'entreprise
      • répartir les responsabilités en fonction des compétences de chacun 
      • définir le processus de recherche, les méthodes employées, les critères de qualité
      • Te focaliser sur la génération et le management d'insights à vocation stratégique: 
      • délimiter ton domaine de compétences et surtout celui de tes collègues PM 
      • rassembler, analyser, et distiller la data pour informer les décisions 
      • aligner ta stratégie de recherche sur la stratégie du produit

      Une stratégie qui a bien fonctionné pour moi a été de me positionner comme un chef de projet de recherche. Ma première initiative a été d'aligner nos objectifs communs: cela m'a permis de ré-établir la communication et de mieux comprendre ce qui les amène à "envahir" sur mon terrain. Une fois que nous nous étions mis d'accord sur un point commun, il était temps d'établir les "frontières" de nos domaines de compétences.

      Nous avons alors établi de grands axes de recherche et j'ai pu leur démontrer les forces et faiblesses de leur approche. Ici, mon rôle était celui d'un consultant: je comprenais leur objectif et leur proposais des activités efficaces et correspondant à leurs capacités. 

      En parallèle, j'établissais mon propre plan de recherche plus "foundational" et stratégique, et renforçais ainsi ma position. Les PM avaient un guide et des méthodes établies et adaptées leur permettant de "mener" des activités de recherche indépendamment — je les ai coaché pour leur permettre d'obtenir des résultats satisfaisants. Mais en aucun cas je n'ai cédé mon expertise: j'ai simplement pivoté vers un travail de fond, de gestion de l'insight. 

      Idem pour l'analyse: établie un score de qualité de la data. Si celui-ci n'est pas atteint, la data n'est pas valide et devra être écartée. Montre leur de façon très concrète les conséquences néfastes d'un mauvais insight (impact financier, réputation, etc.)

      Enfin, propose leur de te soumettre leurs questions en amont, avant même de penser à mener des entretiens: peut-être as-tu déjà les réponses à leurs questions: passe d'un statut réactif (je dois faire de la recherche sur leur demande) à un statut pro-actif (tel et tel insight vous permet de prendre une décision informée). Tu peux aussi te joindre à leur sprint planning ou aligner ton research backlog sur le product backlog.

      Ceci n'est pas une solution magique, mais pourrait te permettre de rétablir le dialogue et te sécuriser ta position. 






      avatar
      Marie-Aude Sourd · Senior UX researcher · il y a 3 semaines
    • Comment délimiter le champ de compétences entre Researcher et PM ?

      Le PM c'est juste un marketeux déguisé... pas de research qui ne soit organisée, conçue, menée à bien, et exploitée par quelqu'un hors de l'équipe Research&Design... Chacun sa spécialité. Ce n'est pas la sienne. En début de projet, avant ou pendant le kickoff, rappel des roles et responsabilités de chacun. on met les pied dans le plat et les points sur les i. mais on attend pas d'avoir commencé.

      avatar
      Antoine RIGAUDIAS · Senior Consultant Design Operations · il y a 3 semaines
    • Un livre qui m'a aidé à mieux performer en tant qu'UXR

      Merci ! belle piqûre de rappel - C'est dans ma liste de lecture depuis bien trop longtemps. Je serais curieux d'avoir ton REX et pourquoi pas une anecdote de comment tu te prépares à ce genre de discussion en amont et comment tu as mis en pratique le livre. 

      Je vais l'acheter de ce pas!

      avatar
      Alexis Gérôme · Staff UX researcher · il y a 1 mois
    • Comment éviter l'effet "On le savait déjà ?"

      @Mathieu Baudonnat j adore !!!❤️

      avatar
      Amandine Gnaedinger · UX researcher · il y a 1 mois
    • Comment éviter l'effet "On le savait déjà ?"

      @Alexis Gérôme j adore merci !!! Je realise que dans les entreprises très silotées le sujet d alignement des stakeholders et de partage de connaissances est complexe.

      Et je vais me manger cette remarque tant que je n arriverai pas à avoir l ensemble des interlocuteurs clés en cadrage... je ferai un post mortem là dessus😉

      avatar
      Amandine Gnaedinger · UX researcher · il y a 1 mois
    • Un article incroyable sur ce que la justification à outrance de notre valeur à comme impact.

      @Antoine RIGAUDIAS Oui je connais l'UX fund, c'est un exemple intéressant de 2015-2016. A voir ce que ça donne aujourd'hui. 

      On n'a pas la même lecture de l'article. Niveau contexte, ça fait un an que les UX font face à des layoffs, des restrictions de budget et une introspection venant de plusieurs figures C-level des US (Ex research Director Meta et d'autres..). En gros on a fait du mauvais boulot, et on n'a pas réussi à prouver notre valeur.

      Et c'est ça justement le bas du problème, et le postulat de ces dernières années. Advocate, advocate, être utile, et les budgets viendront.

      La majorité des équipes se positionnent de base comme devant se justifier comme stratégie, et en réalité se démènent de répondre à toutes les demandes des autres équipes. 

      Cela amène à une réduction de la qualité de notre travail, et comme Marévéry le dit si bien à habituer les équipes à une certaine médiocrité en termes de recherche. (en gros ca devient la new normal)

      En réalité, l'auteure interviews des managers qui ont fait le contraire et où cela à marché.

      Partir d'un point de départ où ton temps est précieux, car la qualité de ton travail n'est pas remise en question est un rappel important en termes de mentalité en ce moment.

      Après il faut dire non, savoir argumenter , communiquer etc.. Cela ne veut pas dire être difficile à travailler, mais communiquer un certain standard en terme de qualité de travail.

      Ce n'est pas la seule solution disponible, mais c'est au moins une piste solide. L'ayant vu autour de moi, cela amène plus de résultats que l'auto-flagellation.

      avatar
      Alexis Gérôme · Staff UX researcher · il y a 1 mois
    • Un article incroyable sur ce que la justification à outrance de notre valeur à comme impact.

      Je sais pas si tu as vu passer l'article sur l'UXfund, les gens qui ont créé un portefeuille d'actions boursières dont le seul critère d'achat etait la maturité en design... en quelques années +450% et des brouettes. j'essayerai de le retrouver.


      Pour cet article, je serais moins catégorique que toi peut etre.


      il faut etre pret a demontrer et ca demande du travail... mais ce que je lis entre les lignes dans cette article, c'est que dans les exemples cité la personne n'a ni priorisé une initiative particulière pour démontrer une fois son impact réellement, elle a essayer de tout faire en meme temps, ni géré sa ressource (elle meme en fait) efficacement, en refusant également de travailler sur des sujets pour lesquels les conditions de réussite n'étaient pas réunis.


      il faut aussi savoir refuser des collabs, meme en interne, et créer du fomo en meme temps qu'on démontre par ailleurs... je suis pas tout a fait en accord avec sa démarche, meme si sur le fond, elle a raison.


      Etre placé en situation de tjs devoir démontrer et justifier, c'est aussi une technique manipulatoire qu'il faut savoir désamorcer. et qund on est junior on ne sait pas forcement le détecter, et le contrer. Ca montre a quel point la maturité, en design, comme dans l'entreprise, peut créer un contexte favorable ou non. Totalement raccord avec les conseils en fin d'article effectivement, mais je pense que ce genre de contexte s'installe souvent quand on est jeune dans sa pratique, moins quand on prend de la bouteille :)

      avatar
      Antoine RIGAUDIAS · Senior Consultant Design Operations · il y a 1 mois
    • Comment gérez-vous et créez-vous la taxonomie en Atomic research ?

      Merci de tes retours @Michael BAEYENS. L'IA peut effectivement aider à proposer des tags mais cela reste très basique je trouve et l'IA n'est pas encore en mesure de prendre correctement le contexte pour tagger efficacement. A ce jour, je n'ai trouvé rien de mieux que d'avoir un responsable global des tags qui s'assure de la cohérence des tags et qui va fusionner / renommer / harmoniser les tags mis par les autres membres de l'équipe.

      avatar
      Thierry Raguin · Design Strategist / ResearchOps / DesignOps / UXR / UXD · il y a 3 mois
    • Comment éviter l'effet "On le savait déjà ?"

      @Mathieu Baudonnat 😂😂😂😂

      avatar
      Equipe Wikihero · Admin · il y a 3 mois
    • Comment éviter l'effet "On le savait déjà ?"

      Il m'arrive par provocation de répondre : "Maintenant on en à la preuve ;) "

      avatar
      Mathieu Baudonnat · User researcher · il y a 3 mois
    • Comment éviter l'effet "On le savait déjà ?"

      Super question Amandine :) 

      J'avais posté une ressource que j'avais vu passé sur l'un des biais qui peut influencé ce genre de commentaire: L'effet rebond.


      Donc une partie peut être expliquée par le fait que c'est une défense psychologique de la part de stakeholders pour dénigrer un peu la recherche et faire passer le sujet comme quelque chose de simple, alors qu'en fait c'était pas le cas. 


      C'est souvent le symptôme de deux choses.

      1. Un manque d'intéraction de leur part dans le processus de recherche. Peut-être n'étaient-ils pas là, n'ont pas participé où tu ne les a pas consulté (souvent ce sont les gens absent qui font ce genre de remarque) Donc quelque chose d'important est de chasser les potentiels stakeholders problématiques hard to get qui peuvent te poser problème dans le futur. ca aussi c'est un hard learning, car tu le paye à la fin et c'est toi le messager qui sera flingué. Donc le risque c'est toi qui le porte.
      2. Un manque de visualisation de leur propre connaissance. Pour éviter cela, une solution est de prendre un snapshot de la connaissance (ou ignorance) de l'équipe à un moment T via un workshop de planning en mettant à plat hypothèses x évidences et intuitions. Ca permet de commencer la présentation avec ce genre d'information et c'est un garde fou contre ce genre de remarques. Oon peut toujours y revenir et dire "Voila ce que l'on avait défini XYZ - voila la connaissance que l'équipe avait"


      Après il y a le cas où tout simplement l'UXR n'a pas fait son boulot de lier des liens forts avec ses stakeholders , connaître leurs priorités etc et passer à côté de ce qu'il devait préparer. Donc il y a toute la notion de relations pro.

      avatar
      Alexis Gérôme · Staff UX researcher · il y a 4 mois
    • Comment gérez-vous et créez-vous la taxonomie en Atomic research ?

      Hello oui en effet, on est passé par les memes étapes et avons du créer des moments d’échanges inter produit pour coordonner les tags. Le but de ces tags est de pouvoir regrouper les facts lorsqu’on filtre pour affiner la recherche. Et le risque c’est naturellement qu’un tag en vale un autre, rédigé par qqun d’autre qui a le même sens mais qui est soit un synonyme. Nous avions aussi recours à la responsabilité d’un seul humain pour parcourir tous les tags et les rapprocher. Avec Coda tu peux désormais tirer parti de l’ia pour faire ces rapprochements. Pour ce qui relève du macro / micro à l’usage il n’y a pas de vrai problème selon moi. Puisque les tags servent à identifier les facts qui pourraient nourrir la réflexion peut importe que tu tri par mobile app ou par iOS. Tout dépend de ce que ru recherche. Est ce que tu cherche un comportement généraliste sur le mobile ou un comportement iOS ? Quelque soit le cas tout doit être taggué. À nouveau ce travail est rébarbatif à la main mais peut être soutenu par l’ia qui te soumet des tags en proposition

      avatar
      Michael BAEYENS · Product & Design evangelist · il y a 4 mois
    • Comment monter l’impact de l’équipe et de ta contribution comme UX writer ?

      @Mike Winnington c'est un super début pour montrer une valeur très concrète de votre travail ! J'ai hâte de savoir comment ça évolue :)

      avatar
      Marie-Anne Chaloupecky · · il y a 4 mois
    • Comment monter l’impact de l’équipe et de ta contribution comme UX writer ?

      Hi @Marie-Anne Chaloupecky,

      Désolé pour la réponse tardive, je viens de la voir à l'instant.

      Actuellement, on essaie de tacler notre dette contenu et pour ce genre de projet, pour que ça devienne pas une montagne de travail, on a décidé de prioriser les sujets qui déclenchent un taux de contact élevé au CS.

      Notre KPI principal sera donc l'évolution de ce taux suite aux changements. On sera ensuite capable de mesurer l'argent économisé puisqu'on sait combien coûte chaque contact en moyenne.

      D'autres KPI pour ce projet sont "time on task" (enfin le temps passé pour accomplir l'action) et le "taux décrochage".

      On aura pas encore les résultats dans le cadre de ce projet, mais j'ai hâte !

      avatar
      Mike Winnington · UX Writing Manager · il y a 4 mois
    • Comment monter l’impact de l’équipe et de ta contribution comme UX writer ?

      Hi Mike :)

      Quels sont vos KPIs actuels ?

      Comment est-ce que l'entreprise mesure son succès ? Est-ce qu'on peu appliquer cette logique sur le travail des UX writers ?

      Je peux juste te parler de mon expérience car je pense que ça dépend un peu des valeurs et des métriques de chaque entreprise.

      Chez Booking.com il y a eu un changement radical de la perception du travail des UX writers à partir du moment où l'on a commencé à noter rigoureusement et publier les effets des changements en A/B testing. On a pu prouver notre valeur par toute une panoplie de métriques différents allant de la conversion net (avec prise en compte des annulations) jusqu'au nombre de contacts au CS (customer service) à propos d'un certain sujet (par exemple pour un problème de paiement par carte bancaire).

      Ceci a non seulement permi de montrer la valeur de notre travail, mais aussi de travailler de manière très stratégique, car on a rapidement commencé à identifier ce qui fonctionnait bien ou non.

      Mais on a pu faire tout ça grâce aux outils de A/B testing devéloppés en interne, et je sais que toutes les entreprises n'ont pas ça, et toutes n'ont pas la possibilité de faire du A/B testing de qualité.

      Donc on peut réfléchir à d'autres métriques. On peut se baser par exemple sur les dropout rates (taux de décrochage ? Sorry for my Franglais), ou alors les contacts CS si c'est possible de leur ajouter un t