Transcription du podcast :
Bienvenue sur le podcast « Parlons UX Design ». Je suis Thomas Gaudy, UX designer spécialisé en accessibilité des jeux vidéo aux personnes ayant un handicap.
Salut tout le monde!
Aujourd’hui, pour ce 28e podcast, je vous parle de l’effet tunnel, un phénomène sociologique qui s’installe tout naturellement dans votre dynamique de projet pour venir y semer les graines de l’échec.
L’effet tunnel, c’est la mort lente de votre projet, sans même que vous la voyiez arriver.
C’est quoi ? C’est la perte de contact progressive avec votre client.
C’est aussi pour ça que les méthodes agiles se sont tant développées : pour maintenir un contact avec vos clients, sur un rythme régulier, toutes les semaines ou toutes les deux semaines, avec un retour en général plus complet, parfois chaque mois.
L’effet tunnel, ça fait quoi ? Eh bien, du fait de l’interruption de la communication entre votre client et vous, vous partez progressivement chacun dans une direction de design de plus en plus distincte.
Ça va très vite. En fait, plus le temps passe, plus c’est dommageable, car plus le temps passe, plus chacun s’attache à sa propre vision, et plus ces visions deviennent incompatibles entre elles.
Et les retrouvailles avec votre client deviennent forcément douloureuses. Typiquement, le client peut vous dire : « Très bonne idée, cher designer, mais ce n’est pas de ça du tout dont on parle. Donc tu vas me jeter ça à la poubelle, et on va repartir sur de bonnes bases, et que je ne te reprenne surtout plus à être hors sujet. »
Sauf que vous ne pouvez pas deviner ce qui devient hors sujet, à partir du moment où la communication se coupe.
Il y a plein de facteurs qui causent l’effet tunnel. Le contexte sociologique est généralement assez favorable à l’installation de cet effet.
En premier lieu, en général, vous n’avez pas le temps.
Pendant qu’on parle du projet avec le client, on ne fabrique pas le projet pour lui.
Deuxièmement, le client n’a pas le temps.
Pendant qu’il vous charge de faire le projet, le client espère bien pouvoir avancer de son côté sur d’autres chantiers.
Troisièmement, ce qu’il y aurait à présenter au client n’est généralement pas convaincant.
Peu de gens aiment tendre le bâton pour se faire battre, donc l’idée de présenter un truc non convaincant risque de miner la confiance du client. Ce n’est probablement pas une bonne idée.
« Cher client, je vous présente mon interface, alors c’est une page blanche, la meilleure interface, c’est celle qu’on ne voit pas… »
Le client va probablement s’attendre à quelque chose de plus substantiel.
Quatrièmement, ça ne sert à rien, puisque tout bon projet démarre avec un doc de spécifications ou un cahier des charges, voire une bonne explication orale bien nébuleuse qui cessera en général d’être claire passée la première minute de fin de réunion.
Je veux dire, si le client vous a expliqué par téléphone qu’il a besoin d’une mise à jour de « l’interface du turbotator exportable sur PC, tablette et terminaux de vente, à l’usage des clients, mais surtout des employés de terrain œuvrant la nuit dans les tunnels du réseau »… À quoi bon faire des réunions si tout démarre de façon aussi limpide ?
Cinquièmement, on sait que les « réunionites » sont un fléau.
Je veux dire, regardez tous ces gens bien sapés autour de vous, c’est insupportable : ils gagnent dix fois plus que vous à discuter à longueur de journée de comment VOUS allez devoir travailler. Vous n’allez pas en plus les rejoindre pour discuter en sachant qu’ils continueront à gagner plus que vous, et que vous devrez quand même faire le projet après la réunion, alors que pour eux, la journée sera terminée.
Sixièmement, vous êtes en galère : un problème technique, un problème d’inspiration, un problème de compréhension.
Par exemple, le plug-in de réalité virtuelle de votre outil de conception de simulateur de phoques arctiques s’avère incompatible avec la librairie d’extraction de données climatiques par prélèvement olfactif. Ça craint! vous misiez tout le projet là-dessus.
Une discussion avec le client vous exposerait donc dans une situation de faiblesse : vous n’allez surtout pas chercher à provoquer ça. Gagnons plutôt un peu de temps à faire mûrir votre compréhension du projet ou à explorer des solutions permettant de contourner le problème. Par exemple, cette librairie de fonctionnalités fonctionnant sur les modèles d’IA de fourmis quantiques pourrait peut-être vous sortir de la crise.
Septièmement, vous n’aimez pas parler et encore moins écouter des branques vous parler. Ça vous gave de voir la gueule de congénères humains : ils ne comprennent rien à votre métier, que tout le monde vous foute la paix et vous laisse travailler.
Huitièmement, ce n’est pas tant la réunion elle-même qui est redoutable, mais les répercussions de la réunion, qui nécessitent d’alourdir la liste des tâches. À la suite de la réunion, le client veut désormais qu’un diffuseur d’oiseaux mazoutés soit ajouté au projet, ainsi qu’un vaporisateur de crabe en boîte, alors qu’à la base, il s’agissait uniquement de concevoir un bac à sable multifonctionnel pour poissons.
Un diffuseur d’oiseaux mazoutés! Le client est fou! La diffusion de mazout implique pourtant plein de complications, d’encrassage mécanique, et la clause d’entretien du matériel C-634b vous mettrait bien en difficulté sur ce point.
Donc, en fait, je pourrais continuer à énumérer plein de « bonnes mauvaises raisons » à ne pas vouloir discuter avec le client.
Et c’est l’une des raisons de l’instauration des méthodologies agiles : garder un contact avec le client, le forcer, même, à travers des protocoles de discussion qui se veulent brefs, mais fréquents et surtout réguliers.
Très bien… Alors, les méthodes agiles, c’est fantastique, mais ce n’est pas miraculeux. Je compte bien faire un podcast prochainement sur mon expérience de certaines méthodologies agiles. Pour ma part, je suis fan, mais ce n’est pas magique. Il y a des risques, on en parlera une autre fois.
Un des problèmes avec les méthodes agiles, c’est qu’elles prévoient souvent un rythme de communication régulier avec le client… mais elles peuvent comporter des trous sur les interlocuteurs avec qui vous devez discuter, sur d’autres interlocuteurs.
Par exemple : Quel est votre planning de communication, non pas avec les clients, mais avec les usagers, les utilisateurs de votre projet ?
Si vous travaillez sur une nouvelle tâche de téléportation transdimensionnelle de démons gorgons, avez-vous pensé à discuter avec la population gorgon pour savoir quelles sont leurs attentes ? Pourquoi le trafic est si faible sur le portail? Pourquoi les failles sont si peu utilisées ? Non évidemment, vous n’y avez pas pensé. Le client compte sur vous pour que vous réalisiez directement les tâches immédiatement, des brèches de transport parfaites, c’est-à-dire tout doit très bien fonctionner, très vite et sans détour. Vous n’allez donc pas en plus passer du temps à discuter avec des gorgons, qui eux-mêmes pourraient d’ailleurs soulever tous les problèmes évoqués dans la liste précédente et en ajouter peut-être quelques autres.
Pire encore, les réunions avec le client passent encore – je veux dire, c’est lui qui vous paie –, mais discuter avec l’usager, franchement, quelle idée saugrenue! N’êtes-vous pas un expert dans votre domaine? Auriez-vous menti lors des 10 entretiens d’embauche à propos de votre maîtrise des normes et standards en matière de conception de portails?
Chercheriez-vous à ralentir le projet ? Si vous prenez du retard, ce n’est pas juste vous qui prenez du retard, c’est toute l’équipe, toute l’entreprise, tout le réseau de partenaires, en fait. Vous savez que vos collaborateurs ont des femmes, des maris, des enfants ? Voulez-vous vraiment mettre tous ces gens à la rue en faisant échouer le projet ? Êtes-vous abruti ? Pire, seriez-vous incompétent ?
Mais admettons…
Admettons que vous soyez un ou une abrutie, et que vous poursuiviez l’idée de communiquer avec vos usagers.
Mais ils vont vous démonter, vos usagers. En tout cas, si vous faites du bon travail, ils doivent être en mesure de vous démonter.
Votre client, il vous paie. Si vous lui fournissez de la merde, c’est de la merde qu’il a payée. De la merde qui a un prix. Ce n’est donc probablement pas vraiment de la merde, mais quelque chose qui a une valeur, une originalité, un propos. Votre projet, c’est un miroir dans lequel se regarde le client qui a investi en vous. S’il vous saque, son égo se fait égratigner aussi. C’est plus facile pour lui de vous féliciter, car en vous félicitant, il se félicite aussi du choix qu’il a fait de recourir à vos services. Et avec un peu de pratique, des clients peuvent y croire à cette qualité.
Mais l’usager, lui, il ne vous doit rien. Il ne vous paie pas. Vous lui présentez de la déjection de yak : pour lui, c’est moche, ça pue et ça tache. Si vous lui demandez de goûter, en plus, il vous éclate la face et il aura bien raison.
Il y a donc une démarche ultraviolente à courir après l’usager. Un designer comparait cette démarche à l’envoi de cartes de visite invitant à venir défoncer votre projet et votre égo.
Il faut quand même être bien masochiste.
L’idée, a priori évidente, de consulter les usagers d’un projet a été systématiquement difficile pour moi, pour toutes sortes de projets et pour toutes sortes de raisons.
Donc, si l’effet tunnel pour communiquer avec le client est déjà difficile à contrer (mais on y arrive avec l’aide méthodologique qui fait de plus en plus sens d’ailleurs dans les cultures d’entreprise), eh bien, l’effet tunnel pour rester en contact avec ses populations d’usagers est encore plus difficile à contrer, car là, vous devez complètement nager à contre-courant.
Contre votre estime de vous, contre votre propre équipe, contre vos clients.
Et si vous parvenez finalement à avoir le contact avec eux, même là, il y a toutes sortes de façons de massacrer votre communication : en renvoyant la responsabilité des problèmes remontés, non pas à votre projet, mais à l’attitude ou au comportement de l’usager. (Note pour plus tard : en général, l’usager n’a jamais tort, mais, par défaut, on a envie de lui attribuer toutes sortes de problèmes qu’on pourrait rencontrer.) Il peut y avoir des formes d’intimidation, même sournoises, qui peuvent rapidement complètement biaiser le rapport du testeur au bidule à tester. Ça aussi, j’y reviendrai sur un autre podcast.
Si vous parvenez à maintenir un bon contact avec d’une part votre client, et d’autre part vos usagers, bravo! A priori, vous êtes quand même sur une très bonne voie pour définir les besoins de chacun des bords… Mais êtes-vous en mesure d’y raccrocher les moyens ? Oui, parce que jusqu’à présent, il s’agissait bien de définir les besoins. Mais les moyens, pour peu que vous travailliez en équipe, dépendent beaucoup de nombreux autres collaborateurs.
Je conclus donc ce podcast par une petite question innocente, comme ça : comment se portent vos effets tunnel avec vos autres collaborateurs, ceux qui détiennent les moyens de répondre aux besoins identifiés ?
Voilà pour l’effet tunnel.
Si vous avez aimé ce podcast, si vous pensez qu’il peut intéresser d’autres personnes, utilisez le système d’évaluation de votre plateforme d’écoute pour le rendre plus visible à plus de monde.
Merci, à la semaine prochaine!
Merci d’avoir écouté ce podcast. Je vous invite à vous abonner pour ne pas rater les prochains épisodes. Si vous voulez en savoir plus sur moi, je vous invite à consulter mon profil LinkedIn : Thomas Gaudy. Si vous souhaitez de l’accompagnement pour implémenter ces notions et ces outils dans vos équipes et vos projets, vous pouvez faire appel à mes services de consultant en UX design. Il vous suffit de me contacter via mon profil Linkedin. Au plaisir!
Transcription et correction du podcast : Mélissa Lamontagne
Édition : Stéphanie Akré