chargement des résultats

Postes

  • ·
  • ·
  • 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
  • Les entretiens avec vos stakeholders

    Les interviews avec les stakeholders sont l'une de mes activités préférées, que ce soit avec un Product Owner ou avec les Business Owners.

    Je trouve que c'est un peu comme un jeu de téléphone arabe. En général, le Business Owner demande à votre PO ou PM de livrer le produit ou la fonctionnalité de ses rêves.

    Le PM pense en termes de planification de produit, de ressources et de budget, mais il ne se concentre pas sur le besoin commercial. Ce n'est pas son travail, et souvent, les Business Owners ne posent pas la question du pourquoi. Ils veulent juste quelque chose livré.

    Votre travail consiste à comprendre les besoins en amont. Vous devez aller chercher les besoins commerciaux et les attentes des utilisateurs. Une fois que vous comprenez les attentes de vos stakeholders, vous pouvez mieux répondre à leurs demandes.

    Vous pouvez leur expliquer pourquoi une solution ne correspond pas à leurs attentes et proposer une alternative qui répond mieux aux besoins des utilisateurs.

    Je pense que cette méthode n'est pas suffisamment utilisée en recherche UX, en particulier lorsque vous travaillez en tant que ressource externe et que vous recevez un brief très technique.

    Dans beaucoup d'entreprises, vous avez une équipe d'UX décentralisée. Certains PM vous donnent un bon brief, mais ce n'est pas toujours le cas. Cette méthode a toujours fonctionné pour moi, même si elle implique un travail supplémentaire en amont.

    Une autre activité que j'aime faire est de passer en revue les users flows et les prototypes avec les designers. Avant même de tester auprès des utilisateurs, je fais ma propre expert review pendant une demi-heure.

    Au fil du temps, j'ai appris que certaines choses n'ont pas besoin d'être testées. Lorsque vous êtes dans une équipe qui est pro user testing, ils vont tester tout et n'importe quoi.

    Cependant, parfois, je pense que tester une fonctionnalité est une perte de temps pour moi, pour mes utilisateurs et pour les ressources de l'entreprise.

    Je ne veux pas utiliser les ressources pour quelque chose qui n'a pas besoin d'être testé. Je leur explique que nous sommes suffisamment experts dans ce domaine pour éliminer certaines choses. Faire des expert reviews est souvent considéré comme étant en dehors du cadre de la recherche, mais je pense que c'est la base. Commencez par la base. Une fois que vous avez réglé les choses de base, vous pouvez vous concentrer sur les problèmes plus fondamentaux.

    Un autre point important est de demander les hypothèses de base de votre équipe produit avant de commencer un user testing.

    Je trouve cela ahurissant que certains chercheurs n'y pensent pas. Cela permet également d'étayer vos arguments et votre communication. Personnellement, je demande toujours quelles sont les hypothèses de base.


    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les questions que je pose en entretiens de parties prenantes

    En général, pour commencer :

  • « Pourrais-tu te présenter et m'expliquer ton rôle au sein du projet? » 
  • Savoir déjà comment se placer. 
  • « Pourrais-tu me décrire ton job au quotidien? ». 

    Après, je me focalise sur la marque ou le produit.  

  • « Comment tu définirais ce produit, selon toi? En quelques mots.
  • « Quel est son histoire? ».

    Parce qu'on a tous en fonction du moment où on a intégré un produit ou une marque, une perception de l'histoire de cette marque, pourquoi et comment elle a été fondée. Puisqu’il y a un degré à ce que l’on connaît vraiment ? 

  • « Comment elle est organisée ? »

    En fonction des gens, l'organisation par département peut être différente, et surtout, les perceptions peuvent être différentes aussi. 

  • « Quelle est la fonction de ce produit ou de cette marque et de quelle manière la remplit -elle? ». 
  • « Et si cette dernière n'existait pas, de quoi manquerions-nous? ».
  • « Qu'est ce qui la rend unique? ».

    Et ça aussi, c'est intéressant. Il y en a qui sont très Corpo, qui vont pouvoir, qui ont bien appris leur leçon. Et puis, il y en a qui parle avec encore une fois ce cœur et voilà, c’est une façon de voir des subtilités qui peuvent être intéressantes, sur lequel on peut s'appuyer. 

  • « Et quelles sont aspects spécifiques à cette marque, à ce produit? ». 

    Puis après, je fais un focus collaborateur.

  • « Comment définirais-tu les gens qui travaillent pour ce produit ou cette marque? », 
  • « Quels sont les critères qui ont permis de recruter? »

    Alors là, c'était en l'occurrence en consultant. Donc, oui, effectivement, je peaufine parfois et j'adapte.

  • « Quel est le mode de fonctionnement entre ces collaborateurs »
  • Autour de quelles valeurs ils se rassemblent ? ». 

    Et puis, après, le focus client. 

  • « A qui ce produit, s'adresse-t-il? », 
  • « De quelle manière? ».
  •  « Selon toi, quels sont leurs besoins et qu'est-ce qu'ils recherchent dans ce produit ? »
  • « Comment les clients le perçoivent et pourquoi? »
  • « Comment décrire une expérience client, et toi personnellement quel est ton rôle dans cette relation? ». 

    Et enfin, le contexte

  • « Qui sont vos concurrents ? » 
  • « Avez-vous de bons référents »
  • « Quelles sont les tendances actuelles du secteur? »

    Et il y a un autre point aussi qu'on oublie, c'est que quand on nous donne un travail à faire, il faut commencer par le Pourquoi.

  • Pourquoi on le crée?
  • Pour qui?
  • Qui en est à l'origine? 

    Parce que ça m'est arrivé d'être devant une chef de projet qui voulait refaire un Header, et j’ai dit pourquoi ? 

  • Elle me répondait « Parce que la direction veut la refaire. ». 
  • Mais pourquoi? « Parce qu'ils la trouvent trop compliquée ». 
  • Pourquoi? « Parce qu'il y a donc trop d’intitulés ». 
  • Pourquoi il y a trop d’intitulés ? « C’est parce que ça a été créé il y a je ne sais pas combien de temps. Et du coup, ils essaient de tout rassembler et de faire en sorte que tout le monde soit content ». 
  • Et pourquoi? « Parce qu'il y a des enjeux politiques qui font qu'effectivement peut mobiliser telle personne, telle personne, tel département, tel département. ». Et en fait, en demandant le pourquoi du comment, du coup, tu vas aller au-delà de juste « Tiens, refais le Header ». 

    Et surtout, tu comprends en très peu de temps d'où ça vient.

    Les problèmes que ça engendre derrière ? Et en fait, elle était étonnée. Elle voulait juste que j'applique et que je lui propose un nouvel Header. 

    J'ai été étonnée moi-même de ces questions et surtout de ces réponses, et ça m'a permis comme ça de penser à une manière de faire pour justement amener les gens et tous ces départements qui veulent tous avoir leur place. 

    Après, elle disait « Plus personne ne clique dessus. ».

  • Pourquoi? « Eh bien, justement, on ne sait pas, ils doivent paniquer. »

    Ben oui, mais pourquoi autant d’intitulés si personne ne l'utilise? Donc, c'est là où c'est intéressant aussi. Parce qu’ils ne comprenaient pas pourquoi les gens ne cliquaient pas dessus.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • Ma vision des entretiens de parties prenantes et du cadrage

    Tout le monde pense qu'un projet, ça commence avec un brief. Ce n’est pas vrai. 

    Un projet, ça commence avec des gens qui se sont penchés sur un projet commun et c'est intéressant de les interviewer séparément parce que chacun perçoit le sujet par rapport à son métier, par rapport à ses compétences, par rapport à ses connaissances.

    Tous les enjeux, la vision business,marketing, utilisateur, chacune est différente. 

    Pour moi, c’est important de commencer par les gens plutôt avant d’attaquer sur les projets.

    Grâce à cette connaissance humaine, on arrive à percevoir si, effectivement, l'équipe est bien alignée ou si au contraire, il y a des disparités qui vont faire que « Ah, attention, il y a une sensibilité que d’autres n’ont pas », et c'est là où il va falloir avoir des points de vigilance: 

  • À qui je m'adresse? 
  • Qui est mon allié ? 
  • Qui va être un peu juste, au contraire, me mettre des bâtons dans les roues, qui va faire qu'il va falloir que je me prépare à me battre, aussi, ça arrive. 

    Parce qu'on nous parle aussi beaucoup d'évangélisation. C'est vrai que certaines personnes sont réfractaires à ces nouvelles méthodes.

    Ces interviews me permettent aussi de cerner le degré de maturité de chacun et de se préparer, d'appréhender ce qui va se passer derrière. 

    En m'intéressant à la personne, à sa vision et de la manière dont on imagine le produit à sa sortie

  • Pourquoi ce produit sera une réussite? 
  • En quoi ça peut être un échec aussi? 

    Puis je vais mettre en place des ateliers parce que les one to one d'interview comme ça, c'est intéressant, mais ce qui est plus enrichissant, c'est de pouvoir rassembler toutes ces personnes autour d'un atelier commun, justement grâce à ce bagage des interviews de cadrage effectué au préalable.

  • Audrey Grimault · il y a 1 an
    • merci! Utile
    • Pas utile
    • Pas sûr

    Commentaires

    Personne n'a créé de contenu dessus.

    Groupes

    Hashtags