Transcription de l'épisode : "Marie Glandus, Le Design Sprint en pratique : transformer une idée en un prototype en 4 jours"
Terry: Salut Marie, merci de m'accorder un peu de ton temps aujourd'hui. Aujourd'hui on va parler de Design Sprint dans le contexte d'applications digitales et on va dérouler un peu toutes les étapes du Design Sprint 2.0 si je ne dis pas de bêtises. Je te propose tout d'abord de te présenter.
Marie: Je suis conceptrice d'expérience utilisateur ou conceptrice pour l'expérience des utilisateurs et aujourd'hui je dis surtout que je suis consultante en conception de produits et services et même en stratégie d'entreprise parce que j'utilise beaucoup la méthode design sprint pour aider les entreprises à accélérer leurs projets ou à résoudre des gros sujets.
Terry: L'aspect consultante pour toi plutôt que de dire juste conceptrice c'est ?
Marie: Oui, alors j'ai choisi ça parce que je vois qu'il y a une énorme incompréhension au sujet du métier. Quand je m'étais designer, on venait vers moi pour réaliser simplement des maquettes, graphiques notamment. En fait, on venait vers moi pour faire la web-designeuse.
Terry: D'accord.
Marie: Et ça je ne souhaitais plus. Donc maintenant avec cette appellation consultante, qui d'ailleurs parfois est connotée négativement, mais je pense qu'on peut reconstruire ce métier, j'ai vraiment ce rôle de conseil. Conseil pour atteindre un objectif en termes d'impact sur les utilisateurs. Donc je fais des recommandations, des préconisations par rapport à une problématique qu'on va fixer dès le départ et un objectif qu'on va se fixer aussi dès le départ en termes d'impact sur les utilisateurs, donc d'expérience utilisateur.
Terry: Et donc pour ce travail de conseil tu vas utiliser du coup les techniques qui touchent autour de ce qu'on appelle plus communément le UX design ?
Marie: Oui, du coup, il y a tout un panel de méthodologies qu'on peut mobiliser pour arriver à atteindre ses objectifs. Je pense surtout aux méthodologies qui sont dans le livre de Karine Lallement et Guillaume Grosnier, 30 méthodes fondamentales de design UX pour concevoir des expériences optimales. C'est le titre du livre. Et voilà, je pense que ce livre est central dans ce métier. Il faut se dire que notre métier, c'est d'effectivement venir utiliser ces méthodes pour atteindre l'objectif du client.
Terry: Et donc si je te prends un cas concret, demain je viens te voir, je te dis j'ai 200 000 euros pour créer une app de coaching sportif et j'ai besoin du coup que tu m'aides à concevoir ça. Quelles vont être tes premières questions ? Comment tu vas me...
Marie: C'est super intéressant, bah justement. Alors, moi, je ne vais pas pouvoir coder ton app, mais par contre, on va se dire quel est l'objectif que tu veux atteindre en termes de réaction des utilisateurs. Quelle réaction tu espères qu'ils aient quand ils vont utiliser ton produit ? Et aussi, qu'est-ce qui te fait le plus peur ? Quelle réaction ils pourraient avoir ? Qu'est-ce que tu veux qu'ils... Quel effet tu veux avoir sur tes utilisateurs ? pour garantir le succès de ton produit en fait. Donc c'est vraiment des questions centrées sur la réaction des gens. Vont-ils aimer ton produit ? Vont-ils le trouver utile ? Oui, c'est ça, vont-ils aimer telle ou telle fonctionnalité ? Et après, tout le travail du X-Design, ça va être de vérifier, de valider ou d'invalider des hypothèses.
Terry: Donc dans cet exemple là si je te dis bah moi je veux que les utilisateurs qui vont utiliser mon app de coaching, une fois qu'ils l'ont utilisé, qu'ils ont fait une séance, ils se sentent... alors avant de l'utiliser je veux qu'ils se sentent capables de réaliser les exercices que je peux leur proposer et après qu'ils l'aient utilisé, qu'ils aient réalisé du coup une session de sport, je veux qu'ils se sentent bien et qu'ils ils ont envie aussi de saisir leurs données sur cette app pour traquer leurs progressions. Donc derrière comment toi tu vas...
Marie: En fait la problématique ça va être comment pourrait-on permettre aux utilisateurs de... je sais pas comment tu reformulerais...
Terry: D'Avoir envie de s'entraîner et de suivre leur progression.
Marie: Voilà, donc ça va devenir la problématique centrale de notre projet UX.
Terry: D'accord.
Marie: Et j'insiste sur le fait que c'est un projet UX, c'est pas un projet de créa, c'est un projet vraiment où on va venir résoudre cette problématique précise que tu viens d'énoncer.
Terry: Donc quand tu dis c'est pas un projet de création, ce que tu veux dire c'est pas un projet où tu vas arriver en fait avec un panel d'outils graphiques pour juste faire du coup...
Marie: Oui, ou un cahier des charges souvent. Parce que moi c'est souvent ça, c'est ça qui se passe souvent, c'est que les porteurs de projets, ils ont un cahier des charges, ils arrivent dans une agence web, digitale souvent, et puis ils disent ben voilà moi je veux ce produit là, enfin je veux toutes ces fonctionnalités, enfin je sais pas si tu vois le genre de scénario, c'est ça qui arrive aujourd'hui. Et ces gens-là n'ont pas forcément, pour moi, besoin d'une expertise en UX s'il n'y a pas une problématique précise au sujet des utilisateurs. Problématique, par exemple, que tu viens de m'énoncer à l'instant. Si, par exemple, ce n'est pas un sujet qui te préoccupe et que tu ne souhaites pas spécialement vérifier, s'il n'y a pas un gros risque, va voir une agence et fais ton cahier des charges et fais bâtir ton app par l'agence, en fait.
Terry: Ouais ça c'est un premier point je pense hyper important donc concrètement si tu connais déjà ton marché, tu connais ta problématique et toi tu es persuadé que ton produit va y répondre, il n'y a plus qu'à exécuter et donc dans ce sens c'est pas toi la meilleure personne pour venir m'aider à exécuter.
Marie: Exactement, tu as tout compris. Je ne suis pas une exécutante. Moi je suis là pour te donner des conseils pour bien concevoir les parties de ton app et être sûr que ça va avoir l'impact que tu espères sur les gens.
Terry: Ok bon ça tombe bien parce que du coup dans le cas de mon exemple je suis pas sûr de ce que je veux on va continuer du coup avec ça donc partons du principe que voilà je pense qu'il y a des gens qui vont vouloir l'utiliser pour s'entraîner mon app mais je sais pas à quoi elle va ressembler encore et qui vont vouloir aussi saisir leurs données pour suivre leur progression un peu tu vois comme comme Strava mais spécialisé on va dire dans le fitness. Comment tu... quels seraient les premiers ateliers que tu me conseillerais de faire ?
Marie: Comme je te disais au tout début, moi j'utilise beaucoup cette méthode design sprint parce que, et je vais plus tellement faire des choses sur mesure avec les différentes méthodos parmi les 30 fondamentales par exemple, je suis revenue sur du basique parce que C'était compliqué déjà pour moi en tant que freelance de prendre du temps à chaque fois pour faire des prestats sur mesure. Il faut faire le devis, il faut faire une propale à chaque fois. Ça demande de la réflexion, de se dire qu'est-ce que je m'oblige comme méthode, ça va me prendre combien de temps, le client il a combien de temps. Le design sprint, plus simple. On va prototyper très vite une idée et la tester en fonction de la crainte majeure que tu as. En fait, on va se fixer sur quelle est ta crainte principale par rapport à ton objectif, ta vision à long terme. Et ta crainte va devenir la question centrale du sprint. J'ai pas expliqué le design sprint mais c'est un format en quatre jours dont le but est de prototyper très vite quelque chose pour le tester et voir qu'est-ce qui bloque et qu'est-ce qui plaît. C'est un peu des tests consommateurs sur un tout petit panel de cinq personnes, donc tu prends aucun risque, mais tu as tout de suite du feedback et des retours hyper précieux sur la direction à prendre par rapport à cette grosse crainte qu'on a identifiée au départ.
Terry: Et du coup si tu devais bien découper le Design Sprint concrètement sur ces 4 jours, comment il se structure ? Enfin vraiment qu'est-ce que c'est ? C'est vrai que c'est quelque chose qu'on entend beaucoup mais... Bah bien sûr !
Marie: Alors déjà je précise que c'est le Design Sprint 2.0, la version en 4 jours parce que la version originale elle est en 5 jours. Et donc c'est un lundi, mardi, mercredi, jeudi. Généralement, on peut faire mardi, etc. On peut commencer par mardi, peu importe. Premier jour, c'est on met à plat le problème. Première demi-journée, on met à plat le problème. La fameuse problématique avec la vision à long terme, quel est le principal risque qui pourrait nous empêcher d'atteindre cette vision à long terme et qui va devenir la question cruciale du sprint. Et quels sont les principaux défis majeurs à relever ? Donc là c'était comment pourrait-on...
Terry: Je sais plus comment tu définis. Alors si on va, pour garder cet exemple, donc la vision long terme c'est que les gens vont utiliser cette app pour s'entraîner et suivre leur progression.
Marie: Voilà.
Terry: Et mon principal risque et ma principale crainte ça serait que les gens en fait n'utilisent pas l'app pour leur entraînement et utilisent des sites classiques pour trouver des programmes, imprime ça et puis...
Marie: Voilà donc en gros les gens vont-ils avoir envie d'utiliser mon app pour faire des exercices dessus ? En gros ce serait ça la question du sprint, je le fais rapidement avec toi. Première demi-journée on est là dessus, c'est un atelier en gros de trois heures. Donc on fait ça avec toi, porteur de projet, et avec ton équipe d'experts, entre guillemets, c'est-à-dire les personnes qui connaissent bien le sujet et qui connaissent un paramètre important de ce sujet, que ce soit la perspective technique ou la perspective business, commercial, juridique, voilà. Il faut que ces personnes-là soient présentes lors de ce design sprint. parce que sinon elle risque de remettre en question tout le travail qu'on aura fait suite au sprint. Tu vas aller voir par exemple le responsable marketing et puis il va dire non mais moi c'est pas du tout comme ça que je voyais les choses, pourquoi vous nous avez pas impliqué dès le début ? Bon bref je reviens au programme.
Terry: Ça c'est très important et je pense que ça se retrouve dans beaucoup d'aspects, même sur des sujets de transformation digitale dans d'autres contextes, d'impliquer le plus tôt possible toutes les parties prenantes qui auront à jouer des rôles différents à différents moments parce que justement ça facilite l'adoption et ça fait gagner beaucoup de temps sur des débats inutiles qui peuvent arriver si tu n'as pas mis les gens dans la boucle dès le début.
Marie: Je suis complètement d'accord et je trouve que ce design sprint c'est vraiment la solution pour embarquer tout le monde et que tout le monde puisse apporter sa voix au projet, sa pierre à l'édifice. Souvent je ressors de ces ateliers et les gens me disent « enfin on m'écoute ». C'est typiquement ce qui arrive dans les boîtes, chacun fait un petit peu de son côté, puis finalement c'est le chef de projet qui dit bon ben on va faire ça, et puis on n'a pas tenu compte de l'aspect tech, le lead dev a pourtant alerté mais non. Donc ouais, c'est des choses qu'on voit beaucoup.
Terry: Donc pour revenir sur jour 1, première demi-journée.
Marie: Oui voilà, merci.
Terry: J'ai toutes ces personnes qui sont là, j'ai un expert tech, j'ai on va dire un responsable marketing et puis j'ai aussi un coach sportif. On va dire que j'ai pas de sujet juridique, on va le faire un peu simple mais ils sont là.
Marie: En gros, il faut se dire que l'équipe idéale c'est environ 7 personnes mais ça peut descendre plus bas quand tu sais, quand c'est des entrepreneurs qui se lancent. parfois ils sont tout seuls avec un dev donc je peux aussi faire le design sprint avec très peu de personnes et tant pis on testera quand même quelque chose puis au fur et à mesure les autres expertises arriveront après le sprint c'est pas non plus impossible donc voilà donc imaginons on embarque ces personnes et donc première demi-journée je t'ai expliqué, l'après-midi Idéation. Idéation ça veut dire, chacun propose sa piste de solution pour relever le défi qu'on a identifié le matin. On s'est fixé un peu une feuille de route en fait. C'est un peu comme un plan de guerre, enfin je sais pas si tu vois, mais tu vois ces flèches qu'on peut voir sur un plan, on se dit bah voilà on va attaquer cette zone-là géographiquement tu vois. le matin on a fait pareil, mais avec ton produit. Donc on voit exactement la partie du produit qui est la plus risquée et qu'on veut mettre un maximum d'efforts et apporter des réponses à nos questions.
Terry: Donc à la fin de cette première demi-journée, le matin, tu vas avoir une série de questions, en général, c'est un peu ça ton livrable de la fin de la première demi-journée.
Marie: J'ai une carte, une cartographie, c'est un peu pour ça que je te parle de plan d'attaque, où on cible vraiment la partie du produit qui mérite le plus d'être travaillé et d'être validé, invalidé avec les utilisateurs. Et oui, on va se poser la question du sprint qui est en fait la principale crainte du porteur de projet.
Terry: Donc cette carte plus la question principale ça représente les métriques qui à la fin du sprint tu pourras dire bah oui c'est positif non c'est négatif et on change du coup.
Marie: Oui en fait ça sert juste à se dire quelle est la question à laquelle on veut répondre et qui est la plus prioritaire pour nous pour notre équipe et surtout pour moi porteur de projet embarquer tout le monde autour de ça déjà d'une c'est super important et puis se dire tous ensemble ok on va pas travailler sur tout le parcours Tu vois, je te prends un exemple de quand tu vas au magasin, il y a le moment où tu arrives sur le parking, tu te gares, tu rentres dans le magasin, tu fais tes courses, tu passes à la caisse, tu mets tes affaires dans le coffre. Tu vois, il y a toutes ces étapes. Et quand tu veux bosser avec ton équipe, il faut bien se mettre d'accord que c'est à une certaine étape qu'il y a le plus de soucis et le plus de défis à relever. Peut-être c'est à l'étape de la caisse, peut-être que c'est à l'étape où on se gare, Donc il faut juste entourer ensemble visuellement cette zone et se dire ok les gars, le sprint c'est là, c'est là dessus qu'on va bosser. Parce que s'il y a des gens dans l'idéation, donc l'après-midi qui commencent à proposer des pistes de solutions pour comment se garer sur le parking alors qu'en fait toi tu veux travailler sur la caisse, ça va pas. Il faut qu'on soit aligné en fait.
Terry: Très clair et je pense que du coup ce que ça peut surprendre de se dire mais attend on va passer une matinée pour définir un problème mais en réalité c'est une matinée comme tu l'as dit pour écouter toutes les personnes aussi qui vont partager un peu comme ça elles se sentent pas bah moi j'ai partagé un problème et personne ne m'a écouté au moins il est mis sur cette carte c'est juste qu'ensuite ensemble on se met vraiment d'accord sur quel est le rond sur lequel on va fixer l'attention. Je suis très visuel.
Marie: Moi aussi j'entoure avec un cercle d'ailleurs un cercle rouge et je dis bah ça c'est la zone cible de travail pour le sprint. Et tout le monde le voit et tout le monde est d'accord quoi.
Terry: Ok. Et donc après-midi, idéation ?
Marie: Oui. Alors, idéation, bon ça c'est le terme technique, j'évite de l'employer avec les équipes. Donc c'est plutôt, chacun propose sa piste de solution pour résoudre le problème qu'on a identifié le matin. La différence par rapport à des brainstorming, c'est que là, je vais demander une esquisse. C'est-à-dire que chacun va un peu dessiner, esquisser sa proposition. Pourquoi ? Parce qu'en fait quand c'est visuel, on comprend mieux quelle est l'idée que tu as derrière la tête plutôt que si tu l'expliques juste verbalement en fait. C'est ce qui se passe beaucoup dans les brainstorming, c'est que chacun dit on pourrait faire ça, on pourrait faire ça et ça. Mais à la fin souvent ce qui se passe c'est que d'ailleurs on met en place un truc et après les personnes voient le résultat et elles disent mais c'est pas du tout ça, c'est pas du tout comme ça que je le voyais. Donc c'est pour éviter ce genre de phénomène. Et aussi embarquer encore une fois cette vision tech, la vision donc par exemple de l'ingénieur ou du lead dev, embarquer la vision du commercial ou du responsable marketing, voilà. Comme chacun va mettre sa proposition, ça va permettre de tenir compte de ces différentes contraintes qui sont hyper importantes pour le projet.
Terry: Donc ça c'est jour 1, donc à la fin de la journée 1 normalement.
Marie: On a plusieurs esquisses de ce à quoi la solution pourrait ressembler d'après chacun des membres de l'équipe.
Terry: Ok, donc jour 2.
Marie: Jour 2, à ton avis, qu'est-ce qui se passe ? On a cette galerie affichée au mur.
Terry: Après, j'ai déjà pratiqué légèrement, donc je suis un peu biaisé, mais je dirais qu'on va essayer de mettre en place...
Marie: Ouais, et même juste on va choisir quelle est la piste la plus prometteuse, quelles sont les idées là-dedans qu'on veut garder en fait. Parce que, imaginons qu'on soit 7 dans l'équipe, on a 7 esquisses différentes, donc 7 propositions différentes. On ne peut pas tout faire, il y a des trucs qui n'ont rien à voir les uns avec les autres, enfin je veux dire où il y a des idées qui sont mieux que certaines autres. Donc là l'idée, sur la demi-journée du mardi, c'est vraiment d'aller montrer qu'est-ce qu'on veut garder de chacune des pistes. Avec un jeu de gommettes, c'est des votes, on va créer une sorte de carte de chaleur pour montrer avec des zones rouges où est-ce qu'il y a des trucs intéressants à garder.
Terry: Du coup pour préciser le jeu de gommettes c'est qu'en gros t'as un nombre de gommettes à coller et plus t'en colles à un endroit plus c'est que t'es favorable pour cette... Bah c'est ça.
Marie: Quand tu vas regarder par exemple la piste numéro 1, l'esquisse numéro 1, tu vas dire ah ouais ça c'est bien et tout, ça c'est vraiment bien, hop je mets 1, 2, 3, 4 gommettes et puis peut-être que mon collègue il va faire un peu pareil et du coup quand on va regarder ça de loin on va voir très rapidement où sont les tâches rouges.
Terry: Donc ça c'est la première demi-journée du jour 2.
Marie: Et la fin c'est juste de se dire, ok, quelle est la piste qui semble la plus prometteuse si on devait en choisir qu'une seule ? Pourquoi converger comme ça ? C'est qu'il y a quand même des pistes qui sont très différentes souvent les unes des autres et donc il faut bien qu'on ait une trame commune à l'équipe. Souvent on me dit, mais vous nous forcez à choisir une, mais on aimerait bien faire plusieurs choses. Et je leur dis, ne vous inquiétez pas, on va récupérer les morceaux intéressants. Mais juste, si on doit choisir une piste qui semble vraiment intéressante, on va la prendre comme trame de base. Comme ossature, je ne sais plus comment je dis, c'est vraiment la trame, la base.
Terry: Le squelette, oui.
Marie: Le squelette, voilà, c'est ça que je ne trouvais pas, exactement. Et donc voilà, l'équipe souvent converge avec une grosse gommette, je l'ai fait voter, donc on voit assez vite que l'équipe préfère telle ou telle piste, et puis le décideur vient voter en dernier, ça c'est aussi intéressant dans ces exercices, c'est de laisser l'équipe voter d'abord, et d'expliquer pourquoi chacune a choisi tel concept, et ensuite le décideur va pouvoir faire son choix en tenant compte ou pas, mais en tout cas, il a les cartes en main, puisqu'il a entendu la vision tech, la vision commerce, etc. Donc il a les cartes en main, ce que souvent il n'a pas dans les projets. C'est qu'il fait un choix en se disant, qu'est-ce que je fais ? Je ne sais pas. Bon, allez, ça, ça me paraît bien. Là, il a entendu chaque personne.
Terry: Oui, souvent, c'est plus au doigt mouillé, tandis que là, c'est basé sur de la donnée concrète qui, même si elle est visuelle et pas quantifiée sur une feuille Excel, elle reste quand même très concrète en termes de...
Marie: Mais c'est surtout ce que je trouve intéressant, c'est que par exemple le dev, il va pouvoir dire ben moi j'ai voté pour telle piste parce qu'en termes de dev, ça va être plus facile à implémenter où on a déjà des bases de données ou du langage ou de je ne sais quoi qui va permettre de mettre en place ça, tu vois. Et donc le directeur, il va entendre ça. Il va se dire ah ok, ça j'avais pas, j'étais pas au courant, enfin ça il faut que j'en tienne compte en fait. Donc voilà.
Terry: Très clair et du coup sur cette phase où tu choisis donc en général même si après tu vas trouver un consensus tu vas avoir quand même toujours des frustrations parce que il ya un choix qui a été fait plus d'un côté de l'autre parce qu'au final c'est le décideur comme tu dis qu'il va choisir en connaissance de cause et de toute façon ça veut pas dire non plus que derrière tu peux pas faire d'autres sprint si jamais ça ça avait pas marché à retester les autres hypothèses d'où l'importance de vraiment choisir et pas essayer de tout faire parce qu'au final ça veut dire rien faire mais quand tu es dans cette phase de choix je vois quand même là un peu avec le recul je me dis c'est quand même une phase où quand les gens sont un peu déçus parce que c'est pas leur idée qui a été choisie il faut les garder motivés pour la moitié du temps qui reste donc et toi des petits conseils pratiques aux pratiques sur des situations que tu as pu vivre dans ce genre de contexte.
Marie: Justement, la suite de l'exercice, ce qui est sympa, c'est qu'on va faire de la récup des bonnes idées de toutes les esquisses. C'est ça qui est rigolo, c'est qu'on peut quand même capitaliser sur des petits morceaux à gauche, à droite, et donc garder l'équipe embarquée. Parce que l'exercice suivant, c'est donc de... Alors il y a une petite astuce au niveau de l'exercice, c'est qu'après, tu vas demander à chacun de décrire le parcours utilisateur pour utiliser cette solution que le chef a retenu comme la plus prometteuse à tester. Donc chacun décrit son flow en six étapes, et ensuite on vote pour la description la plus claire, très rapidement. Une fois qu'on a cette description, c'est-à-dire aussi, ils appellent ça le user test flow dans le design sprint 2.0, Ce user test flow, c'est vraiment le parcours, le scénario de test en vue des tests utilisateurs qu'on va faire le dernier jour. C'est vraiment se mettre d'accord sur qu'est-ce qu'on va afficher, dans quel ordre, vraiment la scénarisation. Et donc, en dessous de chacun des post-it qui décrit une étape du flow, on aura une... comment je pourrais dire, une vignette pour dire qu'est-ce qu'on affiche, qu'est-ce qu'on affiche à cet endroit-là. Étape 2, qu'est-ce qu'on affiche à cet endroit-là. Et là, ça commence à prendre... Visuellement, on commence à voir à quoi ça va ressembler le proto et le test. Et là je leur dis, vous pouvez maintenant découper dans les esquisses que vous avez faites au feutre sur papier, donc celles qu'on a collées dans la galerie, vous pouvez découper les morceaux précis qui correspondent à quelque chose qui est dans une des étapes. Je ne sais pas si tu vois ce que je veux dire.
Terry: On peut découper des petits morceaux.
Marie: Par exemple, dans l'esquisse numéro 2, qui n'a pas été choisie, il y a un petit formulaire qui a l'air super bien fait, où il y a eu pas mal de gommettes rouges et tout. Je le découpe. et je viens le coller à l'étape 3 du flow parce que ça correspond à l'étape 3 et que ce morceau là il est bien fait et ça nous donne déjà une idée de comment le designer visuellement, à quoi il pourrait ressembler en fait.
Terry: Parfois tu n'en as pas deux visions qui s'opposent et qui vont te dire moi je ne veux pas celui-ci, je préfère celui-là.
Marie: Alors ce qu'on peut faire, c'est coller plusieurs morceaux. L'idée c'est que l'exercice de l'après-midi, du mardi après-midi, c'est de se mettre d'accord sur le storyboard, c'est-à-dire ce que je viens de t'expliquer là. C'est vraiment la scénarisation visuelle des écrans qui vont succéder pour le test.
Terry: D'accord.
Marie: En fait, pourquoi je fais cet exercice de bricolage ? C'est juste pour éviter aux personnes de se retrouver face à une case blanche où il faut dessiner l'écran, ce qui est assez difficile en fait. À partir de rien, de se dire à quoi va ressembler l'écran de l'étape 1, à quoi va ressembler l'écran de l'étape 2. Si tu capitalises, si tu récupères des trucs que tu as déjà dessinés, c'est déjà ça de gagné en fait. Tu vois ce que je veux dire ?
Terry: Ouais non très clair et du coup pour revenir sur la question à la base qui était en gros comment tu gères s'il y a des frustrations par rapport aux choix qui ont été faits aujourd'hui la réponse là assez large c'est ben on essaye de réutiliser ce qui était un peu le mieux dans les autres choses qui n'ont pas été choisies et globalement ça se passe bien quoi.
Marie: Je crois que voilà je crois que tu l'as résumé beaucoup plus rapidement que.
Terry: Moi mais c'est exactement ça. Non mais ok très clair et donc donc ça c'est le matin et donc l'après-midi vous définissez le user flow.
Marie: Oui, donc c'est justement cet exercice-là de l'après-midi que j'ai déjà commencé à expliquer. Oui, c'est vrai que le matin est vraiment entièrement dédié à ce choix de quelle est la piste la plus prometteuse. Il faut quand même prendre du temps pour les regarder chacune, les étudier, mettre les petites gommettes rouges pour voir ce qui est bien à garder individuellement. Il y a beaucoup d'exercices en silence, c'est sympa, mais on peut mettre de la musique pour que ça ne fasse pas trop scolaire. Et puis après c'est ces moments où on va prendre la parole mais de manière très cadrée puisque voilà on va demander à chacun de présenter une piste en une minute ou deux minutes et ensuite de voir un peu pourquoi les gens ont voté sur tel ou tel endroit. Donc il y a une sorte de petit pitch, une petite présentation de chacune des pistes avant de converger vers celle qui semble la plus prometteuse.
Terry: Ok, donc là on a la journée du mardi si on commence le lundi. Donc je refais un récap, le lundi matin on définit le problème, le lundi après-midi chacun pense à des solutions, le mardi matin on vote pour la solution la meilleure mais on peut sous-voter parce qu'en général on parle d'écran donc il va y avoir des parties qui peuvent intéresser des personnes mais qui ne seront pas sélectionnées sur la solution globale qui pourront être réutilisées parce que le mardi après-midi ensuite on définit le flow que l'on va ensuite vouloir implémenter.
Marie: Pour le test. Mercredi. Mercredi, vu qu'on a élaboré tous ensemble le plan d'action du prototype, sous ce format storyboard, eh bien on peut prototyper en fait. Donc prototyper, ça veut dire quoi ? Ça veut dire souvent que c'est un designer d'interface qui va prendre le relais.
Terry: Pour prototyper rapidement... Donc type Figma, Adobe XD...
Marie: Voilà, ça peut être ces logiciels, d'ailleurs peu importe le logiciel... Ou PowerPoint, bien configuré... Du moment que tu arrives à faire ton proto en une journée, donc il faut quand même que tu connaisses bien l'outil et que tu arrives à faire le flow en vue du test. Il faut qu'on puisse avoir un lien à envoyer au testeur et qu'il puisse l'afficher sur son écran et qu'on puisse le voir interagir en fait.
Terry: Là-dessus, je mentionne volontairement les noms de ces logiciels, type Figma, Adobe Sketch, ou même PowerPoint, parce que si c'est bien fait en soi, ça peut le faire. Parce que quand même, jusqu'à présent, lundi, mardi, on était sur du papier, sur des dessins, pour exprimer ce qu'on a dans notre tête. Parce qu'une image vaut mille mots, comme tu l'expliquais très bien. En revanche, quand on va tester la validité de notre prototype, on peut voir notamment sur le design print de Google Venture Initial, il y a des vidéos un peu sur des fois des prototypes H-papiers où ils font des tests utilisateurs papiers. Sauf que, on parle là de produits digitaux, donc le produit final implémenté sera utilisé sur un PC, sur un téléphone. Donc tester sur du papier, on n'est pas représentatif de l'expérience que va vivre l'utilisateur final avec le produit final, donc c'est important quand même. comme tu l'expliques, alors après ça c'est ma position peut-être que tu vas me dire que t'es pas d'accord, je te laisserai répondre, mais pour moi c'est important que les tests utilisateurs soient faits, alors je dis pas qu'il faut à tout prix que la fidélité soit à 100% avec le produit final, mais qu'en termes d'usage on arrive à recréer une expérience très similaire à ce que ce que l'on va avoir sur le produit final. J'ai du mal à voir un test d'une app mobile quand tu regardes des écrans sur des feuilles de papier et que tu déplaces des petits bouts de papier pour dire là je scroll, là j'appuie, puis je tourne ma page, enfin voilà.
Marie: Alors, comment répondre ? Dans le design sprint, c'est une méthode le design sprint, et le design sprint tel qu'il est pensé par Jake Knapp et adapté par l'agence AIG & Smart qui a fait la version 2.0, c'est effectivement de projeter les personnes dans l'usage avec quelque chose d'assez réaliste pour qu'elles aient vraiment l'impression d'avoir le produit entre les mains. Même si elles ne peuvent pas cliquer partout, vu la tâche qu'on va leur donner, elles vont normalement cliquer sur les endroits qu'on a prévus pour qu'elles cliquent. Et effectivement, comme je disais, et comme tu le disais aussi, l'idée c'est vraiment qu'elles aient l'impression d'être sur le produit fini ou quasi fini, même si on n'est pas au pixel près, on n'est pas sur du truc parfait parfait. Mais lui donner cette impression-là, c'est ça qui va générer des feedbacks intéressants. D'après Jake Knapp dans le livre, il dit que ce feedback vaut de l'or par rapport à des interviews utilisateurs comme ça, tu vois, une conversation on dirait. Est-ce que vous auriez besoin de ce genre de solution que je décris oralement ? On peut converser longtemps sur des choses comme ça. L'idée du test utilisateur, c'est vraiment de voir comment la personne va s'en servir, puisque demain, elle sera toute seule quand elle aura le produit entre ses mains. En fait, c'est ça qu'on veut voir. C'est comment la personne réagit quand elle est toute seule avec le produit, parce que c'est ce qui va se passer demain quand le produit sera lancé.
Terry: Et là, point important aussi par rapport à ce que tu viens de dire, c'est le contexte de pourquoi on fait ce test. On fait ce test parce qu'on veut tester le cas où la personne se retrouve toute seule avec son produit dans les mains. Et dans ce contexte, effectivement, une interview d'utilisateur où tu lui demandes qu'est-ce que tu ferais si tu avais le bouton là ? Déjà, il faut qu'elle s'imagine l'interface, ça n'a pas de sens. je prends un peu le... je me fais l'avocat du diable, pas vraiment, parce que je change le contexte, c'est que l'interview utilisateur, quand tu veux comprendre un problème, c'est hyper pertinent, c'est-à-dire que même faire du shadowing ou être auprès d'une personne pour comprendre comment elle travaille et comprendre son problème, là ça a du sens. Et les tests utilisateurs, ce qui est différent de l'interview utilisateur, c'est exactement ce que j'imagine on va avoir en jour 4 ou 3 après-midi, et là aussi c'est pertinent. Mais donc là, la nuance que tu fais, c'est de dire, faire une interview utilisateur pour savoir si mettre mon bouton à droite, c'est pertinent, ça n'a aucun sens. En revanche, faire une interview d'utilisateur pour comprendre un problème, avant même ton jour 1 du design sprit, d'ailleurs, ça peut être pertinent aussi de parler à tes utilisateurs.
Marie: Déjà, prépare bien le terrain en amont, qu'ils font des interviews ou des observations terrain en amont. Effectivement, ça enrichit, toute l'équipe est plus au fait. En tout cas, s'il y a au moins une personne qui l'a fait, elle est plus au fait et du coup, son esquisse va en être impactée. et tout son discours pendant le sprint quand elle va dire ben voilà je choisis telle ou telle esquisse elle saura en fait parce qu'elle dira ben oui la semaine dernière je suis allée sur le terrain j'ai vu ça ça ça donc voilà et juste pour dire par contre sur les tests on peut faire des tests en dehors du design sprint parce que ça c'est vraiment une méthode bien précise mais dans les méthodes fondamentales du livre de Karine Lallement et Guillaume Grenier on voit qu'on peut tester des storyboards On peut tester des maquettes papier, ça peut amener du feedback intéressant, mais il faut utiliser à bon escient ces méthodos. Et le design sprint, encore une fois, tel qu'il est pensé par Jake Knapp, c'est d'aller sur quelque chose d'assez haute fidélité quand même, parce qu'il estime que c'est comme ça qu'on a du feedback qui vaut de l'or.
Terry: Une autre façon de le résumer, c'est faire un MVP en une semaine, qu'enfin en 4 jours.
Marie: Par exemple, des fois je me dis, je pourrais challenger un peu ce design sprint et on pourrait avoir du feedback plus tôt dans le process. Par exemple, on pourrait avoir du feedback déjà sur la map, quand on entoure la zone, si on pouvait amener des utilisateurs à ce moment-là dans le process, juste leur dire, regardez le parcours, est-ce qu'on est d'accord que c'est là que vous avez le plus de points de frustration ? Donc déjà, tu vois, la zone pourrait peut-être potentiellement changer dès ce moment-là. Ensuite, quand tu fais les esquisses, donc les petits storyboards, on pourrait à ce moment-là aussi dire, ah tiens, et si on amenait quelques utilisateurs pour un peu voir quelle est la piste qui semble la plus prometteuse d'après eux, juste en regardant le storyboard, c'est-à-dire qu'ils vont juste se projeter dans l'histoire, dans le scénario d'usage et dire, ah oui, ça correspond à ma problématique, donc je me projette dans ce scénario. mais on teste vraiment plus l'utilité là que l'utilisabilité. Je ne sais pas si tu vois ce que je veux dire, mais voilà c'est vraiment... Donc tu vois on pourrait.
Terry: Déjà... Moi je pense que 4 jours c'est déjà hyper court et honnêtement si tu les fais venir en jour 1, c'est un peu comme l'histoire qu'on n'arrive pas de lire de partout sur Ford. Si j'avais demandé à mes utilisateurs ce qu'ils voulaient, ils m'auraient dit des chevaux qui courent plus vite ou des chevaux à 5 pattes. C'est un peu le même. Donc 4 jours je trouve que c'est déjà hyper court pour tester.
Marie: Oui, oui. Et en fait, pourquoi je me suis rabattue sur cette méthode aussi ? C'est parce que les utilisateurs sont quand même difficiles à mobiliser. En plus, oui. C'est difficile de recruter des gens pour qu'ils soient avec toi pendant les ateliers, ou des thèses, ou des interviews, ou n'importe quoi. Donc, ce qui est intéressant dans le design sprint, c'est de te dire, ok, si les utilisateurs, on ne les a que pour un certain laps de temps très court, c'est à quel moment que c'est le plus important de les avoir ? c'est au moment des tests. S'il fallait choisir, renoncer, il faut absolument qu'ils soient là lors des tests. C'est ça qui va être déterminant. Et en plus je trouve que c'est pas mal parce que finalement l'équipe va très vite aller sur des solutions On ne va pas trop la freiner parce que je vois souvent ça aussi. Non, non, vous pensez trop à la solution, etc. Alors qu'ils n'attendent que ça en fait, parce qu'ils ont déjà un peu réfléchi, ils ont déjà des choses en tête. Le design sprint, ça leur permet enfin de les exprimer très rapidement. Donc c'est aussi pour ça que j'aime bien parce que ça les motive, ça les implique et ça leur permet très tôt d'avancer sur les idées et pas de passer par exemple, je dis n'importe quoi, mais faire deux mois d'études terrain, passer du temps sur de l'idéation des concepts. Enfin, on peut, mais moi j'aime quand c'est court et efficace en fait. J'aime l'efficacité.
Terry: Désolé je t'ai coupé, on est parti mais sur le mercredi matin, sur cette phase design haute fidélité, est-ce que soit tu te bases sur des compétences qu'il y a en interne sur l'équipe qui est déjà là, ou toi tu viens avec d'autres personnes avec qui tu fais des partenariats qui peuvent faire ce travail là ?
Marie: Voilà ça dépend de la situation mais t'as bien résumé effectivement c'est soit soit je vois qu'il y a des compétences en interne et que la personne par exemple un designer UI donc d'interface utilisateur est déjà présent dans l'équipe donc je sais qu'on va pouvoir bosser ensemble sur le prototypage le troisième jour Soit je vois qu'il n'y a pas cette compétence et je peux proposer qu'une autre freelance m'accompagne sur le design sprint ou même juste sur cette journée-là, puisque vu qu'on aura un plan d'action du proto sur le storyboard, c'est assez facile pour moi de dire, regarde, j'ai juste besoin que tu me fasses le proto de ces écrans-là, de cet enchaînement. Éventuellement je lui donne quelques informations supplémentaires, mais en gros elle a le plan. Il n'y a même plus à réfléchir en fait. C'est ça qui est sympa aussi, c'est que le designer ne se retrouve plus à se poser 50 000 questions. Toutes les réflexions ont été faites pendant ces deux jours en fait. Et tout a été fait avec l'équipe et les différentes perspectives, business, tech, UX. Donc il a pu re-challenger les choses pendant cette journée de prototypage. Normalement c'est juste, je fais ce qu'il y a dans le plan. Normalement le plan est fait pour qu'il n'y ait aucun doute pour le designer qui va s'en charger. Donc voilà. Et ça peut être fait en équipe réduite, même si c'est quand même sympa d'avoir l'équipe toujours impliquée. Mais on peut vraiment réduire l'équipe. Donc si tu veux, on peut vraiment mobiliser le gros de l'équipe sur les deux jours et le prototypage dire, OK, vous pouvez revenir à vos tâches du quotidien. Et nous, avec le designer UI, par exemple, Visual Designer, on va s'occuper du proto. Et à la fin de la journée, ou déjà à la mi-journée, on vous montre ce que ça donne, on fait un premier petit galop d'essai, et à la fin de la journée on fait un dernier galop d'essai pour dire ok c'est bon, c'est ça qu'on va tester, il n'y a pas de bug au niveau des liens, tout est conforme au plan qu'on s'était donné en fait.
Terry: Et du coup, oui, par rapport à ça, au fait que là, tu peux être en équipe réduite, c'est parce que tout ce travail d'alignement, par exemple, tu l'as fait sur jour 1 et 2, là, on est vraiment, on s'est tous mis d'accord que c'est ça qu'on va exécuter sur une journée. De toute façon, en soi, une journée, c'est très court pour exécuter et mettre en place un proto. Et si, en plus, à la mi-journée, vous faites un repoint avec l'équipe, ça permet aussi de s'assurer que, bon, on a bien exécuté ce qui était prévu. Et donc, jour 4, on va tester.
Marie: Et c'est la journée la plus intéressante, c'est la journée où on découvre les réactions des gens et des gens qui ne sont pas dans l'équipe, qui ne connaissent pas le projet. Il faut faire attention de bien recruter des personnes qui sont vraiment dans la cible aussi. Et des personnes qui ne sont pas de notre entourage proche, parce que des proches ça pourrait donner du feedback positif alors qu'en fait ils se disent que c'est horrible son truc, ou je vois pas du tout l'intérêt, mais ils vont dire que c'est bien pour faire plaisir. Donc on évite de tester aussi avec les proches. Ça donne du feedback plus fiable en fait. Parce que ça servirait à rien de récolter du faux feedback, du feedback erroné. Ça sert à rien d'avoir des gens qui vous disent oui c'est bien alors que ça ne l'est pas. Parce que quand vous allez lancer le produit derrière ça va faire un flop. Donc voilà, c'est pour ça qu'il faut faire gaffe de bien recruter ces personnes.
Terry: Et tu les recrutes à quel moment d'ailleurs ?
Marie: Alors, on peut les recruter, on peut déjà faire un travail préalable avant le design sprint, de se dire, on voit à peu près quel est le sujet. Déjà le sujet du sprint, il est défini avant le sprint. Donc on voit déjà quelles sont les cibles, quelle est la cible potentiellement qui va être celle qui va tester derrière. Donc on peut déjà se dire, OK, pour les tests, il va falloir trouver ce genre de personnes-là. On a établi un profil, je ne sais pas moi, les amateurs de paddle, les médecins urgentistes, n'importe quoi, les jardiniers. Moi, je travaille sur des trucs tellement variés. C'est assez difficile. Moi, ce que je fais, en fait, c'est que je ne fais pas le design sprint sur les quatre jours d'affilée. Ça, je ne te l'ai pas dit au début. Mais là, je suis en train de travailler sur une formule où les deux jours de réflexion, comme tu disais, où on bâtit finalement le plan du proto, parce que maintenant, tu as bien compris le truc. En fait, pour moi, c'est des workshops. Chaque demi-journée est un workshop de trois heures. qu'on peut placer sur une semaine ou deux, de sorte que les gens puissent quand même gérer le flow du quotidien, parce que ça c'est un vrai sujet. Moi j'avais du mal avant de ce design sprint parce que les chefs me disaient, on ne peut pas bloquer pendant quatre jours les employés que vous voulez qu'on bloque.
Terry: Est-ce que c'est vrai qu'on t'essaie de faire by the book, ils te disent vous prenez une salle dans les bureaux que vous dédiez pendant une semaine, les gens ils viennent, ils restent là, focus pendant une semaine.
Marie: C'est vrai que pour la dynamique du groupe et si la problématique est vraiment importante, ça a du sens, make sense qu'on se mette pendant quatre jours focus sur ça et qu'on oublie tout le reste. Mais franchement, dans la réalité, c'est assez compliqué. Donc déjà, rien que caler ces quatre workshops, puisqu'il y a deux jours, donc ces quatre workshops sur une semaine et laisser les gens faire leur travail à côté, déjà, c'est plus gérable, plus possible. Et derrière, donc ça, tu fais ça pendant une semaine. ou deux si tu vois que c'est vraiment... les gens ont vraiment d'autres trucs. Mais ça commence à devenir... il faut quand même essayer de garder la dynamique. Donc sur une semaine c'est pas mal, et la semaine suivante c'est une journée de prototypage et la journée de test. Donc aussi ça te laisse un peu plus de marge de manœuvre. pour recruter ces personnes, tu vois, comme ça tu fais tes ateliers pendant la première semaine et aussi tu travailles au recrutement des utilisateurs, t'as un peu moins la pression parce que franchement c'est... enfin les quatre jours d'affilée ça va vite quoi, surtout si t'as pas bien identifié quelle est ta cible de testeurs et que tu les as pas recrutés, donc si t'as en plus ça à faire en parallèle de tous les exercices de chaque jour, laisse tomber le stress quoi. Donc moi je préfère faire comme ça et déporter ces deux jours, ces deux derniers jours du sprint sur la deuxième semaine.
Terry: Ça fait sens et puis ça permet aussi même indirectement aux gens de digérer les choses potentiellement.
Marie: Voilà le risque comme tu dis à digérer les choses c'est on les remet en question. Alors que quand tu es sur quatre jours d'affilée, généralement, tu n'as pas le temps, on fonce, on avance. Attention, jeudi c'est les tests, on n'a pas le choix, donc on teste ce qu'on a. Donc juste ne pas trop étaler le process, parce que sinon on retombe dans ces travers-là de remettre en question les idées et de partir sur autre chose.
Terry: Et du coup sur cette dernière étape des tests, les tests en fonction de comment ils sont conduits, tu peux avoir des retours qui sont plus ou moins biaisés, notamment quand tu testes des interfaces, si tu fais des tests, alors tout dépend si tu testes, là comme tu le disais à un moment tu testes pas tant que ça l'utilisabilité, tu testes plutôt le fait que tu réponds vraiment à une solution, mais bon indirectement l'utilisabilité a rentré en jeu. Donc si par exemple tu dis t'as ton interface où c'est écrit, je reprends l'exemple de l'entraînement mais c'est écrit choisir un entraînement et tu dis à la personne est-ce que tu peux choisir un entraînement, clairement tu la biaises puisque tu lui dis la phrase qui est écrite sur le bouton. Enfin c'est des petits détails mais dont on se rend pas compte quand on n'est pas un peu dans ce monde là et donc quand tu viens avec un profil commercial par exemple pour faire un peu cliché tu vas pas y penser spécialement et tu vas peut-être du coup ou un profil tech plutôt parce que les commerciaux sont peut-être plus à même à comprendre les enjeux. Comment tu gères ça du coup toi ? Parce que si t'es seul avec cette personne il faut quand même En fait.
Marie: Il y a une grosse expertise sur le côté conduite des tests. Il y a une grosse expertise à avoir. Je trouve que même on n'en parle pas assez dans le bouquin. Ce n'est pas des tests comme j'entends parfois des entrepreneurs dire, ah oui, j'ai testé mon concept, ah oui, j'ai envoyé un mail à tout un groupe ou j'ai envoyé un truc sur Slack. Ce n'est pas ça les tests. Effectivement, il y a un protocole. de test avec une tâche à accomplir par la personne. Il y a vraiment un scénario de test. Elle doit accomplir cette petite mission qu'on lui donne. Je ne sais pas, ça pourrait être vous voulez réserver un voyage en train pour demain à 8 heures de Cannes vers Paris. Voilà, on lui donne une tâche précise et elle va l'accomplir avec le proto. Et on va la regarder faire sans l'interrompre, sans lui dire où cliquer. Et c'est ça qu'on veut voir, c'est est-ce qu'elle va y arriver et est-ce qu'elle va trouver ça bien fait ? En tout cas, est-ce qu'elle va trouver que ça a un intérêt pour elle en fait ? Est-ce que ça va lui faire gagner du temps ? Est-ce qu'elle va se dire c'est génial votre truc, c'est beaucoup mieux que mes solutions actuelles ? Donc effectivement on va tester et l'intérêt et l'utilisabilité parce que c'est très imbriqué ça, c'est-à-dire que si quelque chose est mal pensé, tu vas dire oui le concept il est bien mais par contre j'utiliserai jamais votre truc, sous-entendu parce que mal pensé en fait.
Terry: Et dans ton accompagnement, du coup, est-ce que le matin du dernier jour, tu fais un brief là-dessus ? Est-ce que tu le fais en début ?
Marie: En fait, je leur dis... En gros, je leur dis, c'est moi l'experte sur la partie lead des tests. C'est moi qui les lead. Voilà, c'est pas vous qui allez leader les tests. Parce que sinon, le risque, c'est que vous récoltiez des données biaisées et que tout ce qu'on a fait là ne serve à rien. Et que vous ayez, par exemple, du feedback positif, alors que c'est du faux positif, un peu comme les tests Covid. Je fais ce parallèle-là, mais en recherche, les scientifiques, parfois, ils peuvent récolter des données erronées. C'est ce qu'ils veulent éviter pour faire des publications qui ont du sens. Donc voilà, on veut éviter le faux positif, nous aussi.
Terry: Donc si je fais l'analogie, on imagine que tu as une vitre teintée et toute l'équipe qui a bossé sur le design sprint, ils sont derrière cette vitre. Toi, tu es assise dans un bureau avec ton utilisateur et tu déroules le test et tu le fais avec le panel d'utilisateurs que vous avez sélectionnés.
Marie: Voilà, l'idéal c'est ça. Je peux avoir quelqu'un avec moi qui va prendre des notes, ça peut être pas mal aussi. Vite retenté c'est pas toujours facile à faire, donc des fois on bricole un peu, des fois il y a quand même l'équipe qui est là, des fois on fait les tests à distance donc ils peuvent voir, on est tous dans la même salle mais le testeur il est à distance. Il y a des parades où on peut trouver aussi des choses à faire parce qu'il n'y a pas toujours des vitres teintées. Par exemple, là, demain, ce qu'on va faire, j'ai parlé en design sprint, c'est le jour des tests, et donc on va essayer de retransmettre le test en live dans une autre salle pour que toute l'équipe puisse voir les réactions en live et qu'après chaque test, on puisse faire un petit débrief. Qu'est-ce que vous avez observé ? Qu'est-ce qui a plu ? Qu'est-ce qui a bloqué l'utilisateur ?
Terry: Très clair. Et du coup, juste pour ce test, ça me fait penser à une dernière question par rapport à ça. J'avais fait un poste récemment au sujet des tests utilisateurs et sur comment.
Marie: Tu...
Terry: Sur les bonnes pratiques pour donner envie aux utilisateurs de venir faire le test et puis pour leur laisser une bonne image à la fin. Moi, j'avais pour habitude quand je faisais ce genre de choses, mais c'était dans des contextes où c'est déjà des personnes qui vont utiliser le produit, donc plus des logiciels B2B dans une entreprise. ou à la fin tu vois j'aimais bien des fois donner des chocolats ou avoir des bonbons, des trucs, c'est tout bête mais tu vois ça laisse un peu aussi puisque c'est des pratiques notamment dans les grands groupes où ils sont peut-être moins habitués à le voir, tu viens leur dire prends une heure de ton temps pour que je te fasse essayer un proto, voilà.
Marie: Bah t'as raison.
Terry: Mais toi comment, au-delà de ça aussi peut-être, parce qu'on m'a posé des questions en fait, comment tu, quels seraient tes autres conseils pour réussir à attirer du monde pour tester tes produits en fait ?
Marie: Déjà je rebondis sur le côté rétribution parce qu'en réalité, comme tu le dis très bien, les gens ils t'accordent du temps donc c'est normal de les rétribuer pour ça. C'est anormal de ne rien faire. Dès lors que quelqu'un te donne du temps, il faut qu'il y ait quelque chose en échange. Donc soit tu lui offres un mois gratuit sur ta future app, ça peut être des choses comme ça aussi. Ça peut être des goodies de l'entreprise, ça peut être un chèque cadeau, souvent le chèque cadeau c'est le plus simple, un chèque Amazon ou je ne sais quel autre, bref voilà des choses comme ça. Et est-ce que c'est ça qui doit les attirer ? Parce que ça c'est encore une autre question, pour les recruter je parle. je pense qu'il faut quand même faire attention de pas attirer les gens juste pour ce qu'ils y gagnent en termes de tu vois si c'est je mets chaque cadeau à 50 euros à gagner pour participer au test et il vaut mieux comment dire attirer les personnes en leur disant on a besoin de votre avis sur une application qui va vous aider à faire ça et que cette personne se dise ah oui ça c'est un problème pour moi aujourd'hui je serais curieuse de voir ce que cette entreprise a fait et de donner mon avis Moi, je vais plus sur ça, sur le pain point, c'est essayer de les attraper comme ça et leur dire, voilà, on vous demande votre avis, ça dure 30 minutes. Montrez aussi que c'est très court, parce que la réalité, c'est que c'est des tout petits tests, sous forme d'entretien, avec à l'intérieur un petit test et un debriefing à la fin. Mais bon, ça, tu passes les détails. En gros, tu leur dis juste, j'ai besoin de votre avis sur une nouvelle solution. D'ailleurs, j'évite le mot test quand je recrute les gens, ça ne leur parle pas forcément, tu vois. J'ai besoin de votre avis. Finalement, ça résume bien les choses. C'est à nous, c'est notre tambouille ensuite d'organiser le test, etc. Et qu'est-ce que je voulais dire par rapport à ça ? Oui, et à la fin, tu leur dis rétribution 50 euros en bon d'achat.
Terry: Ouais donc ça c'est un point, retour hyper intéressant sur en gros comment tu attires en premier les utilisateurs, c'est pas en mettant en avant 50 euros Amazon a gagné, c'est plutôt bah j'ai besoin de ton aide pour donner ton avis sur mon produit. Et une fois que la personne elle a eu, elle s'est dit bah tiens j'ai vraiment envie de lui donner mon avis, là tu expliques de manière très transparente, ça dure 30 minutes et à la fin tu auras ça en rétribution parce qu'on considère que de toute façon le travail mérite salaire entre guillemets ou en tout cas tout ton passé mérite...
Marie: C'est plus par exemple, là je travaille sur une app pour des parents, pour qu'ils fassent bouger leurs enfants, et bien ce serait par exemple l'objet d'un mail de recrutement ou d'un post Facebook pour trouver des parents, pour tester, ce serait, vous avez des enfants qui pratiquent peu d'activités physiques ou qui sont tout le temps collés à leur téléphone, venez donner votre avis sur une nouvelle app, Je donnerais même pas le nom je pense parce que tu sais ces noms ça peut être parfois un peu technique, ça n'apporte rien tu vois. Donc venez donner votre avis, durée 30 minutes, rétribution 50 euros en bon d'achat et un calendrier derrière avec prise de rendez-vous comme ça c'est hyper simple pour eux tu vois. Et ça aussi ça facilite le travail pour nous aussi dans l'organisateur du design sprint tu vois. Le calendrier, paf tu ouvres, t'as les créneaux du jeudi. La personne choisie, dès lors qu'elle est inscrite, le créneau n'est plus disponible pour les autres. C'est comme ça que j'aime bien faire.
Terry: Très clair, top, super conseil, très concret. Donc on a fait le tour de qu'est-ce que c'était que le Design Sprint et surtout comment toi tu l'appliques dans le cadre de la conception de produits digitaux. Donc pour aller vers la fin de l'échange... Attends, il reste juste un petit.
Marie: Bout qui est majeur, c'est la toute fin du Design Sprint. C'est super important, mais j'en parle un tout petit peu. Qu'est-ce qu'on fait avec tout ça ? On a fait cinq tests, d'accord, génial. On a vu les réactions des gens, donc en gros il faut juste faire un petit récap, une petite synthèse de qu'est-ce qu'on a observé qui fonctionne bien, qu'est-ce qui fonctionne moins bien, qu'est-ce qui bloque les utilisateurs et qu'est-ce qui leur plaît. En gros, pour faire simple, ça peut être très vite fait avec des post-it verts en haut et des post-it rouges en bas, après on vote avec des gommettes pour voir qu'est-ce qui ressort le plus. Je passe les détails, mais c'est vraiment important de se dire avec quel enseignement on ressort de ce sprint par rapport aux utilisateurs, qu'est-ce qu'on a appris par rapport à notre crainte de départ. Donc on peut renoter la crainte de départ, donc la fameuse question du sprint, les utilisateurs vont-ils avoir envie de... Qu'est-ce qu'on répond à ça suite au test ? Est-ce que c'est plutôt oui ou c'est plutôt non d'après ce qu'on a observé ? Donc là on peut vraiment faire des exercices individuels où chacun va répondre à cette question et mettre en commun sur une fiche de synthèse les réponses. Est-ce que aussi l'équipe trouve qu'on va dans la bonne direction par rapport à l'objectif à long terme ? Donc aussi, pareil, avoir un indicateur rouge, vert, oui, non, chacun. Comme ça, on voit un peu la vue d'ensemble de l'équipe, tu vois. Du point de vue du tech, c'est oui. Du point de vue du marketing, c'est non. Du point de vue du business, c'est oui. Et que chacun puisse expliquer pourquoi. Donc très rapidement, ce récap à la fin. Et surtout, ce que j'aime bien aussi, c'est... Et maintenant, qu'est-ce qu'on fait ? Un petit plan d'action, donc chacun met quelles sont les trois actions clés à mettre en place dès la fin de ce sprint, dès lundi en fait. Et chacun met sa vision en trois post-it et pareil on débrief à l'oral et peut-être même on fusionne et on fait un truc commun pour se dire ok ça c'est notre plan d'action pour la semaine prochaine. sachant que souvent ce qui se passe c'est qu'il y a un sprint d'affinage derrière parce qu'on voit bien qu'il y a des choses qui n'ont pas fonctionné sur le proto, qui n'ont pas plu ou il y a un petit pivot à faire et donc on a envie, on n'a qu'une envie c'est de modifier la maquette et il faut la retester ensuite cette maquette pour voir si on a les bénéfices espérés suite aux corrections quoi.
Terry: Très clair. Désolée pour cette petite parenthèse. Non mais t'as bien fait parce que moi je pensais qu'on en avait parlé alors qu'on n'en a absolument pas parlé donc tu as très bien fait donc je te pose pas la question est-ce qu'il y a un sujet que tu aurais voulu aborder qu'on n'a pas abordé parce que tu viens du coup de le rappeler. Ma question que je pose maintenant sur la fin de mes échanges c'est est-ce que tu as une position forte avec laquelle en général tu es en désaccord avec les autres personnes de la profession ou en tout cas une position tranchée où tu sens que quand tu en parles avec d'autres, il y a des débats qui se créent.
Marie: J'aime bien un peu... Non mais c'est intéressant comme question. Oui, je vois qu'on n'a pas la même vision de ce qu'est le métier du X-designer, de manière générale. Moi, ce que j'observe, c'est une sorte de dérive de ce métier vers du visual design. Alors que c'est un métier à part entière, qui est très intéressant, dont on a besoin, mais ce n'est pas le métier du X-Designer tel que je te l'ai décrit au tout début. Avoir un impact sur l'utilisateur et sur l'expérience qu'il va vivre et donc se définir à chaque fois un objectif en termes d'impact. pour aller faire des préconisations pour atteindre cet objectif et se baser sur des données valides et pas se dire juste je pense que ça va être mieux si on met d'abord le formulaire et ensuite ça et ensuite ça et on se base sur rien, sur juste ma vision de designer. Ça vaut pas en tout cas tout un travail d'investigation pour vérifier et se baser sur des données. Et d'ailleurs ce qu'on voit c'est qu'il y a des projets qui, une fois lancés, échouent auprès du public. Donc les gens n'accueillent pas bien une nouvelle app ou ne l'utilisent pas. Par exemple moi j'ai aussi une entrepreneuse là, qui vient vers moi, qui me dit, j'ai lancé mon app, mais les gens, ils l'installent, mais ils la désinstallent. Donc, en gros, ils ne l'utilisent pas. Elle fait beaucoup d'opérations marketing, donc elle amène des gens à l'installer, mais... Et donc, quand j'ai regardé l'app, effectivement, elle n'est pas conçue de façon optimale. Il y a plein de pop-up dès le démarrage, donc forcément, les gens ne vont pas au bout, et puis ils se disent, non, mais qu'est-ce que c'est que ce truc ? Je l'enlève. Donc, il y a une vraie expertise. Et cette fille-là, elle est venue vers moi parce qu'elle a eu beau essayer de faire des améliorations toute seule et lire des choses sur l'ergonomie, elle s'est un peu renseignée. Elle s'est dit, il faudrait que je fasse ci, que je fasse ça. Il y a pas mal de bonnes pratiques, mais parfois, ça ne suffit pas. Parfois, il faut vraiment une expertise du X-designer pour penser le parcours et tester et voir les réactions des gens et qu'est-ce qui marche.
Terry: Oui et puis pour apporter cette méthodologie comme tu l'as très clairement expliqué, être facilitateur dans la méthodologie parce que c'est toute une méthode, c'est vrai que pour rebondir sur ce que tu dis, c'est ce que tu disais au tout début de l'échange, c'est qu'on peut avoir tendance à penser que c'est un métier où tu arrives et puis tu vas trouver toutes les solutions mais en fait c'est absolument pas ça, c'est que tu arrives avec des méthodes pour trouver des solutions. Et ton job c'est de faire en sorte que tu déroules la méthode le mieux possible, et en fait la solution va être trouvée dans le collectif, et c'est pas toi qui va arriver avec « ouais je sais exactement comment travailler l'ergot, comment travailler ci ». T'as effectivement des domaines d'expertise dans la conduite d'interview par exemple, ou des spécificités telles que celle-ci, mais après le cœur du job c'est quand même d'arriver avec ces méthodes-là et d'être facilitateur de pouvoir les dérouler.
Marie: Et surtout, je trouve que la grosse valeur ajoutée de ce métier, c'est vraiment de pouvoir garantir que les gens vont avoir la réaction voulue avant d'implémenter. J'insiste sur ça, avant d'implémenter. Parce qu'aujourd'hui, les entrepreneurs, qu'est-ce qu'ils font ? Ils vont sur Bubble, ils font leurs trucs, ils implémentent et ils lancent Bubble.
Terry: Outinocode pour les... Oui pardon, t'as raison.
Marie: Donc voilà, c'est vrai que c'est très pratique, du coup ça leur permet de très vite concrétiser leur idée, de très vite la lancer. Et c'est bien, parce que du coup ça leur permet de tester aussi. Mais des fois, malgré ça, ils n'arrivent pas à avoir les réactions espérées de la part de leur public cible. Et c'est là que je pense que toute l'expertise UX design a sa place.
Terry: Top. Merci Marie. Du coup, avant de clore, est-ce que tu aurais des recodes de lecture ? Tu as mentionné le bouquin de Carine Le Mans, mais est-ce que tu as d'autres ?
Marie: Le livre Sprint de Jake Knapp et puis tout le travail que fait l'agence Aegean Smart que j'ai aussi mentionné donc qui a fait cette version 2.0 et qui surtout s'est approprié le design Sprint de Jake Knapp en collaboration avec lui et ils ont repensé certains exercices pour qu'ils soient en tout cas plus efficaces parce que c'est pas toujours simple de ne pas se perdre dans les exos en tout cas de donner les bonnes consignes pour que les gens comprennent ce qu'on attend d'eux à chaque exercice et pas perdre trop de temps par exemple sur la cartographie du premier jour ou sur l'esquisse, faire en sorte que les gens arrivent à esquisser leur idée, c'est pas toujours facile, il y a des gens qui vont dire moi je sais pas dessiner, je sais pas quoi faire, je sais pas quoi dessiner, etc. Voilà, éviter aussi qu'il y ait trop de discussions, des fois ça peut vite retomber, on peut vite retomber dans des débats interminables. Donc là pareil, je trouve qu'Agentsmart ils ont vraiment trouvé des astuces hyper intéressantes et d'ailleurs qui peuvent s'utiliser dans n'importe quelle réunion, quand vous voyez que ça commence à dégénérer, vous dites stop, chacun prend un post-it, chacun écrit sa vision du problème sur des post-it, une idée par post-it, et ensuite on met trois minutes un timer, ensuite on affiche ça au mur, chacun lit ses post-it et on fait voter avec des gommettes et on voit très vite au niveau du classement quel est le post-it qui a remporté le plus de votes, et ceux en dessous et ceux en dessous. Et on peut du coup se dire ok c'est ça la priorité en fait et arrêter de discuter pendant des heures quoi.
Terry: Super ! Et du coup pour les personnes qui seraient intéressées pour travailler avec toi où est-ce qu'elles peuvent te retrouver, te suivre pour te proposer d'éventuels projets ?
Marie: Bah moi là c'est LinkedIn. C'est LinkedIn en attendant que je reconstruise mon site internet. Mais oui n'hésitez pas en message privé à me parler.
Terry: Ok, super. Merci beaucoup Marie.
Marie: Merci à toi, c'est super ce que tu fais. J'espère que ce podcast va vous plaire.
Terry: Super, merci. À bientôt.
Marie: Allez, à bientôt.
