chargement des résultats
Wikihero Bêta
Inscription Connexion
Inscription Connexion
Trois lettres minimum pour effectuer une recherche
108 résultats
Selection
  • #collaboration 87
EN LIEN AVEC VOTRE SÉLECTION
  • 87
  • 28
  • 26
  • 18
  • 16
  • 16
  • 10
  • 10
  • 8
  • 7
  • 7
  • 6
  • 6
  • 6
  • 5
  • 5
  • 5
  • 4
  • 4
  • 4
  • 3
  • 3
  • 3
  • 3
  • 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

Postes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Inspirez vous des design reviews et créez des research review

    Ce qui manque actuellement et ce que j'aimerais voir se développer, c'est une culture de challenge entre les chercheurs, similaire à celle des designers.

    Les chercheurs sont souvent un peu solitaires. 

    Il y a UN chercheur et DES designers. Du coup nous commençons à mettre cela en place en interne, avec les différentes équipes UX dans les différents pays. 

    Nous organisons des moments dédiés où nous discutons d'outils et de méthodes.

    Tout comme il y a des revues de design, nous mettons en place des revues de recherche où nous pouvons présenter nos sujets de recherche aux autres. 

    Il m'arrive encore aujourd'hui de mettre un mois, voire un mois et demi, avant de bien comprendre certains sujets sur lesquels je travaille. 

  • Au départ, je ne comprends pas ce que le PM me demande, il n'y a pas de maquettes, pas de contexte sur le projet. 
  • Je tourne en rond, et finalement, tout se débloque lorsque je demande l'avis d'un collègue qui jette un regard extérieur sur le sujet. 

    C'est là que tout devient clair :

    "Ah, en fait, tu pourrais le faire comme ça." 

    Dans certaines entreprises l'écosystème peut être très complexe, avec de nombreux services différents, et cela peut être nébuleux. 

    Nous nous efforçons de créer des workflows pour guider nos démarches. Ainsi, lorsqu'il s'agit de mener une discovery, nous savons comment procéder, et lorsque nous réalisons des tests, nous avons une méthodologie à suivre.

    C'est pourquoi il est essentiel d'avoir des modèles prédéfinis pour nous aider à structurer et à standardiser notre travail, et les research reviews en font parties.

  • merci! Utile
  • Pas utile
  • Pas sûr
  • 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.

    • Anonyme · Research ops · il y a 1 an
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Collaboration UX - PM, jusqu'à où aller avec l'évangélisme ?
    Comme vous l'avez pu expérimenter tous sans doute, la maturité UX n'est pas pareille dans toutes les organisations, ni parmi les product managers d'une même organisation. Faire de l'UX c'est aussi choisir ses batailles et parfois vivre avec un cadre assez restraint. Bien qu'on est là pour mettre en question le scope de ce qui nous est demandé, jusqu'à où méner la bataille ? Je parle des cas où toute la feature a été pensée et budgettée, "il faut juste un petit design" pour passer en dev. Comment faire si on est mené à faire de la pédogagie en permanence, et comment savoir que c'est le moment d'arrêter la lutte ? (Question un peu réthorique mais un partage d'expériences m'intéresserait !)
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • REX restructurer une équipe et bien la positionner en interne.
    J'ai commencé à diriger des équipes à la fin des années 90, et si je devais donner un conseil à un nouveau manager, ce serait de lire le livre intitulé "First 90 Days". Ce livre vous aidera à établir le cadre nécessaire pour gérer une équipe, car il existe une différence entre le leadership et la gestion. 

    Un leader est celui qui dit : 

    "J'ai une échelle, nous allons grimper un mur et nous devons placer l'échelle à cet endroit précis car c'est le meilleur endroit." 

    Le gestionnaire, quant à lui, veillera à ce que tout le monde monte dans l'échelle au bon moment et dans le bon ordre.

    Une expérience marquante que j'ai vécue à l'IMD m'a pris deux mois pour mettre en place une équipe qui a ensuite progressé, mais c'était un travail nécessaire.

    Pour donner un peu de contexte, quand je suis arrivée, l'équipe était quelque peu délaissée. C'était une équipe de sept personnes qui faisait un peu de tout et n'importe quoi : un peu de design, un peu d'UI, un peu d'UX, alors qu'elle était supposé être d'une équipe de designers UX. 

    Ils avaient une manager qui n'était présente que de temps en temps (problèmes de santé), mais à mon avis, elle manquait également d'expérience en matière de gestion d'équipe.

    Ce que j'ai appris sur le terrain, c'est que le rôle du manager ou du leader est de protéger son équipe des influences extérieures et de sensibiliser à l'impact de son équipe à l'externe. 

    Lorsque j'ai pris mes fonctions, j'ai cherché à comprendre le macrosystème dans lequel je m'insérais. 

  • L'une des premières choses à faire lorsque vous prenez les rênes d'une équipe, c'est de comprendre sa réputation au sein de l'écosystème.
  •  Ensuite, il y a un travail à faire en interne de l'équipe. C'est un travail qui prend du temps et qui va au-delà des problématiques professionnelles.

    Vous devez d'abord évaluer rapidement les flux de travail et la dynamique de l'équipe : 

  • Est-ce que les membres de l'équipe s'entendent bien entre eux ? 
  • Qu'est-ce qu'ils font ensemble ?

    Ensuite, vous prenez chaque personne individuellement et vous les laissez s'exprimer. 

    Vous leur dites : "Je suis là, je ne connais rien. Expliquez-moi comment les choses fonctionnent." 

    Il est important de se mettre dans une position de méconnaissance, ce qui est souvent le cas lorsque l'on arrive dans une entreprise, où l'on ne connaît pas la culture ni la manière dont les choses fonctionnent. 

    L'objectif est d'évaluer deux choses : comment les gens travaillent dans l'écosystème global et comment ils travaillent ensemble.

    La dernière dimension qui est extrêmement importante, selon moi, est de comprendre ce que les gens attendent de leur travail. Sont-ils motivés par la passion, par l'argent ou par une absence d'alternative ? 

    Une fois que vous avez compris tout cela, la prochaine étape est de communiquer.

    La communication est extrêmement importante. Vous ne devez jamais cacher à votre équipe ce que vous faites pour eux et ce que vous prévoyez de faire pour eux. Les considérations politiques au sein de l'écosystème ne sont pas leur préoccupation. 

    Cependant, vous devez constamment communiquer avec eux sur les impacts et les changements à venir. Si nécessaire, replacez les membres de l'équipe là où ils seront heureux et épanouis.

    Je reviens souvent à l'idée des organigrammes, bien qu'ils aient leurs limites. En politique, les gens ont besoin d'organigrammes. 

    Mais dans la réalité, lorsque vous travaillez au sein d'une entreprise ou d'une agence, vous ne devriez pas dire : "Voici ce que nous devons faire, je vais trouver quelqu'un pour le faire." 

    Au contraire, vous devriez dire : "Qui dans mon équipe est capable de réaliser cela ?" Vous partez de l'intérieur et vous évaluez les compétences et les forces de votre équipe.

    Ensuite, vous pouvez positionner votre équipe en interne en disant : "Voici ce que mon équipe est capable de faire pour vous, et voici comment nous allons le faire." 

    En adoptant cette approche, j'ai réussi à passer d'une équipe de sept personnes à une équipe de quatorze personnes en l'espace d'une année. J'ai réorganisé mon équipe UX en trois sections distinctes : 

  • une section dédiée à l'UX
  • une équipe UI avec un product manager travaillant avec l'équipe IT
  • un pôle de design visuel

    Nous avons dû embaucher de nouvelles personnes car notre équipe était devenue très efficace dans la livraison de projets et nous avons commencé à recevoir de nombreuses demandes. Nous avons réalisé que nous avions d'excellents designers et que nous étions devenus très compétents, ce qui nous a permis de développer nos compétences. Beaucoup de managers et de leaders se concentrent souvent principalement sur la livraison des projets, mais il est essentiel de penser d'abord à l'équipe. Il vaut mieux travailler en priorité sur les personnes qui réaliseront la livraison plutôt que sur la livraison elle-même.

    • 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, comment je travaille avec les développeurs.
    Dans mon expérience professionnelle, j'ai remarqué un paradoxe intéressant : j'ai généralement trouvé plus facile de collaborer avec des développeurs back-end qu'avec des développeurs front-end. Les développeurs front-end sont très impliqués dans le flux de travail d'un projet, et ils ont souvent leur propre vision de l'UX, de l'accessibilité, etc. Ils possèdent une expertise que de nombreux UX designers n'ont pas, mais ils ont tendance à être très attachés à leurs propres idées concernant les interactions, le JavaScript et ce qui est ou n'est pas bénéfique pour l'utilisateur. En ce qui concerne les développeurs back-end, j'ai trouvé leur approche de travail très intéressante. Malheureusement, ils sont souvent considérés comme une priorité moindre dans un projet, et leurs contributions arrivent généralement en fin de processus.  Cependant, j'ai adopté une approche pour remédier à cela dans chaque nouveau projet : Établir un cahier des charges et des exigences très précis pour le front-end, accompagnés d'une documentation approfondie. Cela permet de fournir aux développeurs front-end un maximum d'informations dès le départ. Travailler en collaboration avec les développeurs back-end dès le début du projet. Les développeurs front-end ont souvent des idées bien définies sur l'UI et les interactions, tandis que les développeurs back-end sont avides de connaissances et ont un état d'esprit plus ouvert.  En travaillant ensemble dès le début, les développeurs back-end peuvent apporter des connaissances, des idées et des propositions qui sont plus ouvertes à la discussion que celles des développeurs front-end. Quoiqu’il arrive il est essentiel d'inclure les développeurs front-end et back-end dès le début du projet, lors de la phase de réflexion et de stratégie.  Trop souvent, cette phase stratégique néglige l'apport des développeurs back-end, alors qu'ils ont souvent des idées pertinentes à partager.  Par exemple, lors de la définition des objectifs du projet, des objectifs commerciaux et des objectifs des utilisateurs, il est crucial de prendre en compte les implications du back-end. Pour éviter les problèmes, il est important d'impliquer les développeurs back-end dès le début et de rapidement préciser aux développeurs front-end que les décisions relatives au front-end seront définies par la recherche, la stratégie et les objectifs commerciaux. En ce qui concerne la gestion de projets, j'ai utilisé différentes approches pour m'aligner avec les développeurs.  Par exemple, j'ai souvent utilisé un document Google Docs pour suivre les annotations, en organisant le contenu par chapitres et thématiques (stratégie, recherche, etc.). Cela fonctionne bien lorsque le budget est limité. Une autre approche que j'ai mise en place avec mon équipe il y a deux ans consistait à créer un document structuré de la même manière que le site web et ses pages.  Cela nous a permis de développer une refonte complète du site en ayant un document qui correspondait à chaque section du site. Ce document, qui était accessible aux équipes IT, front-end et UX, nous a permis de contribuer les résultats de nos recherches. L'idée était que lorsqu'une personne consultait le moteur de recherche interne, elle savait qu'il existait un document dans la structure qui était un Google Doc regroupant toutes les informations pertinentes. Ce document contenait des informations provenant à la fois du front-end et du back-end. Pour moi, les documents liés à l'UX doivent être vivants et évolutifs. Le cahier des charges, qui est la référence principale, renvoie à des documents externes tels que les personas, les prototypes, et d'autres éléments importants à détailler. En résumé, pour optimiser la collaboration avec les développeurs front-end et back-end, il est essentiel d 'inclure ces deux parties dès le début du projet et de clarifier rapidement les responsabilités et les décisions.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ne vous arrêtez pas aux premières critiques sans avoir rendu tangible votre vision avec un proto

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ce n'est pas possible de refuser complètement. Surtout que si on est complètement lucide, si tu es en CDI et qu'on te demande de faire ça au début de ton contrat et que tu refuses, tu mets un peu ta période d'essai en jeu. Il faut peut-être poser deux ou trois jalons et après dire "non, ce sujet-là, on l'a déjà couvert, on va arrêter de revenir en boucle là-dessus et puis on va avancer".  J'ai l'impression que c'est un piège dans lequel on est... Que ce soit les designers, les researchers et les UX writers. Les deux dernières catégories étant un peu plus dans ces problématiques là, mais en fait typiquement les devs, on ne leur demande jamais de prouver à quoi sert le code.
    • Même problème
    • Déjà posée plusieurs fois
    • Pas sûr
  • Faire ses preuves: Une nouvelle discipline va nécessiter des aménagements pour l’équipe
    C’est la question de l’intégration à des équipes qui se pose. Toute discipline de l’UX a des KPIs et c’est très sain à condition d’arriver dans une équipe ouverte à nos méthodes de travail. D’après moi, c'est un peu un piège dans lequel on tombe souvent dans les métiers de l'UX lors de la construction d’une équipe. On nous fait venir dans une entreprise pour faire des choses, potentiellement dans le cadre d'une transformation digitale dans les grands groupes.  Il faut à la fois qu'on fasse les choses et qu'on prouve pourquoi on ne les fait pas comme avant, tout en essayant d'entretenir de bonnes relations avec des collègues qui faisaient les choses “à l'ancienne.”  Cette situation-là, elle est pratiquement insoluble.  Cette question doit être en cours de résolution quand on arrive. Si en arrivant, on doit continuer à prouver pourquoi on est là, ça installe sur le moyen terme, une ambiance de travail assez délétère.  De mon expérience, ça force à se demander, fondamentalement, qu'elle est notre valeur ajoutée. Tu peux un peu tâter le terrain en entretien d'embauche, et arriver à savoir si: On vient te chercher avec une vision un peu restreinte de l'UX writing, où on va s'attendre à ce que, en te donnant des écrans finis, toi tu relises et que tu harmonises. Ce qui n'est pas passionnant et pas le plus intéressant de ce qu'on a à proposer.  Ou s'il y a un questionnement un peu plus profond sur ces sujets-là.  Ou bien encore s'il n'y a pas encore le questionnement, si tu peux aussi accompagner l'entreprise sur ce terrain-là.  Finalement, avec l'expérience, tu arrives assez facilement à voir où on t'imagine et où tu vas pouvoir aller.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Lors d’une prise de poste, identifiez et collaborez avec ceux qui faisaient l’UX writing
    Je pense qu'il faut embarquer tôt toutes les personnes qui jusque-là faisaient des tâches qui vont nous être réservées. Sinon, sans ça, le défi est d’affronter de la résistance. Donc essayer d'identifier les personnes qui faisaient le contenu. Tu as plusieurs typologies. De manière un peu mécanique, tu as la personne qui le faisait, et ça l'embêtait. C'est souvent les PM. Ils adorent nous voir arriver. Les designers entrent aussi souvent dans cette catégorie-là. L'autre catégorie qui est un peu plus compliquée à gérer, c'est les personnes du marketing qui adorent écrire pour le produit, mais qui souvent le font avec une approche marketing qui ne s'accorde pas avec des besoins produit. Et ça, c'est un peu plus compliqué à rattraper.  Donc il faut essayer de leur expliquer ce que tu fais, pourquoi tu vas le faire. Il ne faut pas les challenger directement sur l’écriture. On se dit à ce moment-là tu rentres dans une querelle entre ancien monde, nouveau monde.  La réponse que tu reçois la plupart du temps, c'est "Oui, mais on a toujours fait comme ça".  C'est très difficile d'en sortir sans dévaloriser le travail qui a été fait jusqu'à présent. Ce travail a bien sûr été fait en toute bonne foi. La personne du marketing qui s'occupait de rédiger le produit n'était pas là pour torpiller le produit ! J'ai remarqué qu'on s'en sort plus facilement en parlant de problématique d'internationalisation ou d’accessibilité. On va avoir une copie en anglais et on va dire "Là ça marche très bien, mais regarde le site en allemand".  Là souvent les gens tombent de très haut en allant voir le site sur des langues qui sont moins synthétiques. Cette technique permet de mettre en avant le fait qu'il va falloir choisir des éléments signifiants et actionnables plutôt que de récupérer des promesses marketing. Selon les objectifs de la boite pour laquelle tu travailles en termes d'accessibilité, ça peut être un levier intéressant de mettre en exergue les lacunes du contenu qui n'est pas conforme aux problématiques d'accessibilité.  Souvent, les personnes du marketing à ce moment-là se découragent un peu et te refilent le bébé tranquillement. Cela permet d'éviter de les aborder frontalement en leur disant "maintenant c'est moi !", en prenant le risque qu'elles s'y accrochent.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Gérer une équipe d’UX writer.
    Il commence à y avoir en France des équipes contenu. C’est très positif, mais comment ça se passe ? Je pense qu'il y a plusieurs façons d'aborder la chose.  D'une part, je pense qu'il faut être patiente. Évidemment il faut faire avancer les choses, mais dans l'écosystème de la tech en France, tu arrives dans des équipes qui n'ont aucune connaissance ou alors très superficielle des problématiques du contenu et de l'internationalisation. Donc il va falloir poser des jalons progressivement, mais tu ne peux pas arriver directement et avoir des exigences hyper élevées.  Après, il y a des fois où je pense que la chose la plus importante, c'est d'apprendre à dire "non". Être capable de dire "Je ne veux pas travailler sur tous les projets en même temps, toute seule, et arriver en bout de course et faire de la relecture".  Refuser de rendre une version appauvrie de ce qu'on aurait pu faire.  Toi, tu sais que la version est appauvrie, mais du côté PM et de toutes les autres personnes, ils voient déjà une grosse amélioration dans ce que tu as fait. Si tu acceptes facilement de travailler comme ça, il n'y a pas vraiment de raison que ça change.  Au début, il faut que tu fasses tes preuves en acceptant des projets qui ne sont pas gérés de manière optimale et en même temps, à un moment donné, il faut passer à une intégration en amont dans le cycle design.. Et cette bascule-là n'est pas évidente à faire, en fait, et elle est presque plus facile à faire s'il y a des projets sur lesquels tu n'arrives pas complètement à éviter la catastrophe. Parce que si tu passes ton temps à mettre des rustines sur des pneus complètement crevés, on ne va jamais changer de pneus !
    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • 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
  • Sachez abandonner certains combats pour vous concentrer sur les bonnes batailles

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

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

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

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

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

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

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

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

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

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

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

  • Les gens sont motivés et participatifs dans les réunions et les ateliers.
  • Ils vont réaliser des actions sur le projet, ils vont avoir envie de le faire avancer. 
  • Ils vont te demander des nouvelles aussi, vont avoir régulièrement envie d’être informés.
  • Ils sont investis et engagés, ils reçoivent tes recommandations et tes propositions de manière positive et enjouée.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Bien intégrer le processus UX avec SAFe (et autres cadres de travail agiles)

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

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

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

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

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

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

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

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

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

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

    1.UN STREAM TRANSVERSE POUR LE DESIGN

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

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

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

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

    2.LA MAITRISE DU VOCABULAIRE

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

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

    3.TRAVAILLER 2-3 SPRINTS EN AMONT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX sur le pair design.
    Le moment est propice pour pratiquer le pair design avec Figma, à l'instar des développeurs, ce qui favorise une collaboration plus étroite. À l'époque, je connaissais des designers qui le pratiquaient, même en 2014-2015, mais cela se limitait généralement à deux personnes travaillant sur un seul ordinateur, l'un guidant et l'autre exécutant. Version en duo : Aujourd'hui, c'est devenu une pratique internalisée pour moi, que je réalise sur Figma avec un autre designer, voire plusieurs, mais en limitant le groupe à un maximum de cinq personnes dans mon équipe. Lorsque je fais du pair design avec un autre designer, nous nous mettons sur Figma, examinons le travail existant et le designer qui a des questions ou des suggestions peut dire : "Je souhaite retravailler ce point spécifique dans le design". Nous commençons ensuite à travailler ensemble pour proposer des solutions. Version en groupe : Lorsque le groupe est plus grand, il est important de mettre en place un processus. Nous limitons généralement le nombre de participants à cinq pour faciliter la collaboration. Nous choisissons un sujet spécifique, que nous abordons collectivement en préparant les composants ou les éléments à travailler dans le fichier Figma. Nous expliquons les problèmes à résoudre, puis chaque personne dispose de 20 à 25 minutes pour travailler individuellement. Environ 30 à 35 idées peuvent ainsi être générées en 20 à 25 minutes, ce qui est bien plus productif que si un designer travaillait seul pendant une heure. Après ces sessions, nous ressentons souvent de la gratitude envers le collectif pour la stimulation créative qu'elles procurent. Certains designers peuvent ne pas être à l'aise avec le pair design, car cela nécessite une certaine ouverture et confiance mutuelle. Il peut y avoir des inquiétudes quant à sa rapidité dans l'utilisation de Figma par rapport à d'autres designers. Cependant, dans mon équipe, nous sommes tous alignés sur l'objectif des sessions de pair design, ce qui facilite leur déroulement. Les commentaires sont basés sur le design et nous évitons les jugements personnels du type "j'aime" ou "je n'aime pas". En tant que manager si un designer exprime une réticence à participer au pair design, je prends le temps d'avoir une discussion ouverte pour mieux comprendre ses préoccupations. Je n'impose pas cette approche sans en discuter et expliquer les avantages et la démarche, et généralement, après avoir compris les bénéfices potentiels, les designers de mon équipe ont été enthousiastes à l'idée d'essayer par eux-mêmes.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Comment savoir si j’ai assez bossé un design ? Le processus que j'ai suivie.
    Le processus de design est à la fois passionnant et exigeant, car la quête de perfection est constante.  Toutefois, au fil du temps, j'ai appris à privilégier la manière dont j'arrive à la solution finale plutôt que le temps que j'y consacre.  Pour moi, un bon design doit être complet, cohérent, utilisable, de haute qualité et efficace, c’est ce qui me donne confiance dans mon processus de design.  Lorsque je suis confrontée à un blocage, j'utilise une checklist. En dernier recours, je m'engage dans des sessions de pair design avec mes collègues de chez Datadog, car nous sommes une grande équipe de plus de 100 designers, et il y a toujours quelqu'un avec qui échanger.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Éduquer et présenter la gamification à ses clients

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

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

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

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

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

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

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

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

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

  • Quels leviers d’engagement pour quel public ? 

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

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

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

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

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

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

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

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

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

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

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

    Ils voulaient donc qu'on retravaille ça. 

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

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

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

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

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

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

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

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

    La directrice dit :

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

    Moi dans ma tête :

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

    La directrice:

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

    Moi :

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

    La directrice :

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • REX: Comment j’organise des ateliers collaboratifs avec mes clients.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Mais parfois, tu te dis :

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Mieux comprendre le contexte des parties prenantes et mes techniques pour faire cela

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

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

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

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

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

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

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

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

    Moi, je fais toujours des twins ethnography.

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

    Il me dit: 

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

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

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

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

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

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

    “ ça sera anonyme.” 

    Puis quand on commence je dis :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Je creuse les représentations du futur :

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

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

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

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

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

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

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

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

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

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

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

    Ça, ça aide vraiment beaucoup. 

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Rendre les livrables actionnables
    Je vais séparer deux types de livrables. Il y a les phases exploratoires et les phases plus évaluatives. Sur les phases exploratoires: je pense que ce qui rend actionnable le livrable c'est principalement la manière dont il a été construit avec la personne qui va l'utiliser après. En l'occurrence pour prendre l'exemple de comment nous travaillons aujourd’hui versus il y a un an c’est toutes les phases sont toujours faites à deux parce que c'est plus agréable, on réfléchit mieux, c'est soit du design, de la recherche, product. Avant l'idée c'était de mettre deux personnes qui connaissent très bien leur discipline pour obtenir un résultat encore meilleur : deux researchers, deux PM] ...... deux designers Et on s'est rendu compte que deux researchers, ils étaient à 8/10 de leurs capacités, ça ne faisait pas pour autant 16 ! Ils savaient un peu les mêmes choses, ils pouvaient s'aider, c'est toujours mieux de rebondir l'un avec l'autre mais en fait c'est plus utile d'avoir quelqu'un qui est "lead" et ensuite quelqu'un qui est impliqué mais pas lead, en l'occurrence un "pm” qui va récupérer ce qui s'est passé en explo pour l'utiliser derrière. C'est le côté "transmission humaine", ça fait une bonne partie du travail pour bien réutiliser le livrable ensuite. Maintenant ce n'est pas toujours possible et on obtient un livrable qui va devoir être utilisé et des détails qui vont devoir être transformés. À ce moment-là, ce qui détermine la qualité c'est de se demander à quelle question on répond, de reprendre les objectifs produits de départ Par exemple :   "on veut améliorer la conversion entre telle et telle partie"  "on sait qu'il y a tel problème", "c'est destiné à tel user" "on a besoin de comprendre ce qu’ils font à un moment donné  "ceux qui convertissent, pourquoi ils convertissent", etc.  Une fois ces questions posées, et avec ce qu'on a appris, quelles sont les différentes réponses qu'on peut donner ? Dans le travail "produit" ensuite on sera facilement capable de notifier que toutes les réponses ne répondent pas aux mêmes questions, que toutes les questions ne se valent pas puisqu'il y a des choses qui sont plus ou moins au début ou à la fin du flow. Ça permet de faire un tri pour prioriser derrière. Une fois qu'on a l'organisation, il y a la qualité même des informations. Il y a 2 choses : 1) Il faut donc avoir la capacité d'écrire quelque chose de précis. Je ne suis évidemment pas parfait, mais je pense que j'ai amélioré cet aspect et j'estime qu'il faut y passer plus de temps. Il faut se relire, se faire relire aussi, parce qu'évidemment on est toujours clair pour soi-même, mais ça ne veut pas dire qu'on est clair pour les autres. Lorsqu'on présente les choses, si quelqu'un ne comprend pas, demander à l'autre ce qu'il a compris. Comment peut-on trouver une manière de réécrire les choses ensemble ? pour s’assurer que c’est clair. Si on énonce quelque chose qui n'est pas clair, il ne faut pas s'étonner après que le produit ne suive pas. De la même manière si l'insight, il est compris de quatre manières différentes par quatre personnes différentes, il y a un moment où ça ne marchera pas. Il faut s'appliquer pour écrire des choses qui sont claires, si on n’en est pas capable, faire un dessin, un miro...se débrouiller pour donner une représentation la plus proche de ce qu'on a appris à travers un langage écrit, imagé etc.; La dernière chose c'est d'arriver à bien connecter ça avec la réalité de ce que le user nous a dit, pas de l'illustrer parce que c'est ce qui va incarner les choses.  Il y a le côté clarté et aussi le côté puissance de l'insight. Et la puissance elle naît de la vidéo, du verbatim qui montre que  “ Ah oui, ça c’est un truc super fort, où si l’on est capable de s’appuyer dessus, ca fera vraiment une différence “ Ou  “Si c’est un truc un peu cool, que tout le montre trouve intéressant, mais où l’on sait que demain cela ne fera pas de différence”
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Le mid-mortem en plein milieu de la recherche pour faire le point et ré-aligner l'équipe
    Quand tu es dans un rôle de prestataire pour un client ce n'est pas toujours facile de lui dire que c'est fini, alors qu'on a pas vraiment fini.... Il faut que la discussion porte sur les choses essentielles, sur ce qu'on a appris et où on veut aller. Cela devient intéressant et on peut mettre une autre phase en place, prendre des décisions. Pour éviter cet écueil-là, je vais vous donner un exemple par lequel on est en train de passer avec un client; On a mis en place une phase de recherche relativement exploratoire avec 2 persona de départ qui sont draft....mais qui nous aident à avancer. En faisant des interviews concernant des produits existants on se rend compte que certains sont plus proches de la cible. Donc là on fait une pause, on a commencé un petit doc d’analyse. On reprend les objectifs de départ pour débriefer ce qu'on a appris, les profils et on a pu déterminer la top liste de la cible à moyen ou court terme.  La question que l’on discute avec le client est donc : “Qu’est-ce que l’on fait par rapport à ça ?” “Comment est-ce que l’on continue la phase ?”  La difficulté étant que parfois il y a des informations écrites qui existent qui sont un peu floues et des informations connues, informelles qui sont plus précises. C'est toujours un peu le problème dans des entreprises qui n'ont pas forcément une culture forte de l'écrit et des documents bien faits.  On va passer du temps à réapprendre les mêmes choses, car des collaborateurs les connaissent, mais l'organisation elle-même ne les a pas apprises. Ce travail de bien les transmettre, bien les écrire et bien les utiliser demande parfois une nouvelle phase de recherche qui n'aurait pas eu lieu d'être si le travail avait été bien fait dès le départ.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Ma vision de ce qu’est un livrable actionnable

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Par exemple:

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

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

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

    Mais plutôt :

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

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

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

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

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

    Ne pas avoir peur et se dire : 

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Pour bien prioriser, il faut comprendre qui veut quoi

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

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

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

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

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

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

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

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

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

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

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

    Donc je fais un peu aussi de mapping interne: 

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

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

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

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

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

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

    J’approche le workshop comme cela: 

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

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

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

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

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

    Pour moi ce workshop permet :

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • 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
  • Comment filtrer les nouveaux projets de clients et dire non à un client ?

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

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

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

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

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

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

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

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

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

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

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

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

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

    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur: 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
  • 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
  • Comment je travaille avec mes clients
    Avec le recul et mes différentes expériences, j’ai mis en place un process en plusieurs étapes qui est une méthode en entonnoir. Je pose le parcours utilisateur et/ou l’arborescence pour avoir une vue d’ensemble. Ensuite, je me focalise sur la partie wireframes Et une fois que la structure est posée, je travaille sur la forme.  C'est un process que j'ai mis en place assez rapidement, qui est très efficace et que j'applique à chaque fois, quitte à passer une demi-heure, trois quarts d'heure à l’expliquer au client pour le rassurer.  Je lui explique que dans un premier temps, on va poser la structure avec des écrans avec des maquettes en noir et blanc, avant de parler du design, on doit savoir "où on met quoi". Ainsi, on se focalise sur le fond et ensuite on passera sur la forme.  Pour avoir travaillé chez des "grands comptes" (clients assez fermés à ce genre de process), on pouvait parfois passer une heure à parler de la couleur d'un élément parce qu'ils ne veulent pas passer par des wireframes. Alors qu’en discutant avec les utilisateurs finaux, on se rend compte que cet élément est inutile et donc on l’enlève. Ils ne comprennent pas l'intérêt de passer par des wireframes. A leurs yeux c'est inutile. C’est assez frustrant mais je continue à défendre ce process et peut être qu’un jour ils se rendront compte de son impact et intérêt. C'est une méthode de travail que je présente à mes étudiants. Je leur explique qu'on travaille en entonnoir, et ils me disent mais "Madame on ne peut pas faire directement la couleur ?", la réponse est "Non !".  Ils comprennent en pratiquant pourquoi c'est important de faire les trois étapes.  Au début, ça les embête, mais ils comprennent très vite l’intérêt et se rendent vite compte qu’ils vont gagner du temps sur le moyen-long terme. En faisant comme ça, on va pouvoir discuter avec le développeur de la faisabilité technique par exemple. J'essaie de mettre mes étudiants dans un contexte de travail. En effet, à l'école, on travaille sur un projet fictif de refonte de site. Il n'y a aucun enjeu, aucun budget, il n’y a aucune contrainte technique. Et je leur dis "Mais demain ton client il a dix mille euros et tu lui demandes dix mille euros pour le design. Il fait comment pour le développeur ? Ils me regardent et ils répondent... "Ah ok !" J'arrive à apporter cette touche-là en disant : "Si ton client a dix mille euros, tu vas pouvoir dire telle fonctionnalité c'est peut-être cinq cent euros, là c'est mille euros, mais celle-là elle ne passe pas, on la mettra en V2.” Ça permet de travailler en collaboration avec le client. C’est comme ça que je travaille. Je travaille avec mes clients, je ne travaille pas pour mes clients.  Je travaille en toute transparence et je suis aussi là pour conseiller mes clients afin qu’ils arrivent à atteindre l'objectif qu'ils se sont fixés, tout en respectant leur budget et leur deadline.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Prenez le temps d’expliquer la démarche en profondeur.
    L’une des erreurs que j’ai commises dans ma carrière, c'est de ne pas savoir amener la mission aux clients.  Avec du recul, je pense que je faisais uniquement cette erreur au début de ma carrière car je ne participais pas à l'aspect commercial. Je pense que dans le fond, je me disais que ces éléments avaient été discutés en amont, mais les interlocuteurs changent entre deux... Ce n’était pas du tout le cas.  En effet, quand on est jeune, on a tendance à vouloir juste se concentrer sur ses tâches sans faire de liens avec d’autres membres de l’équipe et sans se mettre dans une position où il faut cadrer la mission.  Je pense que cette méthode de travail marche encore moins aujourd'hui qu'elle marchait il y à quelques années.  Aujourd’hui, on s’attend à ce que tu sois capable de débloquer les situations et de trouver des solutions. Donc les enjeux sont plus forts et l’attente des clients est encore plus pesante.  Si on arrive la fleur au fusil, sans comprendre le blocage et sans comprendre ce qu’on va apporter, alors on est certain que le projet coincera quelque part.  L’un des exemples qui me vient à l’esprit est la fois où j’ai travaillé sur la refonte de maquettes pour des médecins.  Pour être plus précis, je n'étais pas très bon au départ sur la conduite du changement, car j'étais focalisé sur la plus value de la nouvelle interface (sans forcément oublier ce qui marchait bien sur le produit actuel). Ce que j'avais clairement sous estimé, c'est les personnes qui se sont investi pour apprendre à utiliser l'ancienne version + les demandes d'évolutions acquises etc. Mais une chose est sûre, même après des années d’expérience, je commets encore des erreurs. Récemment, j’ai eu un client qui est venu chez nous, après avoir fait une première tentative de conception avec une autre agence. Mon erreur était de ne pas me méfier et de ne pas me demander pourquoi ça n’avais pas marché avec l’autre prestataire.  Avec du recul, je pense que quand on enchaine les missions qui se passent bien et les réussites, on baisse notre vigilance aussi... Bon je nuancerai un petit peu, je dirais que ce n'est pas totalement la faute du prestataire et que le client avait également sa petite responsabilité. Même si aujourd’hui je travaille encore avec ce client, cela a nécessité beaucoup de réajustement et de travail supplémentaire, car je n’avais pas été vigilant au début de l’engagement.
    • merci! Utile
    • Pas utile
    • Pas sûr
  • Erreur à ne pas faire avec ses parties prenantes - Essayer de les impressionner!
    Je continue de faire des erreurs dans ma carrière, et l’une des plus récentes c’est d’avoir voulu impressionner un chef de projet qui était sur un projet fantastique et qui pouvait nous donner du travail sur les 6 prochains mois. Donc nous sommes partis sur un sondage multi-pays sur 4500 personnes où on n’avait pas le droit à l’erreur et on jouait la crédibilité de l’équipe car cette partie de l’entreprise ne vient jamais nous chercher. C’était donc une étude plutôt tournée marketing, chose que l’on fait moins car l’on devait évaluer la confiance des clients envers la marque marketplace. Le chef de projet est arrivé avec sa méthodologie et son processus clé en main, que j’ai suivi aveuglément. En cours de route, en faisant les questionnaires je me rends compte que le niveau de complexité est beaucoup plus lourd qu’attendu, et que la méthode de ce chef de projet n’allait pas nous donner les résultats escomptés.  Donc j’ai dû faire machine arrière, perdre une demi-journée de travail, (donc petite erreur logistique), et je m’en veux d’être partie tête la première sans remettre en cause la méthodologie, et me poser les bonnes questions. Juste parce que le projet était super intéressant. Un autre apprentissage de cette expérience, c’est de partager ton idée de recherche avec un collègue, un pair en research afin de confronter les idées. Un simple “Qu’est-ce que tu en penses ? “ m’aurait évité d’aller dans le mur. Donc ne jamais hésiter à faire relire à ses collègues, ça fait office de pre-test et c’est très précieux. Lorsque cela arrive, si on vous fait une remarque : Demandez-vous pourquoi je reçois ce commentaire? plutôt que “Qu’est-ce qu’il me dit celui-là ?”
    • merci! Utile
    • Pas utile
    • Pas sûr

    • Commentaires

    • ·
    • ·

    Groupes

    • Vision de l'enfant
      Vision de l'enfant

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

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

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

      15 membres
    • Basse vision
      Basse vision

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

      16 membres
    • Vision et sport
      Vision et sport

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

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

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

      15 membres
    • Travail et vision
      Travail et vision

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

      16 membres
    • Evénements
      Evénements

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

      8 membres
    • Prévention
      Prévention

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

      12 membres
    • ENVIS
      ENVIS

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

      8 membres
    • Solutions optiques
      Solutions optiques

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

      12 membres
    • Facilitation
      Facilitation

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

      5 membres
    • Stratégie UX
      Stratégie UX

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

      13 membres
    • Enseigner l'UX
      Enseigner l'UX

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

      9 membres
    • Management UX
      Management UX

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

      12 membres

    Hashtags

    • #collaboration
    Groupes