Le brief client est clair… jusqu’à ce que tu poses UNE question

Dans l'idéal, un brief client devrait contenir tous les éléments nécessaires pour démarrer un projet UX. Or, la réalité est souvent bien différente. Les briefs sont généralement :

• Les wireframes qui ressemblent plus à une œuvre d'art abstraite qu'à une interface (parce que "l'esthétique avant tout, n'est-ce pas ?"), avec des composants si complexes qu'ils feraient pleurer un développeur senior et une architecture de l'information digne d'un labyrinthe grec

• Des objectifs business qui semblent avoir été générés par un ChatGPT en mode panique ("Nous voulons disrupting the market avec une expérience utilisateur révolutionnaire" - traduction : on n'a aucune idée de ce qu'on veut)

• Une avalanche d'hypothèses non vérifiées qui s'accumulent comme des notifications non lues dans Slack, basées sur ce que le cousin du beau-frère du PM a dit qu'il avait vu chez un concurrent

Par exemple, j'ai récemment travaillé avec une startup qui voulait "refaire leur interface de A à Z". En creusant, il s'est avéré que leur véritable problème était un taux d'abandon élevé sur une fonctionnalité spécifique. Une refonte complète n'était pas la solution.

Un cadrage insuffisant peut avoir des répercussions graves sur le projet :

• Des allers-retours interminables avec le client qui ressemblent à une partie de ping-pong existentielle, où chaque modification entraîne une cascade de "et si on changeait aussi..." jusqu'à ce que plus personne ne se souvienne de l'objectif initial du projet (ni même de son propre prénom)

• Des pivots stratégiques plus fréquents que les mises à jour iOS, transformant votre belle roadmap soigneusement planifiée en un origami conceptuel digne d'un musée d'art contemporain, avec des changements de direction si brusques qu'ils donneraient le mal de mer à un marin aguerri

• Une démotivation progressive des équipes qui commence par des soupirs discrets en daily, évolue vers des regards désespérés en planning poker, et finit en mode "existential crisis" devant la machine à café, pendant que le Product Owner tente de maintenir un semblant d'enthousiasme en parlant de "challenges enrichissants"

• Un produit final qui répond aux besoins d'il y a six mois (quand le brief était encore pertinent), mais qui se retrouve aussi déconnecté de la réalité que votre grand-mère essayant d'expliquer TikTok, créant ainsi un magnifique exemple de ce qu'on pourrait appeler "l'anti-pattern du décalage temporel UX"

Un UX Designer m'a récemment confié avoir passé trois mois sur un projet de refonte, pour découvrir à la fin que le client avait une contrainte technique majeure qui rendait impossible l'implémentation de la solution. Cette information aurait dû être identifiée dès le départ.

Pour éviter ces écueils, voici une approche structurée du cadrage UX :

• Commencer par reformuler le problème sous forme de question ("Comment pourrions-nous..."), une technique ancestrale pratiquée par les plus grands UX Designers qui, las de recevoir des briefs aussi clairs qu'une documentation technique écrite en cunéiforme, ont décidé de prendre les choses en main en transformant chaque demande floue en une formulation précise et actionnnable

• Identifier et prioriser ce qui est essentiel vs. "nice to have" (ou comme on dit dans le jargon, séparer le "must-have-sinon-le-client-va-faire-une-crise-existentielle" du "ce-serait-cool-mais-franchement-on-peut-s'en-passer"), une étape cruciale qui nécessite autant de diplomatie qu'un sommet international et autant de précision qu'un horloger suisse avec trois cafés dans le sang

• Aligner toutes les parties prenantes sur une définition commune du succès, cette quête du Graal moderne où l'on tente de faire converger les visions du PM qui rêve de metrics stratosphériques, du dev qui souhaite un code plus propre que sa vaisselle du dimanche, et du client qui "veut juste que ça marche" (spoiler : personne n'a la même définition de "ça marche")

Cette méthode a fait ses preuves. Sur un projet récent pour une banque, nous avons passé une journée entière en atelier de cadrage. Résultat : un projet livré dans les temps, sans surprise majeure, et des utilisateurs satisfaits.

Un bon cadrage UX n'est pas une perte de temps - c'est un investissement. Il permet d'éviter les malentendus, de réduire les risques et d'augmenter les chances de succès du projet. Comme le dit le vieil adage : "Un problème bien posé est à moitié résolu."