Product thinking : pourquoi l’intégrer dans la conception UX

Le product thinking (ou « pensée produit ») est une façon de concevoir qui part du problème réel de l’utilisateur et de l’objectif de l’entreprise, avant de parler fonctionnalités ou écrans. Intégré à la conception UX, il oblige à se demander pourquoi le produit existe, pour qui, et comment on saura qu’il fonctionne. C’est le meilleur garde-fou contre une interface soignée qui ne sert à personne.

Vous trouverez ci-dessous une définition claire, la différence avec le design thinking, l’exemple célèbre du milkshake raconté sans les approximations habituelles, une méthode en cinq questions, les techniques pour comprendre vos utilisateurs et les erreurs qui font échouer la démarche.

Qu’est-ce que le product thinking ?

Le product thinking consiste à considérer un produit numérique (application, site, logiciel) comme une réponse à un problème précis, et non comme une liste de fonctionnalités. Avant de dessiner quoi que ce soit, on répond à trois questions : quel problème résout-on, pour qui, et quel résultat attend l’entreprise ? Les fonctionnalités ne viennent qu’ensuite, comme des moyens au service de ces réponses.

Pour l’UX, c’est un changement de focale. L’expérience utilisateur ne se limite pas à la facilité d’utilisation d’un écran : elle recouvre ce que ressent une personne en utilisant un produit, un service ou une entreprise. Un parcours fluide qui mène à une fonction dont personne n’a besoin reste un échec. Le product thinking ramène le designer à la raison d’être du produit : si la tâche n’existe pas, ou si la solution ne lui correspond pas, le produit perd son sens et les gens ne l’utilisent pas.

Ces approches se complètent. Le product thinking n’est pas un métier à part : c’est un réflexe que designers, développeurs et décideurs gagnent à partager.

Pourquoi intégrer le product thinking dans la conception UX ?

• Il évite de construire l’inutile. Chaque fonctionnalité coûte à concevoir, développer, tester et maintenir. Partir du problème permet de couper tôt ce qui n’y répond pas.
• Il remet en question les solutions toutes faites. Les bibliothèques de composants et les modèles d’interface font gagner un temps précieux, mais ils poussent parfois à appliquer une solution standard sans se demander si elle convient. Sans connaître les raisons d’une convention, on ne mesure pas les conséquences de s’en écarter, ni celles de la suivre aveuglément.
• Il aligne le design sur les objectifs de l’entreprise. Un bon designer sait défendre ses choix devant des personnes éloignées du design, et accepte d’abandonner une idée séduisante quand elle ne sert pas l’objectif.
• Il installe l’amélioration continue. On ne cherche pas le résultat parfait du premier coup : on décide sur la base des retours des utilisateurs et des données, puis on ajuste.

Le risque inverse porte un nom : l’entreprise qui pense que le monde tourne autour de son produit. Nous l’avons développé dans l’article le monde ne tourne pas autour de votre produit.

Que nous apprend l’exemple du milkshake ?

C’est l’exemple le plus cité pour illustrer la démarche. Il vient des travaux de Clayton Christensen, professeur à Harvard, sur la théorie des « jobs to be done » (les tâches pour lesquelles un client « engage » un produit). On le lit souvent attribué à McDonald’s, mais la version publiée par le Christensen Institute parle seulement d’une chaîne de restauration rapide, sans la nommer.

L’enseigne voulait vendre plus de milkshakes. L’approche classique consiste à améliorer le produit lui-même : plus de parfums, une recette plus sucrée, un format plus grand, des enquêtes pour trouver le goût idéal. L’équipe a changé de question : pour quelle tâche les clients achètent-ils ce milkshake ?

Réponse : le matin, les clients l’achetaient pour tenir jusqu’au déjeuner, rendre leur trajet en voiture moins monotone et avoir quelque chose de facile à tenir d’une main. L’après-midi, le même milkshake servait plutôt de petite récompense pour les enfants. Le vrai concurrent du milkshake du matin n’était donc pas le milkshake d’une autre enseigne, mais la banane ou le bagel.

La leçon pour un produit numérique : tant que vous comparez vos fonctionnalités à celles des concurrents, vous améliorez peut-être la mauvaise chose. Quand vous comprenez la tâche réelle et son contexte (seul en voiture le matin, avec les enfants l’après-midi), les bonnes décisions de conception deviennent évidentes, et elles diffèrent selon le moment d’usage.

Comment appliquer le product thinking, étape par étape ?

Un cadre simple tient en cinq questions, à écrire noir sur blanc avant de lancer la conception :

1. Quel problème ? Le besoin ou la difficulté de l’utilisateur, formulé sans parler de solution. « Les clients ne savent pas si leur commande est partie » plutôt que « il faut une page de suivi ».
2. Pour qui ? Le public cible précis, avec son contexte d’usage : appareil, moment, niveau d’aisance numérique.
3. Quel objectif pour l’entreprise ? Moins d’appels au service client, plus de commandes récurrentes, un délai de traitement réduit.
4. Quelle stratégie ? Les pistes de solution et leur ordre de priorité, en commençant par la plus petite version utile.
5. Comment mesurer ? Les indicateurs qui diront si le problème est résolu, et la durée d’observation nécessaire (par exemple la durée d’un test A/B).

Pour y répondre, la démarche alterne recherche et expérimentation : formuler des hypothèses, mener des entretiens avec des clients, identifier leurs irritants, étudier le marché, puis tester les hypothèses avec des prototypes, des tests A/B ou multivariés. La première version livrée est souvent un produit minimum viable, conçu pour apprendre vite.

Beaucoup d’équipes s’appuient sur le modèle du double diamant, formalisé par le Design Council britannique au milieu des années 2000. Il enchaîne quatre phases : Discover (explorer le problème sans a priori), Define (le cadrer), Develop (imaginer et co-concevoir plusieurs solutions) et Deliver (les tester à petite échelle, écarter celles qui ne marchent pas, améliorer les autres). Le premier diamant porte sur le problème, le second sur la solution, et chaque phase peut être répétée tant que les conclusions ne sont pas solides.

Comment comprendre les besoins des utilisateurs ?

Pour qu’un produit trouve son public, il faut apprendre de ses utilisateurs. Les méthodes les plus utiles, de la plus qualitative à la plus quantitative :

• Entretiens approfondis : parler directement avec des clients pour comprendre ce qu’ils achètent ou non, et pourquoi.
• Questionnaires : quand un client donne une mauvaise note, revenir vers lui pour savoir précisément ce qui l’a déçu.
• Retours du support et des commerciaux : ce sont eux qui entendent les difficultés au quotidien ; leurs remontées sont une mine.
• Analyse des recherches : ce que les utilisateurs tapent dans le moteur de recherche interne du site ou dans Google révèle leur vocabulaire et leurs attentes.
• Analyse des comportements : parcours, taux d’abandon, cartes de chaleur, enregistrements de sessions pour voir où les gens bloquent.
• Communautés et avis : forums, groupes, avis publics, où les utilisateurs décrivent leurs problèmes avec leurs propres mots.
• Tests A/B : comparer deux versions pour trancher avec des données plutôt qu’avec des opinions.
• Étude des concurrents : comprendre ce qu’ils proposent et, surtout, ce que leurs clients leur reprochent.
• Utiliser son propre produit : se mettre dans la peau de l’utilisateur permet de repérer des défauts avant lui.

Quelles compétences faut-il développer ?

Le product thinking se situe au croisement de plusieurs disciplines. Un designer UX qui l’adopte, ou un chef de projet côté client, gagne à progresser dans cinq domaines :

1. Entreprise : comprendre le marché, le modèle économique et la mission de l’entreprise.
2. Produit : prioriser, connaître les contraintes du marché, étudier les consommateurs, animer une équipe.
3. Design : faire preuve d’empathie, concevoir centré sur l’utilisateur, connaître l’architecture de l’information.
4. Technologie : suivre les évolutions techniques et savoir trouver le bon compromis entre ambition du design et coût de réalisation.
5. Communication : raconter un problème de façon claire, présenter une décision, et surtout écouter.

À l’origine, les projets numériques étaient longs, ralentis par la coordination entre spécialistes. La pression concurrentielle a ensuite imposé de sortir des produits plus vite sans sacrifier la qualité, d’où la valeur des profils capables de relier ces domaines. Le product thinking est la méthode qui permet à une équipe entière, et pas seulement à un profil rare, de raisonner ainsi.

Quelles erreurs éviter ?

• Commencer par la liste des fonctionnalités : c’est le réflexe du cahier des charges classique, qui fige des solutions avant d’avoir compris le problème.
• Remplacer les vrais besoins par des besoins « standards » : supposer que vos utilisateurs veulent ce que veulent ceux des autres, sans l’avoir vérifié.
• Confondre ce que disent les utilisateurs et ce qu’ils font : un entretien donne des pistes, les données d’usage les confirment ou non.
• Oublier l’objectif de l’entreprise : un produit que les utilisateurs adorent mais qui ne génère aucune valeur pour l’entreprise ne durera pas.
• Ne rien mesurer : sans indicateur défini au départ, impossible de savoir si une nouveauté a résolu quoi que ce soit.
• Chercher la version parfaite : une solution belle mais inutile coûte plus cher qu’une solution simple publiée tôt puis améliorée.

Vous préparez une application ou un outil métier et voulez cadrer le problème avant d’écrire le cahier des charges ? C’est la première étape de nos projets d’applications web sur mesure, et de notre accompagnement en stratégie digitale. Écrivez-nous à contact@osmova.com ou via le formulaire de contact.

Questions fréquentes

Quelle différence entre product thinking et design thinking ?

Le design thinking est une méthode pour explorer et tester des solutions centrées sur l’humain. Le product thinking est un état d’esprit plus large, qui relie ces solutions au problème à résoudre, aux objectifs de l’entreprise et aux indicateurs de réussite. Les deux s’utilisent ensemble.

Le product thinking est-il réservé aux start-up ?

Non. Une PME qui refond son site, un artisan qui lance une prise de rendez-vous en ligne ou un service interne qui commande un outil métier ont tous intérêt à cadrer le problème avant les fonctionnalités.

Qu’est-ce que la théorie des jobs to be done ?

C’est l’idée, popularisée par Clayton Christensen, que les clients « engagent » un produit pour accomplir une tâche dans un contexte donné. Comprendre cette tâche éclaire mieux les décisions que les données démographiques ou la comparaison de fonctionnalités.

Qui porte le product thinking dans une équipe ?

Souvent le chef de produit ou le responsable du projet, mais la démarche fonctionne mieux quand designers, développeurs et décideurs la partagent. Chacun peut poser la question « quel problème cela résout-il ? ».

Par quoi commencer concrètement ?

Rédigez les cinq réponses (problème, public, objectif, stratégie, mesure) sur une page, puis menez quelques entretiens avec de vrais utilisateurs pour les confronter à la réalité avant toute maquette.

Sources

• Christensen Institute : Jobs to Be Done (exemple des milkshakes du matin)
• Design Council : The Double Diamond