Estelle Landry - Comment perdre sa surcharge featurale ? (FR)

[00:00:15] Hop. Alors, ben écoutez, merci, merci encore pour ton introduction, du coup Sébastien. Euh et je vous remercie aussi euh tous les participants de venir un vendredi soir de confinement euh ben passer du temps avec moi et pour parler de surcharge futural. Donc vous l'avez compris, ce n'est pas un talk technique, hein. C'est vraiment un talk qui va parler du produit, mais qui est autant à destination des développeurs, de de de tout le toute la team R&D, hein, du PO, de l'UI designer. C'est vraiment quelque chose qui pourra être partagé à l'ensemble de l'équipe. Euh mais du coup, je sais pas si certaines personnes euh l'ont ont mal lu entre les lignes. Mais je ne parlerai pas de surcharge pondérale, hein, voilà. J'ai fait une petite blague, j'en suis désolée. Euh mais euh sur ce, on va pouvoir démarrer.
[00:01:02] Avant d'aller un peu plus loin dans la conférence, je me présente très rapidement. Je m'appelle Estelle Landry, euh donc product owner chez Pix, une start-up d'État dans le domaine du numérique. Euh on crée une plateforme pour se se tester, pour tester nos compétences numériques. Euh donc si vous connaissez pas, je vous invite à y aller et à aller vous tester. Euh je suis sur Twitter euh à l'handle euh au handle Estel Landry, donc n'hésitez pas euh à me suivre, je partagerai les slides euh sur Twitter. Euh je fais partie des duchesses. Alors, qu'est-ce que c'est que ce groupe ? C'est une association qui essaie de promouvoir les femmes dans la tech. Euh que vous soyez une un homme, une femme, vous pouvez euh euh y prendre part et nous aider, voilà, par des petites choses, du marrainage euh ou du parrainage de de jeunes de jeunes personnes.
[00:01:48] Ou tout simplement aller donner des des des conférences dans les collèges et les lycées, donc voilà, c'est un peu notre but.
[00:01:56] Et aussi à mes heures perdues, quand il m'en reste, je suis euh dans l'équipe organisatrice de Sonitech. Donc comme pour la Flocon, une conférence. Alors, j'espère pas en ligne, même si c'est en juin 2021, j'espère que ce sera pas en ligne. Et c'est sur Montpellier. Voilà pour les présentations. Euh, on va pouvoir démarrer euh dans le vif du sujet, mais avant, je vais vous raconter une petite histoire.
[00:02:20] Oui, oui, je vais vous raconter une petite histoire. Euh il était une fois, une jeune développeuse qui a découvert l'informatique et surtout l'univers du développement. Elle développait, développait, développait toute la nuit et elle était super heureuse. Elle passait son temps dessus, elle a trouvé une super mission et euh elle a euh elle adorait développer avec ses collègues sur euh des domaines fonctionnels hyper variés. Euh elle avait quelquefois pas mal de de gens qui venaient lui poser des questions, hein, sur son travail. Euh on lui disait souvent, oh, écoute, ce serait bien que tu fasses ça comme ça, tu trouves pas ? Ce serait intéressant, hein. Donc notre développeuse, elle savait pas souvent répondre, hein. Elle avait aussi d'autres personnes qui arrivaient qui lui dit, eh écoute, j'ai entendu dire que certains utilisateurs aimeraient ça. Alors notre développeuse, toujours pareil, elle savait pas répondre. On continuait à lui poser des questions et des fois des questions un peu plus corsées, du style écoute pour valider ce gros gros prospect, j'ai absolument besoin de cette feature. Alors ben notre développeuse, elle elle était euh elle était vraiment vraiment stressée par tout ça, tout ce qui lui arrivait. Euh bon, elle essayait de bien faire, de rajouter les fonctionnalités comme elle pouvait. Euh elle avait aussi des des des des remarques du style, mais pourquoi tu as fait ça comme ça ? Ben voilà, elle prenait encore plus de questions, plus de questions. Et puis des fois, on lui disait même, écoute, ton bouton là, tu l'as fait bien trop gros et bien trop bleu.
[00:03:47] Elle des fois, elle s'essoufflait, elle était assez stressée. Bon, elle faisait du mieux qu'elle pouvait. Jusqu'au jour où finalement, elle a vu arriver, vous savez cette feature, vous la voyez et vous savez que c'est la feature de trop. Vous savez cette feature qui a l'air énorme. Euh et vous imaginez l'ajouter dans un programme surgonflé, dans un applicatif énorme. Du coup, notre développeuse, elle elle a vu ça, elle s'est dit bon, OK. Alors, soyons euh, soyons terre à terre, je vais essayer d'aller voir dans mon modèle de données pour voir où est-ce que je pourrais rajouter ces nouveaux concepts. Ok. Même en prenant des lunettes, c'était compliqué pour elle de se dire, OK, euh où est-ce que je vais rajouter ça dans ma ma base de données, euh elle est énorme, je j'y vois plus rien. J'espère que, enfin, je je sais pas pour vous, mais moi j'ai déjà connu ça, hein. Euh donc la notre développeuse effarée se dit, OK, bon, on va peut-être je vais peut-être demander de l'aide. Euh je vais peut-être regarder aussi côté UI, comment ça va se passer.
[00:04:48] Et puis côté UI euh ouais, c'était euh ah, ça a pas du ça a pas bien fonctionné. J'm'en veux que Vous avez loupé, vous allez louper une super un super gif. Bon ben ça a pas l'air de de s'activer. Ah si, c'est bon. Euh donc notre développeuse se dit dans son applicatif, mais où est-ce que je vais bien pouvoir rajouter cette fonctionnalité dans ces 86 barres de navigation, dans tous ces éléments clignotant, mon dieu, comment ça va se passer ?
[00:05:20] Donc vous l'avez compris, notre protagoniste, elle était au fond du trou, elle ne savait pas par où commencer et elle s'est dit, OK, je vais aller voir mon chef de projet adoré. qui a toujours des solutions, je suis sûr qu'il va me révolutionner le monde et qu'il va me trouver la bonne solution à mon problème. Et le chef de projet lui dit, mais écoute, pourquoi tu ne fais pas de la réécriture, du refacto.
[00:05:45] Je ne sais pas vous, mais je, quand j'ai fait ça moi dans ma ma carrière de développeuse passée, ça n'a jamais trop marché. Ou alors peut-être que j'étais très nulle, hein. Et bon, ça, je le dis. Euh donc voilà, notre développeuse, elle dit, OK, je vais suivre ce que m'a dit mon chef de projet. Euh imaginez là, elle est super inquiète, mais son chef de projet lui dit, écoute, la réécriture. ça va vraiment t'aider pour y voir mieux clair, pour enlever les choses qui ne vont pas et cetera et cetera. Bon, elle a fait ça, mais notre développeuse, malheureusement, elle a pas pu euh elle a corrigé plein de choses, hein, mais ça n'a pas corrigé le problème que ben il y en avait toujours partout et qu'elle avait du mal à s'y retrouver. Donc elle est réallée à revoir son chef de projet euh qui lui dit, écoute. Là, on va démarrer quelque chose que peut-être presque personne n'ont déjà jamais fait dans cette société. On va gérer notre dette technique. Vous savez ce terme magnifique à la mode. Euh et du coup notre notre notre jeune développeuse se dit, OK, ben je vais suivre le conseil de mon de mon chef de projet. Je vais peut-être essayer de mettre à jour les frameworks, améliorer mon archie, revoir un peu les éléments de mon domaine, améliorer certaines perf et cetera. Mais notre héroïne, elle s'est aperçue rapidement qu'elle avait encore cette complexité monstrueuse qui continuait de grandir et de grandir. Elle s'est posé la question pourquoi. Elle a cherché et elle s'est rendue compte en fait qu'il n'y avait pas qu'une seule complexité, mais plusieurs complexités.
[00:07:11] Elle s'est aperçue qu'il y avait une complexité accidentelle, celle que l'on crée en rajoutant du code. Et il y avait aussi cette complexité essentielle. Vous savez cette complexité qui est pas reliée au code, c'est celle qui est reliée au problème que le logiciel est en train de régler. C'est-à-dire que c'est simplement lié à la complexité du problème métier. Plus le problème métier est complexe, plus l'outil sera complexe.
[00:07:35] D'ailleurs si vous si vous ça vous intéresse beaucoup ce sujet là, il y a un super article d'Arnaud Lemaire, euh donc je vous conseille d'aller le voir, je le partagerai dans mes slides. Donc face à ça, face à cette nouvelle définition, notre protagoniste elle s'est dit, OK, donc si je comprends bien, moi euh pendant que j'essayais de régler ma complexité accidentelle.
[00:07:58] Euh ben ma complexité essentielle, elle, elle n'arrêtait pas d'augmenter. Euh OK, donc elle s'est dit euh est-ce que peut-être que des gens ont rencontré déjà cette problématique, ce problème, est-ce que ça avait un nom ? Elle chercha, elle chercha et elle a rien trouvé. Donc elle se dit, bah, OK, je vais appeler ça surcharge fonctionnelle. Bon, elle a elle a pas trouvé de définition, donc elle s'en est fait une, hein. Elle a dit, bah, la surcharge, c'est quoi ? C'est une charge supplémentaire à la normale, fiale, bah d'une fonction ou de fonctions implémentées dans mon SI.
[00:08:28] qui permet à l'utilisateur de faire quelque chose. OK, donc face à ce problème euh qui était très peu documenté, hein, nos développeuses étaient un peu perdues, elle s'est dit, qu'est-ce que je vais faire ? Ben solution première, je vais supprimer des fonctionnalités. Voilà. Il y a trop de fonctionnalités, qu'est-ce que je fais ? J'en supprime. Mais attention, elle s'est dit qu'elle allait pas supprimer n'importe laquelle. Elle allait essayer d'enlever les fonctionnalités qui a soit zéro usage ou un tout petit peu, mais ces fonctionnalités qui sont aussi très difficiles à maintenir.
[00:09:01] Et elle elle a essayé de faire ça, de de démêler un peu tout ce tout ce paquet, tout ce sac de nœuds, et elle s'est dit, OK.
[00:09:09] Même si je fais ça, finalement, je me rends compte que ajouter des features, c'est assez rapide, alors que les supprimer pour défaire mon sac de nœuds et venir enlever ma feature, c'est quand même très complexe, ça prend du temps. En plus, vous le savez très bien, quand une fonctionnalité est implémentée dans notre SI, dans notre applicatif, il y a plein de fonctionnalités un peu partout, hein. En fonction de notre archie et cetera, c'est ça peut être très compliqué à enlever. Pareil côté utilisateur, comment faire ? Est-ce qu'il faut communiquer à tous les utilisateurs ou à simplement les utilisateurs qui avaient encore des usages à cette de cette fonctionnalité là ? Bref, il y avait plein de questions qu'elle se posait et ça prenait du temps. Et puis en plus, je vous laisse imaginer notre développeuse devant une réunion avec euh des grands chefs à plumes, comme on les appelle, en disant, ben écoutez, moi, je suis très fière de moi, j'ai réussi à supprimer trois fonctionnalités ce mois-ci.
[00:09:58] Je vous laisse imaginer la salle et les regards qu'elle a dû se prendre en disant, mais pourquoi elle est elle est contente, celle-là, déjà ?
[00:10:07] Bref, c'est tout là où notre héros s'est dit, ben voilà, je peux plus rien faire, je vais je vais vraiment jeter l'éponge. Euh et du coup, je je laisse tomber, voilà, tant pis. Et c'est toujours là où vous savez, c'est comme dans les Disney où où les héros sont très tristes, mais ils arrivent quand même à trouver une petite idée. C'est que comme par hasard, notre protagoniste, elle s'est elle continuait à lire des articles, elle s'est dit ah ouais, mais il y a il y a peut-être une autre solution. La solution, c'est peut-être de laisser mourir mon applicatif et d'en commencer un autre. Parce qu'elle a lu l'histoire de Fogbus. Je sais pas si vous connaissez Fogbus, si vous avez des idées dans le chat, n'hésitez pas à les mettre. En fait, ce qu'elle a appris notre notre développeuse, c'est que elle elle a appris que Fogbus, qui était un vieux outil qui avait des années, euh qui était euh du coup sur des techno vieillissantes, euh c'était un un outil qui permettait de gérer du ticketing, donc vous le voyez rapidement, hein, il y avait des files, plein de tickets avec des statuts et cetera.
[00:11:07] C'était pas très vendeur, ils avaient du mal à maintenir et ils ont dit, OK, c'est bon, on va laisser tomber. Mais c'est là que notre personnage principal a eu une lueur d'espoir d'espoir, c'est-à-dire que Fogbus, ils se ils sont pas arrêtés là. Ils ont dit, OK, on va refaire un produit, mais on va essayer d'écouter nos utilisateurs là maintenant et prendre en en compte les nouveaux besoins utilisateurs qu'ils auraient maintenant cet instant présent, au lieu de revenir sur les besoins initiaux qu'on avait avec Fogbus. Et c'est là où ils ont créé Trello. Donc Trello, solution que vous connaissez, qui est extrêmement utilisée. Et euh et en effet, ils ont bien fait parce que euh ils ont laissé tomber, en laissant tomber une solution, ils ont réussi à créer quelque chose de d'encore mieux et euh et qui est vraiment quelque chose qui a révolutionné un petit peu nos to-do listes. OK. Donc finalement, notre héroïne, elle se dit que cette morale euh finalement la morale de tout ce qu'elle a vécu, c'est que bah la vie est un cercle vertueux et que finalement toutes les choses ont une fin et que c'est un renouveau perpétuel.
[00:12:13] OK. Bon, notre histoire maintenant est terminée. Euh donc imaginez-vous une développeuse, elle voulait rajouter des features, elle a une feature à rajouter, elle s'est dit, OK, et la morale de cette histoire, c'est, on laisse tomber notre appli, on refait une. Je sais pas vous, mais moi je dis non. J'aime pas beaucoup cette fin. Parce que euh ça me fait penser, vous savez à la fin de Dexter, pour ceux qui connaissent la série, où quand vous regardez la dernière saison, vous dites, oh, c'est un peu c'est pas c'est pas GG. D'ailleurs, je sais pas si vous savez, mais pour Dexter, ils vont refaire une fin, hein, je voilà. Euh pour les fans de Dexter. Mais même moi, j'ai le même sentiment, c'est-à-dire que je ne veux pas, je ne veux pas que ma fin d'histoire, ça soit laisser mourir mon applicatif après X années, si ça se trouve, ça fait que deux ou trois ans que l'applicatif est né. Il y a encore de la valeur à apporter à nos utilisateurs, on n'a pas tout essayé.
[00:12:57] Du coup là, moi, Estel Landry, euh quand j'ai vu cette histoire, euh j'ai essayé de de de la garder en tête et surtout à un moment donné, j'ai vu un documentaire sur France 5. Qui euh s'appelait Hyperconnecté, le cerveau en surcharge. Là, on nous explique que bah les smartphones, les ordinateurs, les tablettes, les consoles de jeux connectées, les montres connectées, les balances connectées, le frigo connecté bientôt, euh tout ça, ça fait qu'on est relié au monde en continue. Et dans cette dans cette émission, on nous disait que tous ces outils connectés, bah ça augmente finalement la productivité au travail, hein, ça augmente plein de choses, c'est génial. Mais il y a des études aussi qui montraient que euh ce trop plein de numérique, ça nous envahit en tant qu'humain, ça envahit nos existences et ça nous amène à même diminuer nos capacités cognitives, voire même nous mettre en surcharge, voire mettre notre cerveau passe en surcharge. à cause de toutes ces notifications. Et euh dans ce documentaire, ils explorent plein de solutions pour éviter ça. Euh basé un petit peu sur euh bah comment en gros, essayer de gérer un espèce de burnout. Et c'est là où je me suis dit, OK, si notre cerveau peut être en surcharge, pourquoi pas notre applicatif ? Est-ce que les solutions que l'on utilise sur l'humain et sur la surcharge de notre cerveau d'humain, peut ne pas être transposé sur notre applicatif ?
[00:14:21] Vous allez sûrement me dire, Estel, qu'est-ce que tu as pris pour avoir cette idée ? Non, non, vraiment, j'ai vraiment cru à ça. Et je me suis dit euh suite à ce documentaire, ça peut être une idée. Pourquoi ne pas appliquer ce qu'on applique sur nous humains à des applicatifs ou à une gestion de projet ? OK. Ben écoutez, je suis allé consulter les meilleurs dans le métier de la psychologie.
[00:14:43] Euh donc bien sûr, hein, psychologie magazine, hein, voilà. Non, je rigole. Euh je suis allé euh je suis allé consulter pas mal de de de bouquins, d'articles sur le burnout. J'ai revu encore encore cette émission. Et euh je vous ai sorti un petit peu là des quatre règles à utiliser en cas de burnout ou de burnout applicatif. On va le voir. La première, grand suspense, on nous dit, il faut tout effacer. et partir d'une page blanche. C'est-à-dire qu'il faut faire le vide dans votre vie et il faut faire une liste de tout ce que vous avez euh mis en place dans votre vie, donc votre travail, vos engagements, vos objectifs, vos groupes, vos loisirs, vos réunions, tout ça, tout ça. Et euh vous allez essayer de voir qu'est-ce qui occupe votre énergie mentale et vous allez supprimer celle qui finalement ne correspondent pas à votre vision de vie, à votre à votre vie, à ce que vous voulez faire de vous, à votre but finalement.
[00:15:39] Je me suis dit, OK, je prends ça, je le transpose côté applicatif.
[00:15:45] Qu'est-ce que ça donne ? Ben en fait, souvent quand on a une question pour définir la vision produit, on pense souvent à Simon Sinek et surtout à euh la question fondamentale de pourquoi cette personne, cette organisation est plus innovante, plus influente, plus rentable qu'une autre. Pourquoi un produit est meilleur qu'un autre, hein, en terme de fidélité, euh voilà, par exemple. Et euh Simon, il a vu qu'il y avait des gens comme Martin Luther King, Steve Jobs, les frères White, qui avaient peu de choses en commun, mais ils ont tous commencé par la question pourquoi. En fait, ils ont réalisé que les gens n'achètent pas vraiment un produit euh tant qu'ils ont pas compris le pourquoi ce produit existe. Qu'est-ce que ça va leur apporter ?
[00:16:31] C'est pour ça que Simon, lui, ce qu'il dit, c'est que avant de commencer un produit, et surtout pour définir le but euh du produit, donc comme un peu comme notre but euh de la de notre vie. C'est commencer par le pourquoi, le start with why. Ça montre en fait que les dirigeants agissent et communiquent tous de la même manière, c'est-à-dire que Simon va appeler ça le le le Golden Circle. C'est-à-dire le cercle d'or. Pour lui, ce cadre là, ça permet de construire des produits qui soient dirigés par le pourquoi et du coup surtout que les gens peuvent être euh ben vont vont vont adorer, vont être inspirés. Donc ce qui se passe, c'est que au tout début, on commence par le why, le pourquoi. Ça veut dire décrire un petit peu la mission, la cause, la croyance d'une entreprise ou d'un produit. On va pas parler d'argent dans le dans le pourquoi, mais on va juste essayer euh de se poser la question, pourquoi ce produit existe ? Pourquoi l'entreprise existe ? Qu'est-ce qu'elle apporte ? Ensuite, on va essayer, une fois qu'on a défini ça, de passer au How. C'est-à-dire, toutes les actions, les valeurs prises pour alimenter notre pourquoi. Euh c'est-à-dire le processus pour parvenir au quoi, OK, qu'est-ce que ça veut dire Estelle ? Non, c'est tout simplement ce qui permet aux entreprises de se distinguer de la concurrence, des uns des autres, en respectant bien sûr l'éthique et la culture forte et de de l'entreprise et qui va favoriser l'innovation. OK. Une fois qu'on a ces deux blocs là, qu'on a répondu à ces deux questions, ce qu'on va faire, c'est qu'on va essayer de décrire les activités de l'entreprise euh dans le what de et surtout on va essayer de décrire le les services que que va nous que va rendre le produit à notre utilisateur. On va dans le what. OK.
[00:18:06] Euh donc si je veux appliquer ça, si je veux essayer de d'extraire le why pour ma pour ma pour ma boîte ou pour mon mon service, pour mon applicatif, euh il y a des techniques assez rapides, hein, qui existent, si vous avez envie de de tester. Il y a le fait de pouvoir faire des complétions de essayer de compléter cette phrase.
[00:18:22] Euh c'est c'est ce qui s'appelle la proposition de valeur. Euh notre produit, euh aide les utilisateurs, euh afin de faire ça, en apportant en apportant ça. OK.
[00:18:34] Euh il existe aussi d'autres moyens, il existe le le Business Canvas ou le ce qu'on appelle aussi on peut aussi trouver ça sous une autre forme qui s'appelle le NABAC, le Need Benefit Approach Competition. Ce que ça permet, ça, c'est finalement de trouver notre why et de définir notre but, donc notre objectif. Maintenant qu'on a défini le le why, c'est-à-dire notre objectif, on notre proposition de value, on va essayer de passer au how, c'est-à-dire toutes les actions, tout tout ce qui nous permettrait euh bah d'expliquer notre pourquoi, tout ce qui pourrait nous distinguer de la concurrence. OK. Pour ça, j'ai essayé un atelier très sympa qui s'appelle l'atelier du Cover Story. Je sais pas si vous le connaissez. Euh dans mon ancienne entreprise, on était en manque de pourquoi, on faisait un un outil qui nous semblait bon et puis on on savait pas trop où on allait. C'est à ce moment-là que le Cover Story, j'ai réalisé le Cover Story avec eux. Alors, c'est une activité euh qui permet de définir où l'on où notre société ou notre produit sera dans 5 ans. Pourquoi les journaux vont parler de nous et de notre produit ? Why, c'est-à-dire notre objectif, on notre proposition value, on va essayer de passer au how, c'est-à-dire toutes les actions, tout tout ce qui nous permettrait euh ben d'expliquer notre pourquoi, tout ce qui pourrait nous distinguer de la concurrence. OK. Pour ça, j'ai essayé un atelier très sympa qui s'appelle l'atelier du cover story. Je sais pas si vous le connaissez. Euh dans mon ancienne entreprise, on était en manque de pourquoi, on faisait un un un outil qui nous semblait bon et puis on on savait pas trop où on allait. C'est à ce moment-là que le cover story j'ai réalisé le cover story avec eux. Alors c'est une activité qui permet de définir où l'on où notre société ou notre produit sera dans 5 ans. Pourquoi les journaux vont parler de nous et de notre produit. C'est une activité qui est ultra créative, je vous l'avoue, il faut avoir un peu de de de de créativité, ça permet aux gens de rêver du potentiel du succès de l'entreprise, ça permis de de revenir sur bah les qu'est-ce qui va différencier notre produit, qu'est-ce qui va pourquoi on va en parler va parler de notre produit. Euh et pour ça en fait, on va essayer de de de définir de définir ensemble, excusez-moi, c'est le weekend bientôt. Ça permet de définir ensemble, on va définir ensemble, excusez-moi, la couverture, euh les entêtes du sujet, euh les citations, les images euh qui vont apparaître dans l'article, les euh bah les vous savez les les parties, les sous les sous-paragraphes et cetera. Et donc du coup, j'ai fait ça de manière très collégiale avec quelques personnes de la société, donc on a posé tous nos post-it. On a fait un agglomérat de toutes nos idées et on en est sorti avec une espèce de journal, avec une couverture, avec des gros titres, avec un peu tous les mots qui se récité autour du produit. Et en fait, ça nous a fait du bien, c'est quelque chose que on a euh on a bien ajouté imprimé dans nos dans nos locaux. Ça nous a fait du bien parce que à chaque fois qu'on allait rajouter une fonctionnalité ou autre, on savait si ça allait aller dans le sens de notre société dans 5 ans. Donc là voilà, on a défini le why, le how, et maintenant passons au what. Le what, souvent, c'est ce que euh c'est c'est finalement ce le produit, qu'est-ce que l'on va essayer d'apporter à l'utilisateur. OK. Là, je me suis fait un pari un peu euh un peu un peu fou toute seule. Je me suis dit OK, pour connaître au mieux ces utilisateurs, on fait des persona. Je pense que vous vous connaissez tous les personas, c'est des objectifs, c'est des méthodes qui permettent de mettre un visage humain sur des cibles utilisateurs. Et là, je me suis dit, ben écoute, pourquoi ne pas définir un persona applicatif de notre produit, afin de finalement lister le what, c'est-à-dire lister les actions qu'on va réaliser dans ce produit. qui correspondrait au why et au how. Et je me suis amusé, j'ai fait ça toute seule, vraiment, j'ai j'ai pris un peu les blocs des personas classiques, c'est-à-dire un peu l'histoire de notre persona, les buts, euh pourquoi les utilisateurs l'utiliseront, j'ai essayé de décrire un peu les freins et les peurs de l'outil et j'ai construit du coup Terra l'octopus, donc qui était le persona de mon ancienne société, enfin du produit de mon ancienne société. Et ce qui était assez intéressant, c'est en faisant ça, je l'ai aussi collé bien sûr dans le l'Open Space. Et ce qui est intéressant, c'est qu'à chaque fois qu'on avait un nouveau besoin exprimé utilisateur ou une nouvelle demande business ou quoi que ce soit, on allait voir ça et on se demandait OK, est-ce que ça correspond bien à l'univers de Terra ? Est-ce que cette fonctionnalité là correspond bien à ce qu'on a listé, à nos buts, euh est-ce que ça ne va pas renforcer les peurs que l'on a concernant notre outil ? Donc ça voilà, ça a été les les premières, on va dire les les méthodes, les premières méthodes qu'on a utilisées pour définir ben de la page blanche, de construire un peu notre but, notre objectif.
[00:22:40] Ensuite, j'ai tourné les pages, j'ai lu dans mes bouquins, et on dit souvent que une fois qu'on a la page blanche, on va essayer d'ajouter simplement les activités que l'on aime faire, mais qu'on l'on aime faire vraiment. C'est-à-dire celle qui sont très prioritaire par rapport à à notre outil, pas n'importe lesquelles. Donc pour ça, je me suis dit, bah finalement il y a quelque chose qui existe vraiment chez nous côté produit, côté R&D, côté équipe de de développement. C'est le treat card. C'est-à-dire que à chaque fois qu'on a un nouveau sprint, c'est-à-dire de nouvelles fonctionnalités qui arrivent, on essaie de les mettre les mettre en commun et de prioriser celles que l'on va rajouter ou pas. Donc là dans notre nouvelle outil Terra, ce qu'on a fait, c'est qu'on a fait vraiment le le treat card, le card sorting. Euh d'ailleurs, je sais pas si vous le savez, c'est le card sorting, ça a été créé au début pour de la psychologie cognitive. Et ça a été utilisé en 1946. Alors désolé, là je suis en train de lire le bout de Wikipédia que je me suis listé, mais ça a été du coup créé en 1946 pour identifier les troubles cognitifs. Comme quoi, je vous l'avais dit, l'humain et les applicatifs, ça peut être très lié. Euh, je reviens à mon carte carte sorting, euh ce que ce qu'on fait avec un trit card, c'est que le principe, c'est de savoir trier, classer, regrouper, nommer les fonctionnalités, euh afin de comprendre vraiment le besoin utilisateur. Donc c'est-à-dire que vous pouvez autant le faire avec votre utilisateur, vous pouvez autant le faire qu'avec votre votre équipe produit, c'est à vous de voir. Vous pour ceux qui ne connaissent pas rapidement, euh vous essayez de poser toutes les fonctionnalités auxquelles vous pensez. Euh donc là en l'occurrence, j'en ai créé vous créez autant de post-it que vous avez que vous en avez que vous avez d'idées, pardon. Soit vous faites un trip card ouvert, c'est-à-dire qu'on dispose de toutes les cartes et on va essayer de les regrouper ensemble comme on le souhaite et on va donner un nom à ce regroupement plus tard, ou soit vous décidez de faire un trip card fermé. Et là, vous vous définissez déjà les noms des regroupements et vous allez juste placer les cartes dans les regroupements. Ce que ça permet de faire, ça permet surtout de voir si euh ces cartes que vous rajoutez au fur et à mesure, ces post-it, ben, ça correspond bien à chacune chacun de vos groupes. Vous pouvez les prioriser, vous pouvez supprimer celles qui n'ont rien à voir. Surtout ça. Pour éviter des choses comme ça, avec des des trucs un peu partout, bref. Euh et surtout, après un un carte sorting, vous pouvez faire un dot voting, c'est-à-dire que vous donnez à l'ensemble de la table quatre points par personne et vous leur demandez de prioriser, de mettre ces quatre points sur les fonctionnalités que vous souhaitez absolument faire. Et c'est ces fonctionnalités là qui va rentrer dans votre backlog et dans votre sprint, euh et c'est celle sur lesquelles vous allez ben passer du temps. Et il faut faire ce ce ce trip carte très souvent pour être sûr que on va dans la bonne direction tout au long de la conception du produit. OK. J'ai aussi une autre idée. C'est-à-dire que j'ai lu que OK, tu as fait tout ce que tu vous pouvais, genre Estelle, ton burnout, tu as géré tes parties de ta page blanche, tu as ajouté ce que tu pouvais rajouter. Mais souvent, il y a des cas perdus. Et oui, imaginez moi, Estelle burnout. Euh des fois, on on peut avoir besoin de l'aide d'un spécialiste, d'un expert, d'un psychologue pour nous aider parce que bah ça nécessite peut-être un plus gros, plus gros travail. Vous voyez ce que je veux dire. Bon dans notre situation, avoir un psychologie un psychologue avec nous pour nous aider dans du trite carte. Non merci. Euh par contre, avoir un UX designer ou quelqu'un qui essaie de représenter un petit peu euh bah la philosophie UX dans notre équipe, ça peut être une bonne idée. C'est-à-dire que le UX designer, lui, son son utilité, c'est d'être sûr que les fonctionnalités que l'on ajoute correspondent bien aux besoins de l'utilisateur et sont bien ajoutées pour que l'outil soit utilisable. OK. Euh donc on va dire que nos UX designers sont nos outils. Et que finalement les ateliers du UX designer sont un peu les séances des psy. Non, je vais trop loin, je suis d'accord, je vais trop loin. Bref, revenons. Les UX designers, on va dire qu'ils sont pleins de techniques pour essayer de comprendre quand notre outil va mal, euh si des utilisateurs n'arrivent pas à retrouver, qui n'arrivent pas à comprendre votre IHM, votre UI, euh ça veut dire qu'il y a un problème. Donc lui, son job, ça va être de vous proposer des techniques pour vous aider à élaguer ou à revenir ou ou venir ou simplement à ajouter les bonnes features au bon moment pour les bons utilisateurs. OK.
[00:26:43] Donc ce que je vais essayer de vous proposer maintenant, c'est que je vais essayer de vous montrer trois ateliers utilisateurs que j'ai moi-même réalisé, et qui vont vous permettre en fait de savoir très rapidement si vous êtes dans le bon, si votre utilisateur comprend, si les vos écrans sont lisibles. Euh voir un peu ce que ressent l'utilisateur en en prenant en main votre outil, est-ce que c'est rapide, est-ce que il il arrive à à s'en sortir seul et surtout avoir s'il arrive à faire ben des cas d'usage classiques. Et pour ça, je vais vous présenter trois ateliers, donc le test des 5 secondes, les complétions de phrases et l'UTT donc l'UUT, pardon, unmoderated user test. J'ai une petite coquille dans la slide. Le premier, c'est le test des 5 secondes. Alors, c'est très simple, test des 5 secondes, c'est une méthode qui permet de recueillir la première impression des utilisateurs, euh vraiment dès les premières secondes. C'est-à-dire qu'on va montrer un écran, puis pouf, on va cacher l'écran au bout de 5 secondes et on va demander à nos utilisateurs de redessiner l'écran sur un morceau de papier. Alors oui, euh ça paraît bizarre, mais on va faire ça au bout de 5 secondes, on va leur demander de dessiner, puis au bout on va remontrer l'écran 10 secondes cette fois-ci. Paf, on va la on va le cacher et on va redemander à nos à nos participants de redessiner l'écran et puis on va le faire une troisième fois avec 15 secondes. Le but de cet atelier, c'est de connaître les impressions euh de votre utilisateur sur l'écran. de de voir si l'utilisateur a compris l'objectif et l'usage de l'écran et savoir ce qu'il pense de l'esthétique aussi globale, s'il arrive à retrouver les les éléments d'interface. Ça permettra de vous montrer du coup et d'éviter qu'on se retrouve sur l'exemple que je vous ai montré tout à l'heure de ce site incroyable où on avait des trucs partout. Alors le je l'ai fait avec un un ami à moi, un collègue à moi sur un outil qui était un outil un un de nos concurrents. Et on était en train de développer une page qui était une page de création de campagne publicitaire pour tout vous dire. Et je décidé de faire cet atelier sur bah la même page de notre concurrent. Donc je lui ai montré euh 5 secondes l'écran. Je lui ai caché et je lui dis vas-y, essaie de dessiner. Donc là rapidement, hop hop hop. Vous avez vu, il a réussi à retrouver les regroupements fonctionnels de l'écran. Le regroupement fonctionnel de la barre de nave en haut, les blocs un petit peu où il a mis des pourcentages, voilà, il pense que c'est un dashboard et un tableau. Ça, c'est la première chose à voir au bout de 5 secondes, si vous ne l'avez pas, c'est qu'il y a un problème, c'est qu'il faut que l'utilisateur, un coup d'œil, arrive à retrouver les regroupements fonctionnels du de l'écran. Si c'est pas le cas, c'est qu'il y a peut-être un problème. Ou si c'est pas clair pour lui, que c'est très flou, c'est peut-être un problème. J'y viendrai après. Ensuite, j'ai fait ça avec 10 secondes. Et là, vous avez vu, vient se rajouter un petit bouton new line et il a complété un petit peu le tableau, il a complété un peu ses dashboard, même la barre de navigation, il savait qu'il y avait un logo. Donc là au bout des 10 secondes, normalement c'est à ce moment-là où on est censé essayer de commencer à prendre des bouts d'esthétique de l'écran et on est surtout censé avoir les boutons primaire. Vous savez, ces actions primaires que l'on met en avant de création, de suppression, euh ben ça normalement, c'est ce que vous devez avoir absolument au bout de 10 secondes. Si vous ne l'avez pas, toujours pareil, ça veut peut-être dire que vous l'avez pas bien mis en avant, pas de la bonne solution, pas de la bonne manière. Et s'il y en a trop, bah l'utilisateur va peut-être pas remonter les plus importantes, donc il va en remonter plein, il va vous faire plein de schémas. Mais avant tout, il faut savoir que un écran a un usage bien défini avec un bouton d'action primaire bien défini, un ou deux, mais voilà. Et pareil, j'ai refait le le test encore 15 secondes et là on rentre vraiment dans un écran un peu plus détaillé où mon collègue a trouvé ben les éléments un petit peu euh je lui ai demandé de rajouter des couleurs pour avoir l'esthétique, donc le vert, le rouge, il a même trouvé en plus euh tout le système de navigation, même le sous-système de navigation, il a même rajouté euh des boutons secondaires, des fonctionnalités secondaires comme dans le tableau, bon, il l'avait fait tout à l'heure au bout de 10 secondes, mais il a rajouté le champ de recherche, le champ de filtre, il a vu qu'il y avait des actions possibles sur chaque case. Bref, il est rentré dans les détails et à ce moment-là quand j'ai demandé à quoi sert l'écran, il savait exactement me dire son usage. Donc ça c'est pour le première le premier exemple, c'est-à-dire que vous avez avec cet atelier, un moyen rapidement de savoir si votre écran est compris ou pas par vos utilisateurs. Bien sûr, il faut faire attention, ils font convoquer des gens qui rentrent dans vos persona initiale et il faut aussi euh ça, il faut faire très attention, prendre des écrans qui soient assez parlants euh aussi de base et qui soit un peu le cœur de votre applicatif. Si vous voyez qu'il y a trop de choses, qu'il y a que les boutons n'ont pas été trouvés dans le bon temps, que le graphisme n'a pas été compris, que le regroupement fonctionnel est un peu fouilli, ce que je vous propose là, c'est de repartir de zéro ou euh d'essayer de de de revenir à l'essentiel et de reprendre la règle numéro 1 et de poser dans votre écran ce qui vous semble le plus important, qui vous semble correspondre à votre objectif, à l'objectif de votre produit. Deuxième méthode, euh c'est le test utilisateur et euh ça me fait très rire parce que euh j'aime beaucoup euh commi script qui fait euh qui dit qu'en fait, le test utilisateur, c'est un peu le but ultime pour savoir si un utilisateur va faire planter votre application ou pas. Donc ça, vous le savez très bien, c'est le principal, c'est-à-dire que dès que vous avez un prototype ou dès que vous avez poussé une version en prod. Le meilleur moyen, c'est de mettre comme commiscrip, une dame devant le le le PC ou un monsieur et de lui demander de l'utiliser. Là, vous voyez la la personne, la dame, elle elle galère un peu, uploader, ça veut dire quoi ? Pourquoi je peux pas fermer, ça bug bug. Bon, ça marche pas. Bon, c'est planté. Et au final on se rend compte au dernier moment qu'il va falloir refaire tout le X voir même un peu plus. Nous, on veut pas ça. Donc ce qu'on veut faire, c'est qu'on va essayer de de de mettre en place des UUT, je vous parlais donc des des tests utilisateurs. Et pour ça, vous pouvez faire des UUT qui sont du coup unmoderated, c'est-à-dire que vous avez pas du tout la main dessus. Donc vous donnez un brief à votre utilisateur. Vous lui dites ben, crée-toi ton compte avec tel et tel information. Va chercher le produit euh qui t'intéresse, qui s'appelle comme ça. Va l'ajouter et va faire le paiement. Et surtout, c'est le moment où vous vous placez derrière lui en shadowing ou que ou si vous êtes à distance, vous prenez en en capture ou en vidéo l'écran de la personne. Et vous essayez d'étudier au plus finement le mouvement de la souris, euh vous essayez de demander à votre utilisateur de décrire ce qu'il fait, de de de de parler à voix haute, enfin de réfléchir à voix haute et de poser toutes les questions qu'il a. Attention, le but étant de ne pas du tout l'aider, de le laisser faire complètement. Et c'est là où vous allez vous rendre compte si oui ou non votre outil est utilisable ou s'il ne l'est pas et si même malgré votre brief, même si vous faites un brief détaillé, il n'arrive pas à s'en sortir, c'est qu'il y a un problème. Et je rajouterai même que même s'il s'en sort et même si ça c'est quelque chose qui reste un succès, vous pouvez après aller dans le détail avec déplacement de la souris pour voir qu'est-ce qui est qu'est-ce qu'on a vu rapidement. Vous pouvez aussi prendre chronométrer le détail de la session pour voir en moyenne combien de temps ça prend de juste mettre un article et l'acheter. C'est c'est des super indicateurs. Et pour terminer, juste rapidement, euh ce que je fais après un UUT, c'est que je fais des complétions de phrases. Alors, une fois qu'on a fait la partie un peu euh test utilisateur, souvent c'est bien d'avoir un un compte-rendu, d'avoir un peu le le mindset de notre notre utilisateur. Donc je lui demande de me renseigner un petit peu ses phrases. Genre utiliser votre produit, c'est hmm hmm. Les fonctionnalités de votre produit sont hmm hmm. Euh votre produit n'est pas adapté pour faire ça, ou c'est le meilleur pour faire ça. Et avec ça, vous allez construire une espèce de d'arbre de de mots où vous allez pouvoir voir euh qu'est-ce qui en qu'est-ce qu'on dit de votre produit et qu'est-ce que qu'est-ce que qu'est-ce qui manque, qu'est-ce qui est irritant et voir s'il y a des des éléments qui se retrouvent. Et le but, c'est de faire ça au fur et à mesure euh un peu tout le temps à chaque fin d'interview utilisateur. OK, j'envoie certains qui me disent ouais mais Estelle, c'est trop de boulot ce que tu me racontes. En plus c'est du c'est du qualitatif, c'est-à-dire qu'il va falloir que je retraite le champ lexical et cetera. Je vous vois venir parce que moi aussi je suis comme ça. Dans ces cas-là, pour éviter de perdre du temps, vous pouvez faire des SUS, donc du system usability scale, c'est-à-dire des échelles d'utilisabilité. C'est assez rapide en fait, c'est un questionnaire qui permet d'avoir un indicateur très rapide sur l'utilisabilité de votre système. Vous avez 10 questions, euh chaque question est notée sur un indicateur qui va de 1 à 5. Je j'ai la version traduite si vous si vous voulez, en tout cas moi je je je l'ai dans mon super livre et Bible que je vous montrerai un peu si vous avez des questions dans UX méthode de design UX. Et en fait cette cette échelle, ça vous permet une fois que l'utilisateur a complété et a mis ses indicateurs, enfin à choisir un chiffre, ça vous permet d'avoir un un quotient entre 0 et 100. Si vous êtes en dessous de 60, ce n'est pas acceptable entre guillemets, on dit que l'UX n'est pas satisfaisante. Si c'est au-delà de 60 et surtout 70, ça veut dire que l'UX est assez bien faite et votre utilisateur va avoir va va pas prendre, va excusez-moi, va pas avoir de souci lorsqu'il va prendre en main votre outil. Pareil, c'est un élément que vous pouvez faire à chaque fois, chaque fin de test utilisateur. Ça vous permettra de voir s'il y a une évolution positive ou négative en fonction des maquettes que vous y avez données. Je dis ça, je dis rien, ça peut être fait dès demain euh dès lundi, si vous sentez euh si si vous souhaitez et si vous avez des questions sur ça, n'hésitez pas, je je pourrais répondre juste à la fin. Dernière étape euh qu'on voit surtout dans les livres hein après l'aide d'un expert et cetera. On vous dit surtout surtout maintenant Estelle, quand tu as fait ces trois étapes. Pour éviter d'être en surcharge, il faut que tu, dès que tu vois quelque chose qui à ton avis va te rendre en surcharge, faut que tu l'évites. Faut que tu essaies d'éviter toute surcharge, toute chose qui va venir te prendre du de l'espace euh et du et du temps. OK. Donc ça vous allez me dire au niveau de l'humain, c'est un peu flou, ça veut dire qu'il faut que je n'accepte pas tout ce que je dois tout ce que j'ai sous la main, OK. Euh ça veut dire aussi que je vais essayer d'être vigilant. Ça veut dire qu'à chaque fois que je vais euh qu'on va me proposer quelque chose, je vais avoir un automatisme qui va dire non, pas pour l'instant, je sais pas si j'en ai vraiment envie. Euh OK, donc si on part sur ce concept de vigilance et d'automatisation, ben côté produit, on sait que rien de mieux que nos outils d'Analytics, je je pense que je vais pas vous je vais pas réinventer la roue en vous disant ça. C'est-à-dire que vous avez des outils comme Google Analytics qui vous permet d'avoir énormément d'éléments pour savoir si vos utilisateurs sont toujours présents. restent longtemps sur votre site, quelle est la moyenne des des sessions, euh voir quelles sont les les les fonctionnalités les plus utilisées. Ça outil très puissant parce que finalement ça vous permet de savoir réellement euh ben si vos utilisateurs sont contents et ont envie de rester sur votre plateforme et est-ce qu'ils ils ont vraiment une valeur ajoutée à utiliser votre produit. Euh ce qu'il y a aussi qui existe aussi, c'est les euh les les cartes alors comment on dirait ça en français, les cartes de chaleur ou les hitmapp. Euh moi j'avais utilisé Hotjar qui est un outil qui est très puissant qui vous permet de savoir en fonction du déplacement de la souris, euh même des fois euh si on fait des tests avec les les yeux, de savoir réellement qu'est-ce que va voir le plus l'utilisateur, où est-ce qu'il va le plus se diriger. Et ça vous permet surtout de savoir voilà, genre si j'affiche euh une une la page de la du site vitrine par exemple, où est-ce que l'utilisateur va rester? Est-ce qu'il va scroller? Est-ce qu'il va rester sur le haut? Ou est-ce qu'il va cliquer au départ? Euh j'avoue que j'avais fait un un test avec une start-up Montpelliraine, on l'avait branché sur leur site vitrine et on avait remarqué que l'utilisateur ne scrollait jamais juste en bas du site et pourtant, quand on scrollait, on avait vraiment euh des promos, des avis, qui l'utilise, on avait beaucoup de choses qui permettait bah la complétion, l'achat. Et donc du coup, ce qu'on s'est dit et grâce à Odjar, grâce à ces ces cartes de chaleur, on s'est dit OK, vu que l'utilisateur a tendance à plus acheter quand il voit qui utilise notre application, vu qu'on est une petite start-up, on va essayer de relever ce paragraphe et le mettre un peu plus haut. Et en faisant ça, on a augmenté plus de 70 % l'outil enfin le le scroll et enfin les gens sont restés euh beaucoup plus euh sur l'outil. Donc clairement, je vous le conseille. En tout cas, c'est très très puissant si vous pouvez l'avoir.
[00:36:15] OK. Ça fait plus de 35 minutes que je vous bassine, que je vous ai donné quatre piliers de de simplification. Euh je pense qu'il est l'heure du bilan. Euh je sais pas si vous l'avez vu, mais finalement ces quatre bonnes pratiques qu'on a sorti. Euh moi je vais les appeler les quatre piliers de la simplification. Parce que finalement grâce à ces règles qu'on a mis en place, euh on s'est aperçu que notre produit, ben on allait euh le rendre finalement euh utilisable, on allait éviter la surcharge grâce à ces grâce à ces quatre piliers. Euh juste pour vous rappeler, le premier pilier, vous savez, c'était euh pourquoi fait notre applicatif, quelles sont nos valeurs, on essaie de se recentrer sur l'objectif du produit. Vraiment c'était une phase d'analyse, d'empathie, on a essayé de comprendre qu'est-ce qu'on voulait faire. Ensuite, dans la deuxième phase, dans notre deuxième pilier, c'était un petit peu générer des idées, prioriser des idées, faire des choix en accord du premier palier. Donc finalement, on est rentré déjà dans la définition, dans la génération d'idées, donc dans l'idéation. Ensuite, on est passé au troisième pilier. Donc là, je vous ai dit, OK, faut avoir l'aide d'un designer pour avoir des retours. Euh donc être donc faire des tests, donc on était vraiment sur du prototypage. Et dernier pilier, donc c'était éviter tout surcharge futurale en restant vigilant. Donc finalement en essayant d'avoir une boucle de feedback pour revenir finalement et corriger ce qu'on aurait. Je sais pas si ça vous fait penser à quelque chose. Euh mais euh ces quatre piliers me font penser un petit peu au design thinking. Alors pour ceux qui ne connaîtraient pas le design thinking, c'est une approche issue de l'UX, de l'expérience utilisateur. qui dit qu'en gros, euh en tant que moi en tant que UX, si vous voulez, dans ma vie, j'utilise tout le temps pour conduire efficacement l'ajout de nouvelles fonctionnalités. Le design thinking, c'est une méthode qui permet de créer, de saturer, comprendre bien le besoin utilisateur et qu'on va venir apporter de la valeur et qu'on est sûr que l'on a réussi cet objectif en faisant des tests et du prototypage par exemple. Euh vous avez du design thinking en trois, 5 ou 7 étapes. Mais le principe reste le même. Et je sais pas si vous l'avez vu là, mais ces 5 étapes regardent, ressemblent finalement à nos quatre piliers de la simplification que j'ai présenté tout à l'heure. Tout ça pour vous dire que euh si vous souhaitez rajouter une fonctionnalité, il faut vraiment voir si cette fonctionnalité correspond à un besoin utilisateur et correspond à l'âme de votre produit, à votre vision produit. Euh c'est très important de ne pas rajouter tout et n'importe quoi et de s'assurer que ce que l'on fait, c'est euh dans la même vision et dans la même lignée que ce que l'on a que que ce que l'on a défini au niveau euh vision. Voilà, c'est vraiment ça sur lequel j'ai envie de terminer. Euh j'espère avoir été très clair, euh vous avoir donné envie de mettre en place toutes ces méthodes et je vous remercie et je suis prête pour les questions. Un grand merci à tous.
[00:38:30] Merci.

Transcription