Arrêtez de développer des fonctionnalités que personne n'utilise - Noémie Rivière #37 | On part en prod

Description

🎁 Guide et résumé
💌 Abonnez-vous à la newsletter

▬▬▬▬▬▬▬▬▬▬

Noémie Rivière, Senior Product Designer chez OnePoint, explique comment le pretotyping et le prototyping permettent de valider vos idées avant de gaspiller votre budget en développement.

94% des fonctionnalités développées sur un produit numérique ne sont pas utilisées. Pourtant, la majorité des équipes continue de foncer tête baissée dans le développement sans vérifier si ce qu'elles construisent répond à un vrai besoin. Le problème, ce n'est pas le développement. C'est tout ce que vous ne faites pas avant.

Avec Marion Sainsar, Delivery Manager chez exFabrica, nous avons interviewé Noémie Rivière en marge de sa conférence à l'Agile Tour Montpellier. Forte de plus de 14 ans d'expérience en design produit (design sprints pour la Société Générale, Decathlon, Cultura), Noémie partage des techniques concrètes pour tester vos idées rapidement, à moindre coût, avant d'écrire la moindre ligne de code.

Ce que vous allez apprendre :

La différence entre pretotyping et prototyping (et pourquoi ce n'est pas la même chose)
Les niveaux d'engagement utilisateur : du simple like jusqu'à la carte bancaire, et pourquoi seul ce dernier compte vraiment
Comment mesurer l'appétence du marché sans biais, en faisant croire à l'utilisateur que le produit existe
Les techniques de pretotypage : turc mécanique, posts réseaux sociaux, mailing list, site fictif
Comment un design sprint de 5 jours peut vous éviter des mois de développement inutile
3 retours terrain : un projet financé grâce au pretotyping, un qui a pivoté juste à temps, et un échec riche en leçons
Pourquoi le pretotypage dérisque le prototypage, qui lui-même dérisque le développement

🎬 Ressources mentionnées

Article de Noémie : "Product Designer dans un Design Sprint : les conseils pour être efficace et pertinent !" https://medium.com/@campb_LLs/product-designer-dans-un-design-sprint-les-conseils-pour-%C3%AAtre-efficace-et-pertinent-2745180aa944
Alberto Savoia https://www.albertosavoia.com/
Pretotyping https://www.pretotyping.org/
"Sprint" de Jake Knapp (Google Ventures), le livre de référence sur le Design Sprint

Pour suivre l'actualité de Noémie
LinkedIn : https://www.linkedin.com/in/noemiemelidariviere/

▬▬▬▬▬▬▬▬▬▬

Postproduction Audio : Guillaume Lefebvre (https://studioecho.webflow.io/)

Music by MADiRFAN from Pixabay

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Dans sa conférence, Noémie Rivière explique que 94% des fonctionnalités développées sur un produit numérique ne sont pas utilisées. 94%. Pourtant, la majorité des équipes continuent de foncer dans le développement sans vérifier si ce qu'elles construisent répond à un vrai besoin. Le problème, ce n'est pas le développement. C'est tout ce que vous ne faites pas avant. Il existe des techniques rapides et peu coûteuses pour savoir en quelques jours si votre idée mérite d'être développée. La clé ? Testez sans que l'utilisateur sache que le produit n'existe pas encore. Avec Marion Saint-Sart, Delivery Manager chez Exabrica, nous avons interviewé Noémie Rivière en marge de sa conférence à la JTour Montpellier. Noémie est Senior Product Designer chez OnePoint, avec plus de 14 ans d'expérience en design de produits, notamment sur des design sprints pour Cédiscount, Société Générale, Decathlon ou Cultura. Dans cet épisode, vous allez découvrir la différence entre préto-typing et proto-typing, les niveaux d'engagement utilisateur, du simple like jusqu'à la carte bancaire, et pourquoi seul ce dernier compte vraiment, comment un design sprint de 5 jours peut vous éviter des mois de développement inutiles, et des retours de terrain, un projet financé grâce au prototyping, un note qui a pivoté juste à temps et un échec riche en leçons. Et comme d'habitude, si vous n'avez pas le temps de regarder l'interview complète, nous avons préparé un guide résumé de cet épisode. Le lien est en description. Cet épisode a été enregistré au cœur de la JTour. Vous entendrez un peu l'ambiance de l'événement en fond sonore. Place à l'interview. Noémie, pourquoi tester avant de démarrer le développement ?
Speaker #1
Tester, c'est avant tout pour dérisquer, que ce soit le développement ou même plus en amont, la stratégie. Si je teste vraiment au niveau stratégie, conception, ça va me permettre d'échouer plus rapidement et de savoir si je suis dans la bonne direction. Parce que ce qui coûte le plus cher sur un projet, c'est le développement. Donc, plus on teste en amont. plus on dérisque, on échoue plus vite. Et comme ça, on peut réorienter, soit pivoter, parce que ça ne convient pas tout à fait, soit carrément abandonner l'idée, le concept qu'on avait, parce que ça ne répond à aucun besoin utilisateur.
Speaker #2
Et du coup, quel type de test on peut mettre en œuvre pour dérisquer en amont du projet ?
Speaker #1
On peut utiliser le prétyping, on peut prétyper. Ce qui est intéressant, c'est vraiment de pouvoir mesurer l'appétence du marché. Donc vraiment savoir si les utilisateurs et les utilisatrices ont de l'appétence pour notre idée, notre concept, notre produit.
Speaker #0
Prétotyping, c'est un prototype que tu fais très en amont.
Speaker #1
Non, ce n'est pas la même chose. Il y a le pré-totype et le prototype.
Speaker #0
Ok.
Speaker #1
Effectivement, dans le pré-totype, on peut avoir des choses qu'on utilise déjà dans nous, ce qu'on connaît du prototype.
Speaker #3
D'accord.
Speaker #1
Pas évident non plus. Après, le pré-totype, c'est quelque chose qui n'est pas forcément très connu en France, qui est très utilisé. Mais c'est une technique qui est hyper intéressante pour ne pas flamber le budget dès le début ou à la fin. Du coup, en termes de méthode...
Speaker #0
Juste pour comprendre, le pré-totype, c'est un prototype plus léger. C'est quoi le... Je me représente très bien des prototypes à différents niveaux de qualité, à différents moments dans un vide-projet, etc. Le pré-totype, si ça correspond à quelque chose de différent, je ne le représente pas.
Speaker #1
En fait, ça va être des techniques pour mesurer l'appétence du marché et le niveau d'engagement des utilisateurs. Mais en fait, ça va être des techniques... Ça peut être le Turc Mécanique où en fait, au lieu de créer le logiciel, ça va être une personne de l'autre côté qui va faire semblant d'être le logiciel, le temps de le tester. Et après, effectivement, quand c'est positif en termes de retour, on a testé en fait vraiment l'utilisateur. Il a l'air d'être intéressé par cette fonctionnalité, ce produit. Et là, après, on va aller peut-être dans plus du prototypage. où on va concevoir plus concrètement l'interface, la partie du produit et peut-être les messages. Mais l'idée, c'est vraiment le prototype. La différence, c'est qu'on est déjà un peu plus sur du concret. On a déjà l'idée, on a la solution. Et en fait, sur le prototype, on va plus vérifier le besoin et vérifier la compréhension de l'utilisateur sur ce qu'on a imaginé. Parce qu'en fait, on peut très bien être bon sur la pétance du marché. pour le besoin, mais en fait, on l'a mal traduit dans le prototype et en fait, l'utilisateur, il va... comprendre et en fait il va pas non plus utiliser le produit donc les tests à différents niveaux au delà effectivement des tests un test QA et test développement bug en fait ça va permettre de vérifier et dérisquer que quand on part en dev en fait on est serein sur le fait que on répond à un besoin que l'utilisateur va comprendre et que l'utilisateur va utiliser dans ma conférence je dis effectivement qu'il y a 6% des fonctionnalités sur un produit qui sont utilisés par les utilisateurs Donc, ça veut dire qu'on a développé 94% qui ne sont pas utilisés.
Speaker #0
Ce gaspillage, c'est terrible.
Speaker #2
Donc, ça veut dire que le pré-totip, c'est vraiment au tout début pour être sûr qu'il y a un réel besoin ou que notre stratégie qu'on veut mettre en place est la bonne.
Speaker #1
Oui, c'est vraiment en amont et ce n'est même pas la stratégie. Je pense que c'est vraiment, en fait, tu as une idée, tu as un concept, tu as un concept comme ça. Et en fait, il faut que tu vois si ça fit avec le marché. Si le marché, il répond positivement. Et avec le prototype, ce qu'il faut surtout faire, c'est que l'utilisateur, il ne sait pas que c'est faux. En fait, pour ne pas introduire de biais, parce qu'effectivement, je vous dis dans ma conférence, c'est que si vous demandez à vos amis des choses comme ça, tu en penses quoi de mon idée, de mon projet, mon produit ? Ah, c'est super et tout. Ils ne vont pas vous dire que c'est pourri. Forcément, tu as fait bien. Voilà. Et en fait, le fait de vraiment... tester l'appétence du marché, de mesurer le taux d'engagement des utilisateurs face à différents crans d'engagement entre liker un poste et faire une précommande et directement mettre sa carte bancaire, ce n'est pas le même niveau d'engagement. Donc ça donne aussi de la sécurité sur ce que tu vas faire. Et du coup, en fait, surtout c'est le fait de tester sans biais, parce que là on est sûr que l'utilisateur n'a pas de... biais autour pour dire il s'est inscrit parce qu'en fait je l'ai poussé ou en fait il a pris ce produit parce que je l'ai poussé, lui pour lui c'est une expérience, une vraie expérience comme il aurait sur un vrai produit il voit pas la différence, par contre à la fin il faut trouver un moyen de gérer le fait qu'il va pas forcément avoir accès au produit en fait il faut arriver à gérer la frustration de l'utilisateur parce que tu vois un truc c'est super bien, j'ai envie de précommander, j'ai envie de m'inscrire et en fait il y a un moment où on disait mais... À formuler, on peut dire très bien, tu es sur de la précommande, tu seras bêta-testeur entre contacts. C'est la rançon du succès. Comment ?
Speaker #0
C'est la rançon du succès. C'est un peu ce qu'on cherche d'ailleurs. Parce que si l'utilisateur s'en fout, c'est qu'on n'est pas sur le bon truc. Alors que si l'utilisateur est frustré à la fin, c'est dire, on a mis le doigt sur quelque chose. C'est un peu le mode fake it until you make it. Et j'aime bien ton idée de tant qu'il n'a pas mis sa carte bleue, il n'a pas vraiment donné son avis parce qu'un avis, on peut tous dire oui, c'est sympa, c'est joli, etc. Mais c'est au moment où on paye quelque chose que ça fait toute la différence.
Speaker #1
Là, quand tu as l'utilisateur qui commence à donner ses données personnelles, qui est prêt à précommander quelque chose, le niveau d'engagement n'est pas le même que j'ai liké le poste. C'est ces crans-là qui peuvent aussi se dire... Si j'ai 80% de mes mesures, de mon taux d'engagement, c'est du like et du commentaire. Et en fait, je n'ai aucune personne qui est allée jusqu'à ce que j'ai mis en place, qui est allée jusqu'à s'inscrire, donner des informations personnelles, voire payer. On peut peut-être aller retester autrement pour un peu plus sécuriser. le concept, la demande utilisateur.
Speaker #2
Donc ça veut dire qu'au niveau des prétypes qu'on peut mettre en place, ça peut être des postes LinkedIn, des mails qu'on peut envoyer, différentes choses comme ça.
Speaker #0
Nous allons revenir au podcast dans quelques secondes, mais j'ai une question pour vous. Est-ce que vous êtes capable de mesurer la performance de vos projets IT ? Si la réponse est non, vous perdez sûrement déjà du temps et de l'argent. Ce podcast vous est présenté par Exfabrica, une USN qui aide les directions métiers et IT Merci. à exiger du ROI dans leur projet. Chez AXA Abrica, nous traitons deux problèmes majeurs. Le manque de performance et le manque d'engagement sur vos projets de développement, trop souvent synonyme de retard et de dépassement de budget. Comment ? En mobilisant une équipe de développement qui s'engage sur le résultat et la performance, et en appliquant une méthode éprouvée pour tous vos projets de développement, modernisation et architecture, expérience développeur ou encore cadrage projet. Vous pouvez dès maintenant prendre rendez-vous en suivant le premier lien en description. Et retrouvez-moi à la fin de cet épisode pour en savoir plus sur notre offre. Allez, on y retourne.
Speaker #2
Donc, ça veut dire qu'au niveau des prétypes qu'on peut mettre en place, ça peut être des postes LinkedIn, des mails qu'on peut envoyer, on va se mettre différentes choses comme ça.
Speaker #1
Toi, tu étais à ma conférence. Oui, effectivement, en fonction du sujet, en fait, il y a plein de moyens. différent. Les choses qui sont assez simples, c'est de faire un post sur les réseaux sociaux, que ce soit LinkedIn, Instagram, Facebook, ça dépend de la cible et du sujet. Mais c'est simple de faire une image avec un petit texte, un petit lien qui va renvoyer soit un formulaire d'inscription, soit un site fictif pour présenter un peu plus en détail. Après, la personne va s'inscrire. Donc ça, c'est hyper rapide. Soit on est prêt à payer, faire un peu du... des postes payants. Soit on a la communauté qui peut suivre, parce que si vous avez un compte LinkedIn avec 100 personnes qui suivent, c'est peut-être pas le meilleur endroit pour faire un poste.
Speaker #0
Sympa révélateur, le test.
Speaker #1
C'est aussi une stratégie. Sur l'exemple dont je parle dans ma conférence, nous, on a fait vraiment... On a créé un écosystème de pré-totypes. où on va tester dans les magasins en réel, on va tester sur des utilisateurs qui sont sur les réseaux sociaux, on va tester sur des utilisateurs dans une base du mailing list, donc en fait ceux qui vont recevoir le mail. Donc on a différentes typologies d'utilisateurs qui vont nous permettre déjà d'avoir une quantité suffisante de données, mais aussi on ne se parque pas à tous ceux qui sont sur LinkedIn ou tous ceux qui sont accrochés à leur mail, parce qu'en fait on a un peu En plus les mails, en termes de newsletter, le taux de clics, la déperdition pour atteindre le tunnel de conversion, ce n'est pas le plus simple.
Speaker #2
Et donc du coup le deuxième niveau après c'est le prototype. Là on est un peu plus engagé déjà dans le projet ou le produit. Oui,
Speaker #1
donc là le prototype c'est un peu plus concret. Même si je disais au début, effectivement, que dans le PrétoType, il y a des choses qu'on associe au prototypage. Dans les techniques de PrétoType, en fait, je parle aussi de MVP, je parle aussi de Pinocchio. En fait, c'est une version non fonctionnelle. Je parle aussi de tests sur des petits échantillons. C'est provincial, donc en fait, c'est vraiment sur un petit truc. On peut se rapprocher aussi du prototype. La frontière entre les deux, elle est assez fine. Après, est-ce que c'est parce que c'est un abus du fait que nous, on ne connaît que le prototype ? Du coup, on a un peu gratté le pré-totype, mais on n'utilise pas le terme pré-totype.
Speaker #0
Le prototype, c'est quelque chose qui est censé être activable, c'est-à-dire réalisé derrière. C'est-à-dire, c'est un plan pour réaliser un pré-totype. On teste, mais on ne sait pas forcément comment le réaliser à ce moment-là.
Speaker #1
Alors, effectivement, le prototype, on ne sait pas forcément comment le réaliser parce qu'on mesure la pétance. Donc, on voit et après on ajuste. Le prototype, on ne sait pas forcément comment le développer. Et en fait, ce qui sort du prototype, parce que moi, j'en parle effectivement au sein d'un design sprint. Un design sprint, c'est toujours au niveau stratégie, conception. À la sortie d'un design sprint, on n'a pas de quoi développer. C'est juste pour valider un concept. un peu plus concrètement auprès des utilisateurs. Et après, du coup, il y a forcément une phase entre la partie prototype dans le design sprint et la phase on bascule en délivrer. Et le prototype qu'on va concevoir, il va être plus concret parce qu'en fait, on sait ce que l'utilisateur cherche, le besoin ou le problème qu'il rencontre surtout. Et on va le traduire, on va trouver une solution, on va la traduire en maquette. Après, moi je parle sur du digital parce que je travaille sur du digital, mais on peut très bien prototyper des choses qui ne sont pas digitales. On peut prétyper des choses qui ne sont pas digitales. Mais ça s'y prête hyper bien en fait. C'est hyper rapide en digital de produire des maquettes, d'itérer, de montrer aux utilisateurs. enfin voilà je veux dire Si je dois tester un espace, si je fais du design de service, si je dois prototyper un espace ou prototyper une expérience, on n'est pas sur le même format. Et après, au niveau du prototypage, c'est des techniques assez connues, assez simples. En fait, ça dépend du niveau de la personne. Je veux dire, si on est un designer, c'est banco, mais on n'a pas de designer. Donc, je disais, effectivement, on peut juste essayer une interface en la faisant sur PowerPoint. En fait, on va faire des zones. Effectivement, des fois, il y a des gens qui maîtrisent très bien PowerPoint, qui peuvent s'en sortir à faire des interfaces sur PowerPoint. Bien sûr.
Speaker #3
C'est accessible, PowerPoint.
Speaker #1
Oui, et même moi, ça m'est arrivé de faire des fois des interfaces sur Miro. Oui, très bien. En fait, c'est hyper simple et c'est beaucoup plus facile en plus de faire du collaboratif. pour construire une interface. Donc on peut faire des écrans prototypes, on peut montrer des écrans, on va montrer des écrans à la personne alors qu'ils ne sont pas forcément reliés entre eux, sur une image. Après, on peut avoir des prototypes où c'est des maquettes qui sont connectées les unes aux autres. Et là, l'utilisateur a plus l'impression d'être sur l'interface, même si en termes de conception, on ne va pas concevoir tout le produit puisque la partie prototype sur un design sprint, on est quand même sur On n'a que 5 jours, donc on est quand même sur un périmètre assez restreint. Mais on peut faire des interactions et on va un petit peu guider l'utilisateur dans le protocole de test. On va lui donner un objectif à faire dans l'interface et on va étudier comment il arrive à le faire dans l'interface, qu'est-ce qu'il comprend, qu'est-ce qu'il ne comprend pas. Et après, la dernière version qui peut être super intéressante, ça dépend des compétences. de la personne et du temps qu'on a et aussi du sujet qui s'y prête ou non, on peut faire du no code hyper rapide no code ou low code et on peut tester un produit effectivement si on a un produit où on a beaucoup si on a vraiment testé il y a beaucoup de formulaires à remplir, il y a beaucoup d'étapes c'est quelque chose qui est assez crucial dans l'expérience moi j'ai déjà fait des prototypes, c'était pas crucial donc en fait vous imaginez que vous cliquez là et ça se remplit Merci. En fait, on pourrait très bien avoir sur certains cas, une spot, oui, en fait, la compréhension. Il y a une interface très complexe si on est sur des trucs métiers. Mais en fait, ça peut peut-être avoir un intérêt de qu'est-ce que tu comprends quand tu cliques ? Il va essayer de saisir, en fait, il va dire « Ah, je pensais que ça allait faire ça » , des choses comme ça. Mais ça, il faut avoir la compétence pour le faire.
Speaker #0
OK, même si de nos jours, avec le ZTIA, etc., on peut aller plus loin. Maintenant, peut-être, à la place du no-code, faire un lovable ou autre, ça peut...
Speaker #1
Oui, maintenant, les outils pour construire des interfaces, effectivement... C'est pour du prototype, ce n'est pas l'interface finale, mais rapidement, j'avais vu des démos à une conférence et elle disait qu'en deux heures, elle avait réussi à faire ce qu'elle voulait. Après, il y a eu le piège de... C'est pas mal ce que j'ai fait ! En fait, elle a fini à deux heures du matin. mais effectivement il y a des logiciels maintenant qui permettent ouais voilà mais pris par la capacité à faire et l'envie de faire mieux et d'aller toujours un petit peu plus loin et aussi mettre des garde-fous sur ce qu'on conçoit parce que sinon c'est aussi intéressant que le design sprint c'est que le design sprint on a 15 jours pour faire le prototype et on peut pas rallonger en fait c'est le mercredi soir on sait ce qu'on va faire et le vendredi matin 9h il faut que le prototype soit fait Merci. que le protocole de test soit fait et on ne peut pas... Ah,
Speaker #0
mais le force-beat unboxing.
Speaker #1
C'est intéressant parce que ça veut dire qu'en fait, même au-delà de ce qu'on veut tester, on est obligé de prioriser ce qu'on veut tester dans le protocole et dans le prototype. Donc là, la priorité, c'est de comprendre s'il arrive à faire ça, s'il comprend ça, s'il atteint son objectif. Et en fait, en fonction de ça, on va aussi construire les parcours. Moi, ça m'est déjà arrivé sur le Design Sprint toi. On s'emballe, on s'emballe. Moi, j'ai qu'une journée. On se calme.
Speaker #2
Est-ce que tu as déjà des exemples sur lesquels le fait de tester en amont, ça a vraiment fait la différence en disant qu'on est parti complètement du mauvais côté ou au contraire, ça permet de réorienter le projet ?
Speaker #1
Des bons exemples ou des mauvais exemples ?
Speaker #0
Tu peux donner les deux.
Speaker #1
Moi, l'expérience dont je parle dans ma conférence, on a fait pré-totype et prototype. En fait, ça s'est super bien passé parce qu'on avait les bonnes personnes dans l'équipe pour justement gérer toutes les parties du pré-totype. Et la finalité, c'est que ça a amené assez de matière, assez de feedback terrain et de validation terrain pour que quand ils ont demandé les budgets, en fait, ça a été validé. Donc l'investissement a été fait sur cette partie-là. Et je crois que c'était l'un des seuls projets portés qui a eu l'investissement dont il avait besoin par rapport au tout. Donc ça a fait la différence. En termes de prototype, donc là j'avais fait que la partie Design Spring Prototype. On avait fait un projet où au final, le vendredi, mais en fait, les feedbacks du tuteur, c'était... C'était assez mitigé, il n'y avait pas de vrai engouement. C'est incroyable, ça répond à un super besoin. Et du coup, c'était assez mitigé. Et ça a quand même testé un concept assez fort, en différenciant de ce qu'il proposait. Et ça leur a permis à eux de dire, OK, en fait, il va peut-être falloir pivoter. Peut-être que la manière dont on a voulu aborder ça, en fait, ce n'est pas la bonne. Mais ça leur a quand même donné des petites indications micro sur, ah, ça, c'est intéressant, on va peut-être pouvoir le réinjecter dans notre produit ou en peut-être l'utiliser différemment. Et après, le dernier exemple dont je parle dans ma conférence, où c'était un fail complet. C'était le prétypage où c'était sur de la banque. On n'avait pas les bons accès, problème de sécurité, banque super sécurisée. On n'avait pas les bons accès, les bonnes personnes dans l'équipe pour avoir des accès à des mailing lists, envoyer des mails directement depuis leur service à eux pour pas que ça passe en mode, c'est de l'hameçonnage, des choses comme ça, qu'on ait les bonnes url. Donc en fait, on n'a rien pu faire en termes de prétypage. Par contre, comme on vient de dire, c'est de la prestation, on avait vendu pré-tout type et prototype. On a quand même fait la partie prototypage dans un design sprint. Ça a quand même permis de valider certains besoins parce qu'il y en avait besoin quand même pour aiguiller. Mais comme on est sur la phase stratégie conception, ça permet eux de savoir s'ils doivent aller plus loin, s'ils vont aller chercher du budget et des choses comme ça. Je veux dire, le... Le pré-totypage et le prototypage vont dérisquer le développement, mais le pré-totypage va permettre aussi de dérisquer le prototypage. Donc, plus on dérisque de ce qu'on dérisque.
Speaker #0
De la même façon qu'on a une approche agile, itérative pour construire le produit, on peut avoir une approche itérative des tests pour dérisquer les phases suivantes à différents niveaux. Et le pré-totype, ça va à ça.
Speaker #1
Après, je pense que je ne me suis jamais retrouvée dans ce cas-là, mais d'avoir effectivement plusieurs... En fait, si le premier pré-totypage, c'est pas bon, c'est mitigé, on n'a pas accès correctement, est-ce qu'il ne faut pas en refaire un ?
Speaker #3
Eh oui.
Speaker #1
On est quand même sur des délais assez courts, j'ai envie de dire. C'est une, deux semaines. On ne va pas aller plus loin parce qu'après, on va créer une inertie. Il faut d'abord mettre en œuvre. Mais même, ça va créer une inertie dans le projet. Ce n'est pas possible. Le prototypage ou même le design sprint, le design sprint, ça permet d'être sur un temps très court, d'être focus. À l'inverse, si on faisait ça, on fait une réunion. Puis dans deux semaines, on fait une autre réunion. Ça crée une inertie. Les gens sont sur d'autres projets, le temps qu'ils reviennent et tout. donc Ce n'est pas forcément intéressant. Et même dans le design sprint avec le prototypage, on peut refaire à la suite des retours utilisateurs un autre design sprint qui va réorienter l'axe qu'on avait choisi. Moi, ça m'est déjà arrivé. Effectivement, on a des retours. On va refaire un prototype pour pouvoir le retester après parce que les retours qu'on a eus ne nous permettent pas de dire oui, on continue ou oui, on arrête. Et c'est mitigé sur comment on pivote.
Speaker #2
Et du coup, tu parles plusieurs fois de Design Sprint. Est-ce que tu peux expliquer rapidement où ça consiste ?
Speaker #1
Design Sprint, c'est basse américain. Ça a été inventé par Jack Knapp de Google Venture. C'est une méthode qu'il a mise en place, qu'il a testée, qu'il a itérée chez Google Venture et qu'il a stabilisé. Et il a écrit un livre sur ça, justement. Et c'est une méthode, en fait, en cinq jours, on va dérisquer une idée, un concept. On ne peut pas dérisquer un produit en entier parce que cinq jours, en fait, c'est trop peu. Et en fait, dans l'idéal, c'est cinq jours. Il y en a qui arrivent des fois à le raccourcir, le tordre, l'allonger.
Speaker #0
J'ai vu des versions trois jours.
Speaker #1
C'est dense. Parce que déjà, cinq jours, c'est dense.
Speaker #0
En fait, on a un feedback comme quoi cinq jours, c'est impossible de bloquer les gens. En fait, sur un projet, dire on ne prend que 5 jours, c'est une question de point de vue.
Speaker #1
Oui, mais ça m'est déjà arrivé de faire des end-prings où ce n'était pas possible. C'était des choses musicales. Ah oui,
Speaker #0
oui.
Speaker #1
Un qui est là un jour, un qui n'est pas là, mais c'est un autre jour, qui prend le relais et tout. Et en fait, ils n'ont pas le même niveau d'information, ils n'ont pas le même niveau d'implication. Et c'est hyper compliqué à gérer. Donc en fait... De toute façon,
Speaker #0
tu joues sur la force du focus. C'est le fait, à un moment donné, d'être concentré sur une seule tâche. Et limite d'essayer en groupe de rentrer en flot sur cette tâche pour pouvoir essayer d'accomplir beaucoup de choses.
Speaker #1
J'ai écrit un article sur être designer dans un design sprint. Du coup, je détaille en fait tout ce qui se passe. Moi, je détaille aussi des hacks que j'ai pour aller plus vite. Tu as le lien,
Speaker #0
on le mettra en description de l'épisode.
Speaker #1
Et en fait, j'ai fait une illustration. En fait, on a des émojis dans quel état on est à la fin de la journée. Donc, on peut dire qu'on est en PLS tous les jours. En termes de détails, c'est que le lundi, ce mois c'est Design & Sprint. Moi j'adore cette méthode parce que j'arrive sur des sujets que je ne connais pas. Et en fait, j'apprends plein de trucs hyper rapidement. Et en fait, l'objectif c'est qu'en un jour, je sois opérationnelle sur le sujet pour être au niveau du client. Et donc le premier jour, c'est on prend toutes les données, terrain, on analyse, on voit avec les experts. On cadre un peu sur quel périmètre on va aller sur la carte de l'expérience. Le mardi, pour moi, c'est la partie facile. C'est tout ce qui est créativité. Donc, en fait, on va faire un bench. Soit on a des gens qui sont à l'aise avec ça. Soit nous, on commence à faire un bench pour les aider, pour ouvrir un peu les chakras. ouvrir la créativité et l'après-midi on a des petites étapes pour justement les aider à débloquer des idées construire des interfaces donc ça on fait tout ça et le mercredi matin ce qui est bien et moi je trouve que c'est hyper important et en fait toutes les méthodes du Design Spring moi je les utilise mais pas en faisant un Design Spring c'est plein d'ateliers en fait qu'on a imbriqués donc c'est des ateliers qu'on peut réutiliser et le mercredi matin c'est la galerie et en fait c'est silencieux C'est-à-dire que personne ne présente son projet, son idée. C'est censé être autoporteur. C'est-à-dire que les personnes, elles ont mis effectivement des post-it autour de leurs idées, de ce qu'elles ont imaginé, dessiné. Et c'est censé être autoporteur. Donc en fait, il n'y a pas le biais de... Il y en a un qui parle super bien à l'oral, mais en fait, son idée, elle est pourrie. Il y en a un, il n'est pas à l'aise à l'oral, mais son idée, il est super bien. Donc personne n'est desservi par ses qualités ou ses défauts. Donc tout le monde est au même niveau. Donc, des fois, il faut quand même les cadrer parce qu'il y en a qui commencent à les présenter, ces projets. Non, Les gens sont tout seuls, lisent et après, ils peuvent poser des questions. Et souvent, c'est le Sprint Master qui va aider à répondre, des choses comme ça. Mais les personnes ne présentent pas eux-mêmes leurs projets parce que sinon, ça rend des avantages certains. Et le mercredi, du coup, on cadre dans le sens… Il y a eu plein d'idées. Donc, qu'est-ce qu'on prend comme solution ? Est-ce qu'on peut prendre des morceaux de solution ? quel parcours on va définir à tester, quand même définir un parcours qu'on va tester auprès de l'utilisateur. Et le jeudi, on part en phase de prototypage. Donc là, si on est un designer, c'est mieux. Mais on peut ne pas avoir de designer. Et là, en fait, le designer, il va produire les écrans, les interfaces, là où il a son expertise. Et toutes les autres personnes qui sont là, elles sont là pour l'aider. Elles vont chercher tout le contenu, rédiger les choses, chercher les photos. Le designer, il n'a pas le temps de faire ça. Donc, tout le monde est sollicité. Donc, souvent, le jeudi matin, on se met en ordre de bataille. On répartit. Toi, tu fais ça, tu dois livrer à telle heure. On refait un point de synchro. Toi, tu fais ça, machin. Et il y a quelqu'un, dans l'idéal, qui chapote un peu la vision globale parce qu'il faut quand même que le parcours, le contenu soient cohérents. Le jeudi soir, non, en parallèle, le jeudi, il y a quelqu'un qui fait le protocole de test pour le lendemain. Et le jeudi soir, si on a de la chance on termine tôt sinon on termine tard. Moi ça m'est déjà arrivé de terminer à 23h parce qu'en fait il me manquait des cas et c'était hyper complexe à comprendre et il y a un moment à temps d'air qu'on n'a plus de cerveau. Donc les choses qu'on fait 6 minutes, on met une demi-heure à comprendre. Et le vendredi matin, on fait des tests. Donc il y a eu un recrutement utilisateur. soit en amont du sprint, soit pendant le sprint, ça dépend comment on a organisé. Et là, on fait tester. Et ce qui est bien, c'est qu'on invite tous les participants au sprint. Ils sont là, mais on peut aussi inviter les parties prenantes, les décideurs qui sont plus hauts. Ceux qui ont acheté le sprint, ils vont venir. Et en fait, ce qui est hyper bien, c'est qu'ils vont voir directement les utilisateurs. Ils aiment bien ça, ils adorent. Et des fois, il y a des pépites, des pépites en termes de test, sur du feedback ou sur des contextes utilisateurs. Moi, j'ai eu des tests et on regarde ça, et je me dis, la personne qui anime les tests, elle a une patience folle parce qu'il y a des tests où la personne ne va pas être à l'aise avec un ordinateur, elle ne va pas être à l'aise avec la caméra. Et du coup, on va avoir la webcam, mais elle n'arrive pas à la régler. Du coup, la webcam, on ne voit que le haut de sa tête. C'est assez drôle où la personne ne comprend même pas comment on peut partager son écran. donc au final c'est un peu mais c'est la personne qui mène les tests, qui partage son écran, qui va poser des questions. Donc, c'est du hack en plein test pour avoir du feedback. Parce que sinon, et on prévoit aussi le vendredi, on a toujours un test de backup. Normalement, c'est cinq, mais on en prend six, voire on en prend sept pour avoir du backup.
Speaker #0
Il peut toujours y avoir des testements ou un peu de technique.
Speaker #1
Le vendredi. On essaie de finir tôt quand même, mais vendredi soir on a une synthèse, qu'est-ce que vous avez retenu dans les feedbacks, qu'est-ce que vous en avez pensé ? Et après c'est un peu le... alors ça je ne suis pas sûre si ça va dans le design sprint officiel, mais c'est quoi les prochaines étapes ? C'est quoi les prochaines actions ? On se met en ordre de marche, parce que sinon ça peut retomber comme un triplé. exactement donc la semaine prochaine vous faites quoi ? je pense pas que tu as d'indicé en sprint mais je pense que naturellement et si tu encres pas des next steps systématiquement sur ce genre d'étape ça fonce pas c'est vraiment prochaines étapes la semaine prochaine qu'est-ce que vous faites qu'est-ce que vous allez présenter vous allez valider qu'est-ce que vous allez valider à qui et ça permet d'embrayer sur la suite et que ça retombe pas parce que c'est vraiment dommage il y a énormément il y a énormément d'effervescence sur le projet Merci. Et ce qui est hyper bien avec le design sprint, c'est qu'en fait, toutes les personnes qui ont participé, elles deviennent ambassadrices de l'idée, de la solution. Et en fait, ça diffuse. Ça fédère. Ça éligne. Voilà. Et ça, c'est hyper intéressant parce que dans les design sprints, en plus, on prend souvent des personnes qui sont plus loin de l'idée et qui ont des axes différents, qui ont des expertises différentes. Et en fait, tout le monde amène sa vision. sa vision des choses, son angle des choses aussi parce qu'en fait il y en a ils vont voir ça comme ça et d'autres pas du tout. Moi ça m'est déjà arrivé sur un sprint où en fait j'avais des gens qui étaient très opérationnels, très techniques et en fait dans l'interface ils me proposent de mettre ça et en fait je leur fais est-ce que vous êtes sûr que les utilisateurs ils vont comprendre ce que vous êtes en train de me dire d'écrire ? Oui oui il n'y a pas de souci, t'as le succiateur vendredi, c'est quoi cette abréviation, ça veut dire quoi ? c'est aussi les ramener au terrain aux utilisateurs c'est un peu d'empathie si une personne si vous mettez à la place d'un utilisateur lambda qui ne connait pas votre produit est-ce qu'il va vraiment comprendre ce que vous lui proposez bon Noemi on
Speaker #0
est en train de se faire envahir je trouve que c'est la pause c'était super euh tu me donneras le lien du blog que tu as cité si on veut te contacter sur LinkedIn on mettra ton lien à LinkedIn et puis encore merci d'être venue en prod et puis à Fébri et à Montpellier et à Montpellier bravo d'être réussie à devenir à Montpellier beau parcours pour la petite histoire ceux qui veulent savoir vous faites un feedback sur cet épisode à Noémie elle vous raconte la petite histoire derrière Merci. Et puis, comme d'habitude, vous n'oubliez pas, vous devez liker, vous abonner et vous abonner à Newsletter. Puisque j'envoie un email une fois par mois avec une ou deux vidéos qu'on enregistre et des ressources, des articles, etc. que je partage beaucoup.
Speaker #2
Merci. Merci Marion.
Speaker #0
Merci Noémie. 94% des fonctionnalités développées ne sont pas utilisées. Pour ne pas flambler votre budget, il faut tester avant de développer. Le préto-typing pour valider que le besoin existe, le proto-typing pour vérifier que votre solution est comprise et le design sprint pour faire tout ça en 5 jours. C'est exactement la philosophie qu'on porte chez Axabrica. Avant de développer, on vous aide à valider vos hypothèses sur le terrain avec des ateliers de discovery, des design sprints et du prototypage rapide. Si vous avez un projet de développement de solutions IT sans mesure et que vous voulez investir votre budget sur ce qui compte vraiment pour vos utilisateurs, contactez-nous. Le lien est en description. Et n'oubliez pas, le monde se divise en deux catégories. Ceux qui suivent en parent prod.

Description

📅 Discutons de VOTRE projet

🎁 Guide et résumé
💌 Abonnez-vous à la newsletter

▬▬▬▬▬▬▬▬▬▬

Noémie Rivière, Senior Product Designer chez OnePoint, explique comment le pretotyping et le prototyping permettent de valider vos idées avant de gaspiller votre budget en développement.

Ce que vous allez apprendre :

La différence entre pretotyping et prototyping (et pourquoi ce n'est pas la même chose)
Les niveaux d'engagement utilisateur : du simple like jusqu'à la carte bancaire, et pourquoi seul ce dernier compte vraiment
Comment mesurer l'appétence du marché sans biais, en faisant croire à l'utilisateur que le produit existe
Les techniques de pretotypage : turc mécanique, posts réseaux sociaux, mailing list, site fictif
Comment un design sprint de 5 jours peut vous éviter des mois de développement inutile
3 retours terrain : un projet financé grâce au pretotyping, un qui a pivoté juste à temps, et un échec riche en leçons
Pourquoi le pretotypage dérisque le prototypage, qui lui-même dérisque le développement

🎬 Ressources mentionnées

Article de Noémie : "Product Designer dans un Design Sprint : les conseils pour être efficace et pertinent !" https://medium.com/@campb_LLs/product-designer-dans-un-design-sprint-les-conseils-pour-%C3%AAtre-efficace-et-pertinent-2745180aa944
Alberto Savoia https://www.albertosavoia.com/
Pretotyping https://www.pretotyping.org/
"Sprint" de Jake Knapp (Google Ventures), le livre de référence sur le Design Sprint

Pour suivre l'actualité de Noémie
LinkedIn : https://www.linkedin.com/in/noemiemelidariviere/

▬▬▬▬▬▬▬▬▬▬

Postproduction Audio : Guillaume Lefebvre (https://studioecho.webflow.io/)

Music by MADiRFAN from Pixabay

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Dans sa conférence, Noémie Rivière explique que 94% des fonctionnalités développées sur un produit numérique ne sont pas utilisées. 94%. Pourtant, la majorité des équipes continuent de foncer dans le développement sans vérifier si ce qu'elles construisent répond à un vrai besoin. Le problème, ce n'est pas le développement. C'est tout ce que vous ne faites pas avant. Il existe des techniques rapides et peu coûteuses pour savoir en quelques jours si votre idée mérite d'être développée. La clé ? Testez sans que l'utilisateur sache que le produit n'existe pas encore. Avec Marion Saint-Sart, Delivery Manager chez Exabrica, nous avons interviewé Noémie Rivière en marge de sa conférence à la JTour Montpellier. Noémie est Senior Product Designer chez OnePoint, avec plus de 14 ans d'expérience en design de produits, notamment sur des design sprints pour Cédiscount, Société Générale, Decathlon ou Cultura. Dans cet épisode, vous allez découvrir la différence entre préto-typing et proto-typing, les niveaux d'engagement utilisateur, du simple like jusqu'à la carte bancaire, et pourquoi seul ce dernier compte vraiment, comment un design sprint de 5 jours peut vous éviter des mois de développement inutiles, et des retours de terrain, un projet financé grâce au prototyping, un note qui a pivoté juste à temps et un échec riche en leçons. Et comme d'habitude, si vous n'avez pas le temps de regarder l'interview complète, nous avons préparé un guide résumé de cet épisode. Le lien est en description. Cet épisode a été enregistré au cœur de la JTour. Vous entendrez un peu l'ambiance de l'événement en fond sonore. Place à l'interview. Noémie, pourquoi tester avant de démarrer le développement ?
Speaker #1
Tester, c'est avant tout pour dérisquer, que ce soit le développement ou même plus en amont, la stratégie. Si je teste vraiment au niveau stratégie, conception, ça va me permettre d'échouer plus rapidement et de savoir si je suis dans la bonne direction. Parce que ce qui coûte le plus cher sur un projet, c'est le développement. Donc, plus on teste en amont. plus on dérisque, on échoue plus vite. Et comme ça, on peut réorienter, soit pivoter, parce que ça ne convient pas tout à fait, soit carrément abandonner l'idée, le concept qu'on avait, parce que ça ne répond à aucun besoin utilisateur.
Speaker #2
Et du coup, quel type de test on peut mettre en œuvre pour dérisquer en amont du projet ?
Speaker #1
On peut utiliser le prétyping, on peut prétyper. Ce qui est intéressant, c'est vraiment de pouvoir mesurer l'appétence du marché. Donc vraiment savoir si les utilisateurs et les utilisatrices ont de l'appétence pour notre idée, notre concept, notre produit.
Speaker #0
Prétotyping, c'est un prototype que tu fais très en amont.
Speaker #1
Non, ce n'est pas la même chose. Il y a le pré-totype et le prototype.
Speaker #0
Ok.
Speaker #1
Effectivement, dans le pré-totype, on peut avoir des choses qu'on utilise déjà dans nous, ce qu'on connaît du prototype.
Speaker #3
D'accord.
Speaker #1
Pas évident non plus. Après, le pré-totype, c'est quelque chose qui n'est pas forcément très connu en France, qui est très utilisé. Mais c'est une technique qui est hyper intéressante pour ne pas flamber le budget dès le début ou à la fin. Du coup, en termes de méthode...
Speaker #0
Juste pour comprendre, le pré-totype, c'est un prototype plus léger. C'est quoi le... Je me représente très bien des prototypes à différents niveaux de qualité, à différents moments dans un vide-projet, etc. Le pré-totype, si ça correspond à quelque chose de différent, je ne le représente pas.
Speaker #1
En fait, ça va être des techniques pour mesurer l'appétence du marché et le niveau d'engagement des utilisateurs. Mais en fait, ça va être des techniques... Ça peut être le Turc Mécanique où en fait, au lieu de créer le logiciel, ça va être une personne de l'autre côté qui va faire semblant d'être le logiciel, le temps de le tester. Et après, effectivement, quand c'est positif en termes de retour, on a testé en fait vraiment l'utilisateur. Il a l'air d'être intéressé par cette fonctionnalité, ce produit. Et là, après, on va aller peut-être dans plus du prototypage. où on va concevoir plus concrètement l'interface, la partie du produit et peut-être les messages. Mais l'idée, c'est vraiment le prototype. La différence, c'est qu'on est déjà un peu plus sur du concret. On a déjà l'idée, on a la solution. Et en fait, sur le prototype, on va plus vérifier le besoin et vérifier la compréhension de l'utilisateur sur ce qu'on a imaginé. Parce qu'en fait, on peut très bien être bon sur la pétance du marché. pour le besoin, mais en fait, on l'a mal traduit dans le prototype et en fait, l'utilisateur, il va... comprendre et en fait il va pas non plus utiliser le produit donc les tests à différents niveaux au delà effectivement des tests un test QA et test développement bug en fait ça va permettre de vérifier et dérisquer que quand on part en dev en fait on est serein sur le fait que on répond à un besoin que l'utilisateur va comprendre et que l'utilisateur va utiliser dans ma conférence je dis effectivement qu'il y a 6% des fonctionnalités sur un produit qui sont utilisés par les utilisateurs Donc, ça veut dire qu'on a développé 94% qui ne sont pas utilisés.
Speaker #0
Ce gaspillage, c'est terrible.
Speaker #2
Donc, ça veut dire que le pré-totip, c'est vraiment au tout début pour être sûr qu'il y a un réel besoin ou que notre stratégie qu'on veut mettre en place est la bonne.
Speaker #1
Oui, c'est vraiment en amont et ce n'est même pas la stratégie. Je pense que c'est vraiment, en fait, tu as une idée, tu as un concept, tu as un concept comme ça. Et en fait, il faut que tu vois si ça fit avec le marché. Si le marché, il répond positivement. Et avec le prototype, ce qu'il faut surtout faire, c'est que l'utilisateur, il ne sait pas que c'est faux. En fait, pour ne pas introduire de biais, parce qu'effectivement, je vous dis dans ma conférence, c'est que si vous demandez à vos amis des choses comme ça, tu en penses quoi de mon idée, de mon projet, mon produit ? Ah, c'est super et tout. Ils ne vont pas vous dire que c'est pourri. Forcément, tu as fait bien. Voilà. Et en fait, le fait de vraiment... tester l'appétence du marché, de mesurer le taux d'engagement des utilisateurs face à différents crans d'engagement entre liker un poste et faire une précommande et directement mettre sa carte bancaire, ce n'est pas le même niveau d'engagement. Donc ça donne aussi de la sécurité sur ce que tu vas faire. Et du coup, en fait, surtout c'est le fait de tester sans biais, parce que là on est sûr que l'utilisateur n'a pas de... biais autour pour dire il s'est inscrit parce qu'en fait je l'ai poussé ou en fait il a pris ce produit parce que je l'ai poussé, lui pour lui c'est une expérience, une vraie expérience comme il aurait sur un vrai produit il voit pas la différence, par contre à la fin il faut trouver un moyen de gérer le fait qu'il va pas forcément avoir accès au produit en fait il faut arriver à gérer la frustration de l'utilisateur parce que tu vois un truc c'est super bien, j'ai envie de précommander, j'ai envie de m'inscrire et en fait il y a un moment où on disait mais... À formuler, on peut dire très bien, tu es sur de la précommande, tu seras bêta-testeur entre contacts. C'est la rançon du succès. Comment ?
Speaker #0
C'est la rançon du succès. C'est un peu ce qu'on cherche d'ailleurs. Parce que si l'utilisateur s'en fout, c'est qu'on n'est pas sur le bon truc. Alors que si l'utilisateur est frustré à la fin, c'est dire, on a mis le doigt sur quelque chose. C'est un peu le mode fake it until you make it. Et j'aime bien ton idée de tant qu'il n'a pas mis sa carte bleue, il n'a pas vraiment donné son avis parce qu'un avis, on peut tous dire oui, c'est sympa, c'est joli, etc. Mais c'est au moment où on paye quelque chose que ça fait toute la différence.
Speaker #1
Là, quand tu as l'utilisateur qui commence à donner ses données personnelles, qui est prêt à précommander quelque chose, le niveau d'engagement n'est pas le même que j'ai liké le poste. C'est ces crans-là qui peuvent aussi se dire... Si j'ai 80% de mes mesures, de mon taux d'engagement, c'est du like et du commentaire. Et en fait, je n'ai aucune personne qui est allée jusqu'à ce que j'ai mis en place, qui est allée jusqu'à s'inscrire, donner des informations personnelles, voire payer. On peut peut-être aller retester autrement pour un peu plus sécuriser. le concept, la demande utilisateur.
Speaker #2
Donc ça veut dire qu'au niveau des prétypes qu'on peut mettre en place, ça peut être des postes LinkedIn, des mails qu'on peut envoyer, différentes choses comme ça.
Speaker #0
Nous allons revenir au podcast dans quelques secondes, mais j'ai une question pour vous. Est-ce que vous êtes capable de mesurer la performance de vos projets IT ? Si la réponse est non, vous perdez sûrement déjà du temps et de l'argent. Ce podcast vous est présenté par Exfabrica, une USN qui aide les directions métiers et IT Merci. à exiger du ROI dans leur projet. Chez AXA Abrica, nous traitons deux problèmes majeurs. Le manque de performance et le manque d'engagement sur vos projets de développement, trop souvent synonyme de retard et de dépassement de budget. Comment ? En mobilisant une équipe de développement qui s'engage sur le résultat et la performance, et en appliquant une méthode éprouvée pour tous vos projets de développement, modernisation et architecture, expérience développeur ou encore cadrage projet. Vous pouvez dès maintenant prendre rendez-vous en suivant le premier lien en description. Et retrouvez-moi à la fin de cet épisode pour en savoir plus sur notre offre. Allez, on y retourne.
Speaker #2
Donc, ça veut dire qu'au niveau des prétypes qu'on peut mettre en place, ça peut être des postes LinkedIn, des mails qu'on peut envoyer, on va se mettre différentes choses comme ça.
Speaker #1
Toi, tu étais à ma conférence. Oui, effectivement, en fonction du sujet, en fait, il y a plein de moyens. différent. Les choses qui sont assez simples, c'est de faire un post sur les réseaux sociaux, que ce soit LinkedIn, Instagram, Facebook, ça dépend de la cible et du sujet. Mais c'est simple de faire une image avec un petit texte, un petit lien qui va renvoyer soit un formulaire d'inscription, soit un site fictif pour présenter un peu plus en détail. Après, la personne va s'inscrire. Donc ça, c'est hyper rapide. Soit on est prêt à payer, faire un peu du... des postes payants. Soit on a la communauté qui peut suivre, parce que si vous avez un compte LinkedIn avec 100 personnes qui suivent, c'est peut-être pas le meilleur endroit pour faire un poste.
Speaker #0
Sympa révélateur, le test.
Speaker #1
C'est aussi une stratégie. Sur l'exemple dont je parle dans ma conférence, nous, on a fait vraiment... On a créé un écosystème de pré-totypes. où on va tester dans les magasins en réel, on va tester sur des utilisateurs qui sont sur les réseaux sociaux, on va tester sur des utilisateurs dans une base du mailing list, donc en fait ceux qui vont recevoir le mail. Donc on a différentes typologies d'utilisateurs qui vont nous permettre déjà d'avoir une quantité suffisante de données, mais aussi on ne se parque pas à tous ceux qui sont sur LinkedIn ou tous ceux qui sont accrochés à leur mail, parce qu'en fait on a un peu En plus les mails, en termes de newsletter, le taux de clics, la déperdition pour atteindre le tunnel de conversion, ce n'est pas le plus simple.
Speaker #2
Et donc du coup le deuxième niveau après c'est le prototype. Là on est un peu plus engagé déjà dans le projet ou le produit. Oui,
Speaker #1
donc là le prototype c'est un peu plus concret. Même si je disais au début, effectivement, que dans le PrétoType, il y a des choses qu'on associe au prototypage. Dans les techniques de PrétoType, en fait, je parle aussi de MVP, je parle aussi de Pinocchio. En fait, c'est une version non fonctionnelle. Je parle aussi de tests sur des petits échantillons. C'est provincial, donc en fait, c'est vraiment sur un petit truc. On peut se rapprocher aussi du prototype. La frontière entre les deux, elle est assez fine. Après, est-ce que c'est parce que c'est un abus du fait que nous, on ne connaît que le prototype ? Du coup, on a un peu gratté le pré-totype, mais on n'utilise pas le terme pré-totype.
Speaker #0
Le prototype, c'est quelque chose qui est censé être activable, c'est-à-dire réalisé derrière. C'est-à-dire, c'est un plan pour réaliser un pré-totype. On teste, mais on ne sait pas forcément comment le réaliser à ce moment-là.
Speaker #1
Alors, effectivement, le prototype, on ne sait pas forcément comment le réaliser parce qu'on mesure la pétance. Donc, on voit et après on ajuste. Le prototype, on ne sait pas forcément comment le développer. Et en fait, ce qui sort du prototype, parce que moi, j'en parle effectivement au sein d'un design sprint. Un design sprint, c'est toujours au niveau stratégie, conception. À la sortie d'un design sprint, on n'a pas de quoi développer. C'est juste pour valider un concept. un peu plus concrètement auprès des utilisateurs. Et après, du coup, il y a forcément une phase entre la partie prototype dans le design sprint et la phase on bascule en délivrer. Et le prototype qu'on va concevoir, il va être plus concret parce qu'en fait, on sait ce que l'utilisateur cherche, le besoin ou le problème qu'il rencontre surtout. Et on va le traduire, on va trouver une solution, on va la traduire en maquette. Après, moi je parle sur du digital parce que je travaille sur du digital, mais on peut très bien prototyper des choses qui ne sont pas digitales. On peut prétyper des choses qui ne sont pas digitales. Mais ça s'y prête hyper bien en fait. C'est hyper rapide en digital de produire des maquettes, d'itérer, de montrer aux utilisateurs. enfin voilà je veux dire Si je dois tester un espace, si je fais du design de service, si je dois prototyper un espace ou prototyper une expérience, on n'est pas sur le même format. Et après, au niveau du prototypage, c'est des techniques assez connues, assez simples. En fait, ça dépend du niveau de la personne. Je veux dire, si on est un designer, c'est banco, mais on n'a pas de designer. Donc, je disais, effectivement, on peut juste essayer une interface en la faisant sur PowerPoint. En fait, on va faire des zones. Effectivement, des fois, il y a des gens qui maîtrisent très bien PowerPoint, qui peuvent s'en sortir à faire des interfaces sur PowerPoint. Bien sûr.
Speaker #3
C'est accessible, PowerPoint.
Speaker #1
Oui, et même moi, ça m'est arrivé de faire des fois des interfaces sur Miro. Oui, très bien. En fait, c'est hyper simple et c'est beaucoup plus facile en plus de faire du collaboratif. pour construire une interface. Donc on peut faire des écrans prototypes, on peut montrer des écrans, on va montrer des écrans à la personne alors qu'ils ne sont pas forcément reliés entre eux, sur une image. Après, on peut avoir des prototypes où c'est des maquettes qui sont connectées les unes aux autres. Et là, l'utilisateur a plus l'impression d'être sur l'interface, même si en termes de conception, on ne va pas concevoir tout le produit puisque la partie prototype sur un design sprint, on est quand même sur On n'a que 5 jours, donc on est quand même sur un périmètre assez restreint. Mais on peut faire des interactions et on va un petit peu guider l'utilisateur dans le protocole de test. On va lui donner un objectif à faire dans l'interface et on va étudier comment il arrive à le faire dans l'interface, qu'est-ce qu'il comprend, qu'est-ce qu'il ne comprend pas. Et après, la dernière version qui peut être super intéressante, ça dépend des compétences. de la personne et du temps qu'on a et aussi du sujet qui s'y prête ou non, on peut faire du no code hyper rapide no code ou low code et on peut tester un produit effectivement si on a un produit où on a beaucoup si on a vraiment testé il y a beaucoup de formulaires à remplir, il y a beaucoup d'étapes c'est quelque chose qui est assez crucial dans l'expérience moi j'ai déjà fait des prototypes, c'était pas crucial donc en fait vous imaginez que vous cliquez là et ça se remplit Merci. En fait, on pourrait très bien avoir sur certains cas, une spot, oui, en fait, la compréhension. Il y a une interface très complexe si on est sur des trucs métiers. Mais en fait, ça peut peut-être avoir un intérêt de qu'est-ce que tu comprends quand tu cliques ? Il va essayer de saisir, en fait, il va dire « Ah, je pensais que ça allait faire ça » , des choses comme ça. Mais ça, il faut avoir la compétence pour le faire.
Speaker #0
OK, même si de nos jours, avec le ZTIA, etc., on peut aller plus loin. Maintenant, peut-être, à la place du no-code, faire un lovable ou autre, ça peut...
Speaker #1
Oui, maintenant, les outils pour construire des interfaces, effectivement... C'est pour du prototype, ce n'est pas l'interface finale, mais rapidement, j'avais vu des démos à une conférence et elle disait qu'en deux heures, elle avait réussi à faire ce qu'elle voulait. Après, il y a eu le piège de... C'est pas mal ce que j'ai fait ! En fait, elle a fini à deux heures du matin. mais effectivement il y a des logiciels maintenant qui permettent ouais voilà mais pris par la capacité à faire et l'envie de faire mieux et d'aller toujours un petit peu plus loin et aussi mettre des garde-fous sur ce qu'on conçoit parce que sinon c'est aussi intéressant que le design sprint c'est que le design sprint on a 15 jours pour faire le prototype et on peut pas rallonger en fait c'est le mercredi soir on sait ce qu'on va faire et le vendredi matin 9h il faut que le prototype soit fait Merci. que le protocole de test soit fait et on ne peut pas... Ah,
Speaker #0
mais le force-beat unboxing.
Speaker #1
C'est intéressant parce que ça veut dire qu'en fait, même au-delà de ce qu'on veut tester, on est obligé de prioriser ce qu'on veut tester dans le protocole et dans le prototype. Donc là, la priorité, c'est de comprendre s'il arrive à faire ça, s'il comprend ça, s'il atteint son objectif. Et en fait, en fonction de ça, on va aussi construire les parcours. Moi, ça m'est déjà arrivé sur le Design Sprint toi. On s'emballe, on s'emballe. Moi, j'ai qu'une journée. On se calme.
Speaker #2
Est-ce que tu as déjà des exemples sur lesquels le fait de tester en amont, ça a vraiment fait la différence en disant qu'on est parti complètement du mauvais côté ou au contraire, ça permet de réorienter le projet ?
Speaker #1
Des bons exemples ou des mauvais exemples ?
Speaker #0
Tu peux donner les deux.
Speaker #1
Moi, l'expérience dont je parle dans ma conférence, on a fait pré-totype et prototype. En fait, ça s'est super bien passé parce qu'on avait les bonnes personnes dans l'équipe pour justement gérer toutes les parties du pré-totype. Et la finalité, c'est que ça a amené assez de matière, assez de feedback terrain et de validation terrain pour que quand ils ont demandé les budgets, en fait, ça a été validé. Donc l'investissement a été fait sur cette partie-là. Et je crois que c'était l'un des seuls projets portés qui a eu l'investissement dont il avait besoin par rapport au tout. Donc ça a fait la différence. En termes de prototype, donc là j'avais fait que la partie Design Spring Prototype. On avait fait un projet où au final, le vendredi, mais en fait, les feedbacks du tuteur, c'était... C'était assez mitigé, il n'y avait pas de vrai engouement. C'est incroyable, ça répond à un super besoin. Et du coup, c'était assez mitigé. Et ça a quand même testé un concept assez fort, en différenciant de ce qu'il proposait. Et ça leur a permis à eux de dire, OK, en fait, il va peut-être falloir pivoter. Peut-être que la manière dont on a voulu aborder ça, en fait, ce n'est pas la bonne. Mais ça leur a quand même donné des petites indications micro sur, ah, ça, c'est intéressant, on va peut-être pouvoir le réinjecter dans notre produit ou en peut-être l'utiliser différemment. Et après, le dernier exemple dont je parle dans ma conférence, où c'était un fail complet. C'était le prétypage où c'était sur de la banque. On n'avait pas les bons accès, problème de sécurité, banque super sécurisée. On n'avait pas les bons accès, les bonnes personnes dans l'équipe pour avoir des accès à des mailing lists, envoyer des mails directement depuis leur service à eux pour pas que ça passe en mode, c'est de l'hameçonnage, des choses comme ça, qu'on ait les bonnes url. Donc en fait, on n'a rien pu faire en termes de prétypage. Par contre, comme on vient de dire, c'est de la prestation, on avait vendu pré-tout type et prototype. On a quand même fait la partie prototypage dans un design sprint. Ça a quand même permis de valider certains besoins parce qu'il y en avait besoin quand même pour aiguiller. Mais comme on est sur la phase stratégie conception, ça permet eux de savoir s'ils doivent aller plus loin, s'ils vont aller chercher du budget et des choses comme ça. Je veux dire, le... Le pré-totypage et le prototypage vont dérisquer le développement, mais le pré-totypage va permettre aussi de dérisquer le prototypage. Donc, plus on dérisque de ce qu'on dérisque.
Speaker #0
De la même façon qu'on a une approche agile, itérative pour construire le produit, on peut avoir une approche itérative des tests pour dérisquer les phases suivantes à différents niveaux. Et le pré-totype, ça va à ça.
Speaker #1
Après, je pense que je ne me suis jamais retrouvée dans ce cas-là, mais d'avoir effectivement plusieurs... En fait, si le premier pré-totypage, c'est pas bon, c'est mitigé, on n'a pas accès correctement, est-ce qu'il ne faut pas en refaire un ?
Speaker #3
Eh oui.
Speaker #1
On est quand même sur des délais assez courts, j'ai envie de dire. C'est une, deux semaines. On ne va pas aller plus loin parce qu'après, on va créer une inertie. Il faut d'abord mettre en œuvre. Mais même, ça va créer une inertie dans le projet. Ce n'est pas possible. Le prototypage ou même le design sprint, le design sprint, ça permet d'être sur un temps très court, d'être focus. À l'inverse, si on faisait ça, on fait une réunion. Puis dans deux semaines, on fait une autre réunion. Ça crée une inertie. Les gens sont sur d'autres projets, le temps qu'ils reviennent et tout. donc Ce n'est pas forcément intéressant. Et même dans le design sprint avec le prototypage, on peut refaire à la suite des retours utilisateurs un autre design sprint qui va réorienter l'axe qu'on avait choisi. Moi, ça m'est déjà arrivé. Effectivement, on a des retours. On va refaire un prototype pour pouvoir le retester après parce que les retours qu'on a eus ne nous permettent pas de dire oui, on continue ou oui, on arrête. Et c'est mitigé sur comment on pivote.
Speaker #2
Et du coup, tu parles plusieurs fois de Design Sprint. Est-ce que tu peux expliquer rapidement où ça consiste ?
Speaker #1
Design Sprint, c'est basse américain. Ça a été inventé par Jack Knapp de Google Venture. C'est une méthode qu'il a mise en place, qu'il a testée, qu'il a itérée chez Google Venture et qu'il a stabilisé. Et il a écrit un livre sur ça, justement. Et c'est une méthode, en fait, en cinq jours, on va dérisquer une idée, un concept. On ne peut pas dérisquer un produit en entier parce que cinq jours, en fait, c'est trop peu. Et en fait, dans l'idéal, c'est cinq jours. Il y en a qui arrivent des fois à le raccourcir, le tordre, l'allonger.
Speaker #0
J'ai vu des versions trois jours.
Speaker #1
C'est dense. Parce que déjà, cinq jours, c'est dense.
Speaker #0
En fait, on a un feedback comme quoi cinq jours, c'est impossible de bloquer les gens. En fait, sur un projet, dire on ne prend que 5 jours, c'est une question de point de vue.
Speaker #1
Oui, mais ça m'est déjà arrivé de faire des end-prings où ce n'était pas possible. C'était des choses musicales. Ah oui,
Speaker #0
oui.
Speaker #1
Un qui est là un jour, un qui n'est pas là, mais c'est un autre jour, qui prend le relais et tout. Et en fait, ils n'ont pas le même niveau d'information, ils n'ont pas le même niveau d'implication. Et c'est hyper compliqué à gérer. Donc en fait... De toute façon,
Speaker #0
tu joues sur la force du focus. C'est le fait, à un moment donné, d'être concentré sur une seule tâche. Et limite d'essayer en groupe de rentrer en flot sur cette tâche pour pouvoir essayer d'accomplir beaucoup de choses.
Speaker #1
J'ai écrit un article sur être designer dans un design sprint. Du coup, je détaille en fait tout ce qui se passe. Moi, je détaille aussi des hacks que j'ai pour aller plus vite. Tu as le lien,
Speaker #0
on le mettra en description de l'épisode.
Speaker #1
Et en fait, j'ai fait une illustration. En fait, on a des émojis dans quel état on est à la fin de la journée. Donc, on peut dire qu'on est en PLS tous les jours. En termes de détails, c'est que le lundi, ce mois c'est Design & Sprint. Moi j'adore cette méthode parce que j'arrive sur des sujets que je ne connais pas. Et en fait, j'apprends plein de trucs hyper rapidement. Et en fait, l'objectif c'est qu'en un jour, je sois opérationnelle sur le sujet pour être au niveau du client. Et donc le premier jour, c'est on prend toutes les données, terrain, on analyse, on voit avec les experts. On cadre un peu sur quel périmètre on va aller sur la carte de l'expérience. Le mardi, pour moi, c'est la partie facile. C'est tout ce qui est créativité. Donc, en fait, on va faire un bench. Soit on a des gens qui sont à l'aise avec ça. Soit nous, on commence à faire un bench pour les aider, pour ouvrir un peu les chakras. ouvrir la créativité et l'après-midi on a des petites étapes pour justement les aider à débloquer des idées construire des interfaces donc ça on fait tout ça et le mercredi matin ce qui est bien et moi je trouve que c'est hyper important et en fait toutes les méthodes du Design Spring moi je les utilise mais pas en faisant un Design Spring c'est plein d'ateliers en fait qu'on a imbriqués donc c'est des ateliers qu'on peut réutiliser et le mercredi matin c'est la galerie et en fait c'est silencieux C'est-à-dire que personne ne présente son projet, son idée. C'est censé être autoporteur. C'est-à-dire que les personnes, elles ont mis effectivement des post-it autour de leurs idées, de ce qu'elles ont imaginé, dessiné. Et c'est censé être autoporteur. Donc en fait, il n'y a pas le biais de... Il y en a un qui parle super bien à l'oral, mais en fait, son idée, elle est pourrie. Il y en a un, il n'est pas à l'aise à l'oral, mais son idée, il est super bien. Donc personne n'est desservi par ses qualités ou ses défauts. Donc tout le monde est au même niveau. Donc, des fois, il faut quand même les cadrer parce qu'il y en a qui commencent à les présenter, ces projets. Non, Les gens sont tout seuls, lisent et après, ils peuvent poser des questions. Et souvent, c'est le Sprint Master qui va aider à répondre, des choses comme ça. Mais les personnes ne présentent pas eux-mêmes leurs projets parce que sinon, ça rend des avantages certains. Et le mercredi, du coup, on cadre dans le sens… Il y a eu plein d'idées. Donc, qu'est-ce qu'on prend comme solution ? Est-ce qu'on peut prendre des morceaux de solution ? quel parcours on va définir à tester, quand même définir un parcours qu'on va tester auprès de l'utilisateur. Et le jeudi, on part en phase de prototypage. Donc là, si on est un designer, c'est mieux. Mais on peut ne pas avoir de designer. Et là, en fait, le designer, il va produire les écrans, les interfaces, là où il a son expertise. Et toutes les autres personnes qui sont là, elles sont là pour l'aider. Elles vont chercher tout le contenu, rédiger les choses, chercher les photos. Le designer, il n'a pas le temps de faire ça. Donc, tout le monde est sollicité. Donc, souvent, le jeudi matin, on se met en ordre de bataille. On répartit. Toi, tu fais ça, tu dois livrer à telle heure. On refait un point de synchro. Toi, tu fais ça, machin. Et il y a quelqu'un, dans l'idéal, qui chapote un peu la vision globale parce qu'il faut quand même que le parcours, le contenu soient cohérents. Le jeudi soir, non, en parallèle, le jeudi, il y a quelqu'un qui fait le protocole de test pour le lendemain. Et le jeudi soir, si on a de la chance on termine tôt sinon on termine tard. Moi ça m'est déjà arrivé de terminer à 23h parce qu'en fait il me manquait des cas et c'était hyper complexe à comprendre et il y a un moment à temps d'air qu'on n'a plus de cerveau. Donc les choses qu'on fait 6 minutes, on met une demi-heure à comprendre. Et le vendredi matin, on fait des tests. Donc il y a eu un recrutement utilisateur. soit en amont du sprint, soit pendant le sprint, ça dépend comment on a organisé. Et là, on fait tester. Et ce qui est bien, c'est qu'on invite tous les participants au sprint. Ils sont là, mais on peut aussi inviter les parties prenantes, les décideurs qui sont plus hauts. Ceux qui ont acheté le sprint, ils vont venir. Et en fait, ce qui est hyper bien, c'est qu'ils vont voir directement les utilisateurs. Ils aiment bien ça, ils adorent. Et des fois, il y a des pépites, des pépites en termes de test, sur du feedback ou sur des contextes utilisateurs. Moi, j'ai eu des tests et on regarde ça, et je me dis, la personne qui anime les tests, elle a une patience folle parce qu'il y a des tests où la personne ne va pas être à l'aise avec un ordinateur, elle ne va pas être à l'aise avec la caméra. Et du coup, on va avoir la webcam, mais elle n'arrive pas à la régler. Du coup, la webcam, on ne voit que le haut de sa tête. C'est assez drôle où la personne ne comprend même pas comment on peut partager son écran. donc au final c'est un peu mais c'est la personne qui mène les tests, qui partage son écran, qui va poser des questions. Donc, c'est du hack en plein test pour avoir du feedback. Parce que sinon, et on prévoit aussi le vendredi, on a toujours un test de backup. Normalement, c'est cinq, mais on en prend six, voire on en prend sept pour avoir du backup.
Speaker #0
Il peut toujours y avoir des testements ou un peu de technique.
Speaker #1
Le vendredi. On essaie de finir tôt quand même, mais vendredi soir on a une synthèse, qu'est-ce que vous avez retenu dans les feedbacks, qu'est-ce que vous en avez pensé ? Et après c'est un peu le... alors ça je ne suis pas sûre si ça va dans le design sprint officiel, mais c'est quoi les prochaines étapes ? C'est quoi les prochaines actions ? On se met en ordre de marche, parce que sinon ça peut retomber comme un triplé. exactement donc la semaine prochaine vous faites quoi ? je pense pas que tu as d'indicé en sprint mais je pense que naturellement et si tu encres pas des next steps systématiquement sur ce genre d'étape ça fonce pas c'est vraiment prochaines étapes la semaine prochaine qu'est-ce que vous faites qu'est-ce que vous allez présenter vous allez valider qu'est-ce que vous allez valider à qui et ça permet d'embrayer sur la suite et que ça retombe pas parce que c'est vraiment dommage il y a énormément il y a énormément d'effervescence sur le projet Merci. Et ce qui est hyper bien avec le design sprint, c'est qu'en fait, toutes les personnes qui ont participé, elles deviennent ambassadrices de l'idée, de la solution. Et en fait, ça diffuse. Ça fédère. Ça éligne. Voilà. Et ça, c'est hyper intéressant parce que dans les design sprints, en plus, on prend souvent des personnes qui sont plus loin de l'idée et qui ont des axes différents, qui ont des expertises différentes. Et en fait, tout le monde amène sa vision. sa vision des choses, son angle des choses aussi parce qu'en fait il y en a ils vont voir ça comme ça et d'autres pas du tout. Moi ça m'est déjà arrivé sur un sprint où en fait j'avais des gens qui étaient très opérationnels, très techniques et en fait dans l'interface ils me proposent de mettre ça et en fait je leur fais est-ce que vous êtes sûr que les utilisateurs ils vont comprendre ce que vous êtes en train de me dire d'écrire ? Oui oui il n'y a pas de souci, t'as le succiateur vendredi, c'est quoi cette abréviation, ça veut dire quoi ? c'est aussi les ramener au terrain aux utilisateurs c'est un peu d'empathie si une personne si vous mettez à la place d'un utilisateur lambda qui ne connait pas votre produit est-ce qu'il va vraiment comprendre ce que vous lui proposez bon Noemi on
Speaker #0
est en train de se faire envahir je trouve que c'est la pause c'était super euh tu me donneras le lien du blog que tu as cité si on veut te contacter sur LinkedIn on mettra ton lien à LinkedIn et puis encore merci d'être venue en prod et puis à Fébri et à Montpellier et à Montpellier bravo d'être réussie à devenir à Montpellier beau parcours pour la petite histoire ceux qui veulent savoir vous faites un feedback sur cet épisode à Noémie elle vous raconte la petite histoire derrière Merci. Et puis, comme d'habitude, vous n'oubliez pas, vous devez liker, vous abonner et vous abonner à Newsletter. Puisque j'envoie un email une fois par mois avec une ou deux vidéos qu'on enregistre et des ressources, des articles, etc. que je partage beaucoup.
Speaker #2
Merci. Merci Marion.
Speaker #0
Merci Noémie. 94% des fonctionnalités développées ne sont pas utilisées. Pour ne pas flambler votre budget, il faut tester avant de développer. Le préto-typing pour valider que le besoin existe, le proto-typing pour vérifier que votre solution est comprise et le design sprint pour faire tout ça en 5 jours. C'est exactement la philosophie qu'on porte chez Axabrica. Avant de développer, on vous aide à valider vos hypothèses sur le terrain avec des ateliers de discovery, des design sprints et du prototypage rapide. Si vous avez un projet de développement de solutions IT sans mesure et que vous voulez investir votre budget sur ce qui compte vraiment pour vos utilisateurs, contactez-nous. Le lien est en description. Et n'oubliez pas, le monde se divise en deux catégories. Ceux qui suivent en parent prod.

Embed