Quand le client arrive avec un prototype AI

Un constat sur les débuts de projets
Au cours des dernières semaines, j'ai remarqué un changement dans la façon dont plusieurs projets démarrent. De plus en plus souvent, les premières rencontres ne commencent pas avec un besoin d'affaires, une problématique ou une opportunité à explorer. Elles commencent avec un prototype conçu par le client.
Qu’il soit conçu dans Claude, Lovable, V0 ou Figma Make, le résultat est souvent le même : une solution déjà matérialisée, parfois très détaillée, qui sert de point de départ aux discussions.
Ce changement n'est pas surprenant. Les outils sont plus accessibles que jamais et permettent de transformer rapidement une idée en interface tangible. Ce qui demandait autrefois plusieurs jours ou semaines par des experts du numérique peut maintenant être produit en quelques heures.
Mais cette nouvelle réalité m'a amenée à constater un phénomène intéressant : plus le prototype est avancé, plus il risque d'occuper l'espace de discussion. Les conversations se déplacent naturellement vers ce qui est visible. On commente les écrans, les fonctionnalités et les parcours.
Sans s'en rendre compte, on peut commencer à discuter de la solution avant d'avoir pleinement clarifié le problème.
Exemple fictif réalisé avec Figma Make
Quand le prototype devient le brief
Ainsi, j'ai constaté que le prototype attire rapidement l'attention durant l’étape de découverte. Parce qu'il est concret et visuel, il tend à devenir la référence principale des premières discussions.
Bien que plusieurs intervenants semblaient parfaitement alignés lorsqu'ils regardaient le prototype. Ce n'est qu'en approfondissant les discussions que des divergences importantes sont apparues. Les attentes d'affaires n'étaient pas les mêmes pour tous. Les critères de succès variaient d'une personne à l'autre. De plus, le prototype ne représentait pas toutes les contraintes du projet. 
Parce qu'on voit un prototype abouti, on peut penser à tort qu'il représente l'ensemble des attentes du client : requis d’affaires, contraintes techniques, besoins réels des utilisateurs ou stratégie.
Il faut briser la barrière de cet élément visuel et aller au cœur des problématiques du projet, revenir aux questions de base : À qui nous adressons-nous, que cherchons-nous à résoudre comme problème, quel est la liste de requis, des contraintes ? Je recommande fortement de creuser le prototype présenté en demandant : est-ce que le prototype répond à tout vos besoins ? Qu’est-ce que vous aimez et qu’est-ce qui ne fonctionne pas ? 
L’objectif n’est pas de dénigré le travail réalisé avec le prototype mais de pouvoir identifier à quel point il est complet pour représenter la vision des clients et de leurs besoins.
Un prototype généré par un client n’est pas une recherche utilisateur
Les clients possèdent souvent une connaissance approfondie de leur domaine. Cette expertise est précieuse et nourrit de bonnes idées. Les prototypes qu'ils conçoivent s'appuient sur leur expérience, leur compréhension du marché et leur vision du produit. Malgré cela, un prototype ne remplace pas la recherche utilisateur. Il représente simplement une interprétation de leur besoin.
L'une des forces de la démarche UX a toujours été sa capacité à valider les hypothèses à la réalité du terrain. Les utilisateurs ne se comportent pas toujours comme on l'imagine. Ils développent leurs propres stratégies, leurs propres raccourcis et leurs propres façons de contourner les obstacles.
C'est souvent dans cet écart entre ce qui était prévu et ce qui est réellement observé que les apprentissages les plus intéressants émergent et que les fonctionnalités vont se raffiner pour offrir des expériences qui sont vraiment utiles pour les utilisateurs.
Lorsqu'une solution est déjà bien matérialisée, il peut devenir plus difficile de maintenir cette posture d'exploration. Les écrans nous forcent à envisager une solution particulière et, par facilité, nous pouvons être portés à explorer moins activement d'autres avenues qui répondraient peut-être mieux aux besoins.
Exemple fictif réalisé avec Figma Make
Quand le prototype devient difficile à remettre en question
Les outils actuels permettent de produire rapidement des prototypes très aboutis. Les interfaces sont cohérentes, les parcours semblent réfléchis et le résultat donne parfois l'impression d'un produit presque terminé.
Cette qualité visuelle est précieuse pour communiquer une idée, mais elle peut aussi influencer la dynamique des discussions.
Dans une démarche UX, un prototype est avant tout un outil d'apprentissage. Il sert à explorer des hypothèses, à tester des idées et parfois à démontrer qu'une solution doit être revue en profondeur. Son rôle n'est pas de confirmer une réponse, mais de faciliter sa validation.
Pour les clients, la relation au prototype est bien différente. Celui-ci représente parfois plusieurs heures de réflexion et devient la matérialisation d'une vision. Plus il paraît abouti, plus il peut être difficile de le considérer comme une simple hypothèse.
Il devient difficile de le remettre en question.
Plus un prototype est soigné visuellement, plus il devient difficile à challenger. Qu'il s'agisse d'ergonomie, d'accessibilité, de contraintes techniques ou d'enseignements issus de la recherche utilisateur, certaines recommandations peuvent être perçues comme des modifications à une solution déjà établie plutôt que comme des occasions de l’améliorer.
Le défi n'est donc pas le prototype lui-même, mais l'attachement qu'il peut générer. Le rôle du UX est alors de rappeler qu'un prototype, aussi convaincant soit-il, demeure une hypothèse appelée à évoluer.
Exemple fictif réalisé avec Figma Make
Les avantages sont bien réels
Malgré les défis qu'ils peuvent introduire, je considère que ces prototypes clients peuvent être un apport positif au projet.
Ils rendent les idées concrètes. Ils accélèrent certaines discussions. Ils réduisent les ambiguïtés et facilitent la collaboration entre les équipes. Dans plusieurs situations, ils permettent même d'atteindre un niveau de compréhension mutuelle beaucoup plus rapidement qu’auparavant. 
Nous pourrions aussi imaginer qu’un prototype bien construit pourrait être un gain de temps pour réaliser des tests utilisateurs et proposer des ajustements par la suite. Ce serait un accélérateur incroyable.
Le problème n’est donc pas le prototype mais plutôt la manière qu’il a été conçu et l’attachement qu’il peut créer auprès du client. Un prototype doit être perçu comme un élément modifiable dans le projet, non une finalité.
Exemple fictif réalisé avec Claude Design
Un rôle UX qui continue d'évoluer
L'un des constats les plus intéressants que je retire de cette évolution est que la valeur du UX ne disparaît pas. Elle se transforme.
Les outils rendent la création d'interfaces plus accessible. Ils accélèrent la matérialisation des idées. Ils permettent à davantage de personnes de donner forme à leurs concepts. Mais plus les solutions deviennent faciles à produire, plus la capacité à comprendre les problèmes devient importante.
La valeur du UX ne réside pas uniquement dans la création d'écrans. Elle réside dans la capacité à créer un pont entre les objectifs d'affaires, les besoins des utilisateurs et les décisions qui façonnent l'expérience.
Les prototypes continueront d'évoluer et les outils deviendront encore plus performants. Ils permettront de matérialiser des idées plus rapidement que jamais. Mais la compréhension du problème, l'alignement des parties prenantes et la validation des besoins demeureront des activités profondément humaines.
Après tout, un prototype peut illustrer une solution. Comprendre pourquoi elle devrait exister est une tout autre histoire.

Autres projets

Back to Top