Vidéo dans laquelle Manue nous parle de ses outils préférés (Stable diffusion, Adobe podcast, AutoGPT...) Des cases studies (persona, recherche utilisateur, création) et finie par une réflexion sur les usages, les limites et les process La suite ici: . https://www.youtube.com/watch?v=D5IeZcwUM0I&ab_channel=ManueMar%C3%A9v%C3%A9ry Attention : les propos sont valables le 12 mai 2023 : avec les changements de règlementations, les nouveaux outils et les rachats, il est possible que les informations de cette vidéo soit obsolète rapidement.
Dans un écosystème où les process de research sont récents et en cours de construction, tout apparait centré autour de l'atomic research, des insights et du repository. En fait J'ai l'impression qu'on privilégie des process à la place du sens, et du coup le sens se perd. Cela me fait revenir aux bases...il m'apparait important de redéfinir le sens de ce qu'est un insight / un pain point ...et d'intégrer une certaine logique de traitement de l'information pour être efficace et impactant. Je ne sais pas si certains d'entre vous l'on déjà vécu, mais je suis curieuse de vos avis et retours sur ce sujet. pain point versus insights : quelles distinctions ? Comment les traiter ? Les relier ? quid des signaux faibles : comment les traiter ?
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.
Colbys Dovi
· Senior Product designer
· il y a 1 an
J’ai pris conscience de l’importance des Checklists grâce à une erreur que j’ai fait sur un de mes premiers projets.
J’étais entrain de présenter mon travail de façon plutôt confiante, quand un Développeur m’a posé une question anodine en apparence sur l’état d’un composant. Et là, j'ai eu le sentiment de me voir à la troisième personne et je me dis "Colbys comment tu as pu oublier ça ?" . C'était une claque galactique !
J'ai essayé de rattraper le coup : " Ah oui, effectivement, c'est quelque chose que j'ai oublié, mais au début, j'avais noté ça quelque part, donc je ferai la modification sans que ça change vraiment tout".
Mais en réalité, c'était une grossière erreur de ma part. Aujourd'hui ce que je fais c'est que je fonctionne beaucoup par checklist dans tout ce que je fais.
Si je dois faire un redesign par exemple:
Je vais toujours faire une sorte de curation de l'existant
Faire une liste de la cible, des choses comme ça et je vais merger les deux en une checklist.
J'essaye de toujours avoir une checklist, par exemple de tous les composants, de tous les états d'une page, de tous les états d'un service, de tous les statuts possibles, d'un système.
Ainsi je vais toujours me fier à cette checklist. Donc au fur et à mesure que j'avance, je vais l'ouvrir et je vais checker. Vient enfin le jour de la présentation et je sais que je suis prêt et que je couvre tous les uses case.
Je sais ainsi qu'il n'y aura pas de question qui va me mettre K.O. On n'abuse jamais assez des check-lists !
Sur les produits denses en plus, il y a beaucoup de choses à prendre en compte et je pense qu'il n'y a pas de honte à connaître ses limites. C'est nécessaire pour bien faire.
La création d’une Checklist
Quand je dois partir de zéro sur un projet, je fais de la recherche pour connaître les besoins, les contraintes, … les informations à afficher, dans quel ordre, par priorité.
Par contre, si c'est un projet existant, je découpe d’abord l'existant. J'essaye toujours de découper les choses et de les grouper avant d’attaquer la phase la recherche.
Je vais prendre l'exemple d'une page car c'est à une échelle réduite et ça aide à visualiser ce que je veux dire .
Si je dois redesigner une page, je vais la découper en plusieurs morceaux. Il peut y avoir la navigation d'une part, un fil d’Ariane, la pagination ou un footer.
Je vais découper tout ça, leur donner des noms et les grouper.
Dans ma checklist, je vais inclure chaque élément qui compose ces bouts de la page ainsi que leurs différents états à prévoir.
Par exemple, dans le footer, je vais avoir des liens vers telle ou telle page, peut-être des CGU, …
À partir de là, normalement, l'exercice est relativement simple parce qu’au fil de la recherche, quand j’identifie les nouveaux composants à apporter, je les rentre dans cette checklist, il me suffit juste d'un petit tag pour différencier l’existant du nouveau, et voilà ma Checklist est complète et me donne une vue d’ensemble.
Ça m'aide à faire du zoning parce que si je dezoome, je sais tout ce qui doit être sur cette page-là. Puis à l’étape de wireframing, je vais zoomer et travailler sur chaque bout de la page individuellement.
Colbys Dovi
· Senior Product designer
· il y a 1 an
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.
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.
MC Casal
· Head of Digital Transformation | CX-UX (UXMC NN/g)
· il y a 1 an
J'ai relevé un défi que j'ai réussi à relever avec succès : faire évoluer les pratiques de recherche sur la production d'éléments monétisables(rex ici).
En démontrant qu'il était possible d'obtenir des résultats exploitables plus tôt, cela est devenu un processus standard. Ainsi, des tests utilisateurs axés sur la monétisation dans les jeux doivent maintenant être effectués avant la sortie du jeu.
Ces tests ont entraîné des changements dans la façon dont la production crée les éléments de monétisation, à la fois en termes de planification et de livrables.
Nous avons entamé des discussions avec les designers sur les types de matériel expérimental nécessaires pour effectuer ces tests.
Par exemple, nous encourageons les concepteurs à créer des prototypes plus tôt et à mettre en place un flux de production permettant des itérations et une anticipation, afin de maîtriser les coûts.
D'autre part, la recherche utilisateur permet de modifier l’approche des designers et des producteurs quant au processus créatif.
Ce qui est paradoxal dans cette histoire, c'est qu'il n'est parfois même pas nécessaire de mener des recherches utilisateurs.
Les concepteurs, en créant des prototypes, sont déjà capables de détecter et de résoudre 70 % des problèmes par eux-mêmes.
En revanche, si une approche plus traditionnelle en cascade avait été utilisée, avec une spécification détaillée, une construction et une finalisation tardive, rien ne fonctionnerait lors de l'interconnexion de tous les éléments.
Ainsi, la recherche utilisateur contribue à modifier le flux de travail de manière significative. Ce qui est intéressant, c'est que historiquement dans le domaine des jeux, la recherche intervient à la fin du processus.
Dans d'autres industries, la recherche utilisateur peut être présente dès le début mais absente à la fin, cela dépend du contexte.
Historiquement, dans notre cas, nous provenons du contrôle de qualité (QC). Nous utilisions des tests effectués par les développeurs eux-mêmes, et souvent ce sont les éditeurs qui assuraient le contrôle de qualité. Les éditeurs intervenaient à la fin du projet pour valider et décider si le jeu serait publié ou non.
Nous avons entrepris de remonter le processus jusqu'à la phase de pré-conception. Je pense que dans les milieux créatifs, l'expérimentation est souvent limitée à des essais internes, et le produit n'est exposé au public qu'à la fin. Il s'agit d'une mentalité spécifique qui freine notre progression en termes de conception et de prototypage plus précoce.
J'ai beaucoup réfléchi à ce problème où la recherche est réalisée en amont mais pas à la fin, ou à la fin mais pas en amont, et cela m'a amené à réfléchir aux types d'informations et d'observations que vous pouvez fournir en fonction de la phase du projet.
Pour les demandes de type prospective ou portant sur l'intention, nous réfléchissons en termes de risques, d'opportunités et de limites. Cependant, pour que cela se produise, les concepteurs (ou autres parties prenantes) doivent être ouverts à cette mentalité. Cela permet d'anticiper, mais pas de prévoir exactement.
Pour les demandes d'évaluation, nous procédons à des tests pour déterminer ce qui fonctionne et ce qui ne fonctionne pas, et nous cherchons à comprendre pourquoi. Pendant longtemps, la narration dans les jeux n'était pas testée. C'est pourquoi nous avons commencé à travailler sur un projet visant à montrer qu'il était possible de tester des extraits de scripts, des scènes coupées et à réaliser des montages vidéo pour évaluer la compréhension de la narration.
En conclusion, pour réussir à faire évoluer la production, il est essentiel de proposer en tant que chercheur des méthodes et des idées d'observations potentielles. Ensuite, il faut co-construire avec les concepteurs dans leur exploration du design et leur processus créatif.
Pour donner un contre-exemple où la recherche est très présente en amont mais moins à la fin, je pense à l'industrie automobile et à d'autres domaines fortement axés sur l'ingénierie.
Dans ces cas-là, les recherches se concentrent davantage sur les neurosciences et les aspects scientifiques, comme la conception des cockpits et la charge cognitive.
Malheureusement, il y a moins de recherche effectuée après l'implémentation. Il suffit de regarder la tendance des écrans tactiles. Il faut quinze étapes pour effectuer une action qui était auparavant réalisée avec un simple bouton, et l'on se demande pourquoi ils n'ont pas testé cette conception jusqu'au bout. Parfois, l'esthétique prime. Dans ces cas-là, on réalise que la recherche utilisateur peut être très présente en amont, mais moins après l'implémentation. Dans notre domaine, c'est l'inverse : la recherche est très présente lors de l'implémentation, mais beaucoup moins en amont, lors de la phase de conception.
Les langues et cultures étrangères ne vont pas s’adapter à votre produit. Une chose qui ne va pas fonctionner, c'est de laisser des personnes natives d'une langue, traduire l'interface simplement parce qu'elles sont internes. La traduction c'est un métier.Souvent, les personnes qui travaillent dans des start ups ou des grands groupes ont une appétence vers l'international, elles utilisent énormément d'anglicismes et vont les garder dans la copie finale alors que le reste du pays ne s'exprimera pas forcément comme ça.Déjà pour la génération de tes parents, la langue qu'on parle en interne dans une équipe startup, c’est pas clair… et potentiellement, ces personnes-là, selon le projet, ça peut être ta clientèle. Donc c'est un vrai sujet d'aller trouver des personnes professionnelles et ensuite, autant que possible, d'identifier soit une agence, soit des freelances, mais en tout cas d'avoir des points de contact fixes, de ne pas varier en permanence les personnes qui traduisent, c'est assez crucial. Ensuite, essayer de ne pas tirer les prix vers le bas parce que tu vas trouver des agences peu scrupuleuses qui paient très mal leurs équipes. Si tu as une petite connaissance des métiers de la traduction, tu te rends compte que ça ne peut pas marcher. Les pros facturent au mot et ont intérêt à traduire le plus vite possible. Si tu lui envoies des docs pour un petit projet, peu prendront le temps de lire pour passer à un autre projet. Donc si tu as vraiment besoin de briefer, tu paies à l'heure et tu fais une réunion pour expliquer le projet. Soit tu prends des freelances avec qui tu vas avoir une relation sur le long terme, et à ce moment-là, ils vont investir un peu plus de temps pour te garder. Mais quand tu passes par une agence, il y a forcément une énorme perte de connaissance entre ce que tu dis à l'agence et les modifications. En résumé, il faut essayer d'avoir un peu une connaissance de ces métiers-là et on a besoin que les heads of voire les C level fassent preuve de curiosité pour cet aspect du Produit au même titre que pour le dév. Les facs françaises forment des linguistes qui sauraient faire ça très bien si les entreprises savaient où les chercher. On a un problème pour intégrer ces savoir-faire dans des équipes UX ou des équipes produit. On se retrouve avec des ouvertures de pays qui ratent complètement sans que le niveau de connaissance des processus de traduction et localisation progressent. Chez Sendinblue, j’ai poussé pour le recrutement d'une personne à temps plein qui devait s’occuper de ça et nous aider lors du lancement des projets à faire un glossaire (un élément clé du design system) qui va servir à préparer la traduction autant du côté marketing que produit. Souvent on a le marketing qui vend un produit en lui donnant un certain nom, mais au sein d'une équipe produit, et bien, depuis le début, le projet porte un autre nom. Pour illustrer tu te retrouves avec le marketing qui va te vendre des pommes, et une fois que tu es dans le produit, c'est des oranges. Maintenant, comment tu vas trouver tes fruits si en plus sur la langue que tu utilises, il y a une ambiguïté et un seul mot pour dire pomme et poire ? C'est un vrai sujet et c'est un sujet pour lequel il faut investir un peu dans peu de temps. La bonne nouvelle, c'est qu'un glossaire, c'est certes du temps mais ce ne sont pas des outils incroyables non plus.
Là où j’ai besoin d’aide et où je serais vraiment curieuse d'échanger et avoir des retours d’expériences et de tips, c’est comment l’UX s’intègre dans les organisations d'entreprises ?
Parce que là, chez mon client, on est en train de développer la research, le product discovery et on se questionne beaucoup sur comment optimiser la chaîne de valeur de la discovery au delivery dans le contexte de cette grande entreprise.
Comment tu vas de la discovery au delivery dans ce contexte ?
Quelles sont les organisations des autres entreprises ?
Comment ils mesurent aussi le résultat et l'impact de leur sujet à chaque étape ?
Comment ils s’organisent entre les timings en research, la vue globale en design d’expérience où on va penser des parcours complet et une chaîne de production découpée en features ?
On ne peut pas se sortir de cette vision de parcours global parce que c'est le propre de l'expérience utilisateur. Mais par contre, on développe en agile par petits bouts.
Je serais vraiment curieuse de savoir comment les autres entreprises équivalentes font pour intégrer le Design dans des organisations plus traditionnelles et anciennes, ayant déjà un socle technique et un historique long de plusieurs dizaines d’années.
Carine Charles
· UX designer & researcher
· il y a 1 an
En termes de gestion d’étudiants, c’est marrant, parce que tu as des personas d’étudiants , des typologies et des pattern que tu retrouves d’une promotion à l’autre.
Tu as le profil “à convaincre”, celui qui te regarde quand tu arrives au début du cours, type : "Montre-moi ce que tu vaux, prouve-moi que ça va être intéressant d’être là et que ça va m’apporter quelque chose d’assister à ton cours”.
Il ne te le dit pas comme ça, mais tu vois dans ses yeux qu’il faut que tu fasses tes preuves. Au début, ça m’a un peu interpellée parce que ce n’est pas du tout ma personnalité, donc c'était marrant de me retrouver face à cette réaction. Mais si ton cours a un vrai apport, ce profil-là est vite rassuré et embarqué.
J’ai plutôt la chance d’avoir eu des promotions d’élèves cools, ils vont être bien les futurs UX. ;)
En termes de situation d’enseignement plus complexe à gérer, une année j’ai eu une promotion à laquelle j’avais donné un travail d’interviews à réaliser dans le cadre d’un cours de User Research.
Le cours et le travail sont arrivés en parallèle d’autres rendus dans leur cursus, ce qui a généré énormément de travail supplémentaire pour eux, et en doublon avec un autre projet pour lequel ils devaient faire des interviews aussi.
Ils m’ont remonté le point à l’issue d’un cours et nous avons dû, avec le référent de la filière, rediscuter du programme et réadapter le contenu des cours sur deux axes :
On a resolidarisé le cours avec leur projet de semestre, et on a plutôt positionné plus en amont le cours de user research avec le fait qu'il soit collé à leur grand projet.
On a changé l’objectif du cours pour qu’il vienne plutôt comme support théorique pour qu’ils puissent appliquer la discipline dans leur grand projet de semestre. J’évalue ensuite l’application de la théorie à leur pratique et je ne leur donne pas de sujet complet à traiter en supplément.
Sur le coup, ce n'était pas un moment agréable, parce que j’ai dû réajuster tout le programme de ma journée en live, mais ça a été très riche d’enseignements et ça nous a permis d’identifier les points à réajuster et de les rétablir.
J’ai aussi fait le constat que quand ça fait des années qu’on travaille dans un domaine, et qu’on s’adresse à des étudiants, o n a tendance à oublier que pour eux, c’est la première fois qu’ils font l’exercice, et que forcément ils vont mettre plus de temps, ils vont s’éparpiller, ils vont faire des essais, des erreurs, ils sont là pour ça.
Maintenant j’ai bien retravaillé les briques de mon cours, je leur demande un peu moins mais mieux pour qu’ils puissent prendre plus de temps d’intégrer les notions et assurer une qualité d’apprentissage plus élevée.
Et finalement, ces feedbacks des étudiants ont été extrêmement précieux car les deux promotions d’après, le modèle choisi a très bien fonctionné. Une nouvelle fois, l’intégration de feedback des utilisateurs finaux du cours ont permis de bien améliorer l’expérience et l’efficacité de ce module de cours et de son contenu.
Carine Charles
· UX designer & researcher
· il y a 1 an
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.
Teodora Blindu
· Product design manager
· il y a 1 an
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.
Teodora Blindu
· Product design manager
· il y a 1 an
Pour définir le niveau “juste” de gamification, on essaye de mixer différentes approches. Soit on va faire des entretiens avec les utilisateurs et on pose quand même des questions sur tout ce qui est motivation, afin de le connecter avec une grille de lecture des leviers d’engagement. Même si ce n'est pas parfait, ça permet d'avoir une première lecture quand on fait les persona, puisque du coup, on les refait en général pendant le sprint (souvent, c’est un peu hors sol même si, nos clients ne sont pas les plus éloignés par rapport aux utilisateurs.) Puis, on a effectivement la possibilité de faire des questionnaires. Notamment notre questionnaire sur les 9 leviers d’engagements. On a travaillé avec un doctorant en gamification pour affiner le questionnaire, voir un peu des tendances, etc. Normalement, on aura une publication scientifique sur le questionnaire. C’est une publication qui présentera un peu comment on l'a conçu et quels sont les résultats qu'on en tire. Ensuite, on mixe un peu ces différents résultats et on essaye de les confronter aux utilisateurs (que ce soit dans le sprint via des tests de prototypes, que ce soit via de la recherche utilisateur, avec des entretiens ou des questionnaires, ou que ce soit avec des tests plus poussés avec un prototype plus qualitatif, tout dépend du projet et de ses enjeux). Quelque chose que je rappelle souvent c’est que : Le niveau de gamification qui est optimal, ce n'est pas mettre le plus de gamification possible. Même sur des leviers d'engagement, ce n’est pas mettre le plus de tels leviers d'engagement possible, mais il faut trouver justement l'équilibre qui va par rapport à tes utilisateurs. Je regarde souvent ce qui se passe dans le monde des jeux qui fonctionnent sur le marché. Il y en a beaucoup qui fonctionnent avec des lootBox (quand tu obtiens une récompense, tu ne sais pas laquelle tu vas avoir.) C’est plutôt une boîte surprise. Et c'est assez utile pour générer de l'engagement. C'est-à-dire qu'au lieu d'avoir les joueurs qui disent : “Il faut trois boîtes pour avoir la récompense que je veux, là potentiellement, ce sera une, ce sera dix, ce sera cent.” On ne sait pas. C’est un truc qui génère quand même de l’engagement dans la durée pour les jeux et ça reste assez efficace. En tant qu’observateur tu pourrais dire que ça fonctionne bien. Et si on pousse plus loin le concept? Si les gens aiment bien cet effet de surprise aléatoire, il n’y a plus qu'à y aller à fond. C'est ce qu'a fait un jeu qui s'appelle Magic Legend. En termes de gameplay, c'est un peu comme Diablo, et ça se passe dans l'univers des cartes Magic avec un mix de licence assez sympa du jeu, sauf qu’en fait les concepteurs se disent : “ Comment on fait pour gagner le maximum d'argent? “Ils vont y mettre toutes les techniques un peu sales pour gagner de l'argent, notamment dans des LootBox. Ils ont poussé le truc tellement loin, avec tellement d’éléments aléatoires et peu de chances de gagner ce que tu voulais, qu’au final, je crois que 2 ou 3 mois plus tard, ils ont annoncé qu’ils arrêtaient le jeu et qu’ils allaient devoir rembourser les achats, parce qu’en fait ça sentait trop l’arnaque pour les joueurs et donc personne ne jouait. Les utilisateurs se disent : “ Ce n’est pas ça qu'on veut.” Je pense souvent que c'est un peu ça la question : “Un peu d’aléatoire, c'est cool. Trop, ce n’est pas cool.” Du coup, la question, c'est à quel niveau c'est OK ? Eh ben ça dépend de l’utilisateur pour chacun de ces éléments de gamification, il faut choisir le bon niveau. – Et c’est là que la base de connaissance méthodologique est clé. (comme notre méthode Fidbak où on s’intéresse aux utilisateurs, qu’on prévoit des tests, etc.)Je donne un exemple:. Hier, je faisais une formation pour des formateurs sur comment travailler la gamification. Parmi les gens qui sont venus, il y en a plein qui s’attendaient du coup à ce qu’ils découvrent une boîte à outils de jeu: Avoir tel levier d’engagement pour telle situation Mais non, ce n’est pas comme ça que ça fonctionne. Lors de la formation je leur ai expliqué que justement que l’on ne va pas parler de jeu. On va parler de gamification, mais pas directement de jeu.C'est typiquement le genre de personnes qui, généralement, va avoir beaucoup de mal à se poser sur ces questions d'objectifs, de persona, etc. Dans ce que j’observe c’est le genre de personnes qui veulent juste vouloir avoir son jeu. Par exemple, je les choque lorsque je dois leur dire “Il y a des gens qui aiment bien jouer en ayant de la compétition, et d'autres qui n’aiment pas.” Parce que jusqu'à maintenant ce qu’ils connaissaient dans les jeux, c’était la compétition. Mais si dans certains jeux il y a de la compétition, il y a plein d’autres qui n’en n’ont pas. Pour nous, c'est important de recadrer un peu ces éléments de méthode et de problèmes. Ensuite, on fait assez souvent bouger la méthode qu'on travaille pour les clients parce que justement, il y a besoin de l’adapter à différents types de contraintes. On a l'impression que c'est linéaire, mais en réalité c’est complètement itératif, on passe notre temps à évoluer sur plein de points différents, à faire des tests, etc. Ce sont des choses que les gens ont un peu plus de mal à appréhender. Pour l'instant, on est plutôt contents de notre méthodo « sprint », mais on continue d'affiner un peu ce que ça ne fait pas si longtemps que ça qu’on fait des sprints sur la gamification et qu’on rencontre toujours des cas particuliers. C’est aussi ça qui rend le sujet aussi passionnant.
Alexandre DUARTE
· Expert en gamification
· il y a 1 an
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.
Le Covid m'a amené à changer mes livraisons. Le prototype du début, c'était un Kanban dans notion.
Le client recevait un Kanban un peu comme une espèce de site web très visuel, un Pinterest avec un découpage de toutes les différentes sections. Mais c’est pas du tout assez accessible pour un client corporate qui n’a pas Notion, qui ne connaît pas le Kanban et qui n’a pas envie d’ouvrir et de fermer le truc.
Donc très vite, j’ai pivoté sur Miro, et je me suis fabriqué petit à petit des gros building blocks, en vrai des datawalls.
En fait, j'ai une partie de ma recherche que j'appelle le Codex, qui est toutes les sources auxquelles je fais référence, de manière presque académique, des notes, des codes hyper faciles, des liens pour tout retrouver. Tout sur ce quoi je suis tombé dans le Codex.
Puis dans Google doc, la navigation de côté est super bien faite, ça marche sur mobile, et il y en a qui aiment bien lire et qui trouvent ça cool, ils se baladent dedans. J’en fais un espèce de executive summary d’une douzaine de pages que je mets vraiment à la fin de la recherche.
À partir de ça, tu peux tout fabriquer le reste :
Ça sera des sticky notes,
Des moodboards dans des canevas bien structuré
Mon trend radar
Ma recalibration.
À la fin, quand j’ai livré, tu as un sprint qui est prêt. J’ai fabriqué des canevas qui permettent de framer tes grandes questions de recherche.
Puis en fait tu vas aller chercher dans la recherche les briques dont tu as besoin pour fabriquer ton framing de recherche et ça te donne des grandes avenues dans lesquelles tu peux faire ton idéation.
En fait, mon job to be done, je travaille dans le business de l’orientation.
Je ne fais pas assez la différence dans notre métier entre la créativité et l’imagination.
Moi je viens pour t’aider à développer ces représentations intérieures, un peu comme le champ intérieur chez les musiciens.
Tu peux entendre ta propre voix quand tu penses mais tu peux chanter à l’intérieur de toi. Donc la visualisation est super importante pour comprendre des situations qui ne nous affectent pasL’imagination, ce n'est pas juste un truc de rêveurs créatif pour imaginer du Mobius.
Non, non, non. Sherlock Holmes a besoin d'imagination pour faire des inférences, de l’inductif.
On dit que l'imagination c’est breach the gap between the known and the unknown.
C'est ça ma mission.
Donc je veux fabriquer ce datawall qui ça être très riche et en plus, je rajoute des principles design qui sont propres à la recherche.
Ce qui fait que je vais te donner toute une série d’équipements, d’instruments qui vont maintenant t’aider pour aller monter ta montagne et je t’ai envoyé sur la bonne piste, tu as ton matos et tu ne retrouves pas au point zéro à fabriquer ton sprint, où tu vas tu vas systématiquement sacrifier la profondeur de l'investigation à la justesse pour la vitesse et la visibilité.
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.
Grégoire Devoucoux
· Lead Researcher
· il y a 1 an
Je pense que la première chose qui m'aurait aidé au tout début, c'est de passer plus de temps non pas à faire de la recherche, mais à comprendre les autres Stakeholders qui sont principalement le produit, le design, éventuellement, des c-level dans les entreprises. Parce que souvent c'est plus difficile d'être un bon transmetteur de l'information qu'un bon collecteur. En fait un researcher il fait ce métier parce qu'il aime bien collecter les informations, parce qu'il a un esprit d'analyse, etc. Par contre, il n'est pas forcément naturellement bon transmetteur de l'information, alors que c'est une étape cruciale dans son métier puisqu'une bonne partie de la valeur de son travail se trouve ici. Et pour bien transmettre des informations, ce n'est pas nécessaire d'améliorer tellement sa practice de researcher mais il est nécessaire par contre de comprendre qui sont les skakeholders. Comment réfléchissent-ils ? Quels sont leurs problèmes aussi ? Parce qu'ils sont toujours en train de courir après le temps, de résoudre des problèmes qui ne sont pas suffisamment clairs, ils sont tout le temps en train d'essayer de matcher la technique avec leur mission produit. Une fois que l'on comprend ça, on comprend mieux dans quoi on s'inscrit et on peut délivrer des insights qui ont plus de valeur, éventuellement participer aussi aux phases de stratégie produit, d’idéation, de définition de l'expérience, de l'UX... et apporter beaucoup de valeur. En fait, je pense que ça devient très vite vertueux, parce que soi-même on comprend mieux comment ça marche, donc on travaille mieux. A l'inverse des personnes qui cultivent la valeur de la recherche quand ils sont en train de faire du design, du produit, ils sont plus demandeurs. Voilà ça je pense que cela m'aurait aidé dès le départ. Samantha Davis qui est la Head of Research chez Zoopla et qui intervient dans Cousto, a fait une bonne partie de son intervention sur la "no tada" research, le tada faisant référence au researcher qui arrive au bout de trois mois et qui dit " tada voilà j'ai des super insights maintenant débrouillez-vous pour faire un bon produit ! ". En fait, pour bien réaliser cette phase-là, il faut impliquer les personnes. Comment est-ce que l'on peut vraiment faire concrètement et qui impliquer ? Je pense que quand on lance un cycle de Research, on a développé nos produits par exemple, ça marche sur une cible, on va transformer pour aller chercher un nouveau marché. C'est un gros travail qui va durer plusieurs semaines, voire plusieurs mois. Il est important d'impliquer tout le monde au moins dans la communication : le produit, le design, les sales, les opérations, etc. Des personnes qui vont avoir la vision de la manière dont l'entreprise en tant que système fonctionne, avec des compétences différentes et qui vont devoir être "owner" de la solution le jour où elle existe. C'est aussi cela l'écueil du researcher, il n'est pas "owner" de la solution, il doit transmettre cet ownership, il est “juste” en charge de comprendre qui sont les users, comment ils fonctionnent. Il faut ensuite les impliquer dans des phases, participer à des interviews, participer à la définition du research plan. Pour ce qui concerne leur implication dans l'analyse je pense qu'il faut faire attention parce qu'ils n'ont pas forcément les compétences pour le faire. Il ne faut pas jouer aux apprentis researchers mais les impliquer pour leur poser des questions, leur montrer qu'ils font partie de la manière dont on analyse les données. Ensuite ils peuvent par exemple co-présenter les insights, illustrer eux-mêmes avec les researchers ce qui a été appris. Finalement il faut que ce soit un travail collectif piloté par le researcher et non un travail individuel où le researcher arrive et dit à la fin " tada ! " C’est en ça que c’est contre-intuitif, car on nous dit qu’il faut aller vite, il faut faire les choses bien, alors que ça peut être des barrières à la diffusion de la recherche. Donc par exemple, laisser quelqu’un d’autre faire une interview ne sera pas exactement aussi bien faite que si je l’aurais faite. Mais le bénéfice d’avoir impliqué cette personne peut-être supérieur à ce que l’on a perdu vis-à-vis de l’exactitude de la recherche.
Grégoire Devoucoux
· Lead Researcher
· il y a 1 an
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.
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.
