Pourquoi un MVP ne devrait jamais commencer par des écrans
Un écran n'est pas un produit. C'est la conséquence d'une décision produit.
C’est pourtant souvent par là que commencent les projets.
Une idée arrive.
On ouvre Figma, on dessine un écran d’accueil.
Puis un bouton, puis un menu.
Puis un dashboard.
Rapidement, quelque chose apparaît à l’écran. Le projet semble avancer.
Mais une question essentielle n’a toujours pas été posée :
quel problème sommes-nous réellement en train de résoudre ?
Le piège du premier écran
Commencer par les écrans donne une impression de progression.
C’est visuel. C’est concret. On peut montrer le résultat à une équipe, à un client, à un investisseur.
Mais cette première interface repose généralement sur beaucoup de décisions qui n’ont pas encore été réellement validées.
- Qui est l’utilisateur ?
- Que cherche-t-il à accomplir ?
- Dans quel contexte utilise-t-il le produit ?
- Quelle est sa première action ?
- Qu’est-ce qui doit absolument être possible dans le MVP ?
- Qu’est-ce qui peut attendre ?
Et surtout :
qu’est-ce qui doit être appris grâce à ce MVP ?
Si ces questions ne sont pas résolues, dessiner les écrans revient souvent à construire la solution avant d’avoir suffisamment compris le problème.
Un MVP n'est pas une petite version du produit final
C’est probablement l’une des confusions les plus fréquentes.
Un MVP n’est pas nécessairement : « le produit final avec moins de fonctionnalités ».
Un MVP doit surtout permettre de tester une hypothèse produit avec le minimum d’investissement nécessaire, cela change complètement la manière de le concevoir.
Au lieu de demander :
« Quels écrans devons-nous créer ? »
je préfère commencer par :
« Quelle hypothèse voulons-nous vérifier ? »
Puis :
« Quel comportement utilisateur devons-nous observer ? »
Et enfin :
« Quelle est la plus petite expérience permettant de le vérifier ? »
À partir de là seulement, les écrans commencent à avoir une raison d’exister.
Avant l'écran : le parcours
Prenons une application mobile de coaching santé.
On pourrait commencer directement par :
- écran d’accueil ;
- profil ;
- tableau de bord ;
- statistiques ;
- notifications ;
- paramètres.
Cela ressemble déjà à une application.
Mais on ne sait toujours pas comment fonctionne réellement l’expérience.
Prenons le problème autrement.
L’utilisateur veut-il simplement suivre son évolution ?
Ou veut-il :
- comprendre son état ;
- recevoir une recommandation ;
- réaliser une action ;
- mesurer son évolution ;
- être accompagné ;
- rester motivé ?
Ces différences changent complètement le produit.
Le travail de Product Design consiste justement à faire émerger ces questions avant de transformer les réponses en interfaces.
Le wireframe arrive avant le pixel
C’est pour cela que les wireframes sont si importants dans un projet de MVP.
Pas parce qu’ils sont une étape obligatoire du processus UX.
Mais parce qu’ils permettent de travailler sur la structure du produit sans être distrait par son apparence.
À ce stade, une boîte grise suffit.
On peut déplacer un élément, supprimer une étape, réorganiser un parcours.
Tester une hypothèse.
Changer complètement la logique d’un écran.
Et tout cela peut encore se faire très rapidement.
C’est précisément ce que nous avons cherché à faire sur plusieurs projets comme MIL ou AUDYA.
Le design visuel arrive ensuite.
Quand le produit commence à tenir debout.
Le vrai coût d'un MVP mal commencé
La même décision prise après :
- le design UI ;
- le développement frontend ;
- le développement backend ;
- les tests ;
- l’intégration ;
Le Product Designer ne dessine pas seulement des interfaces
C’est probablement là que se situe la différence entre UI Design et Product Design.
Le UI Designer travaille principalement sur la manière dont une interface se présente et fonctionne visuellement.
Le Product Designer intervient plus largement sur le produit :
problème → utilisateurs → objectifs → parcours → fonctionnalités → structure → interface → validation.
Les écrans deviennent alors une conséquence du travail de conception.
Et non son point de départ.
Alors, par quoi commencer ?
Avant de dessiner le premier écran d’un MVP, je poserais au minimum ces questions :
1. Quel problème cherchons-nous à résoudre ?
Pas une fonctionnalité.
Pas une technologie.
Un problème utilisateur.
2. Pour qui ?
Un MVP destiné à « tout le monde » n’a généralement pas beaucoup de chances de produire un apprentissage précis.
3. Quelle hypothèse voulons-nous tester ?
C’est elle qui doit guider le périmètre du MVP.
4. Quel parcours doit absolument fonctionner ?
Pas dix parcours.
Le parcours essentiel.
5. Qu’est-ce qui peut attendre ?
Un MVP est aussi un exercice de renoncement.
Chaque fonctionnalité supplémentaire augmente le coût et dilue potentiellement l’apprentissage.
6. Comment saurons-nous que le MVP fonctionne ?
Sans critère d’apprentissage ou de validation, on risque simplement de construire une petite version d’un produit dont on ne sait toujours pas s’il répond au bon problème.
Le premier écran devrait être la dernière conséquence
Un bon MVP ne commence donc pas par :
« Dessinons l’écran d’accueil. »
Il commence plutôt par :
« Comprenons ce que nous devons apprendre. »
Puis viennent les utilisateurs.
Les parcours.
Les hypothèses.
Les fonctionnalités essentielles.
Les wireframes.
Les prototypes.
Et enfin les écrans.
Ce n’est pas plus lent.
C’est simplement une autre manière de construire.
Une manière où chaque écran a une raison d’exister.
Le rôle du Product Design, ce n’est pas de dessiner plus vite, c’est de comprendre la globalité du projet avant de construire.
Découvrez ma méthodologie de conception
Découvrez d'autres insights
