chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
42 résultats
Selection
  • #cadrage 24
EN LIEN AVEC VOTRE SÉLECTION
  • 24
  • 11
  • 10
  • 6
  • 5
  • 5
  • 3
  • 3
  • 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

Postes

  • ·
  • ·
  • 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
  • Comment tester la monétisation d’un jeu / produit avant son lancement

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

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

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

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

    Comment tester cela ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • merci! Utile
  • Pas utile
  • Pas sûr
  • Le cadrage, une clé pour la compréhension et la réussite d'un projet
    Il faut toujours commencer par bien cadrer et le faire vivre, car on ne peut pas comprendre une équipe ou un projet sans cela.  D'ailleurs, c'est ce qui m'a donné envie de faire ce métier lorsque j'étais dans une école de design. On nous demandait souvent de créer des produits, sans vraiment nous dire "pourquoi?".  Pour moi, avoir un bon cadrage, c'est avant tout avoir un cadrage qui évolue constamment. Trop souvent perçu comme statique, le cadrage doit au contraire s'adapter aux nouvelles informations qui émergent tout au long du projet.  C'est une question de gestion des attentes et de définition préalable. Pour moi, le cadrage est en réalité un espace partagé où l'on établit les priorités, mais surtout où l'on le revisite constamment. Prenons l'exemple d'un projet que nous avons réalisé récemment, qui a duré un mois avec une étude.  Dès le premier jour, nous écoutons et commençons à organiser les idées.  Au bout d'une semaine, nous avons déjà affiné notre approche Mais c'est souvent pendant la deuxième et la troisième semaine, lorsque nous écoutons les retours des équipes, que nous revoyons nos objectifs et que nous les repriorisons ensemble.  Il peut arriver que nous réalisions que nous ayons oublié un objectif clé, qui se révèle être l'un des plus importants.  Étant donné que nous travaillons beaucoup à distance, nous organisons cela dans une feuille de calcul où nous numérotons les objectifs par priorités et ajoutons des éléments détaillés sur les résultats attendus.  Mais surtout, nous veillons à revisiter constamment le cadrage du projet pour nous assurer que tout le monde est aligné. Lorsque cela se produit, nous pouvons changer l'ordre des objectifs, revoir la formulation, etc.  Pour ma part, j'utilise un google sheet, mais le cadrage peut prendre différentes formes, comme être collé un mur par exemple. Le cadrage s'inscrit dans le même sujet de l'alignement dont je parle dans ce post (lien à ajouter). Par exemple, hier, j'étais au téléphone avec un client avec lequel nous avions rendu une étude il y a un mois.  Nous avions travaillé en flux tendu car ils nous avaient donné seulement une semaine pour réaliser une étude dans 2 pays.  Entre le recrutement et le rendu, nous n'avions que sept jours jours ouvrables.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Quels sujets sont les plus durs à démêler pour vous en recherche ?
    Hello à tous ! Récemment mon intuition de researcher s'est allumé sur un brief récent qui avait l'air inoffensif en apparence pour un lancement de nouveau produit. Les thèmes Les photos La famille Les enfants Whatsapp etc... Malgré le fait d'avoir déjà vu des sujets très variés (Hardware, finance, B2B, gouvernement, consumer products, Crypto, Saas) il y a quelque chose qui ne collait pas. Il y avait une complexité qui était différente. Après réflexion, je me suis dit que c'était très glissant et que les retours risquaient facilement d'être très superficiels car: On est sur des sujets de tous les jours Que les gens font instinctivement Où il y a une grande influence sociale, culturelle etc. Plutôt que des entretiens purs, les ateliers me seraient beaucoup plus utile. Mais cela impliquait de changer la méthodo, et le scope qui était déjà vendu et au final j'ai perdu le client. Est-ce que c'est que moi ou vous avez aussi ressenti cela sur des sujets très B2C ? Merci :)
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Éduquer et présenter la gamification à ses clients

    On est souvent contactés par des gens qui nous connaissent un peu. 

    Il y en a qui ont suivi nos Meetup, sur la gamification. Certains ont acheté le bouquin, mais tu ne sais pas s'ils ont commencé à le feuilleter ou pas.

    Dans tous les cas avant de partir sur un projet on essaie de parler en amont de la gamification et on s’adapte à ce que connaissent les gens de ce qu’on fait. 

    Pour cela on partage du contenu un peu pédagogique sur la gamification, notamment des courtes vidéos. 

    L'idée, c'est que toutes les personnes qui viennent sur le sprint de cadrage (lien vers ce poste) notamment, puissent avoir regardé à la fois une vidéo qui présente rapidement la gamification, et une vidéo qui présente rapidement le sprint, même si du coup c’est une chose qu'on revoit pendant le sprint.

    Pour les participants avoir quelques éléments en amont, c'est quand même pas mal, et ça se fait un peu de façon naturelle dans le sprint. 

    Par exemple lorsque l’on sera sur des phases de génération d'idées on va avoir justement des idées très « ludiques » sur des choses vraiment colorées, sur des jeux, etc.

    Il y aura des idées qui seront un peu plus terre à terre et ça va nous servir pour débattre du niveau de gamification qu’on a envie d'avoir, des attentes des utilisateurs.  On a un jeu de cartes comme prototype qui s'appelle “les personacartes” qui permettent d'identifier les leviers d'engagement qui pourraient coller par rapport à son public. (Le nom n’est pas complètement parfait parce que ce n'est pas vraiment des cartes pour mieux construire son persona, mais c’est plus des cartes qui vont bien avec les Gamificartes) 

    Du coup, on se sert de ces cartes pour répondre à la question:  

  • Quels leviers d’engagement pour quel public ? 

    Si on est sur un public très sensible à l’immersion, alors partir sur des univers alternatifs ou sur des choses assez visuelles avec beaucoup de narration, ça va vite fonctionner.

    Pour d’autres publics, peut-être que ça ne sera pas le cas. 

    Donc mon travail, ces questions vont aussi dépendre des attentes du client.

    Parce que si on part sur la refonte d’un outil, ou d’un site web, on a moins de possibilités que si on commence un projet de zéro.

    C’est pour cela que j’impose aussi une phase de benchmark. On essaye de piocher un peu large dans des choses qui s'approchent des sujets de nos clients, et on va présenter différentes choses avec un peu de points positifs ou négatifs. 

    Ça permet assez vite aussi de trancher sur les attentes, plutôt en général avec les clients et leurs équipes, ainsi qu’avec les utilisateurs. 

    Comme il y a des choses qui sont assez ludiques, c'est ça qui va aussi aider. 

    Après, même avec tout cela mis en place, ça n’empêche pas d’avoir des petits couacs.

    On a fait un projet dont je parle un peu en ce moment. On a fait un sprint avec Antropia Essec. C'est l’incubateur d’entreprenariat social de l'Essec qui existe depuis longtemps et qui travaille notamment sur la mesure d’impact social.  

    Ils nous ont sollicités pour reprendre un peu un nouveau programme qu’ils lançaient.

    Ils ont déjà des outils, mais quand on parle d’outils, ce sont des fichiers Excel qui ne sont pas automatisés ni rien. 

    Ils voulaient donc qu'on retravaille ça. 

    Dès le début, il fallait définir le problème. Est-ce que le problème c’est :

  • Que la mesure d'impact sociale n'est pas sexy ?
  • Du coup, on part sur un jeu qui t’explique ce que c'est de façon assez sympa pour que ça donne envie de rejoindre l'incubateur ? 
  • Ou est-ce que le problème, c'est que les gens dans l'incubateur, des fois, ils sont perdus parce que l’accompagnement dure 1 an ? Car en réalité il n’y a des points d’étapes que tous les deux mois et ils ont besoin du coup d'être mieux équipés entre temps ? 

    La réalité est qu’ils ont beaucoup trop de candidatures, qu’ils n’ont pas du tout besoin d'expliquer aux gens ce qu’est la mesure d’impact sociale, parce que les candidats savent déjà ce que c’est.

    Par contre, le programme en soi, c'était plus compliqué. C’était tout de suite clair:

    “En termes de gamification, on ne veut pas un truc trop rigolo, on va dire, parce qu’on s'adresse à des entrepreneurs sociaux qui sont très sérieux, et qui portent fort leur conviction du forum. On veut juste rester focus sur leur sujet, on ne veut pas la détourner sur autre chose.” 

    Cela nous a guidés sur les deux jours de sprint et sur le prototypage qu’on a continué ensuite parce qu'ils voulaient un proto utilisable. 

    Tout cela était début février, afin que le proto tourne avec leurs entrepreneurs. 

    D’un coup mi-mars, on a eu un call avec leurs équipes et la directrice qui avait suivi de super loin le projet. 

    La directrice dit :

    “Ah, en fin de compte On est un peu déçus, on s’attendait à davantage de fun”

    Moi dans ma tête :

    “Déjà tu ne sais pas trop qui est “On”. Je lui dit : “ Jusqu'ici, on n'avait que des bons retours. Qui est déçu ?”

    La directrice:

    “On est un peu déçu quand même. Nous, on voulait de la gamification donc on imaginait vraiment un truc plus fun.”

    Moi :

    “C’est-à-dire que déjà c’est technique, ça veut dire quoi « Plus fun » ? “

    La directrice :

    “Oui, mais tout de même, vous êtes experts en gamification.”

    Du coup, on a sorti cette expertise, avec des arguments. 

    J’en parle dans mon bouquin (la boîte à outils de la gamification) ; j’ai un passage qui parle des différents types de Fun et du fait que ce soit un terme un peu fourre-tout pour discuter de quoi que ce soit. 

    Le fun, ça peut être des blagues, ça peut être l’adrénaline d’une compétition, ça peut être l’engagement dans une cause qui nous tient à cœur… 

    Personne ne va imaginer la même chose en termes de fun.

    Donc il faut lui expliquer que dans un sprint, on a fait des choix-là que c’est pour ça, et qu’on a fait justement les bons choix. 

    Plus tard, j’ai appris du coup que le “On” c’était elle et le directeur.

    Le problème, c’est que pas leur avis qui compte pour juger l’expérience : le public ce n’est pas eux. Tout cela n’aura pas eu de conséquences graves sur le projet. Mais ce sont le type d’événement qui peuvent arriver et peuvent poser problème. Typiquement, ça vient des parties prenantes qui sont détachées du projet et dans ce cas la vidéo que j’avais envoyée spécialement sur le sujet n’avait probablement pas été regardée.

    • Alexandre DUARTE · Expert en gamification · il y a 1 an
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Comment j’organise des ateliers collaboratifs avec mes clients.

    Auparavant dans notre travail on était plus sur une structure du style audit, conseil, et ça produisait un décalage avec certains clients.

    Maintenant, ça nous arrive toujours de faire ça, mais on travaille beaucoup plus sur des sprints. On intervient aussi plus en amont sur les projets, avec plus de cadrage pour aligner les équipes afin qu’ils travaillent ensemble sur l’aspect gamification.

    Pour cela, on organise souvent des sprints de deux jours avec la majorité de l'équipe. 

    C'est tout de même beaucoup plus efficace et beaucoup plus sympa aussi parce qu’au lieu de travailler chez toi, tu travailles avec les clients, ça permet de les rencontrer et de récolter et sentir les avis de tout le monde. 

    Néanmoins, le grand avantage c’est surtout d'aligner tout le monde et d'être sûr qu’on se met bien d'accord sur les objectifs, et sur le niveau de gamification qu'on a envie d'atteindre.

    Souvent, on peut avoir un décalage sur cette question-là entre la personne qui se dit “Avec la gamification on va créer un jeu à la Candy Crush” 

    De l’autre côté tes utilisateurs disent :

    ” Non, nous, on ne veut pas ça. On veut juste un truc clair qui nous motive un peu. Mais tu vois, avec peut-être des barres de progression, ou des choses un peu plus soft “

    Donc tu as un décalage entre ce que le client veut et ce que les utilisateurs veulent. Passer par le sprint, ça t’évite beaucoup de problèmes de ce type-là. 

    Ce sont des choses que tu perçois pendant un sprint, car tu commences à prototyper, et ça donne un résultat assez cool. 

    Le bénéfice principal est surtout sur l’aspect cadrage qui est primordial.

    Lorsque l’on commence un nouveau projet on a besoin généralement de cadrer dans quelle direction on va partir de la gamification, ainsi que de réunir un peu les équipes.

    On a souvent des missions d’intervention un peu courtes donc l’organisation est clé:

  • Grosso modo on a un temps de préparation avec le client pour être sûr de bien trouver des dates, pour valider les salles, etc, notamment quand les équipes sont éclatées en France. 
  • Du coup, on prépare et on recadre un peu l’objectif du sprint.
  • Parce que du coup, on fait quand même assez souvent les «mêmes situations ».
  • On essaie d’avoir de la remontée d’infos du client avant de se lancer sur le sprint (des données sur le nombre de connexions par mois, la récurrence de connexions pour les utilisateurs engagés, les pain points qu’ils ont identifiés, des synthèses de recherche utilisateur quali ou quanti, ce genre de choses, ça dépend un peu des projets)
  • On réalise le sprint sur deux jours avec le client et ses équipes.
  • Généralement, on a à la fois des décideurs, et on a du temps avec des utilisateurs, (ce sont des trucs qui sont les plus complexes à organiser ) 
  • Là on fait des interviews assez rapides. (30-40 min) 
  • Puis on fait un peu de tests, de proto ou de storyboard, juste pour ressortir avec quelque chose des deux jours. 

    Durant le sprint on travaille un peu en mode double diamant.

  • Avec un premier jour qui est plutôt autour du cadrage, pour vraiment se mettre d'accord sur l'objectif.
  • Dans ce premier jour on analyse souvent l'expérience de l’utilisateur qui est déjà présente car dans la majorité des cas on va partir sur des choses qui sont déjà existantes qu’il faut améliorer. 
  • On va reposer justement la question du public, leur motivation, on va commencer déjà à générer les premières idées. 
  • Sur le jour 2, on est généralement plus un peu du prototypage.
  • On va prendre certains éléments de l'expérience qu’on va modifier et prototyper. Certaines sont plus rapides que d’autres à prototyper, et parfois, ça prend différentes formes. 

    Potentiellement, on peut avoir forcément des choses qui sont autour d’écrans, mais parfois, on a des maquettes papier.

    Mais parfois, tu te dis :

    “Tiens, on va distribuer un demi jeu de cartes sur l’onboarding du collaborateur”

    Ça va te permettre d’identifier les personnes-clés dans la boîte ou ce genre de choses.

    Tu prototypes ça pareil sur papier ou Powerpoint ou ce que tu veux d’après tes cartes. 

    Par la suite de ce premier atelier on accompagne le client sur les next steps de la conception, mais plutôt vers les aspects de la gamification, et on travaille généralement avec d’autres équipes.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Lors de longs projets travaillez par itérations et mettez-vous d’accord sur un owner interne.
    Ce dont je vais vous parler est vraiment un learning sur lequel j'ai passé beaucoup de temps à refléter. En réalité, c’est parce que je m'en suis voulue, et c’est en analysant le déroulé que je réalise que la situation est beaucoup plus nuancée.  Le projet se passait dans une grosse boite multinationale avec des milliers d'employés dans le monde. Ils avaient fait l'acquisition d’une société dans la santé connectée et le but était de développer le marché de la e-santé dans les entreprises aux US. Pourquoi?  Parce qu'aux US, la santé ne marche pas comme en France, c'est pris en charge par les entreprises. Une autre particularité outre-atlantique est que plus les gens tombent malades, moins l'entreprise est productive et plus cela a un coût, puisque que c'est l'entreprise qui prend en charge les soins.  Donc, ils voulaient mettre en place une sorte de stratégies de HRA ( health risk assessment). En gros, des études en interne pour voir si les gens étaient malades ou pas, et leur proposer des programmes de santé, des coachs et des objets connectés.   C'était donc un projet de research et de proposition de concepts très high level. Il s'agissait de pouvoir tester des concepts en les faisant tester à des milliers de personnes. Un projet énorme, hyper intéressant.  Niveau ressources, j’étais très bien servie, car je disposais de “la puissance de feu” d’une multinationale, et pour faire la research, c'était vraiment génial. J'ai eu la chance d'avoir un boss qui m'a fait confiance sur ce projet,  J’ai eu accès à tous les outils que je voulais  Un support cross-fonctionnel (marketing, etc) Accès à des milliers de patients pour tester les concepts (ce qui est normalement compliqué en termes de data etc)  De mon côté, j'avais bien géré le brief pour être sûre des objectifs. La recherche était hyper ciblée car il fallait identifier des personnes ayant différentes maladies (diabète) par tranches d'âge et potentiellement ayant des symptômes différents. Par contre, je n’avais pas anticipé que je serais toute seule et qu'il me fallait des gens en face dédiés au projet (ou qui passent du temps sur le projet), pour qu'on puisse avancer. Finalement, j'ai donc beaucoup avancé toute seule, à un rythme saccadé sans réellement pouvoir avoir un fort impact final. Pourquoi?  Ça a pris beaucoup plus de temps parce qu’il se passait des semaines entre les réponses des parties prenantes, pour savoir si j’allais dans la bonne direction, et savoir si c'est ce qu'il leur fallait ou pas.  La conséquence est qu’avec toutes ces pauses, la dynamique a été perdue et le projet fut jeté à la poubelle, car cette boite de santé connectée à en fait été revendue durant ma recherche.  Nouveau management, nouvelles priorités… L’apprentissage de cette expérience est double : En soi, j'ai passé beaucoup trop de temps sur la recherche. C'était tellement intéressant, j'ai cherché, cherché, cherché et peut-être que j'ai cherché trop loin. Je pense que c'est là où je n'ai pas été itérative dans ma recherche. Quand tu as un budget illimité d’argent et de temps ta curiosité peut l’emporter sur l’important. Je réalise que je n'ai pas arrêté la recherche là où il fallait et j'aurais dû être plus itérative dans mon processus. C'est là où je me suis dit: “les cycles itératifs dans la recherche, ça marche aussi.” C'est la première fois que j'en avais vraiment conscience. Assurez-vous d’avoir quelqu'un qui soit dédié au projet de l’autre côté et mettez des guidelines claires pour le suivi en amont. C'est ultra-important. C'est une règle que je me mets en place pour tous mes projets free et même en interne, c'est une question que je pose : 
  • “Qui est owner dans la boite sur ce projet ? “. 
  • “Combien de temps ont-ils dédié à ce projet ?”  Lorsque j’étais freelance, je mettais la barre assez haute:  S'il n'y avait personne qui était dédié à 20% au projet, généralement je ne prenais pas le projet. C'est une règle personnelle.
    • 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
  • Erreur: Mal cadrer l’étude, et ne pas faire évoluer sa stratégie de recherche
    On peut rater une interview, ce n'est pas très grave. Ce qui coûte le plus cher c'est de mal cadrer au départ, notamment sur des phases où il y a beaucoup de stakeholders.  Quand on est junior et qu’on n’a pas forcément confiance en sa capacité de dire "non" aux autres, très vite dès qu'on a beaucoup de stakeholders, chacun va vouloir rajouter sa petite question de recherche sur des choses qui sont parfois très futiles.  Alors que l'objectif de départ est stratégique, on va passer la moitié du temps à faire des recherches sur des subtilités et on oublie d'apprendre l'essentiel. On se tire une balle dans le pied. C'est notre métier de savoir faire le tri dans tout ça si on a bien fait le job. En plus une fois qu'on va présenter les résultats, en général on va nous dire "ce n’est pas ce qu'on avait demandé". Il faut accepter que ce travail-là prend du temps, il faut accepter qu'on puisse se tromper aussi. Le deuxième gros problème qu'on peut avoir au début... c'est quand on choisit un angle large, qu'on a recruté des users, avec une cible mal identifiée. Au début des entretiens même si on voit qu’on n’arrive pas à percer le mystère de ce qu'on cherche à apprendre, potentiellement on exécute le plan avec ce qu'on avait dit au départ.  La bonne pratique c'est de se dire "on s'est trompé". On ne va pas réussir à apprendre suffisamment de choses pour être capable de délivrer un produit, une feature, un modèle de business, etc. Il faut se reposer, recentrer les choses, essayer de savoir à qui on veut parler et ce qu'on veut apprendre. Cela dépend aussi de la qualité des interlocuteurs business, des produits, etc. C'est aussi le rôle du researcher, s'il n'a pas un brief clair au départ, de challenger. Dans les phases très exploratoires, c'est un art subtil, car on ne sait pas exactement ce qu'on cherche, c'est difficile de savoir à quel moment on passe suffisamment de temps. Il y a un moment où il faut passer à la solution.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Conseil – mieux collaborer avec les équipes

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

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

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

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

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

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

    Par exemple:

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

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

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

    Mais plutôt :

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

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

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

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

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

    Ne pas avoir peur et se dire : 

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Casser les a priori de son client sur l’IA et la donnée

    Il y a trop de fantasmagorie autour de mon métier.

    L'intelligence artificielle dans la tête des gens, c'est un coup de baguette magique. 

    Le point central de notre démarche est l’usager. S’il n’y a pas l’étude utilisateur, on ne rentre pas sur le projet. Nous ne répondons pas aux appels d’offres qui vont morceller les projets et qui ne permettent pas d’avoir une vision globale du bot, de ses objectifs et des gains qu’il va apporter. 

    Ça m'est donc déjà arrivé de rediriger des prospects vers des produits de substitution. 

    Ce qui nous intéresse quand on va choisir un nouveau partenaire, c'est parce que ça va nous permettre d'aller tester des choses très concrètes sur le terrain. Alors on sait qu'on va répondre à un besoin identifié et surtout obtenir un gain. 

    Comme notre spectre est assez réduit et que nous croyons dans l’efficacité par la spécialisation des algorithmes ( on a créé IA Médical et IA Marketing car on ne mélange pas nos usages). 

    Il faut en premier expliquer ce que l'IA n’EST pas. 

  • L’IA ne décide pas, elle est entrainée
  • L’IA n’est pas éthique, c’est à nous de l’être 
  • l’IA n’est pas sexiste, son dataset est biaisé 

    Elle ne peut tout simplement pas ÊTRE quoi que ce soit, ce sont des algorithmes, ils n'ont pas d'existence. Déjà, d'expliquer ça, c’est casser des choses dans la tête des gens.

    C'est un système qui va appliquer des recommandations, pour ma part, il est important de considérer les usages d’aujourd’hui, j’ai écrit  un article sur ce sujet. 

    Notre parti pris c’est de comprendre pourquoi il y a des biais dans les dataset et est-ce que certains sont intéressant pour le projet. Pour moi, un dataset avec des biais est un moyen de rectifier le tir ou de mieux comprendre la cible visée.  Par exemple, LISA sait analyser des sentiments dans un contexte d’avis précis. Il y a forcément des biais à l’interieur car on est sur un texte écrit à l’émotion, sur une expérience vécue et souvent sur un mobile. Demain, tu lui donnes un texte de Baudelaire, elle ne saura pas l’analyser et c’est très bien, ce n’est pas son périmètre.  Nous croyons que pour développer une IA efficiente, elle correspondre à un contexte et des usagers particuliers et être évaluée en permanence car ceux-ci évoluent.

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

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

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

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

    J’approche le workshop comme cela: 

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

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

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

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

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

    Pour moi ce workshop permet :

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment filtrer les nouveaux projets de clients et dire non à un client ?

    C’est toujours un exercice délicat, et j’ai toujours du mal à dire non à des demandes externes, néanmoins, avec le temps j’ai appris quelques petites choses sur le sujet.

    Je commence par éliminer tout projet qui est impossible à réaliser : 

  • soit par manque de temps
  • soit par manque de budget, c’est une question difficile pour beaucoup de Free (y compris pour moi), mais savoir se vendre à sa juste valeur, c’est quelque chose de très important, et c’est tout un autre sujet. 
  • Soit par manque de ressources, le fameux, « Alors, il faut rendre accessible et inclusif, mais par contre, vous avez juste un Dev là avec vous », ce n’est pas possible. 

    Ce type de situations, c’est déjà une alerte qui permet une première sélection.

    Ensuite, là où j’apprends aussi à dire non, c’est les projets qui vont trop me bouffer. Ça me l’a fait quelquefois. Quand on s’est fait bouffer par un projet, on sent ceux qui vont potentiellement nous bouffer.

    Dans ces cas-là je ne vais pas forcément dire un NON catégorique, mais je mets des limites à mon client dès le début : lui donner le périmètre de mon intervention, bien dresser la situation, bien cadrer les choses. Je pense que c’est indispensable justement pour mettre ses limites d’apprendre à dire

    « Ah non, il y a telle chose je ne ferai pas » soit parce qu’on ne sait pas faire, soit parce qu’on ne veut pas le faire et dans ce cas, diriger son client vers une autre personne qui sera en mesure d’y répondre et en qui l’on a confiance.

    Si l’on ne met pas ce cadre, on prend le risque de se mettre nous-mêmes des bâtons dans les roues mais si on le fait, il y a de fortes chances que l’on gagne en légitimité auprès de nos clients. 

    Je trouve que ce n’est pas évident de dire NON. Mais après quelque temps, avec l’expérience on a quelques alarmes qui s’activent automatiquement. 

    La prochain objectif que je me fixe, c’est pouvoir sélectionner tous mes projets sur leur valeur :

  • Est-ce que le projet en lui-même correspond à mes valeurs personnelles ?  

    Par exemple, un projet où je suis sûre qu'en termes éthique, en termes écologique vraiment c’est une catastrophe, j’aurais de grandes difficultés à y participer car dans ma vie personnelle, ça a clairement une grande importance. 

    Mais j’ai quand même eu de la chance, en travaillant dans l’accessibilité et dans l’assurance qualité, les enjeux d’éco-conception et d'éthique viennent en parallèle. Pour l’instant en tout cas, je n'ai pas encore eu cette problématique de me dire sur un projet, qu'il ne correspondait pas du tout à mes valeurs. Si je rencontre un jour cette situation, ça va vraiment me poser question. Ce que j’aimerais vraiment c’est trouver des projets qui portent ces sujets qui me tiennent à cœur.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur faite sur un projet: Mal cadrer le projet
    Au début de ma carrière, l’une des erreurs que j’ai commises en début de projet, c’est de ne pas poser assez de questions.  Parfois tu penses que tu as cerné le besoin du client, parce qu'il te dit que tu as carte blanche, sauf qu’on n'a jamais carte blanche.  Le client sait toujours ce qu’il veut ou du moins ne veut pas, inconsciemment. Du coup, je me suis cassée les dents sur un projet, j'ai dû recommencer plusieurs fois, parce que je n'avais pas bien défini le besoin du client.  Maintenant j’ai construit un questionnaire qui me permet de bien cerner le besoin du client. Je demande toujours un cahier des charges pour établir un devis ce qui me permet de savoir quelles sont les grandes fonctionnalités que la personne veut : le contexte, si elle veut dix, vingt, cent écrans...  Il faut toujours passer par un questionnaire pour identifier les contraintes de temps (coucou le planning), ou encore définir l’utilisateur cible… En effet, l’utilisateur cible va impacter le design, le ton que tu vas utiliser dans les maquettes car il doit se reconnaître en arrivant sur ton site. Si tu n'as pas ces informations, tu ne peux pas les deviner. C'est un aspect sur lequel j'ai buté et ça fait mal quand tu dois recommencer, et aux frais de la princesse, parce que du coup tu as signé un devis et c'est toi qui as fait l'erreur.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Accepter n’importe quel planning client est une erreur!
    Savoir éduquer son client sur le planning est un art. En fait c'est plus large que le planning. Je parle de l'art d'éduquer le client. La raison pour laquelle je dis que ce soft skill est un art parce que ça prend du temps à l’acquérir. Je connais des ergonomes très expérimentés qui n'arrivent toujours pas à refuser des plannings irréalisables et acceptent tous les plannings venant des clients.  Pour agrémenter un peu. Je pense que le client sait très bien que le planning n'est pas vraiment possible. Pas forcément sur les dates de réalisations mais sur le start projet. Je vois encore trop souvent des clients qui pensent que l'on va démarrer un projet la semaine suivante après la signature. Si on fait le retour que non, souvent ils n'insistent pas, ils comprennent très bien mais beaucoup n'osent pas. Les répercussions sont énormes puisqu’en acceptant un tel planning, on met toute l’équipe sous pression.  J’ai observé des situations où certains seniors ont la crédibilité de s’engager auprès du client. En réunion, ils répondent du tac au tac, acceptent son planning sans se concerter avec le calendrier et la charge de travail de l’équipe et ça crée des situations intenables pour le client, l’équipe, et l’agence. Ca arrive aussi sur des dates de rendu de livrable. "Vous finissez les tests Mardi? C'est possible d'avoir le rapport fin de semaine? “
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Prenez le temps d’expliquer la démarche en profondeur.
    L’une des erreurs que j’ai commises dans ma carrière, c'est de ne pas savoir amener la mission aux clients.  Avec du recul, je pense que je faisais uniquement cette erreur au début de ma carrière car je ne participais pas à l'aspect commercial. Je pense que dans le fond, je me disais que ces éléments avaient été discutés en amont, mais les interlocuteurs changent entre deux... Ce n’était pas du tout le cas.  En effet, quand on est jeune, on a tendance à vouloir juste se concentrer sur ses tâches sans faire de liens avec d’autres membres de l’équipe et sans se mettre dans une position où il faut cadrer la mission.  Je pense que cette méthode de travail marche encore moins aujourd'hui qu'elle marchait il y à quelques années.  Aujourd’hui, on s’attend à ce que tu sois capable de débloquer les situations et de trouver des solutions. Donc les enjeux sont plus forts et l’attente des clients est encore plus pesante.  Si on arrive la fleur au fusil, sans comprendre le blocage et sans comprendre ce qu’on va apporter, alors on est certain que le projet coincera quelque part.  L’un des exemples qui me vient à l’esprit est la fois où j’ai travaillé sur la refonte de maquettes pour des médecins.  Pour être plus précis, je n'étais pas très bon au départ sur la conduite du changement, car j'étais focalisé sur la plus value de la nouvelle interface (sans forcément oublier ce qui marchait bien sur le produit actuel). Ce que j'avais clairement sous estimé, c'est les personnes qui se sont investi pour apprendre à utiliser l'ancienne version + les demandes d'évolutions acquises etc. Mais une chose est sûre, même après des années d’expérience, je commets encore des erreurs. Récemment, j’ai eu un client qui est venu chez nous, après avoir fait une première tentative de conception avec une autre agence. Mon erreur était de ne pas me méfier et de ne pas me demander pourquoi ça n’avais pas marché avec l’autre prestataire.  Avec du recul, je pense que quand on enchaine les missions qui se passent bien et les réussites, on baisse notre vigilance aussi... Bon je nuancerai un petit peu, je dirais que ce n'est pas totalement la faute du prestataire et que le client avait également sa petite responsabilité. Même si aujourd’hui je travaille encore avec ce client, cela a nécessité beaucoup de réajustement et de travail supplémentaire, car je n’avais pas été vigilant au début de l’engagement.
    • 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
  • Mon workshop de cadrage de mission
    Je ne veux pas que mon entretien de cadrage soit trop formel avec mes clients, et donc j’ai opté pour un format workshop. Pour avoir été de l’autre côté de la table comme directeur digital, c’est assez stressant de se faire interroger sur ses utilisateurs, car ça démontre à quel point on ne les connait pas assez. Ça crée un sentiment d’être mauvais élève, qui est dérangeant, car tu penses avoir la bonne réponse, et durant ce cadrage tu te rends compte que tu ne l’as pas, et donc ton premier réflexe est de se dire. “ Ah ! mais il me fait c**** avec ses questions” Donc, pour éviter cela, je ne veux pas être donneur de leçon, et je l’anime d’une manière que cela soit les clients qui découvrent par eux-mêmes ces vérités. Lorsqu’ils s’en rendent compte, que l’on se met dans une logique de co-construction de la mission. Par exemple: “Ah vous n’avez pas ces indicateurs de performances? Ok, très bien, à quoi ces indicateurs pourraient ressembler ?” Et moins: Je te pose une question tu me donnes une réponse Je te pose une question, tu me donnes une réponse.  Pour finir, on me demande souvent, comment j’arrive à justifier de prendre 2 heures dans l’agenda de stakeholders, et pour cela il faut que certains critères soient réunis. Ce n’est pas à faire à chaque fois pour tous les projets! Il faut que cela soient des projets ayant un gros impact pour vos clients Je le fais lorsque je sens que je n’ai pas toutes les clés pour mener le projet à bien, en expliquant le sens du pourquoi je le fais.  Car ok que les gens n’aient pas le temps, mais s’ils délèguent à un prestataire j’ai besoin de savoir ce qui va les rendre satisfait de mon travail. Ce n’est pas juste une case que je coche dans mon processus. Pour que mes clients soient satisfait, j’ai besoin de savoir ce qu’ils attendent en tant qu’indicateurs de succès du projet. En plus de l’aspect relationnel que cela construit, cela mets en confiance le client qui comprend que c’est important et ça les rassurent. Pour l’histoire, on ne m’a jamais refusé ces deux heures, et je ne transigerai jamais dessus si je sens que c’est quelque chose d’important pour le projet.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Un conseil à moi même: Mieux prendre le temps dans le cadrage au début d'un projet.
    Un conseil que j’aurais voulu avoir au tout début de ma carrière est de prendre le temps, de savoir prendre le temps dans un démarrage de projet, produit ou toute problématique. On est toujours dans une course au livrables, au rythme des plannings, des contraintes... et on ne travaille pas forcément bien comme ça ! Le risque est de traiter la mauvaise problématique ! Finalement, on peut prendre son temps, c'est même mieux. C'est juste une question d’approche, de communication, une manière d'aborder les choses différemment et de mieux les cadrer. Il faut prendre le temps de parler de la bonne problématique et non du livrable final ! Ce n'est pas toujours évident parce que les parties prenantes ont besoin de voir des choses notamment en phase de recherche. Ce n'est pas tout de suite palpable ce que l'on fait en tant que ‘UX Researcher’ donc il faut rassurer ! surtout dans le cadre d’une organisation qui n’a pas l’habitude de ce type d’approche ou de méthodologies. Il faut prendre le soin de communiquer Les différentes étapes de nos activités et le pourquoi de celles-ci Qui l’on va intégrer et pourquoi Ce que ça nécessite comme niveau d'investissement (temps, ressources, etc.)  Je prends le temps de partager cette vision dès le départ, pour ne pas créer un effet déceptif et donner des points d’étapes pour échanger sur les apprentissages… même si ça reste sur du court terme et assez spécifique il faut le faire, sur du long terme le partage de vision peut-être beaucoup plus macro. J'ai une expérience avec ce cas récemment où l'on m’a demandé pourquoi je commençais par traiter ce point alors que leur objectif premier était autre, notamment pour ce projet, l’objectif premier de mes commanditaires était de fournir une GED (outil de gestion documentaire) aux collaborateurs. Comme on manque d'apprentissage et d'expérience sur cette partie GED , et que l’identification des problèmes auxquels nous voulions résoudre n’était pas claire, j’ai proposé de commencer plutôt par un pilote sur lequel nous pourrions apprendre des usages et des problématiques que rencontrent l’utilisateur ; ça reste un produit utilisable sur lequel nous pourrions en récolter au fur et à mesure des données qui seront essentielles pour la bonne évolution du produit qu’ils souhaitent déployer.  Comme ce type de livrable (le pilote) ne répondait pas suffisamment à un produit fini, il a été difficile de le faire accepter par l’ensemble des parties prenantes. C'était une approche nouvelle et ce n'était pas évident, ce n'était pas ce qu'ils avaient en tête. Donc, forcément, il y a plus de discussions et il faut réussir à expliquer pourquoi on fait ça, avec les bons arguments qui feront ‘écho’ aux problèmes qu’ils essaient de résoudre. Je prends donc le temps d'expliquer et je me suis rendu compte que la répétition était importante pour un apprentissage de l’approche également. Je vais jusqu'à une Roadmap du projet, une vraie vision, ce que l'on va faire, des personnes qu'on va impliquer et des ressources dont j'ai besoin. Ça passe évidemment par le budget, la validation juridique, la logistique (réservation de salles, outils et licences, etc.)
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Difficulté d'être au milieu de la relation agence x client. Que faire ?
    Hello ! Aujourd'hui j'aimerais partager un challenge qui est en train de m'arriver, et solliciter un avis extérieur pour prendre de la hauteur sur cette situation. Je travaille de temps à autre avec un product studio qui vends des sprints de recherche ( et le timing de base est hyper serré - 4 jours avec 2 jours d'un autre PM) J'ai accepté d'être sur le projet tout en mentionnant que je me gardais le droit de renégocier si l'objectif du sprint n'était pas aligné avec l'estimation initiale de départ (pour éviter de travailler gratuit, perdre de l'argent, mais surtout par expérience. Entre ce qui est vendu et nécessaire il y a un monde). Dès le début le cadrage initial du client était mauvais, et il avait des attentes démesurée de la recherche. Il m'a fallu un peu de temps pour le remettre sur les rails. J'ai mieux cerné son besoin, mais c'est une recherche beaucoup plus complexe avec des grosses questions d'explorations qui touchent la famille, les enfants, l'image de soi, celle que l'on veut laisser etc.. Donc j'ai recommandé une approche plus solide, et qui nous permettait de dé-risquer certaines hypothèses en amont. Mais que évidemment cela avait un coût car le budget initial nous permettait de faire 8 entretiens de 60 min ou10 de 45min, et pas le double comme j'en avais besoin. (car oui on avait 2 cibles) Au cours de 3 appels différents j'ai prévenu le client que cela aurait un coût extra.Il a dit ok, et qu'il verrait la question commerciale une fois que l'on se mettait d'accord. J'ai prévenu l'agence en interne en donnant les détails de la discussion. Vient donc cette question de la négociation aujourd'hui, et cela s'est mal passé. Le client a campé sur ses positions, et n'a pas voulu d'extension de budget. Suite à cela, l'agence l'a mauvaise. Pour ne pas faire sauter le projet (vu qu'il y a d'autres phases) on décide de réduire le scope pour faire tenir la recherche dans le temps imparti 😥 (dents qui grinçent) Je communique cette info au client, et rebondissement. Maintenant le client ne veut plus réduire le scope du plan de recherche car ça paraît être "un grand écart". Mais ne veut pas payer non plus. Donc imaginez le drame, moi évidemment je suis au milieu entre l'agence qui gère cette question commerciale avec le client, et le client avec qui je dois réaliser la mission pour qu'il lance son projet. Pour info, lorsque l'on parle au client on n'a pas le droit de parler en jrs/h. (d'où la difficulté de parler d'efforts, ou relancer les discussions commerciales) Perso, en 2 ans et demi de freelance c'est la première fois que ça m'arrive. Donc ma question est: Voyez-vous un point ou je suis passé à côté dans le process ? Imaginons que cette situation continue et se dégrade, que feriez-vous ? Merci :)
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Creative Strategy and the Business of Design
    https://www.goodreads.com/book/show/26450623
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ne présumez pas que les gens savent pourquoi ils font appel à vos compétences.
    Dans le passé, une erreur de débutante dans laquelle je me suis souvent retrouvée est de me lancer dans des projets en pensant que parce que le client fait appel à toi, il sait pourquoi. En réalité, c’est souvent le contraire. Dans mon cas, c'est encore plus criant, car je touche à des médiums comme l'intelligence artificielle, les algorithmes, les données, et je n’ai jamais un client, ni un secteur type. De plus, les domaines sont nouveaux et victimes d'a priori.  Par exemple lorsque tu fais ton compte rendu en commençant par : “Voici les points de frictions” :  Un défaut de lisibilité sur une fiche produit car le contraste texte / fond est trop faible.  L’équipe va s’attendre à ce que derrière, il y ait des maquettes, que ce ne soient pas des outils de réflexion mais la version finale. Parcequ’il y a aujourd’hui une forte confusion entre les expertises.  Alors que dans mon cas j’arrive avec une roadmap d’AB test, des quick wins pour venir aider la refonte.  Mon métier, c’est avant tout de faire un audit de la stratégie marketing, ça peut commencer par l’audit d'un site pour comprendre quels sont les endroits où tu sens que c’est un peu compliqué pour l’utilisateur (que ce soit dans la fiche produit, dans la marque) jusqu’à l’expression de l’offre et la stratégie de communication..  J’ai encore pas mal de travail de vulgarisation à fournir sur mon métier le marketing et mes outils Data analyse, algorithmes ou encore matrices. :  Mon objectif c’est de faire accepter qu’aujourd’hui on doit redonner la parole à l’usager “ on va tester et c'est l'utilisateur qui va décider, ce n'est pas vous, parce qu’on veut redonner la voix à l'utilisateur.” est l’étape cruciale dans la démarche que j’entreprends avec mes clients.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Quand savoir dire non à un client et refuser une mission
    Cela m’est rarement arrivé, de dire à un client “Je ne préfère pas qu’on y aille”. Avec l'expérience, je me l’autorise de plus en plus pour la simple et bonne raison que je sais que je ne vais pas pouvoir faire tout ce que je veux faire, et livrer dans les bonnes conditions. C’est le genre de situation où l’on va tous les deux être déçu. Le client sera déçu, et moi je serais déçu, car je n’aurais pas pu livrer comme je le désirais, et en utilisant les méthodes qui me paraissaient les plus appropriées. Pour repérer ce genre de situation, j’ai créé ma checklist de cadrage, qui est absolument primordiale dans mon processus en tant que freelance. J’essaie de savoir: Quels sont les critères de succès sur lesquels je vais être évalué ? Qu’est-ce qui dira si le projet est un succès ou non ? Leur niveau de connaissances clients. Le client a-t-il de la data ? Si oui, quel type de data ? Des personas ? Si oui, comment ont-ils été créés ? Des études précédentes sur lesquelles je peux me documenter ? Ce genre de questions avec le client permettent de subtilement délimiter le terrain de jeu. Cela me permet de définir sir le client est humble vis-à-vis de sa méconnaissance client, ou s’ils ont l’impression de connaître, mais ce n’est pas aussi définitif.  Ce cadrage, je le fais donc sous un format workshop de deux heures avec eux.  Cela me permet de jauger ce niveau de connaissances client, mais aussi leur permettre de réaliser par eux-mêmes “Ah oui, en effet, ici nous ne savons pas” ou dans un autre cas de figure me rendre compte qu’ils pensent savoir et que je vais devoir marcher sur des oeufs, car cela ne m’a pas l’air clair sur la partie documentation.
    • 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.

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

    • Commentaires

    Groupes

    Hashtags

    Groupes