chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
106 résultats
Selection
  • #erreursaeviter 82
EN LIEN AVEC VOTRE SÉLECTION
  • 82
  • 17
  • 15
  • 15
  • 8
  • 6
  • 6
  • 6
  • 6
  • 6
  • 4
  • 4
  • 4
  • 4
  • 3
  • 3
  • 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

Postes

  • ·
  • ·
  • Evitez le piège de trop parler de la méthodologie.
    Je voulais partager avec vous une réflexion sur les erreurs que j'ai pu faire dans mon parcours professionnel.  Pour vous donner un peu de contexte, j'étais dans une banque qui débutait sa pratique de recherche UX, investissant à fond dans les talents, les processus et les outils. Comme cette pratique était toute nouvelle, il y avait un réel besoin de "démocratiser la recherche UX", c'est-à-dire d'expliquer clairement nos méthodes, nos démarches et nos objectifs. Là où j'ai peut-être un peu trop poussé lors de restitution, c'était dans mon désir d'expliquer en détail la méthodologie, de montrer pourquoi les études que je proposais étaient impeccables, que ce soit en termes d'échantillonnage, critère de recrutement, de méthodologie ou de réduction des biais.  Je me suis rendu compte que ça ennuyait profondément tout le monde. J'avais l'impression de perdre leur attention et leur intérêt en m'attardant trop sur ces aspects dont personne n’était capable de challenger.  Pour moi, c'était important pour deux raisons.  D'abord, ça donnait de la crédibilité à notre profession et ça renforçait ma position en tant qu'expert apportant de nouvelles méthodes éprouvées.  Ensuite, sachant que j'étais parmi les premiers à pratiquer la recherche UX dans cette organisation, je pensais aux chercheurs qui me succéderaient et qui, dans 2, 5 ou 10 ans, pourraient lire mes rapports.  L'idée qu'ils puissent juger ma rigueur et mon expertise méthodologique me préoccupait beaucoup. Je craignais qu'un nouveau venu, tombant sur un rapport sans explications détaillées sur la taille de l'échantillon ou le protocole expérimental utilisé, puisse être perdu.  Cependant, lors de mes présentations, en insistant tant sur la méthode et le recrutement, je réalisais que je lassais tout le monde.  Finalement, les gens ne sont pas si intéressés par ces détails. Ils savent que tu es un expert, l'entreprise t'a embauché pour cela, et tu as déjà la validation de ton boss. J'ai compris que ce n'était pas nécessaire de passer autant de temps sur la méthodologie, une erreur que beaucoup de juniors font également.  Je pense qu'il est plus important de se concentrer sur les résultats, les recommandations et comment cela peut faire avancer les discussions, le processus de création de produits et, ultimement, améliorer l'expérience des utilisateurs concernés par ces produits.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Management et amitié ne font pas bon ménage
    Hello à tous, Je veux partager une erreur marquante de ma carrière. Elle concerne une relation personnelle qui a eu un impact significatif sur mon environnement professionnel. Quand j'ai démarré dans l'UX, et plus spécifiquement en UX Research, j'ai rejoint une agence UX à Paris.  En tant que chef de projet études internationales, j'étais chargé de toute l'organisation des études à l'étranger. Je collaborais étroitement avec les UX Researchers de mon équipe, responsables de la rédaction des guides, de la modération, de l'analyse, et de la présentation des résultats aux clients. Notre équipe était restreinte, seulement 5 personnes, mais nous formions un noyau dur, sans réelle hiérarchie entre moi et les autres UX Researchers. Cette proximité a naturellement conduit à la formation de liens d'amitié solides, à tel point que nos interactions ont dépassé le cadre professionnel, avec des rencontres et des dîners chez les uns et les autres. Après deux ans et demi, une opportunité est survenue pour l'une des UX Researchers de rejoindre un concurrent. Peu après, cette même entreprise m'a approché avec une proposition alléchante : venir et établir leur pôle UX Research. Intrigué, j'ai consulté mon ex-collègue et amie pour recueillir son avis sur cette nouvelle entreprise. Encouragé par ses retours positifs, j'ai accepté l'offre. Cette décision s'est révélée être la pire que j'ai prise.  Me retrouvant à la tête du département, une hiérarchie s'est immédiatement établie entre mon ex-collègue et moi, transformant notre relation.  Elle a commencé à adopter des comportements qu'elle n'aurait jamais eu avec un autre supérieur, utilisant notre amitié comme prétexte pour refuser des projets ou éviter des calls avec les clients. L'arrivée d'une nouvelle UX Researcher a exacerbé les tensions, plaçant notre relation dans une situation encore plus compliquée.  Face à cette toxicité croissante qui nuisait à l'ensemble du pôle research et à l'entreprise, j'ai dû alerter le top management.  La décision a été prise de se séparer de cette personne d'un commun accord, à travers une rupture conventionnelle. Ce fut une des erreurs les plus difficiles que j'ai dû affronter, m'enseignant qu'il est crucial de ne pas tisser des liens trop personnels avec ceux que l'on manage, pour éviter de tels débordements.  Avec du recul, même si cette expérience m'a permis de grandir professionnellement, je n'aurais probablement pas pris la décision de rejoindre cette entreprise si j'avais su à l'avance les complications que cela entraînerait. J'espère que mon expérience pourra éclairer. À bientôt.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur de positionnement en interne qui m'a VRAIMENT coutée très chère.
    Bonjour à tous ! Je viens partager avec vous l'erreur qui m’a coûté la plus chère dans ma carrière de freelance et de researcher.  Surtout parce qu'elle a conduit (en partie) à la non-reconduction d'un contrat avec un client de longue date.  On parle ici d'un engagement qui s'étendait sur 4 jours/semaine réparti sur un an et demi, durant lequel j'étais l'équipe de recherche du client.  Autant dire que ça a été un coup dur. L'erreur principale que j'ai identifiée dans cette mésaventure, c'est que, en tant que freelance, je me suis trop cantonné au travail avec le middle management.  Je parlais bien avec des VP et des leads, mais je n'ai jamais cherché à aller plus haut, à échanger directement avec les CXO et CEO.  La raison ? Principalement par crainte de bousculer les équilibres ou d'intimider managers qui étaient, après tout, mes clients. Un autre aspect que j'ai négligé, c'est de ne pas avoir suffisamment prêté attention aux signaux qui indiquaient la manière dont l'organisation prenait réellement ses décisions.  Il y avait tant de signes, comme:  L'absence de roadmap claire Les changements brusques de priorités Le démarrage ou l'abandon soudain de projets, qui montraient que tout se décidait en interne suivant la vision d'une sorte de "dieu" interne J'ai cru naïvement, que mon travail de qualité et mon engagement auprès de mes interlocuteurs directs, comme les équipes produit, marketing etc, suffiraient.  J'étais même en pleine réflexion sur comment améliorer ma valeur ajoutée, surtout après qu’en interne nous ayons réussi à faire évoluer la position de l’UXR de la Brand/marketing vers le département produit. Cette évolution à pris un an de travail en interne. En réalité ce qui se passait c’est que les middle managers avaient tendance à occulter ou minimiser ces aspects face aux dirigeants de l'entreprise. Je me rappelle très une discussion avec une amie qui dirige une agence en Afrique du Sud, présente dans 42 pays et forte de 20 ans d'expérience.  Quand je lui ai parlé des sujets et obstacles sur lesquels je travaillais, elle m'a demandé si je communiquais avec le CEO, soulignant l'importance que la C-suite soit au courant de ces éléments pour éviter les problèmes.  À cette époque, il y avait déjà pas mal de complications en interne, et je reconnais avoir eu peur (ou même paralysé sur comment faire) pour m'adresser directement plus haut. Cela me fait penser à cette citation qui dit que  "des règles existent, et soit tu les utilises, soit elles seront utilisées contre toi".  C'est assez représentatif de ce qui s'est passé.  Avec l'arrivée de nouvelles personnes et le début du bear market en 2022, l'entreprise, qui dépensait beaucoup, a dû restructurer ses activités.  Bien que le rythme de demandes était élevé niveau research c'est finalement un C-level, qui m'avait peu vu, qui a pris la décision finale de couper les budgets de l’équipe produit et bloquer le renouvellement de mon contrat. Je pense que cette décision a été influencée par un manque de visibilité passé car je m’étais concentré à servir mes clients internes, sans prendre en compte la (vraie) chaîne de décisions en interne. En espérant que cette expérience serve à d’autres :)
    • merci! Utile
    • Pas utile
    • Pas sûr
  • La research secondaire est souvent minimisée à tort
    Un autre point de réflexion que je trouve particulièrement intéressant est lié à mon approche des nouveaux projets de recherche.  Auparavant, je n'avais pas d'inquiétude à l'idée de me plonger dans des domaines inconnus. Mon parcours m'a amené à travailler dans des secteurs variés : l'industrie du jeu vidéo, des startups dans l'immobilier, la gamification, ou encore la création de contenu pour les plateformes comme TikTok et Facebook. Actuellement, je travaille dans le secteur du retail.  Ma philosophie était de maintenir un regard de non-experte lors de mes interviews, ce qui, je pensais, favorisait la qualité de ma recherche. Cette approche a certes été bénéfique dans certains cas, me permettant d'apporter un regard neuf sur un sujet.  Toutefois, j'ai aussi découvert ses limites, en particulier pour les projets plus techniques. Prendre le temps de se former et d'approfondir mes connaissances dans un domaine a nettement amélioré la qualité de mes interviews et de mes insights.  Cette prise de conscience est survenue l'année dernière alors que je travaillais pour Jelly Smack, sur un projet centré sur le montage vidéo. Un stakeholder insistait pour que j'apprenne moi-même le montage vidéo, pour mieux comprendre les pressions auxquelles sont soumis les monteurs vidéo internes.  Au début, j'étais réticente, peut-être à cause de la manière dont cette demande était formulée. Mais au fil du projet, j'ai réalisé à quel point une connaissance approfondie du sujet pouvait enrichir ma recherche, rendre mes questions plus pertinentes et me permettre de mieux observer certains automatismes. Cette expérience m'a démontré que, contrairement à ce que je pensais, une immersion préalable dans le domaine d'étude peut grandement enrichir la recherche.  Aujourd'hui Quand j'aborde un nouveau domaine, je m'investis davantage dans la recherche secondaire, je lis énormément et je cherche à comprendre en profondeur, non pour devenir experte, mais pour mieux me connecter avec mes interlocuteurs et saisir les nuances de leur métier. Cette évolution de ma pratique n'a pas été un échec mais une révélation, grandement facilitée par le travail en binôme avec un designer expert du domaine, que je remercie chaleureusement. Cette collaboration m'a montré qu'une passion et une curiosité véritables pour un sujet peuvent conduire à des insights bien plus profonds. Désormais, je sélectionne mes missions de recherche aussi en fonction de mon intérêt pour le sujet, cherchant des projets qui m'inspirent à découvrir et à explorer, comme un véritable travail de détective avant même le début du projet.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Astuce test utilisateur: Oubliez les commentaires sur le look & feel.
    On le répète souvent, les retours sur l'esthétique sont des considérations à éviter et c'est du bruit. Donc à ne pas inclure dans vos résultats. Je liste  Sauf si cela amène des problèmes de confiance et d'identification vis à vis du produit. Mais du genre " Le jaune je n'aime pas".  "La photo n'est pas belle" wikihero-image-id: 1251 J'aime bien David à créer sa liste d'astuces à retrouver ici. https://david-hamill.medium.com/usability-testing-tips-a7960b987fe8
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mes REXS de refonte E-commerce.
    La refonte, c'est un processus que nous abordons de temps en temps, bien que dans le passé, nous nous y sommes plus souvent consacrés.  L'une des choses essentielles à comprendre en premier lieu est la raison pour laquelle nous entreprenons une refonte.  J'ai observé avec le temps que dans la plupart des cas, les refontes sont déclenchées par un changement de la plateforme technique.  Cela signifie qu'une mise à jour technique entraîne souvent des modifications au niveau du design et d'autres aspects. Personnellement, j e trouve que ce n'est pas une raison suffisamment solide pour lancer une refonte complète. Lorsque nos clients viennent nous voir, ils ont souvent une vision très négative de leur site ou de leur application. Ils expriment des critiques sévères, qualifiant l'existant de médiocre, bourré d'erreurs et difficile à comprendre.  Cette tonalité humoristique peut sembler exagérée, mais elle reflète en partie leurs véritables préoccupations.  En tant que professionnels, notre première étape consiste à examiner de manière approfondie la situation. Notre domaine d'expertise réside dans l'expérience utilisateur. Nous testons leurs sites et applications pour identifier ce qui fonctionne et ce qui ne fonctionne pas réellement,mais d’un point de vue UX,bien sûr.  Il s'avère souvent que certaines choses qui semblaient dysfonctionnelles fonctionnent plutôt bien. D'autre part, il y a des éléments précieux qu'il ne faut pas jeter.  Par conséquent, il est essentiel d'aborder un projet de refonte avec prudence, en évitant une vision trop négative ou trop positive. Un autre problème fréquemment rencontré est l'impulsion de tout révolutionner.  Une refonte implique de tout casser et de tout reconstruire, ce qui est un processus complexe.  Il est donc essentiel de partir avec une compréhension claire de la situation existante, sans préjugés excessifs envers les aspects négatifs ou positifs.  J'ai même rencontré des personnes qui pensaient que leur site était parfait, alors qu'il était malheureusement médiocre, et ils refusaient de considérer des changements majeurs.  Cependant, ce genre d'attitude est de moins en moins courante. Dans les cas de sites web ou d'applications à fort trafic, il est impératif d'être prudent lors de la mise en œuvre de changements majeurs.  La modernisation de la charte graphique ou des éléments d'ergonomie peut présenter des risques, même lorsqu'elle est accompagnée par une agence expérimentée et des experts en expérience utilisateur.  Les réactions des utilisateurs sont imprévisibles, comme l'ont montré des exemples passés, notamment le cas de Snapchat ( https://www.marianne.net/economie/le-probleme-de-snapchat-derriere-kylie-jenner). En conséquence, il est essentiel de procéder de manière progressive, en testant et en communiquant clairement les changements apportés. Le comportement des utilisateurs a également évolué, avec une impatience croissante et une plus grande volatilité, notamment en raison de la pandémie de COVID-19.  Les utilisateurs sont de moins en moins tolérants envers les changements, et les marques doivent en être conscientes.  Pour éviter de se heurter à la résistance des utilisateurs, il est essentiel de procéder par étapes et de bien communiquer sur les modifications apportées.  Des exemples comme Airbnb montrent comment une approche progressive et pédagogique peut atténuer les effets négatifs des changements(avec un patron, ancien designer, qui prend souvent lui même la parole pour expliquer ces changements : https://twitter.com/bchesky/status/1524372742048718848?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1524372742048718848%7Ctwgr%5E37ea663cbed37a1bdb11ccdc1e6aefbaf32ca613%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwexperience.fr%2Fblog%2Fanalyse-ux-de-la-refonte-dairbnb%2F . (avec un bon PMM) En fin de compte, il est préférable de prendre des précautions pour éviter de dépenser de l'argent en réalisant des changements qui se révéleront contre-productifs.  La prudence est de mise, quel que soit le niveau de trafic, car le mécontentement des utilisateurs peut rapidement devenir un problème majeur et faire le bonheur de la compétition."
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Quand utiliser ou non les ateliers avec vos stakeholders ou vos clients.
    Dans la pratique, pour améliorer la communication et sa gestion, j'ai expérimenté diverses méthodes. Le succès de ces méthodes varie selon plusieurs facteurs, notamment la maturité de l'entreprise, des gens et des interlocuteurs concernés. Par exemple, j'ai tenté d'organiser des ateliers, mais cela peut parfois être contre-productif.  Bien que j'aie souvent reçu des retours positifs, il y a eu des moments où les participants cherchaient plutôt une expertise directe de ma part. Ils attendaient de moi des recommandations d'expert plutôt qu'une séance de création collaborative. J'ai longtemps cru que les ateliers étaient une solution universelle à tous les problèmes, mais je me suis rendu compte que ce n'est pas toujours le cas. Il y a des moments où il est préférable de présenter les choses en tant qu'expert. Lorsqu'un stakeholder ou un client exprime clairement qu'il attend de vous une expertise, c ela indique qu'il est temps de montrer des résultats concrets et un produit finalisé. Il ne souhaite pas forcément participer activement au processus, ce qui est compréhensible. Ainsi, je dirais que l'utilisation des ateliers dépend vraiment du contexte. Si la personne est ouverte à cette approche et que le projet en est à ses débuts, un atelier peut être utile pour définir le périmètre et la vision du projet. Toutefois, parfois, il est nécessaire de passer en mode recommandation et de présenter une vision globale plus concrète. Parmi d'autres outils que j'ai utilisés, l'un d'eux, qui a fonctionné de manière variable, est l'utilisation de Loom. Enregistrer et présenter par vidéo un prototype, une recherche ou un document, offre la possibilité de s'améliorer en présentation, car on peut se revoir et ajuster notre discours. Envoyer la vidéo plutôt que de tenir une réunion peut être un moyen efficace de communiquer. Enfin, la communication textuelle est tout aussi importante. Rédiger un email ou un message sur Slack ou Discord qui est à la fois concis et clair est crucial. Dans un monde où l'attention est limitée et où les gens sont souvent submergés, savoir communiquer de manière succincte et directe est un art. Des vidéos Loom postées dans les canaux de communication peuvent éviter des réunions inutiles et structurer la discussion. Bien que tout le monde ne regarde pas les vidéos, elles peuvent être un outil précieux pour ceux qui le font. En résumé, les trois outils principaux que j'utilise pour une communication efficace sont la communication écrite, les enregistrements vidéo et les ateliers. Chacun a son rôle et son importance, adapté au contexte et aux besoins du moment.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les 3 types d'erreurs qui peuvent arriver avec votre étude.
    Dans cet article Lawton explore 3 types d'erreurs où votre recherche peut être ineffective et même dangereuse pour le business. Ce que j'aime bien ce sont les exemples réels des études sur lequel il se repose. (Oldies but goodies) Etude de Walmart Coca-Cola Et je pense que l'erreur numéro 3 - Le problème de contexte est déterminante dans notre travail. Car ce qui se passe en test, peut ne pas du tout se reproduire dans la vraie vie, lorsque vous avez des intéractions sociales et publiques entre vos clients. (ex de coca) C'est notamment vrai pour les lancements de nouveaux produits où la question de loyauté et de promesses réalisées dans le passé est clé. Parfois ça peut être destructeur lorsque cet aspect n'est pas pris en compte dans l'étude. (du coup les focus groupes deviennent intéressant). https://www.quarterinchhole.com/p/ux-research-failures
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon début de parcours chaotique comme manager d’équipe.

    Lorsque j'ai été nommé responsable du pôle digital, j'ai été confronté à la gestion d'une équipe. Il faut imaginer que je venais de sortir de l'école et que pendant six mois, j'étais chef de projet, puis tout d'un coup, je me suis retrouvé à devoir manager. 

    J'ai occupé ce rôle pendant les cinq premières années de ma carrière professionnelle. En me plongeant dans l'UX, j'ai dû me confronter à l'aspect humain. Cela signifiait développer des compétences en communication non violente, en empathie et en bienveillance, et me former pour écouter les utilisateurs, savoir quand me taire et poser les bonnes questions. 

    En somme, cela a été une formation sur la façon d'interagir avec les autres, de respecter et de mettre en place des cadres d'échange et d'équipe.

    Cependant, j'ai dû gérer une équipe alors que j'avais une expérience limitée dans ce domaine, et surtout, je n'étais pas le genre de personne perçue comme "méchante" ou "gentille". 

    Du jour au lendemain, j'ai été informé que mon supérieur hiérarchique était parti et que je devais prendre le relais. 

    Cela s'est produit du jour au lendemain, sans aucun avertissement préalable. Donc, dans toutes les situations où je ne connaissais pas le sujet, où je ne me sentais pas suffisamment mature ou compétent pour y répondre, ma première démarche était de faire des recherches. 

    Je savais que d'autres avaient vécu des expériences similaires, travaillé sur les mêmes sujets, et pourraient au moins me fournir des données pour commencer à construire ma compréhension et m'éduquer sur le sujet.

    À cette époque, je n'avais pas du tout réalisé ce travail de recherche, probablement influencé par l'idée que les relations humaines sont simples, une question de bon sens, et que tout se passerait bien. 

    Or, la réalité est bien plus complexe et demande une rigueur extrême. Il faut mettre en place des processus pour le bien-être des collaborateurs, mais aussi pour ta propre santé mentale en tant que manager. Malheureusement, tout ne s'est pas déroulé de manière optimale. J'ai dû embaucher quelqu'un que j'ai ensuite dû licencier quelques mois plus tard, une expérience que personne ne souhaite vraiment vivre.

    À ce stade, on pourrait dire rapidement : 

    "Je ne veux plus avoir à gérer tout cela. Ce n'est pas mon domaine, cela ne me parle pas, je ne veux pas être responsable de la gestion d'équipe de cette manière." 

    Cela demande de prendre des responsabilités, comme dire à quelqu'un qu'il doit partir. Ou bien, cela implique des situations où des personnes avec lesquelles tu t'entends très bien, presque des amis, n'obtiennent pas l'augmentation qu'elles souhaitent parce que ton supérieur ne l'a pas approuvée, et finissent par te dire : 

    "Je vais partir." 

    Tu finis par le prendre personnellement. En réalité, cela te confronte à tes propres lacunes, à ton incapacité à les accompagner correctement et à améliorer leur situation dans l'entreprise. Ces situations sont à la fois dramatiques pour toi en tant que manager et parce que tu ne contribues pas grand-chose. 

    Tu essaies de faire mieux, mais tu as déjà l'impression de faire beaucoup par rapport à d'autres. Je vois d'autres managers dans l'entreprise gérer leur équipe différemment, ce qui indique que j'avais une relation différente avec mon équipe. Cependant, cela restait insuffisant par rapport à l'ampleur du pouvoir que tu as en tant que manager sur la vie des gens, et sur le fait qu'ils se sentent bien ou mal dans leur poste.

    C'est une responsabilité énorme à cette époque, sur laquelle je n'ai pas cherché à construire ma vision, à mettre en place un cadre, à essayer de proposer un contrat commun pour améliorer les choses ensemble. 

    Pour remédier à cela, aujourd'hui: 

  • Je prévois des entretiens individuels chaque vendredi de 10 heures à 11 heures, et tout le monde peut y participer. Vous avez quelque chose à améliorer ? Une frustration ? 
  • Dans d'autres équipes, j'ai également mis en place des "météos d'humeur", où chaque personne indique son état d'esprit avec un simple smiley, sans avoir à se justifier. Si vous voulez mettre un smiley "doigt d'honneur" parce que tout vous énerve, vous pouvez le faire gratuitement. 
  • Cela permet aux autres de comprendre comment vous vous sentez et d'être plus attentifs à vous. 
  • J'utilise de nombreuses techniques pour recueillir davantage la satisfaction des gens et essayer de co-construire avec eux de meilleures façons de travailler.

    À l'époque, je ne connaissais rien de tout cela, et je me contentais de penser : "De toute façon, tout se passera bien, nous ne sommes pas des méchants."  Évidemment, cette approche était très insuffisante. C'est une leçon que je retiens, car aujourd'hui, lorsque j'exerce un rôle de manager, j'ai beaucoup progressé sur ce point.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • Ne vous laissez pas flatter par des choses qui n’ont rien à voir avec votre métier.
    Pour introduire le sujet j’aimerais ajouter que pour moi il n'y a pas d'erreurs en fait. On peut se tromper souvent, mais dans le fond, je retire toujours un positif d'un négatif.  Donc si je devais citer un exemple, je sais qu'à un moment donné, j'étais pas très bien parce que, j'avais croulé ma première boîte, et il fallait que je mange.  Il a fallu 2-3 mois pour rebondir quand ça m'est arrivé ça, on m'a attiré dans une grosse boîte, vraiment une énorme boîte, une entreprise nationale, qui était un e-commerce très prestigieux. J’y suis allé, parce que c'était une grosse boîte, c'était un poste assez prestigieux, et mine de rien qui avait l'air intéressant.  L'erreur que j'ai commise, c'est que je me suis laissé flatter par des choses qui n'avaient rien à voir avec mon métier.  Je me suis fait flatter par le prestige du poste, je me suis dit que de me retrouver avec des directrices, des gens importants, c’était une avancée. Il n'y avait d'ailleurs pas un salaire important à la clé, mais c'était plus le côté, j'ai un poste important, voyant et prestigieux.  Au final, ça s'est avéré plutôt inintéressant comme poste, je me suis retrouvé dans une entreprise qui allait très très mal, avec beaucoup de dysfonctionnements humains, et puis avec quelque chose qui n'était même pas en adéquation avec mon tempérament.  Moi je suis un indépendant, j'aime bien les petites structures, les petites impros, c'est ça qui me plaît, et là je me suis retrouvé dans une énorme machine, (avec des rouages rouillés d'ailleurs) des processus complexes.  Il fallait faire attention aux mails qu'on envoyait, il ne fallait blesser personne, c'était très complexe pour moi, très très lourd.  Donc j'ai vite pas aimé ce qui s'est passé. Je ne suis resté que deux ans, et même si j'ai passé deux années, la deuxième année m'a permise de monter en interne (ndlr:2008) un studio de test utilisateur.  Du coup, quand je suis sorti, j'ai monté ma boîte et j'ai fait exactement la même chose. Le fait de mettre en place des choses en interne, ça m'a permis de relancer ma carrière en tant qu'entrepreneur, de recréer une boîte. L'erreur de se laisser avoir par son égo, regretter, puis heureusement, pouvoir rebondir en repartant par le métier, l'opérationnel et par la passion est mon apprentissage au final. C'est le fait d'aimer quelque chose passionnément, dans son boulot, qui permet toujours de trouver une nouvelle source d'inspiration, une nouvelle fonction, et puis de faire quelque chose qu'on aime.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Gardez le lead lorsque vous travaillez avec vos clients.
    J'ai réalisé des erreurs dans ma carrière, notamment en accordant ma confiance à des individus qui, au final, ont causé plus de préjudice qu'autre chose.  C'est un point d'apprentissage crucial pour moi : il faut savoir faire confiance, mais en même temps, il est essentiel de toujours garder le contrôle, de garder le lead. Ce concept de leadership est fondamental.  J'ai appris que même en déléguant, on ne peut pas se désengager totalement.  Si on est à la tête d'un projet, il est crucial d'être perçu comme le leader, même si notre rôle actif dans les détails peut être limité.  Mon expérience passée m'a montré l'importance de maintenir une présence et un leadership clairs dans toutes les interactions professionnelles. Ma stratégie a beaucoup changé à la suite de cela.  Au début, j'étais plus orientée vers la création d'équipes, mais maintenant je suis dans une démarche de contrôle plus approfondi. J'ai compris qu'il faut être très attentif dans la gestion des relations professionnelles, car malheureusement, les situations où les personnes que vous formez utilisent leurs compétences et leurs contacts pour leur propre bénéfice existent. Maintenant, je m'implique davantage, je supervise de près. Je partage des responsabilités, mais je segmente très précisément les rôles et je garde toujours le lead sur les projets. Je veille à ce que mes collaborateurs rapportent directement à moi et non au client. Ils peuvent assister aux présentations, mais seulement quand je suis présente. Je ne les laisse plus aller à des réunions ou à des briefs sans moi.  Un signe qui ne trompe pas est lorsque des collègues commencent à établir des liens directs avec les clients sur LinkedIn ; cela annonce souvent un risque pour le leadership et la fidélité professionnelle. Cet épisode m'a appris qu'il vaut mieux parfois se surévaluer que de se sous-évaluer.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur réalisée lors d’une prise de poste.
    Il y a quelques années, j'ai été confronté à un défi de taille : repenser un flux complexe lors de mes premiers mois dans une nouvelle organisation.  Le projet était déjà en gestation lorsque je suis arrivé et j’ai repris le bébé à bras-le-corps. Vous savez, le genre de flow qui vous donne des maux de tête dès le départ.  Les problèmes étaient évidents, mais en tant que designer, je me suis engagé dans une refonte sans une boussole claire basée sur les indicateurs clés de performance (KPI). Nous avons cherché à créer une expérience utilisateur exceptionnelle en combinant intelligemment des patterns éprouvés.  Nous avons effectué des analyses comparatives, benchmarks etc.. mais nous savions que copier les autres ne résoudrait pas nos problèmes. Cependant, à mesure que nous progressions, la vérité nous a rattrapés.  Le projet était colossal, nécessitant un investissement massif en temps et en ressources. (1 an et demi de dev) Une révélation nous a frappés :  Était-ce vraiment nécessaire ?  Le jeu en valait-il la chandelle pour gagner quelques points de pourcentage dans les taux de conversion ? Si le problème initial de conversion n'était pas si grave et que les ressources nécessaires étaient disproportionnées, pourquoi redesigner tout le flux ?  Un moment d'introspection s'est imposé. Nous aurions dû identifier les problèmes spécifiques du flux et envisager des améliorations ciblées. En fin de compte, ce projet s'est avéré être un éléphant trop imposant à avaler.  Les ressources, le temps et l'argent investis ne justifiaient tout simplement pas la poignée de points de pourcentage gagnés.  Nous avons compris que la prémisse initiale était erronée, et que refondre un flux complexe est une tâche délicate.  Il faut bien plus qu'une légère défaillance pour justifier une refonte complète.  Si quelque chose fonctionne déjà relativement bien, il est difficile de justifier une transformation radicale. En somme, retenez ceci : une refonte majeure doit reposer sur des bases solides.  Il faut vraiment que quelque chose soit cassé pour justifier une telle entreprise.  Si ce n'est que partiellement brisé et que les résultats sont satisfaisants, optez pour des ajustements tactiques plutôt que de plonger tête baissée dans une refonte monumentale.  Concentrez vos ressources sur des projets plus urgents et célébrez les succès tels qu'ils sont, sans chercher à tout réinventer.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Une erreur de débutant que j'ai commise tôt dans ma carrière.
    À cette époque, j'étais encore relativement novice, avec moins de deux ans d'expérience, et par mon manque de séniorité, je ne suis pas allé secouer le contexte dans lequel je me suis retrouvé. À l'époque, je travaillais chez EDF, alors que le marché de l'énergie s'apprêtait à s'ouvrir à la concurrence. Notre mission était de créer des interfaces pour les auditeurs énergétiques, équipés de leurs ordinateurs portables, prêts à rencontrer nos clients industriels.  Leur rôle ? Simuler la consommation énergétique de l'entreprise, en prenant en compte chaque détail, des compresseurs aux tapis roulants, du chauffage aux réfrigérateurs.  En collectant ces données, nous pouvions proposer des solutions pour réduire les coûts, tandis que nos concurrents se contentaient d'offres standardisées, incapables de personnaliser leurs propositions. Nous nous sommes lancés, une équipe hétéroclite de designers et d'experts en énergie. Nous avons conçu des formulaires, imaginé des interfaces, puis nous sommes passés au stade des essais. Cependant, notre première erreur fut de ne pas placer l'utilisateur au centre de notre réflexion.  Nos experts en énergie, aussi compétents soient-ils, ont façonné un plan qui semblait parfait sur le papier, sans jamais consulter les auditeurs qui devaient utiliser notre solution sur le terrain.  Et...nous n’avons pas testé nos interfaces pour nous assurer de leur validité dans le contexte de l’audit. Notre passion pour le projet a pris le dessus, nous n'avons pas cherché les retours des clients sur leurs besoins spécifiques en matière de simulation.  Nous avons créé une interface esthétiquement séduisante, des icônes élégantes, des fonctionnalités de drag & drop, même des icônes custom élaborées avec soin lors de week-ends entiers.  Mais nous avons omis de nous poser les questions essentielles :  Le drag&drop est-il vraiment pratique ou utiliser le clavier aurait été plus simple ?  La hiérarchie visuelle est-elle adaptée au modèle mental des utilisateurs ? Aujourd'hui, je travaille dans le secteur du e-commerce de la mode.  Se mettre dans la peau d'un acheteur en ligne est plus simple comparé à comprendre les défis d'un auditeur énergétique. Pourtant, cette erreur persiste : négliger l'utilisateur et présumer que nous détenons toutes les réponses. Comment j'éviterai de reproduire cette erreur Avec le recul, j'aurais dû m'asseoir avec ces auditeurs énergétiques, ces pionniers qui redéfinissent leur profession.  Comprendre leur point de vue aurait été inestimable :  Comment percevaient-ils leurs visites clients ?  Quels étaient leurs besoins réels sur le terrain ?  À cette époque, il n'y avait pas de modèle établi. Néanmoins, un simple ordinateur portable ne suffisait peut-être pas.  Peut-être avaient-ils besoin d'autres outils ou de notes à portée de main ? J'aurais cherché à sonder ces experts pour extraire des informations vitales. En outre, j'aurais exploré le côté client. Trouver des entreprises intéressées par notre service aurait pu offrir une perspective précieuse.  Les clients pouvaient avoir une vision différente de ce que les auditeurs souhaitaient réellement. Peut-être préféraient-ils une version simplifiée ?  Ou au contraire, une version plus détaillée ? Peut-être étaient-ils plus intéressés par les rapports que par la visite en elle-même ?  L'objectif aurait été de dialoguer avec les deux parties pour concevoir une expérience répondant aux besoins de tous.
    De nombreuses entreprises qui n'ont pas les designers comme utilisateurs adoptent cette approche. Prenons Doctolib, par exemple. Ils encouragent leurs employés à consulter régulièrement des professionnels de la santé et à partager leurs expériences pour améliorer leurs services.  C'est, selon moi, la clé : rechercher activement des informations, se glisser dans la peau de l'utilisateur pour concevoir des solutions qui répondent véritablement à leurs besoins.
    Une autre dimension de cette erreur est la tentation de complexifier les choses. Nous avons tendance à pousser les limites de la complexité pour créer des solutions plus attrayantes, plus élégantes, supposant qu'elles fonctionneront mieux, sans garantie. C'est une erreur que je répète fréquemment, mais c'est aussi une erreur que je m'efforce de commettre sciemment.  Je sais que je tends à suivre les modèles établis avec mes équipes, mais chaque fois qu'une situation nouvelle ou inhabituelle se présente, je m'interroge sur une approche différente, une solution alternative. Dans mes débuts en tant que designer, dans le tumulte des années 2000, j'ai eu la chance de travailler sur des projets innovants, où nous créions à l’époque de nouveaux patterns.  Aujourd'hui, créer une application repose souvent sur des briques existantes. Pourtant, je continue de me demander : n'y a-t-il pas une voie non tracée ?  C'est un exercice risqué, source d'erreurs potentielles, car il peut nous conduire à ajouter des options complexes, exotiques, exigeant temps et réflexion, sans garantie de succès. Pourtant, je m'autorise souvent à prendre des patterns apparemment inapplicables et à les adapter à notre contexte.  Parfois, cela fonctionne de manière surprenante, ajoutant une touche d'originalité à l'ensemble.  Mais nous les testons systématiquement et ces solutions moins conventionnelles se distinguent parfois lors des tests, surpassant les schémas plus classiques.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Liste de 100 projets et 100 leçons qui se sont plantés en Ed-tech
    Superbe compilation d'exemples de projets dans le domaine de l'ED tech qui n'ont pas marchés.L'article offre un peu de contexte et une leçon de l'échec. Très bien pour réaliser un tour d'horizons de ce qui à été tenté par le passé et pas réussi.  https://hackeducation.com/2019/12/31/what-a-shitshow
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Erreurs basiques en travaillant avec de la donnée.
    Je suis fille de prof de maths, donc les nombres c'est un peu ma LV2 ! J’adore travailler avec de la donnée et les représentations statistiques comme les ACP, dendrogrammes, AF.  En général, dans la donnée, tu as deux possibilités : tu veux absolument savoir une chose par la data ou alors l'attitude opposée, c'est d’aller explorer librement cette immense base de données.  Tu peux vite te perdre dans les deux. Parce qu'en fait chaque donnée que tu vas collecter, tu peux la croiser avec d'autres données. Potentiellement tu as une infinité de paramètres à aller creuser.  Les 2 erreurs les plus communes que j’observe sont celles-ci:  Tu peux te perdre dans ce que tu recherches (excès de curiosité, pas de recherche guidée).  Tu peux être trop directif (et te couper d’énormément d’information utile). 
    La data te donne l’impression que” plus tu en fais mieux c'est”. Tu commences à explorer, tu fais des stocks.  C'est important de stocker, de séquencer le projet parce qu'il y a un moment donné tu peux saturer ! tu peux savoir tellement de choses… et tu veux tout savoir.  Donc il faut se discipliner et être organisé. Sinon ça peut vite être le vrac dans ce que tu vas chercher derrière. Et d’un autre côté, il ne faut pas avoir peur de la data, parce que je sais qu'il y a une arithmophobie croissante dans le monde de l'UX.  Quand j'entends des influenceurs UX dire "moi je n'aime pas le quanti et de toute facon je ne sais pas faire"... ca m’interroge car je me demande si on peut encore faire de la user research aujourd'hui sans faire de quantitatif, sans comprendre les chiffres et sans utiliser la data. J’aurais peur d’être obsolètes d'ici à quelques années.  Et puis, aujourd’hui, beaucoup de choses sont automatisées, tu peux très bien faire des stats sans connaitre les formules complexes : Il faut savoir à quoi sert la donnée et ce que veulent dire les statistiques que tu vas récolter. J'adore particulièrement bosser avec les avis clients. Parce que l'exploration des datas ne sert pas juste quand tu as fini le produit et que tu l'as testé.  C'est après en post achat, ce que tu analyses. Parce que si tu veux vraiment faire des guidelines solides, il faut s’appuyer sur ton produit. Souvent l'UX va s'arrêter au moment où il a fait un premier test et basta. C'est comme faire la moitié du travail. Et que fait-on du reste ? Donc oui les avis clients c'est quand même un bon kif. A force d'en faire, ça devient un automatisme. Amener de la donnée dans son travail d'UX La première étape évidemment, ça va être de créer ou de trouver la data. Et la bonne nouvelle, c’est qu’aujourd'hui il y en a partout et sur tous les sujets. Entre les avis, l’UGC, les parcours, … Alors franchement si on ne trouve pas...je me dis qu’il est temps de faire un tour chez l’ophtalmo.   Il y a toujours de la donnée disponible. Si on me rétorque que le produit n'existe pas encore et qu’il est unique, et bien tu vas voir ce que fait la concurrence. (concurrence élargie: pour ceux qui n’ont pas de concurrents “directs”). On peut aussi créer sa propre donnée.  Une fois que la donnée est récupéré il est souhaitable de s'entourer d'un data scientist compétent. Le travail en binome va commencer. On va déméler et donner du sens au données.  Pour les plus motivées et ceux qui sont à l’aise avec R, Anaconda, Python.. Ils peuvent être autonomes.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Les promotions ne sont pas attribuées au mérite.
    L’erreur de débutante que j’ai faite, je crois qu’on est nombreux à la faire : c’est de croire que le monde de l'entreprise serait méritoire. Que si je travaillais bien, que j’atteignais mes objectifs, alors cela aurait un impact positif sur ma carrière.  Les premières années je travaillais jusqu’à 75h par semaine ! (oui j’ai beaucoup d’énergie et je m’investie beaucoup professionnellement), je voulais surpasser les objectifs qu’on me fixait.  Je travaillais tellement que je n’avais plus le temps de prendre de pause café, je mangeais à mon bureau et travaillais de chez moi en rentrant le soir. Au final la promotion attendue a été donnée à un autre (plus junior) mais qui passait du temps avec les patrons (dans les petits papiers) et faisait la promotion des projets de l’équipe…pendant que je faisais mon travail (et une partie du sien car il prenait du retard). Ça m’a fait un choc ! Je crois que ça été un déclic pour plus travailler ma communication ! Je pensais que tu progressais au mérite et que c'était fair-play. Je pense que c'est la plus grosse erreur que j'ai faite.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Ne jamais accepter le “C’est mieux que rien”
    Un autre de mes conseils serait de ne jamais accepter le "c'est mieux que rien". Quand tu es dans une entreprise et que tu exprimes le besoin de 30 utilisateurs et qu'on te répond, que tu as le budget pour 5 utilisateurs... Je ne pense pas que la meilleure idée soit de faire un test dégradé.  Parce que les gens vont s'habituer à des choses de moins bonne qualité. et le jour où tu vas me demander un budget pour 30, ils ne vont pas comprendre… puisque tu as toujours fait avec 5.  Pour moi les choses sont assez simples :  Si tu n'as pas le budget pour faire une bonne étude, tu ne la fais pas.  Si tu n'as pas les moyens pour faire un bon prototype, tu ne le fais pas.  Je pense que c'est une hygiène de l'UX à s'appliquer. Si tu n'as pas les moyens, tu ne le fais pas tout simplement.. Le "c'est mieux que rien",en réalité ca devient vite “pire que tout”. Autant assumer un parti pris plutôt que de faire les choses à l’arrache..  Quand j'entends "oui mais on ne peut interroger que nos amis, ils sont dans la cible"... mais es-tu sur de cela? Ne vont-ils pas être influencés dans leur réponse parce qu’ils te connaissent et connaissent ton entreprises? Serais-tu prêt à parier que le comportement de tes amis et ceux du client final seront le même?  Alors oui, certes, tu vas donner l'illusion que tu as fait quelque chose mais tu ne sais pas si au fond le résultat sera sur ton futur utilisateur.  Je vais plutôt essayer de négocier :  “tu as 1000€ pour cette étude, alors la seule chose que je peux te dire c'est si les utilisateurs vont apprécier ton logo.  Voilà ce que tu pourras savoir. Mais si tu me donnes 10 000€, je pourrai te dire si ton site sera un succès ou pas.  Pour le coup, je fais en sorte que mes études soient le moins chères possible, mais toujours avec des prestataires compétents. Je suis dans une optique d'optimisation, d'efficacité opérationnelle... Il faut être parfois être inventif pour tenir le budget.  Et si ca ne passe toujours pas et bien… dans ces cas-là, sinon je suis désolée mais je ne le fais pas. Ils peuvent passer par une agence externe, se débrouiller autrement, mais moi en tout cas, je ne le ferai pas. J'ai mieux à faire de mon temps que de réaliser un test qui ne sert pas à prédire le futur comportement de l’utilisateur parce qu’il a été mal fait.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ne croyez jamais que vous avez compris l'utilisateur.
    Je donnerai ce conseil à un débutant : ne jamais croire que tu as compris l'utilisateur.  À partir du moment où tu penses que tu as compris l'utilisateur, c'est que tu as arrêté d’essayer de le comprendre. Si jamais dans la boite où tu travailles, un UX ou un PO te sort “je connais l’utilisateur”. C'est qu'il a arrêté le process de reflexion. Parce que la compréhension de l'utilisateur c'est un process continu et ce n'est pas quelque chose de figé. J’ai tendance à penser que quand tu es UX et qu'il y a un truc que tu crois savoir faire parfaitement, c'est que tu as perdu ton discernement. Si tu crois que tu as trouvé la méthodologie parfaite que l’on peut appliquer dans tous les cas et contextes : c’est une illusion. Chaque étude a ses limites.  J'ai quinze ans de carrière derrière moi, j'ai plus de 300.000 utilisateurs qui ont répondu à mes questionnaires et 700 études différentes... Il n'y a pas une fois où je ne me fais pas relire par un pair. Je reste vigilante. Car le jour où on croit qu'on est “bon” ou qu’on a “compris”, c'est qu'on a arrêté de bien travailler. En résumé, le secret c'est d’être à l’aise avec les incertitudes et avec le fait qu’on ne peut pas tout savoir. C’est une remise en question permanente, et pour cela il faut s’armer d’un bon esprit critique.  Quand on me demande ce que pensera l’utilisateur du produit, ma réponse préférée est “ça depend!” car je n’ai pas la science infuse et l’humain n’est pas trivial ni rationnel dans ses décisions qui dependent du contexte, de sa personnalité, de son humeur, de son expérience passée…   D’ailleurs cet esprit critique est valable pour son travail mais il est aussi de mise pour le reste. Et notamment ce que l’on peut apprendre en expérience utilisateur. Il y a des livres et des auteurs aujourd'hui qui sont cités comme des références... Franchement ? Vous êtes sûrs ? Le domaine de l’UX n’est pas épargné par les “fake news” et les contre-vérités. Il y a aussi des influenceurs en UX qui avancent des propos méthodologiques tout à fait contestables (voir contre-productives). Malheureusement, cela a un impact sur les plus juniors. Il y a des juniors qui arrivent avec des méthodologies hasardeuses...parfois on se demande où ils ont appris ça ! Parfois les méthodes sont supers mais sont appliquées … dans le mauvais contexte.  Si je prends un cas précis, c'est le mythe du test avec cinq utilisateurs. Le junior va faire un test sur cinq personnes et c'est suffisant pour lui. Il donne même une note (“le site a 7/10”). Alors j'explique que c’est statistiquement pas possible ni suffisant pour donner une note. Si je change mes 5 testeurs aurais-je la meme note? Certainement pas. Il me répond "c'est Norman qui a dit ça !" et je lui réponds : "Et alors ?".  Il n'a pas compris le contexte dans lequel c'était dit (5 personnes pour détecter une majorité des défauts, certainement pas pour faire une évaluation !) et ce n'est pas parce que c'est tu as une personne que tu as sacralisée qui te dis une chose que c'est vrai. Je sais que ce n’est pas sa faute : il y a beaucoup d’écoles qui enseignent l’UX avec des niveaux très hétérogènes. Je vois parfois des professeurs qui ont des parcours "surprenants" considérant les matières qu'ils enseignent. Et aussi quelques autodictactes qui, certes ont le mérite d’avoir appris seuls, mais dont les méthodologies me font parfois hérissées les poils.  Méfiez-vous de ce que vous avez appris, ayez un regard critique sur la profession, et entourez-vous de pairs de confiance.  Je vous raconte ma petite histoire pour exemplifier cela. Mon tout premier test c'était pour choisir un vélo pour les femmes urbaines à Paris. Je n’avais jamais conduit de test avant ce jour. J’ai passé mes vacances d’été à lire des bouquins pour apprendre à le faire correctement. J'ai ingurgité des dizaines de bouquins en analyse sensorielle, en marketing pour préparer mon étude.  Alors on a produit des vrais vélos, qu’on a mis dans une vraie situation (dans un magasin) avec de vraies testeuses (recrutées). J'ai vu que statistiquement il m'en fallait 200. Donc ca nous a couté cher. Mais je voulais faire cela bien. Pas question de déroger sur la qualité de l’étude. Surtout que c’était une premiere !  Comme je l’avais vu dans les livres, j’ai posé plusieurs questions à mes testeuses.  Quelle est leur couleur préférée ?  Parmi les vélos, quel est celui qu'elles prendraient ?  Et le cas échéant, quel est celui qu'elles achèteraient ?  Si on vous en offre un lequel vous prendriez?  Et en fait, quelle que soit la question que je posais, je n’ai jamais eu la couleur qui s'est le plus vendue Ça m'a ennuyé ! Il y avait un vrai problème. A quoi servent mes études si elles ne permettent pas de prédire le résultat !?! Il y a eu un décalage énorme entre la méthode et le résultat des ventes. Et c’était embêtant parce qu'on a sorti l'artillerie lourde et c'est un test qui nous a coûté cher et qu’on avait passé des mois à préparer. Et pour rien. Ça m'a mis un gros coup de pied au derrière sur le fait qu'il y avait peut-être d'autres choses à aller chercher.  Alors j’ai repris les banc de la fac (pour comprendre ce qui se passent dans la tete des gens) et j’ai déployé un arsenal de technique implicite pour palier à l’absence de fiabilité du déclaratif.  Je peux en citer plusieurs :  1. La biométrie. Car le corps sait ce qu’il se passe bien mieux que notre propre introspection. Il ne trahit pas. Il réagit à chaque stimuli.  2. La data. Grâce à elle, Facebook arrive à mieux prévoir ce que l'on va faire que …nous-même ! Il sait si on va aimer telle ou telle publicité grâce à des algorithmes qui analysent chaque jour des millions d’utilisateurs. C'est quand même assez flippant. 3. La psychométrie. C'est l'art de mesurer la personnalité des gens. On va aussi développer des questionnaires qui doivent être extrêmement de bonne qualité, robustes. Grâce à eux, on peut mesurer des aspects de la psychologie des utilisateurs. En fait, j’utilise régulièrement ces trois outils que sont la biométrie, la data et la psychométrie pour essayer d'aller un cran plus loin sur la recherche utilisateur. Mais j’ai encore beaucoup à apprendre. Je suis actuellement des cours en Psychologie Evolutionnaire et en Linguistique.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le pouvoirs des Checklists

    J’ai pris conscience de l’importance des Checklists grâce à une erreur que j’ai fait sur un de mes premiers projets.

    J’étais entrain de présenter mon travail de façon plutôt confiante, quand un Développeur m’a posé une question anodine en apparence sur l’état d’un composant. Et là, j'ai eu le sentiment de me voir à la troisième personne et je me dis "Colbys comment tu as pu oublier ça ?" . C'était une claque galactique !

    J'ai essayé de rattraper le coup : " Ah oui, effectivement, c'est quelque chose que j'ai oublié, mais au début, j'avais noté ça quelque part, donc je ferai la modification sans que ça change vraiment tout". 

    Mais en réalité, c'était une grossière erreur de ma part. Aujourd'hui ce que je fais c'est que je fonctionne beaucoup par checklist dans tout ce que je fais. 

    Si je dois faire un redesign par exemple:

  • Je vais toujours faire une sorte de curation de l'existant
  • Faire une liste de la cible, des choses comme ça et je vais merger les deux en une checklist. 
  • J'essaye de toujours avoir une checklist, par exemple de tous les composants, de tous les états d'une page, de tous les états d'un service, de tous les statuts possibles, d'un système. 

    Ainsi je vais toujours me fier à cette checklist. Donc au fur et à mesure que j'avance, je vais l'ouvrir et je vais checker. Vient enfin le jour de la présentation et je sais que je suis prêt et que je couvre tous les uses case. 

    Je sais ainsi qu'il n'y aura pas de question qui va me mettre K.O. On n'abuse jamais assez des check-lists !

    Sur les produits denses en plus, il y a beaucoup de choses à prendre en compte et je pense qu'il n'y a pas de honte à connaître ses limites. C'est nécessaire pour bien faire.


    La création d’une Checklist

    Quand je dois partir de zéro sur un projet, je fais  de la recherche pour connaître les besoins, les contraintes, … les informations à afficher, dans quel ordre, par priorité. 

    Par contre, si c'est un projet existant, je découpe d’abord l'existant. J'essaye toujours de découper les choses et de les grouper avant d’attaquer la phase la recherche.

    Je vais prendre l'exemple d'une page car c'est à une échelle réduite et ça aide à visualiser ce que je veux dire . 

    Si je dois redesigner une page, je vais la découper en plusieurs morceaux. Il peut y avoir la navigation d'une part, un fil d’Ariane, la pagination ou un footer. 

    Je vais découper tout ça, leur donner des noms et les grouper.

    Dans ma checklist, je vais inclure chaque élément qui compose ces bouts de la page ainsi que leurs différents états à prévoir. 

    Par exemple, dans le footer, je vais avoir des liens vers telle ou telle page, peut-être des CGU, …

    À partir de là, normalement, l'exercice est relativement simple parce qu’au fil de la recherche, quand j’identifie les nouveaux composants à apporter, je les rentre dans cette checklist, il me suffit juste d'un petit tag pour différencier l’existant du nouveau, et voilà ma Checklist est complète et me donne une vue d’ensemble.

    Ça  m'aide à faire du zoning parce que si je dezoome, je sais tout ce qui doit être sur cette page-là. Puis à l’étape de wireframing, je vais zoomer et travailler sur chaque bout de la page individuellement.

    • Colbys Dovi · Senior Product designer · il y a 1 an
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur: Prendre trop de temps pour se séparer des personnes non performantes.
    Il est important d'éviter l'erreur de prendre trop de temps pour se séparer des personnes non performantes.  Les échecs les plus importants que j'ai observés sont souvent liés à un manque de courage de la part des manager de se séparer des personnes qui ne sont pas à la hauteur de leur travail.  En effet, ce sont toujours les erreurs humaines qui peuvent nuire à une entreprise. Parfois, je constate que des clients recrutent la mauvaise personne, même dans des domaines différents du mien, et cela me fait réaliser l'impact financier et énergétique que cela peut avoir sur l'entreprise.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Pour augmenter votre impact de researcher comprenez l’organisation où vous travaillez

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

    Pour comprendre cela il faut comprendre mon parcours.

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

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

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

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

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

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

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

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

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

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

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

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

    Quels sont les objectifs business ?

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Etude qualitative, entretien exploratoire. La phase de préparation est clé !
    Je suis très compétente en méthodologie qualitative et les entretiens exploratoires, car c'est mon domaine d'expertise. Une astuce que j'ai apprise dès le début, c'est que la phase de préparation est d'une importance cruciale pour mener efficacement des entretiens exploratoires.  Il y a une idée préconçue qui m'agace et que l'on entend souvent : "Il ne faut surtout rien dire, rien regarder pour arriver neutre sur le sujet." C'est la première erreur que l'on apprend à éviter lors d'études en sociologie.  On ne peut jamais être totalement neutre, notre regard sera toujours biaisé.  La clé est de reconnaître ce biais et de s'en affranchir. Ainsi, en lisant, en posant des problématiques, en formulant des hypothèses, on s'assure qu'au moment d'être sur le terrain, on est capable de reconnaître ce biais et de dire :  "Ah, ce que je vois, c'est un regard biaisé", et on en est conscient.  Si on ne se prépare pas, tout est biaisé, mais on ne sait pas ce qui est vrai ou faux. Donc, pour moi, la réussite d'un bon entretien exploratoire passe par une phase de documentation.  C'est quelque chose que peu de personnes font. Prendre le temps de lire un peu de contenu scientifique ou même du contenu marketing sur le sujet permet d'avoir des premières pistes de réflexion, un point de référence. Une fois que cela est fait, on construit le protocole d'entretien en se basant sur les hypothèses que l'on souhaite étudier par la suite.  Les erreurs à éviter sont justement d'induire des réponses en prétendant être neutre. Plus on est armé et préparé pour l'entretien, plus on peut être certain que cela sera un échange ouvert où l'on saura laisser la personne s'exprimer sans trop intervenir.  Bourdieu dit qu'un sociologue est quelqu'un qui regarde avec ses yeux, tout comme un photographe prend une photo ou un peintre peint un tableau.  Ainsi, il transcrit une réalité vue à travers son regard.  Cependant, si ce regard reste complètement subjectif, sans être encadré, il devient inexploitable. L'erreur est de croire que la naïveté ouvre toutes les possibilités, alors qu'en réalité, pour moi, cela réduit considérablement la portée de l'étude.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • N’assumez pas que vos collègues et clients savent ce qu’est l’UX !

    L'une des plus grandes erreurs que j'ai commises en tant que responsable d'équipe et experte UX a été de supposer que mes clients connaissaient déjà ce qu'était l'UX, sans rien préparer pour leur expliquer. 

    Nous pensions qu'ils étaient déjà familiers avec le concept, alors qu'en réalité, nous aurions dû partir du principe qu'ils ne le savaient pas et leur montrer comment nous pouvions les aider.

    Ma vie aurait été bien plus facile si j'avais eu une brève présentation résumant :

  • Ce que nous faisons,
  • Comment nous le faisons, et
  • Comment nous pouvons les accompagner sur ces sujets.

    C'est toute la notion d'advocacy, et cela a des répercussions sur votre carrière :

  • Les gens refusent de payer pour votre expertise
  • Ils vous confondent avec d'autres professions
  • Ils ne savent pas exactement où vous intervenez.

    Au sein de l'IMD (Institut de Management et de Design), j'ai lancé une vaste campagne de sensibilisation, car j'ai réalisé que lorsque nous vendions l'UX à nos clients, ils le percevaient simplement comme du design. Depuis lors, l'une des choses les plus importantes que j'ai faites est de sensibiliser les gens à ce qu'est réellement le métier de l'UX, quelles sont les valeurs ajoutées, comment cela fonctionne et comment nous pouvons les impliquer.

    Je me souviens avoir organisé une série de trois présentations de trente à quarante minutes chacune, où nous avons invité l'ensemble de l'IMD pour leur expliquer. Nous devions dissiper cette confusion persistante :

    "Ah, vous faites du design ; ah, vous travaillez dans l'informatique ?"

    Pour bien expliquer l'UX, il n'est pas nécessaire d'avoir des éléments concrets à montrer, mais plutôt de raconter une bonne histoire, en établissant des analogies avec leur travail quotidien. 

    Par exemple, l'un de nos clients internes qui rencontrait le plus de problèmes avec l'outil que nous utilisons actuellement était le secteur de la médiation (travaillant avec le public, notamment les enfants). 

    Ils étaient confrontés depuis plus de dix ans à un problème majeur : la mise à jour de leur CMS interne. À l'époque, il était largement utilisé et considéré comme la référence, mais aujourd'hui, il est devenu obsolète, lourd et extrêmement difficile à optimiser, ce qui freinait toute l'équipe.

    Lorsque vous sensibilisez les gens, il est important de vous référer à ces problèmes spécifiques qui les affectent au quotidien, et de construire votre histoire autour de cela. Par exemple :

    "En résolvant ce problème de cette manière, vous n'aurez plus à passer trois heures à recréer des données et à vous épuiser avec votre CMS."

    L'objectif est de susciter leur intérêt en replaçant ces problèmes dans leur contexte quotidien. Il n'est pas nécessaire de se concentrer sur de grands enjeux, même de petites améliorations peuvent faire toute la différence.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX sur l’internationalisation du contenu.
    Les langues et cultures étrangères ne vont pas s’adapter à votre produit. Une chose qui ne va pas fonctionner, c'est de laisser des personnes natives d'une langue, traduire l'interface simplement parce qu'elles sont internes.  La traduction c'est un métier. Souvent, les personnes qui travaillent dans des start ups ou des grands groupes ont une appétence vers l'international, elles utilisent énormément d'anglicismes et vont les garder dans la copie finale alors que le reste du pays ne s'exprimera pas forcément comme ça. Déjà pour la génération de tes parents, la langue qu'on parle en interne dans une équipe startup, c’est pas clair… et potentiellement, ces personnes-là, selon le projet, ça peut être ta clientèle. Donc c'est un vrai sujet d'aller trouver des personnes professionnelles et ensuite, autant que possible, d'identifier soit une agence, soit des freelances, mais en tout cas d'avoir des points de contact fixes, de ne pas varier en permanence les personnes qui traduisent, c'est assez crucial.  Ensuite, essayer de ne pas tirer les prix vers le bas parce que tu vas trouver des agences peu scrupuleuses qui paient très mal leurs équipes. Si tu as une petite connaissance des métiers de la traduction, tu te rends compte que ça ne peut pas marcher.  Les pros facturent au mot et ont intérêt à traduire le plus vite possible. Si tu lui envoies des docs pour un petit projet, peu prendront le temps de lire pour passer à un autre projet.  Donc si tu as vraiment besoin de briefer, tu paies à l'heure et tu fais une réunion pour expliquer le projet. Soit tu prends des freelances avec qui tu vas avoir une relation sur le long terme, et à ce moment-là, ils vont investir un peu plus de temps pour te garder. Mais quand tu passes par une agence, il y a forcément une énorme perte de connaissance entre ce que tu dis à l'agence et les modifications. En résumé, il faut essayer d'avoir un peu une connaissance de ces métiers-là et on a besoin que les heads of voire les C level fassent preuve de curiosité pour cet aspect du Produit au même titre que pour le dév. Les facs françaises forment des linguistes qui sauraient faire ça très bien si les entreprises savaient où les chercher. On a un problème pour intégrer ces savoir-faire dans des équipes UX ou des équipes produit. On se retrouve avec des ouvertures de pays qui ratent complètement sans que le niveau de connaissance des processus de traduction et localisation progressent. Chez Sendinblue, j’ai poussé pour le recrutement d'une personne à temps plein qui devait s’occuper de ça et nous aider lors du lancement des projets à faire un glossaire (un élément clé du design system) qui va servir à préparer la traduction autant du côté marketing que produit.  Souvent on a le marketing qui vend un produit en lui donnant un certain nom, mais au sein d'une équipe produit, et bien, depuis le début, le projet porte un autre nom.  Pour illustrer tu te retrouves avec le marketing qui va te vendre des pommes, et une fois que tu es dans le produit, c'est des oranges. Maintenant, comment tu vas trouver tes fruits si en plus sur la langue que tu utilises, il y a une ambiguïté et un seul mot pour dire pomme et poire ? C'est un vrai sujet et c'est un sujet pour lequel il faut investir un peu dans peu de temps. La bonne nouvelle, c'est qu'un glossaire, c'est certes du temps mais ce ne sont pas des outils incroyables non plus.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Mon REX de freelance: Le savoir administratif est important

    J'avais prévu d'écrire un petit article sur divers thèmes, notamment celui de la liberté, et ce que j'aurais aimé savoir au début: Ce qui concerne l'administratif. 

    Par exemple comment gérer tout ce qui est rupture conventionnelle ou démission, ce genre de choses. Le savoir administratif est important, il n'est pas à négliger. 

    Des milliers d'euros peuvent se jouer sur une mauvaise décision, donc c'est bien d'être informé et pas juste se lever et dire voilà, je l'ai fait, c'est bon.

    Quand je veux quelque chose en général je planifie très bien et après je me lance. J'étais consultant avant, j'ai planifié, j'ai démissionné, je suis passé freelance. 

    J'ai réalisé plus tard que si j'avais eu une rupture conventionnelle, j'aurais pu avoir le choix... Parce que tu peux cumuler le chômage de Pôle emploi avec le statut d'auto-entrepreneur. 

    Là où ça aurait été intéressant spécifiquement, c'est que moi j'étais dans un système de facturation de 45 jours fin du mois, ce qui veut dire que je suis payé 60 jours calendaires après l'envoi de ma facture. Donc avoir le chomage dans cette période aurait été d’une grande aide.  

    Heureusement que j'avais prévu quelques mois de réserve avant de passer en freelance. Mais pour ceux qui n'ont pas prévu ou qui n'ont pas pu à cause de la somme qu'ils gagnaient avant, ça, c’est une petite info qui peut tout changer.

    Ca ne sert à rien d'envoyer ta facture, si d’ici le temps que tu reçoives les sous tu es obligé de vivre sous le pont ! 

    Ce n’est pas génial. Ce genre d'info te permet de faire les choses le mieux possible. 

    En fonction de mon expérience ou des moments de ma vie, j'ai choisi un statut plutôt qu'un autre. 

    Ils ont tous les deux des avantages et des inconvénients et je pense qu'il faut être assez intelligent pour ne pas forcément s'associer ou associer son identité à l'un des deux. 

    Mais simplement se dire "je suis dans une phase de ma vie ou telle chose m'aiderait beaucoup". Je vais aller vers ça, être un peu plus malléable d'esprit et ne pas s'enfermer dans des boîtes sans raison.  

    Ce que j'aime bien dans ce statut de freelance, c'est la vélocité, et la rapidité de décision que tu peux avoir parce qu'il n'y a personne d'autre à convaincre que toi. 

    C'est quelque chose avec lequel j'ai eu un peu de mal quand j'étais consultant parce que je faisais pas mal de veille. 

    J'aime bien tester des choses.

    Si je tombe sur un outil qui peut me permettre d'aller plus loin ou de faire pareil en moins de temps... Pour moi c'est bon, c'est le budget test ! 

    Si c'est bien, tant mieux, si ce n’est pas bien, j'aurais appris et je partagerai tout ça via un article ou autre. 

  • Lorsque tu es dans une grande structure, il faut convaincre beaucoup de gens. Il faut avancer et être remboursé à long terme. 
  • Alors que là, c'est une autre histoire. Tu tombes sur quelque chose, si t'as bien géré tes fonds, tu as un budget que tu réinvestis dans ton activité ou de la formation. 

    Tu mets la carte et c'est tout ce qu'il faut.

    Là tu viens d'acquérir un nouveau savoir et c'est ce que j'aime le plus. Alors je ne vais pas nier qu'il y a d'autres avantages, bien sûr, mais ça, c'est vraiment la chose que j'aime le plus.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Si vous vous positionnez dans l’UX writing faites vos recherches pour savoir combien vous valez
    Quand j’ai commencé, j'aurais voulu avoir une idée un peu plus précise de ce que sont les salaires dans les équipes UX.  Parce que mon parcours relève de la fac en Langues et pas d'une école donc je n'étais pas préparée aux salaires de designer et je pense que je me suis longtemps sous-vendue.  C'est mon impression ces dernières années mais l'UX s’ouvre de plus en plus à des profils universitaires qui n’ont pas la connaissance des tarifs dans le privé.  En recherche, pas mal de personnes qui arrivent de la sociologie ou de l'anthropologie. L’UX writing, c'est très atypique, il n'y a pas une formation qui y mène et pas de préparation aux attentes salariales.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Acceptez que votre recherche soit instrumentalisée pour trouver du soutien. Mais de la bonne manière

    "Une erreur récurrente à laquelle je suis malheureusement encline à sous-estimer est la dimension politique entourant la recherche utilisateur et l'instrumentalisation des résultats une fois la recherche livrée.

    Par le passé, j'avais tendance à ignorer ces aspects et à ne pas les anticiper, ce qui m'empêchait de mettre en place des actions pour y remédier.

    Récemment, j'ai fait face à un problème lié à la monétisation dans les jeux, un sujet majeur dans l'industrie du jeu vidéo. Initialement, la recherche utilisateur ne portait pas du tout sur ce sujet, ce qui a créé des difficultés alors que certains collègues et moi-même nous battions contre de nombreux obstacles. 

    Heureusement, j'avais des alliés en interne pour me soutenir.

    Normalement, nous testons fréquemment les jeux avant leur sortie. Cependant, dans ce cas précis, nous voulions le tester en amont, avant même d'introduire la dimension monétisation. Malheureusement, j'ai été confrontée à des critiques méthodologiques telles que : 

  • "Pourquoi voulez-vous tester des éléments à vendre alors que le jeu n'est pas encore finalisé ? 
  • Cela va biaiser les résultats, c'est absurde, etc."

    Le problème vient du fait que la recherche utilisateur est distincte de la market research. Il existe donc des silos entre le volet Market Research et la recherche utilisateur. 

    J'ai pensé que la monétisation était à la fois une question de design et une question commerciale. J'ai donc proposé de réunir les deux équipes pour travailler ensemble sur cet objectif de monétisation dans les jeux.

    Mon idée était un peu naïve politiquement parlant. 

    Malheureusement, je me suis heurtée à des obstacles politiques qui ont ralenti mes projets. Certains pensaient fermement que la recherche utilisateur n'avait rien à voir avec le volet commercial et que cela ne faisait pas partie de notre mandat. J'ai rencontré de nombreux blocages et j'ai eu du mal à trouver des interlocuteurs et interlocutrices du volet commercial avec qui développer des méthodologies adéquates. C'était un véritable parcours du combattant pour trouver les bonnes personnes.

    Heureusement, au milieu de cette tempête, j'ai rencontré quelqu'un qui souhaitait avancer sur le projet et qui était également frustré ces aspects politiques. Cette personne m'a fourni les ressources nécessaires pour mettre en place un prototype et tester les éléments monétisables du jeu avant sa sortie.

    Nous avons ainsi démontré que la collaboration entre les équipes apportait une réelle valeur ajoutée.

    Par la suite, lorsque le projet a pris de l'ampleur, nous avons fait preuve d'encore plus d'ambition. Cependant, nous avons encore une fois manqué de soutien hiérarchique en raison des enjeux politiques complexes entourant la monétisation. 

    En tant que chercheur utilisateur, il est difficile de trouver des appuis auprès de mes collègues, car nombreux sont ceux qui ne souhaitent pas intégrer des aspects monétisations dans les jeux. 

  • Les designers sont réticents, ce qui complique davantage la situation. 
  • Les acteurs du volet commercial veulent quant à eux conserver leur part du gâteau.

    Cela a rendu ma tâche plus difficile et j'ai personnellement beaucoup souffert de cette lutte dans la sphère politique. 

    Je ne disposais pas des bons outils, et c'était un peu frustrant. 

    Étant UXR, j'occupe une position relativement basse dans la hiérarchie, et je n'ai pas réussi à établir un réseau solide d'alliés de poids au sein de l'organisation pour m'aider à faire face à ces défis.

    Au fil du temps, j'apprends de plus en plus à anticiper ce genre de situations et à sécuriser l'environnement avant de me lancer dans de grands projets. Ainsi, je peux m'assurer d'avancer avec le moins d'embûches possibles. Pour cela, le dialogue informel interdivisionnel est essentiel. 

  • Il me permet de trouver les bonnes personnes en interne, celles qui peuvent m'aider à réaliser mes projets. 
  • Cela me permet également de mieux comprendre les enjeux politiques en amont grâce à ces discussions. 

    En poussant mes projets avec acharnement, j'ai dû affronter les enjeux politiques au fur et à mesure de leur apparition. (ce qui est ingérable sur le long terme. Il faut anticiper et débloquer avant)

    Finalement, je constate qu'il y a inévitablement une instrumentalisation de la recherche utilisateur, et cela entraîne naturellement des frictions irrationnelles entre les différentes parties prenantes avec lesquelles il faut “ jouer” pour faire bouger les choses.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Mon REX sur l’implémentation et la restructuration de process UX avec SAFe

    Dans ce post, je vais vous parler de ma méthode de travail pour trouver un équilibre entre la méthodologie agile et UX. Je partagerai également les outils que nous utilisons pour gérer nos backlogs et prioriser nos tâches.

    En ce moment, je suis très impliqué dans la mise en place d'un nouveau modèle chez mon client pour établir la manière dont nous travaillons. Cela correspond à du “Dual-Track Agile” ou encore une méthodologie de “Product Discovery / Product Delivery”. On n’est pas très loin non plus d’une méthode Shape Up de Basecamp.

    En gros, nous avons deux axes de fonctionnement parallèles : 

  • La partie implémentation et développement qui fonctionne en mode scrum classique avec des sprints de développement, où nous intervenons pour ajuster les éléments de design et gérer les tests utilisateurs en cours de sprint. 
  • En parallèle, nous travaillons sur la recherche et la découverte, qui ne fonctionne pas en sprint car cela peut prendre du temps variable en fonction des besoins et des activités, parfois une semaine, parfois un mois. 

    Nous utilisons une approche plus classique pour la recherche, en gérant un backlog de découverte et en traitant les priorités à l’aide d’un Kanban. Une fois traités, les sujets de recherche testés et validés sont finalisés sous forme de story et quittent le backlog de découverte pour aller nourrir le backlog de développement.

    Nous intervenons ensuite assez peu dans le flux de développement, uniquement pour les petits ajustements nécessaires en cours de route. 

    Une fois que les éléments sont ancrés, nous gérons les tests et les retours pour nourrir le backlog de découverte. Cela nous permet de travailler sur ces deux modèles en parallèle, avec deux "lignes de production" distinctes sur lesquelles nous travaillons.

    Ce mode de fonctionnement fonctionne plutôt bien pour nous, mais le plus important à retenir c’est qu’aucun framework n’est parfait.

    Il faut souvent adapter un modèle au contexte de l’entreprise et du projet / produit sur lequel on travaille car chaque sujet est différent et les équipes ont une culture et une expérience différentes. Si on ne prend pas en compte ce contexte et qu’on cherche à appliquer une méthode, quelle qu’elle soit, au pied de la lettre, c’est le meilleur moyen de se prendre le mur.

    Auparavant, j'avais tendance à aligner la recherche sur la même cadence que les sprints de développement, mais cela ne faisait que créer une pression inutile. Nous nous retrouvions parfois à la fin des sprints avec des recherches partielles, ce qui n'était pas efficace. 

    Passer à une approche plus classique pour la recherche nous a simplifié la vie et nous a donné une meilleure visibilité sur nos activités. 

    L'équipe de développement a également bien accueilli ce changement, car cela ne perturbe pas trop leurs habitudes de travail, et cela fonctionne donc plutôt bien pour eux. 

    La seule difficulté que nous rencontrons, c'est que nous avons deux backlogs distincts : le backlog de découverte et le backlog de développement. 

    Étant donné que nous travaillons en mode kanban d'un côté et en mode sprint de l'autre, il n'est pas toujours facile de les gérer dans le même outil. 

  • En terme d’outils nous utilisons principalement Google Sheet pour gérer le backlog de découverte, car c'est plus pratique que des outils traditionnels pour établir les priorités avec différents axes de travail. 
  • Pour les ateliers et la priorisation des différents types d'utilisateurs, nous utilisons Miro, car c'est l'outil déployé chez mon client. 
  • Ensuite, nous résumons les résultats dans Google Sheet pour suivre les étapes, déplacer les éléments dans nos backlogs, et réaliser le design. Pour le design, nous utilisons différentes méthodes en fonction des besoins, comme Figma pour les designs plus complexes, ou des Google Sheets ou Google Docs pour les éléments plus structurés, comme les formulaires. Parfois, nous créons également des prototypes pour les faire tester, mais dans le projet actuel sur lequel je travaille, ce n'est pas nécessaire.

    Pour vendre cette nouvelle approche, cela a été plutôt complexe et tendu.

    Le client est en pleine transformation et a mis en place un modèle hybride entre SAFe et le pseudo-modèle Spotify (“pseudo-” car ce modèle n’est pas réellement utilisé chez Spotify), avec des personnes ayant peu d'expérience en agilité, pensant peut-être que certifier les équipes à tout va suffisait à réaliser une transformation Agile... 

    Cependant, ce modèle n'a pas été bien évalué, car ils n'ont même pas encore établi de retour d'expérience sur le MVP avant de le généraliser à d'autres équipes, ce qui est une première erreur. 

    Pour donner un exemple concret de ce qui ne fonctionnait pas, sur un projet en particulier, le coach Agile qui nous accompagnait cherchait à nous imposer ce modèle, car c'était la consigne qu'il avait reçue, même si ce n'était pas du tout pertinent pour le produit sur lequel nous travaillions.

    Heureusement, avec l'aide de la Product Manager (PM) avec qui je travaille depuis presque un an, nous avons pu proposer une orientation différente pour les squads et la structure du projet : Étant donné que notre produit a des sous-produits avec des équipes techniques et métiers différentes, il était important d'avoir des Product Owners (PO) dédiés à chaque sous-produit, ainsi qu'un PO global pour la vision globale du produit. 

    Nous avons donc dû sortir du modèle officiel qui nous était imposé, ce qui a généré quelques discussions sur le choix des termes, mais pour moi, le wording n'était pas un point crucial.

    De plus, étant donné que notre charge de travail allait évoluer au fil du temps, avec des petites et potentiellement grandes évolutions à gérer, nous avons mis en place un système évolutif avec une capacité à scaler facilement. 

  • Nous avons convenu qu'au début, nous aurions un Scrum Master commun pour gérer plusieurs squads
  • À terme, si nous devions multiplier les squads, nous aurions besoin d'un Scrum Master dédié à chaque sous-produit, qui pourrait gérer plusieurs squads, dans une limite de trois maximum. Cela s'explique aussi par le constat que le rôle de Scrum Master n'est pas à temps plein, et qu'il peut être partagé entre plusieurs produits et squads.
  • Cependant, gérer un écart important entre trois squads avec des équipes potentiellement différentes serait difficile à gérer en raison des différences de rythme, de fuseaux horaires et de rituels (notamment pour les daily.)  D’où l’objectif de maintenir une cohérence au sein d'un même produit ou groupe de produits en impliquant les mêmes acteurs dédiés.  Nous avons ainsi synchronisé les moments clés, tels que :  La planification des sprints, en commençant par une planification globale avec le Product Owner (PO) global, puis en se divisant en planifications spécifiques à chaque sous-produit.  De même, pour les rétrospectives, nous commençons par celles de chaque sous-produit avant de remonter au niveau global, afin de toujours garantir une vision transversale.  Les daily stand-ups sont également synchronisées pour maintenir un rythme cohérent.  De plus, si nous avons besoin de lancer des sous-projets, nous appliquons le même principe en adaptant l'échelle de manière appropriée et intelligente, en avançant avec un backlog commun qui se divise ensuite en sous-backlogs par sous-produit, avec une partie dédiée à la découverte et au développement.  Nous avons imposé cette approche, en laissant les équipes discuter des détails de formulation. Au départ, elles étaient réticentes, mais nous avons expliqué que c'était ainsi que nous allions procéder en raison du contexte spécifique du produit.  Pour résumer : Étant donné que les équipes n'étaient pas en mesure de nous proposer une organisation répondant à nos besoins, nous avons pris l'initiative de la créer. Cette organisation correspond à nos besoins actuels, mais nous sommes conscients qu'elle peut nécessiter des ajustements, que nous effectuerons en temps voulu. Nous avons déjà mis en place un modèle adaptable en fonction des KPI’s. Pour plus de rigueur, j'ai également effectué une recherche pour vérifier que cette approche n'était pas uniquement de mon invention, et j'ai trouvé des frameworks similaires, tels que LeSS et LeSS Huge qui correspondent à 95% à ce que nous avons proposé.  Nous avons ainsi pu légitimer notre approche en nous appuyant sur ces références externes.  En appliquant ces principes, nous avons un PO global et des area PO pour chaque zone et sous-produit, avec des domaines de besoins spécifiques.  Cette approche a permis de faciliter l'adhésion des équipes à la stratégie. En effet, nous avions constaté que l es équipes partaient souvent trop rapidement dans la définition du produit sans prendre en compte la stratégie produit et la roadmap.  Même si cela ne correspond pas entièrement à notre modèle actuel, nous estimons que c'est la meilleure approche pour notre équipe et cela nous permet de mieux remonter les besoins des utilisateurs.  Il est également important de noter que les recherches que nous effectuons ne se limitent pas uniquement aux aspects digitaux. En effet, dans notre entreprise, nous ne demandons pas aux équipes de remonter les problèmes liés uniquement au digital. Même si certains aspects ne sont pas digitaux, il est important de les reconnaître, car ils peuvent être transmis aux équipes responsables des processus, des ressources humaines, des infrastructures, de la communication, etc. De ce fait, la phase de recherche, bien qu’officiellement liée à un produit, a une portée plus transverse et nous remontons régulièrement des sujets à d’autres équipes produits (ou même des équipes ne fonctionnant pas sur ce type de modèles). Notre objectif est de travailler de manière globale, holistique et systémique avec toutes les entités, sans se limiter à notre domaine digital. En effet, cette approche va à l'encontre des objectifs mêmes de la transformation.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Bien préparer son atelier pour gagner en efficacité et sérénité

    Quelques astuces et écueils à éviter

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

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

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

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • La logistique et le matériel, le pain point de tout UX researcher.

    La logistique et le matériel sont souvent des éléments sous-estimés dans l’organisation d’une session de recherche, en particulier lorsque l’on débute. Et c’est d’ailleurs un des feedbacks que j’ai le plus de la part d’étudiants ou débutants, après l’organisation d’une première séance de tests.

    Le pré-test du matériel est essentiel, surtout si on utilise du matériel pour la séance (prototype, eye-tracking, caméras…). Il y a une fois où j'ai mené des tests utilisateurs et on n’avait pas vérifié le matériel en amont, la caméra ne fonctionnait pas et on n'a pas pu filmer la matinée de tests.

    Une situation comme ça fait perdre du temps de test, sans compter le stress que ça amène le jour J !

    Il y a aussi toutes ces fois où l’on n’a pas assez testé le prototype, ou alors on a rajouté des choses en dernière minute sans tester. Un prototype ou un bout de prototype cassé, et tu peux perdre 5 ou 10 minutes de ton test, ce qui est énorme sur une session d’1h au final.

    Une autre erreur réalisée était cette fois sur la partie logistique de la session de recherche. Pour cette étude, c’est mon client qui s’était occupé d’organiser les rendez-vous, par soucis de facilité car nos utilisateurs étaient des employés de l’entreprise. 

    Nous ne l’avions pas briefé sur le comment organiser des sessions de recherche, et notamment qu’il fallait prévoir un temps de pause entre chaque session. Et le quart d’heure minimum entre deux interviews ou deux sessions de tests, il est nécessaire !

    Nous nous sommes donc retrouvés avec 4h d’interviews programmées à la suite, sans coupure, et chaque rendez-vous était dans une salle et à un étage différent du bâtiment. Nous avons couru entre chaque séance, et ce n’est pas du tout confortable, ni pour nous, ni pour la personne interviewée. 

    Sans temps de battement entre deux rendez-vous, tu n’as pas de marge de manœuvre possible pour gérer les imprévus, les retards, t’installer pour accueillir la personne d’après, et switcher mentalement d’un participant à un autre pour commencer ta session de research “à neuf”. 

    Je pense qu'on ne se rend pas assez compte quand on n’est pas user researcher ou quand on n’a jamais fait de recherche, à quel point la logistique est importante et chronophage.

    C’est quelque chose également que je souligne beaucoup quand on parle à des débutants, de ne pas négliger cet aspect qui prend quand même assez de temps de préparation parce que mener des séances de recherche c’est un exercice qui prend beaucoup d’énergie, qui demande de la concentration et qui peut être stressant, surtout quand on démarre. 

    Si on peut éviter du stress logistique en plus du stress de mener la recherche, on gagne en sérénité. Donc vraiment préparer et anticiper au maximum, et faire des checklists c’est le secret de la logistique en user research.

    • 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
  • L’illusion des raccourcis

    Il fut un temps où j'avais tendance à adopter un comportement qui finissait par me décevoir. J'avoue être parfois un peu flemmard. Bien que j'aime fournir les efforts nécessaires, il m'arrive parfois de chercher des raccourcis.

    Quand j'étais plus jeune, j'espérais trouver des astuces pour simplifier certaines choses. Je pensais qu'il y avait des raccourcis pour atteindre mes objectifs. Cela était étroitement lié à l'idée de patience. Mais j'ai rapidement appris à mes dépens qu'il n'y a pas de raccourcis.

    Parfois, il en existe, mais généralement, ils ont un coût caché. Ce coût n'est pas immédiatement perceptible.

    Au final, ce que tu penses économiser en termes d'efforts se transforme souvent en leçons que tu apprends plus tard. Tu réalises que ces efforts étaient nécessaires pour réellement avancer. Je ne veux pas être dogmatique, mais je pense qu'il y a une vertu dans les efforts que nécessitent certaines choses.

    Au début de ma carrière, je souhaitais avoir plus de responsabilités que ce qui m'était confié, car je pensais que c'était le seul moyen de faire ce que je voulais réellement faire.

    J'avais cette idée idéale selon laquelle si j'avais le pouvoir de décision, qui était lié à la responsabilité, je pourrais réaliser mes aspirations. Cependant, il est biaisé de penser que la responsabilité entraîne automatiquement le pouvoir de décision.

    Ce n'est pas toujours le cas. J'étais en quête de ce pouvoir de décision à travers la responsabilité. Cette impatience m'a poussé à parfois aller trop vite. À cette époque, je n'étais pas encore orienté vers la conception d'interfaces ou de solutions numériques, mais plutôt vers la conception de produits physiques et l'architecture. J'espérais pouvoir travailler rapidement sur des projets qui m'intéressaient, alors j'ai accepté de collaborer avec des personnes dans l'espoir d'acquérir cette capacité de prendre des décisions qui m'intéressaient.

    Finalement, cette volonté d'aller trop vite m'a mis en relation avec des personnes qui, rétrospectivement, n'étaient pas les plus fiables. Ce n'étaient pas des individus recommandables avec qui travailler.

    Ils avaient l'expérience de lancer de nombreux projets et initiatives pour collecter des fonds, mais ils ne parvenaient jamais à les concrétiser. Cela m'a placé dans des situations problématiques. Lorsque tu es jeune et étudiant, tu peux t'en sortir. Mais lorsque tu commences à te poser, à être en couple et à réfléchir à l'avenir, tu ne veux plus vivre ce genre de situations. Cela change ta perspective.

    Pendant de nombreuses années, j'ai également dirigé une agence de communication où j'acceptais des clients car leurs projets semblaient faciles à réaliser. Cependant, ces clients ne savaient pas toujours ce qu'ils voulaient, ce qui aboutissait à de nombreux allers-retours et à une course après les paiements.

    À ce moment-là, tu te demandes si tout cela en vaut réellement la peine. Qu'est-ce que cela t'a apporté ? Plus de problèmes que d'avantages, malheureusement.

    Finalement, tu apprends. Tu te rends compte que ce genre de situation n'est pas une bonne stratégie. Je vois maintenant que cette recherche de facilité, parfois associée à l'idée de prendre des décisions, s'est retournée contre moi.

    J'observe également cette erreur chez d'autres personnes plus jeunes dans la profession avec qui je discute. Je ressens l'impression qu'ils doivent faire ces erreurs eux-mêmes pour en tirer des enseignements réels. On peut dire ce que l'on veut, mais j'ai également reçu les mêmes avertissements et conseils. Malgré cela, j'ai agi selon ma propre vision. J'ai subi les conséquences nécessaires pour apprendre.

    Est-ce si grave que ça ? Parfois, cela peut être grave lorsque cela te met réellement dans une mauvaise situation. Je dirais que c'est dommage. Si c'est évitable, c'est vraiment regrettable. D'une certaine manière, tu apprends. Parfois, tu dois faire tes propres expériences pour comprendre ce qu'il faut faire et ne pas faire.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Superbe deck sur ce qui tue la recherche en interne et ce qui la rend "Killer".
    Dans son deck l'auteur explique 4 erreurs à éviter et 4 astuces pour rendre votre research meilleure avec un jeu de mot en "Killing research" et "Killer research" wikihero-image-id: 1063 Lien du deck. Lien du post Linkedin et comments
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment définir le niveau de gamification où vous voulez aller ?
    Pour définir le niveau “juste” de gamification, on essaye de mixer différentes approches.  Soit on va faire des entretiens avec les utilisateurs et on pose quand même des questions sur tout ce qui est motivation, afin de le connecter avec une grille de lecture des leviers d’engagement. Même si ce n'est pas parfait, ça permet d'avoir une première lecture quand on fait les persona, puisque du coup, on les refait en général pendant le sprint (souvent, c’est un peu hors sol même si, nos clients ne sont pas les plus éloignés par rapport aux utilisateurs.)  Puis, on a effectivement la possibilité de faire des questionnaires. Notamment notre questionnaire sur les 9 leviers d’engagements. On a travaillé avec un doctorant en gamification pour affiner le questionnaire, voir un peu des tendances, etc. Normalement, on aura une publication scientifique sur le questionnaire. C’est une publication qui présentera un peu comment on l'a conçu et quels sont les résultats qu'on en tire.
    Ensuite, on mixe un peu ces différents résultats et on essaye de les confronter aux utilisateurs (que ce soit dans le sprint via des tests de prototypes, que ce soit via de la recherche utilisateur, avec des entretiens ou des questionnaires, ou que ce soit avec des tests plus poussés avec un prototype plus qualitatif, tout dépend du projet et de ses enjeux). Quelque chose que je rappelle souvent c’est que :  Le niveau de gamification qui est optimal, ce n'est pas mettre le plus de gamification possible.  Même sur des leviers d'engagement, ce n’est pas mettre le plus de tels leviers d'engagement possible, mais il faut trouver justement l'équilibre qui va par rapport à tes utilisateurs.  Je regarde souvent ce qui se passe dans le monde des jeux qui fonctionnent sur le marché. Il y en a beaucoup qui fonctionnent avec des lootBox (quand tu obtiens une récompense, tu ne sais pas laquelle tu vas avoir.) C’est plutôt une boîte surprise. Et c'est assez utile pour générer de l'engagement.  C'est-à-dire qu'au lieu d'avoir les joueurs qui disent :  “Il faut trois boîtes pour avoir la récompense que je veux, là potentiellement, ce sera une, ce sera dix, ce sera cent.”  On ne sait pas.  C’est un truc qui génère quand même de l’engagement dans la durée pour les jeux et ça reste assez efficace. En tant qu’observateur tu pourrais dire que ça fonctionne bien. Et si on pousse plus loin le concept? Si les gens aiment bien cet effet de surprise aléatoire, il n’y a plus qu'à y aller à fond. C'est ce qu'a fait un jeu qui s'appelle Magic Legend.  En termes de gameplay, c'est un peu comme Diablo, et ça se passe dans l'univers des cartes Magic avec un mix de licence assez sympa du jeu, sauf qu’en fait les concepteurs se disent : “ Comment on fait pour gagner le maximum d'argent? “ Ils vont y mettre toutes les techniques un peu sales pour gagner de l'argent, notamment dans des LootBox. Ils ont poussé le truc tellement loin, avec tellement d’éléments aléatoires et peu de chances de gagner ce que tu voulais, qu’au final, je crois que 2 ou 3 mois plus tard, ils ont annoncé qu’ils arrêtaient le jeu et qu’ils allaient devoir rembourser les achats, parce qu’en fait ça sentait trop l’arnaque pour les joueurs et donc personne ne jouait. Les utilisateurs se disent : “ Ce n’est pas ça qu'on veut.”  Je pense souvent que c'est un peu ça la question : “Un peu d’aléatoire, c'est cool. Trop, ce n’est pas cool.”  Du coup, la question, c'est à quel niveau c'est OK ? Eh ben ça dépend de l’utilisateur pour chacun de ces éléments de gamification, il faut choisir le bon niveau.  – Et c’est là que la base de connaissance méthodologique est clé. (comme notre méthode Fidbak où on s’intéresse aux utilisateurs, qu’on prévoit des tests, etc.) Je donne un exemple:. Hier, je faisais une formation pour des formateurs sur comment travailler la gamification.  Parmi les gens qui sont venus, il y en a plein qui s’attendaient du coup à ce qu’ils découvrent une boîte à outils de jeu: Avoir tel levier d’engagement pour telle situation Mais non, ce n’est pas comme ça que ça fonctionne. Lors de la formation je leur ai expliqué que justement que l’on ne va pas parler de jeu. On va parler de gamification, mais pas directement de jeu. C'est typiquement le genre de personnes qui, généralement, va avoir beaucoup de mal à se poser sur ces questions d'objectifs, de persona, etc.  Dans ce que j’observe c’est le genre de personnes qui veulent juste vouloir avoir son jeu.  Par exemple, je les choque lorsque je dois leur dire “Il y a des gens qui aiment bien jouer en ayant de la compétition, et d'autres qui n’aiment pas.”  Parce que jusqu'à maintenant ce qu’ils connaissaient dans les jeux, c’était la compétition.  Mais si dans certains jeux il y a de la compétition, il y a plein d’autres qui n’en n’ont pas.  Pour nous, c'est important de recadrer un peu ces éléments de méthode et de problèmes. Ensuite, on fait assez souvent bouger la méthode qu'on travaille pour les clients parce que justement, il y a besoin de l’adapter à différents types de contraintes.  On a l'impression que c'est linéaire, mais en réalité c’est complètement itératif, on passe notre temps à évoluer sur plein de points différents, à faire des tests, etc.  Ce sont des choses que les gens ont un peu plus de mal à appréhender.  Pour l'instant, on est plutôt contents de notre méthodo « sprint », mais on continue d'affiner un peu ce que ça ne fait pas si longtemps que ça qu’on fait des sprints sur la gamification et qu’on rencontre toujours des cas particuliers. C’est aussi ça qui rend le sujet aussi passionnant.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Utilisez les ateliers pour forcer la communication avec clients (internes/externes)

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

    La situation de départ était assez positive:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Poussez à l’embauche de collègue dans vos équipes. N’essayez pas de tenir la baraque seul.e
    Une erreur que j’ai faite c'est de ne pas pousser à l'embauche. Que ce soit en tant que manager ou en tant que designer. En début de carrière il m’est souvent arrivé de ne pas pousser à l'embauche de plus de designers. Spécialement lorsque j'étais la première designer d'une startup.   Je pensais que proposer cela était une marque de faiblesse. En réalité, c’est tout l’inverse !  Je pensais que c’était l'opportunité de montrer que j'étais capable de prendre sous ma responsabilité plus de projets, de faire encore plus. Et c’était surtout, il faut l’admettre, une manière de rester dans le contrôle.  Je m’explique : Lorsque l’on est tout seul, on arrive à gérer son rythme, son emploi du temps jusqu’à être sous l’eau. Et ce n’est qu’à ce moment-là que l’entreprise prend la décision d’embaucher.  Entre le temps de l’annonce et l’embauche (il faut en moyenne 3-6 mois) c’est déjà trop tard en terme de charge de travail. Tu prends la surcharge entre temps, tu grinces des dents en espérant que cela s’améliore.  Le conseil que je donnerai, (et que dorénavant je m'applique à moi-même)... c'est d'embaucher avant d'en avoir besoin.  Pour cela, je track le temps passé sur les différents projets que j’entreprends et lorsque je commence à me rapprocher de 100% de mon temps sur des sujets sans avoir la possibilité de dégager plus de temps pour d’autres activités comme la recherche exploratoire, je me dis  "Il faut que tu embauches ! " .  Ou il faut que je pousse à l'embauche, en disant qu'il nous faut un collaborateur de plus sur tel ou tel sujet et surtout d'expliquer pourquoi ! Il faut bien expliquer pourquoi tu as besoin de quelqu'un, et non pas juste signifier un besoin.  Sinon, on peut se demander : Pourquoi tu n'as plus le temps ? Comment tu rationalises ce temps ?  Quel est ton ratio sur chaque projet ? Quel impact positif cela peut-il avoir sur la boite ?  C'est la meilleure manière de s'aider soi-même et d'aider la boite. Pour “comptabiliser” le temps, ce que je fais, c 'est que je me donne des ratios de temps que je devrais passer sur certaines activités afin d’assurer une qualité de projet finale.  Par exemple, la research est un élément hyper important pour moi, mais que je vais avoir tendance à déprioriser parce qu'il faut livrer tel ou tel projet...  Je me suis toujours dit:   " Il me faut 20% de mon temps, en research” (et c'est beaucoup 20%...) Quand je n'arrivais pas à atteindre ce quota, j'en constatais les impacts en interne. On n'arrivait pas à comprendre cette problématique On n'arrivait pas à valider cette hypothèse On pourrait aller plus vite sur cette fonctionnalité-là etc.  Lorsque tu décortiques tes activités en % de ton temps et tu lie ça aux résultats que cela produites personnes comprennent naturellement pourquoi tu as besoin de plus de gens et sur quels sujets.
    • 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
  • Erreur: Dire que le design c’est la chasse gardée du designer.

    Une grosse erreur que j’ai aussi faîte, c’était il y a 6 ans chez Ooreka où il y avait un beau projet et j'avais encore ce truc de :

    “C’est moi qui suis en lead design, je sais ce qui doit être fait point de vue design.”

    On a vachement parlé sur le projet avec les PO, les PM, on était chauds. 

    Il y avait des personnes qui étaient essentielles dans le projet. Les rédacteurs, parce que Ooreka c’était majoritairement de la rédaction. (Le site maintenant il est mort. Il est encore là, mais en fait, il n’y a plus l’équipe qui bosse dessus, il n’y a quasiment plus personne. Ils laissent vivre le contenu. Mais c’était un très beau projet à l’époque.)

    Mon erreur ça a été de penser que le design n’était que l’affaire du designer et ne pas voir cet aspect, d’idéation et de collaboration. 

    C’était de dire : “Je suis designer, c’est mon affaire à moi. (le PO à la limite.) Vous vous êtes rédacteurs et votre tâche c’est de faire de la rédaction. “

    Je n’ai jamais mis en place cet aspect de :

    “On co-construit ensemble, les rédacteurs sont des designers, eux aussi ils ont leurs trucs à donner.” 

    On a trop poussé une version, dont nous étions super contents et il y a eu des clashs avec les rédacteurs. 

    On conservait un peu notre position un peu hautaine, dédaigneuse, tout le temps :

    “Rédigez quoi, vous êtes rédacteurs.” 

    En retour ils me disaient :

    “C’est pas comme ça que ça doit être fait.” 

    Et on a fait la sourde oreille. 

    Finalement, tout cela m’a ouvert les yeux et cet aspect de collaboration, de co-conception maintenant c’est essentiel. 

    Il faut vraiment mettre tout le monde à fond. Notre taff, c’est de demander toutes les idées et de prendre celles qui sont bonnes, d’un point de vue ergonomie, d’un point de vue design, et pas faire du consensus, mais arriver à amplifier la richesse de toutes les propositions et des besoins de chacun en un design qui surpasse les attentes.  Ne pas se dire que le designer c’est notre affaire à nous le design.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur: Aller bosser dans des boites pour une mauvaise raison.

    Par exemple, une erreur parcours que j’ai réalisé c’est lorsque que j’ai commencé dans une boîte et après je me suis dis:

    “Merde, je n’ai rien à faire là” 

    Je suis allé bosser dans des boîtes sur des projets qui finalement ne me ressemblaient pas du tout. 

    J’y suis allé parce que j’étais attiré par le poste ou par le salaire, et finalement une fois dedans, le projet en lui-même ne me bottait pas plus que ça. 

    L’ambiance ne me bottait pas tant que ça. Il y a des trucs que je ne peux pas découvrir juste avant les entretiens. Mais tu vois, rien que le projet, je savais que ça ne le faisait pas. 

    Du coup, un des trucs c’est ne pas aller quelque part pour le salaire ou l’intitulé du poste. L’important c’est le projet et l’équipe. C’est pour eux que tu te lèves tous les matins, si ca ne va pas avec l’un ou l’autre alors le travail ne sera pas plaisant. 

    Donc l’apprentissage que j’ai de cette expérience c’est de prendre du temps pour se faire sa feuille de route personnelle, et de prendre du temps pour se faire un persona de soi-même (par exemple ). 

  • Pour savoir qu’est-ce que j’aime ?  
  • Qu’est-ce que je veux faire, quels sont les trucs sur lesquels je ne veux pas bosser ?
  • Quels sont les trucs sur lesquels je veux bosser ? Qu’est-ce qui me rend heureux dans mon travail ? 
  • Quels sont les trucs qui me rendent heureux dans mon travail ? 
  • Quels sont les trucs qui me passionnent, qui me motivent au sujet de mon boulot, et au contraire, quels sont les trucs que j’ai envie d’essayer ? 

    Prendre du temps régulièrement aussi pour se dire : 

  • Dans mes expériences passées, quels sont les moments qui me restent émotionnellement comme saillants, les plus agréables ? 
  • Au contraire les moments saillants qui étaient désagréables ?

    Par exemple : 

    “Sur les X années qui sont passées, ça, je ne veux plus jamais le vivre. “

    Ce type de situation, je ne veux plus y être, ce type de projet, ce type de futur. 

    Au fur et à mesure, donc au début forcément c’est compliqué de le faire au début quand on est junior on peut se dire ouais, voilà le genre de choses vers lequel je veux aller, et voilà le genre de choses que je ne veux pas aller, et au fur et à mesure on commence à se dire voilà les choses que j’ai aimées et les choses que je n’ai pas aimées. 

    Je pense que c’est essentiel, au fur et à mesure de se dresser sa cartographie, comment est-ce qu’on veut évoluer dans cette carrière. 

    Par exemple quels sont les boulots sur lesquels on doit aller, où on ne doit pas aller. 

    Au moins ça, ça permet de sentir à un moment qu’en tant que free, on est surexposé à ça parce qu’avec toutes les missions qui nous arrivent, les propositions et tout, il y a des moments où tu sens le truc. 

    Tu te renseignes un peu sur la boîte, tu as un premier entretien, tu sens qu’il y a un truc qui ne passe pas. Tu te dis, “ Je ne peux pas y aller.” 

    Mais si on n’a pas fait ce taff de profiling avant, je trouve que c’est beaucoup plus compliqué à sentir. 

    Donc quand tu as tout le profiling qui a été fait, que tu as posé plusieurs fois ces questions tout le long de ta carrière, au bout d’un moment, les projets arrivent, tu les vois et assez rapidement tu te dis : 

    “Ouais, ça, c’est un projet pour moi.” 

    Tu le sens, il y a cette valeur, cette valeur, que je retrouve par rapport à cette proposition-là que j’avais avant. 

    Ou alors tu te dis : 

    “Ça, ce n’est pas pour moi. Il y a des designers qui se plairont dans ce type d’ambiance, dans ce type de projet, ben je leur laisse. “

    Surtout, ne pas avoir peur justement de dire non à des projets, et même à des postes. 

    Si quelqu’un cherche vraiment une boîte, ne pas forcément sauter sur le premier truc, ne pas avoir peur de dire non parce que plus tard, quand on a de la chance, on nous proposera vachement de taff. 

    Donc si au début tu te dis : 

    “Il faut vraiment que je saute sur un truc” peut-être qu’il vaille mieux de dire non pour attendre ce qui arrive derrière.

    Dans la même veine, une dernière chose que je voudrais préciser: il ne faut pas avoir peur de partir d’un projet / boite.

    J’ai vu des gens extrêmement doués, des ergo qui étaient géniaux en termes de communication et de compétences partir en burn out, ou vivre avec le syndrome de l’imposteur au point que ça en détruise leur vie.

    Tout ça pour une peur de partir de l’entreprise, alors que les signaux étaient là.

  • Manque de culture design
  • Le travail n’est pas pris en compte
  • Ça se passait mal avec leur manager

    Donc si cela vous arrive, n’hésitez pas à partir, vous retrouverez un meilleur endroit.

    • merci! Utile
    • Pas utile
    • Pas sûr
  • L’importance de la sensibilisation à l’accessibilité dans l’industrie du luxe

    Il y a eu plein de problématiques, mais je crois que ça a été pour moi l’un des plus beaux défis, et surtout de réussir à le relever, à faire en sorte que tout le monde soit content à la fin.

    C’était pour un gros site vitrine, qui présentait la marque.

    Pour présenter la marque, il fallait forcément quelque chose de très qualitatif, luxueux, avec – je déteste ça mais pour le coup, c’était exactement la demande - créer un effet « Waouh ».

    Ils étaient vraiment dans ce truc-là. Il fallait un site très beau, très épuré. Ils étaient typiquement dans le fameux “texte gris clair sur blanc” que beaucoup trouvaient très élégant mais qui est illisible. 

    On a réussi, on a répondu à leurs demandes en étant accessibles ! Finir par y arriver, rien que ça, c’est déjà super gratifiant. 

    Ce que j'adore sur des projets comme ça, c’est qu’il y a des défis. C’est beaucoup plus intéressant. Plutôt que des projets où il n’y a pas de débats, donc pas défi, sans grosse recherche de solution derrière.

    J’aime bien devoir dénouer, identifier comment on va faire pour correspondre à tous les besoins, c’est plus intéressant.

    Pour le coup, je pense que c'est avec ce projet-là justement que j'ai appris la nécessité de sensibiliser et de former.  Au départ, il était difficile de trouver comment aborder les équipes. Il a donc fallu que je trouve des moyens pour pouvoir discuter avec eux, en faisant en sorte que la discussion soit agréable et constructive. Ce projet-là m’a permis d’évoluer dans ma façon de faire. Avec eux, je testais des choses que je n’avais pas trop faites avant. Il y a certains trucs qui n’ont pas marché. Par exemple, j'avais eu l'idée de partir dans un atelier audit et co-conception – je n'avais pas fait de sensibilisation et de formation au préalable, rien. Sauf que, quand les gens ne sont pas formés aux sujets, c’est compliqué de travailler dessus. Il faut savoir que la plupart des gens n’aiment pas faire de l’audit. Déjà, je partais sur un truc pas hyper glamour, sur un sujet, l’accessibilité, qu’ils ne connaissaient pas et sur lequel ils avaient des à prioris. Et en plus, ils auditent eux-mêmes, ils voient qu’ils ont fait des erreurs mais ils ne comprennent pas trop pourquoi c’est une erreur parce qu’ils n’ont pas été formés, pour eux c’est la bonne manière de faire. Bref, en tant que consultante, ça, c’est typiquement une erreur. Avant de lancer ce type d’ateliers, il y a des choses à faire pour que ça se passe bien.                               Ça m’a pris un peu de temps pour le comprendre mais je pense qu’il faut le prévoir, ce temps en amont. Aussi, ce que je ne faisais pas forcément, et c’est la deuxième erreur que je faisais et que je veux rectifier : Prendre le temps Qu’il va y avoir justement de discussion et d’appropriation des équipes. Quand on arrive avec un nouveau sujet, un sujet que les équipes ne connaissent pas, on ne peut pas se dire qu’on va tout révolutionner en une semaine. Il est important de faire comprendre aux équipes ; ne pas débarquer avec les référentiels, par exemple ; en tout cas moi c’est ma manière de faire. Je ne débarque pas avec les WCAG ou les RGAA , qui peuvent paraître être l’Everest. Quand on ne connaît pas, c’est hyper abstrait. Souvent à la fin des formations que j’anime et où l’on a vu plein de choses à faire autour du numérique responsable, je fais un petit atelier : je leur demande « On a vu tous ces critères, chacun si vous en retenez 3 à appliquer dès le demain, vous prenez quoi ? » Chacun sélectionne, et en fait, que je leur propose de mettre en place dans leurs prochains projets et 1 mois, 2 mois plus tard etc je leur demande d’en prendre 3 de plus. Avec cette méthode-là, on sait qu’on ne va pas changer le monde. En revanche, on sait qu’au fur et à mesure, les équipes vont prendre en compte les choses, ça va entrer dans leur process, ça va devenir automatique et ça va se retrouver dans tous les projets après. Finalement, l’impact sera beaucoup plus important, parce que ce ne sera pas juste sur un projet donné mais sur tous projets futurs. On aura pu faire en sorte que chacun s'approprie ces sujets. C’est ce qu’on dit souvent en tant que consultant : « le jour où on n’aura plus besoin de nous, ce sera le rêve ». On en est loin, mais c’est la meilleure des perspectives.

    • 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
  • Une erreur que j'ai faite: Être trop dans les cases qui m'étaient imposées.

    Un conseil que j’aurais voulu avoir plus tôt serait de me faire un peu plus confiance et de plus suivre mon instinct au lieu de vouloir rentrer à tout prix dans des petites cases, certes, elles peuvent être très rassurantes, mais au final elles peuvent aussi freiner nos envies. 

    Un exemple : je suis en situation de handicap, je suis malvoyante. Tout le long de ma scolarité, j’ai entendu quelques profs et certains médecins (heureusement ce n’était pas du tout la majorité) dire :

  • « Tu ne pourras pas avoir un métier normal. Ce n’est pas possible. ».  
  • En CP, on me disait « Pour dépasser le CM2, ça va être compliqué. ». 
  • En Sixième, « Pour dépasser la Troisième, ça va être compliqué », 
  • Etc …

    Pour l’anecdote, finalement j’ai fait un Master.


    À force d’entendre ça, j’avais intégré le fait que ce serait difficile pour moi, que la seule voie viable était d’être salariée en CDI, que je n’aurai jamais un métier stable et que si une entreprise me proposait miraculeusement un CDI, il fallait que je l’accepte sans me poser de question : le CDI c’était mon Graal. Au fond, je suis entré dans ces petites cases en acceptant des postes stables et en sécurité mais je me suis éloignée de ce que je voulais faire.

    Surtout dans un poste en particulier, les missions étaient correctes mais l’entreprise en elle-même, ses valeurs, ses façons de travailler... ne me correspondaient pas. Je l’ai senti dès le premier jour.

  • Si je m’étais vraiment écouté, jamais je ne serai restée dans cette entreprise.
  • Se laisser un peu plus guider par son instinct, c’est aujourd’hui pour moi plus logique.

    J’ai commencé à m’interroger sur ces questions à l'issue de mon Master, je voyais tout le monde partir dans plein de voies différentes que je n’avais même jamais envisagées possible pour moi. J’ai alors commencé à me dire : « Être indépendante, ça peut être sympa aussi », mais j’avais peur, je me répétais « Jamais tu vas y arriver, jamais tu ne vas trouver des clients » Et puis le déclic c’est fait alors que j’étais en CDI, donc en sécurité mais dans cette entreprise où je ne m'épanouissais pas. Des boîtes et des écoles m’ont contacté pour me demander : « Par hasard, tu n’aurais pas un statut Free ? On a besoin de quelqu'un pour animer des formations ». Au fur et à mesure, j’ai eu plus de demandes alors que j’étais toujours en CDI. J’ai fini par me dire : « Pourquoi ne pas me lancer ? ». J’ai sauté le pas et finalement, c’est la meilleure décision que j'ai prise de ma vie pro !

    • 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
  • La contrainte technique : Erreur à éviter en travaillant avec les développeurs
    Pour moi, la plus grosse erreur que je vois, c'est de ne pas demander quelles sont les contraintes techniques au développeur avant de commencer à maquetter.  C'est un indispensable parce que si le développeur utilise PrimeNG, il a forcément des librairies de composants derrière et donc si on fait un bouton arrondi et que dans sa librairie le bouton est rectangulaire, il va juste perdre du temps à customiser le bouton. C'est ce qui est hyper important d'après moi.  C'est limite LA première question que je pose quand je rentre sur un projet :  "Ok ! quelles sont les contraintes techniques ?  Quel est le langage de programmation ?" Encore une fois, c'est hyper important. Déjà pour montrer qu'on respecte le développeur et qu'on veut parler le même langage que lui. Je n'y connais pas grand-chose en développement, j'en ai fait pendant ma formation mais je n’aime pas ça. Il y en a qui sont très doués pour ça. Mais le fait d'avoir fait un peu de développement, j'ai ce recul pour me dire "Attends ! Quelle est la contrainte du développeur ?".  Récemment, j’ai mis en place des UI kits que je donne au développeur. Ça lui permet de commencer à coder ses composants le temps que je finisse de créer les maquettes. Une fois qu'il a tous ses composants développés, il a juste à prendre le code et le copier-coller, cela va beaucoup plus vite. Après, au niveau design si demain je quitte le projet pour une raison X ou Y le UI kit est toujours là ! Il peut vivre ! Il peut continuer à être développé, il peut être customisé, modifié...  Donc ça va se répercuter sur les maquettes de manière très rapide. Finalement ça nous permet d'avoir une boîte de "legos" et de concevoir de plus en plus rapidement. On perd sans doute du temps au début. A ce moment-là, j'explique au client qu'on va prendre une demi-journée pour ça, mais que c'est quelque chose qu'on va alimenter au fur et à mesure. Ce temps passé, tu le gagnes à la fin. Tu as tes composants déjà prêts, forcément ça va beaucoup plus vite que de dessiner à la main.
    • 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

    • Commentaires

    Groupes

    Hashtags

    Groupes