- La plupart des utilisateurs n’exploitent qu’environ 20 % des fonctionnalités d’une application, et ces 20 % diffèrent d’un utilisateur à l’autre
- Les 80 % restants peuvent être perçus comme des éléments perturbateurs, et même provoquer de l’inconfort ou de la frustration
- En visant précisément un marché de niche, il est possible de bâtir une base d’utilisateurs solide
- Des exemples comme Kagi, Figma et Notion, qui ont bien répondu aux 20 % ignorés par les grands groupes pour créer un marché très fidèle, montrent de nouvelles opportunités de marché
- VS Code, Slack et Discord permettent, grâce à l’extensibilité et à la personnalisation, d’aider les utilisateurs à optimiser eux-mêmes leurs propres 20 %
- L’essentiel n’est pas de créer un produit pour tout le monde, mais un outil qui satisfait en profondeur la partie que chacun veut vraiment, et c’est la voie pour éviter l’obésité fonctionnelle
Expériences d’enfance et manière d’utiliser les logiciels
- Quand il était enfant, l’auteur gérait 2 Go d’espace de stockage en supprimant des fichiers inutiles, et finissait souvent par casser son ordinateur
- Après avoir supprimé des fichiers système importants comme des fichiers
.ini, il devait réinstaller Windows et Office 97 depuis le début
- Son père insistait pour qu’Excel soit absolument installé, mais pour l’auteur, Excel n’était qu’un outil pour coller des tableaux dans Word
- Parmi les innombrables fonctions d’Excel, seule la copie et le collage de tableaux avaient du sens pour lui
- Une de ses connaissances n’a elle aussi utilisé Excel que comme carnet de comptes domestiques, sans toucher aux autres fonctions
Les 20 % sont différents pour chacun
- L’usage des logiciels obéit à une règle des 80/20 : la plupart des utilisateurs n’utilisent que 20 % de l’ensemble des fonctionnalités
- Mais les 20 % sur lesquels chaque utilisateur se concentre varient, et chacun considère que la partie qu’il utilise est la plus importante
- Ex. : on crée des tableaux dans Word mais on n’utilise pas le publipostage ; on utilise les tableaux croisés dynamiques dans Excel mais pas les scripts ; on n’utilise pas les animations dans PowerPoint
- Les mises à jour qui ajoutent de nouvelles fonctions ou modifient l’interface suscitent de la frustration, car l’application semble alors plus lente ou chargée de fonctions inutiles
- Les 80 % de fonctions non utilisées peuvent même être perçus comme des éléments qui entravent le workflow des 20 % réellement utilisés
Le désir d’un résultat parfait
- Ce phénomène ne concerne pas seulement Microsoft, mais aussi les autres entreprises IT
- Par exemple, lorsqu’on veut faire une recherche par mots-clés précise dans Google Search, des résultats élargis à des termes associés peuvent au contraire devenir une source de mécontentement
- Du point de vue d’une entreprise, cela peut sembler relever des « 1 % de besoins utilisateurs », mais 1 % d’un milliard d’utilisateurs, c’est dix millions de personnes
- Kagi s’est attaqué à ce petit marché négligé par Google avec un positionnement différencié : une recherche axée sur la qualité, sans publicité et respectueuse de la vie privée
- En exploitant les angles morts des géants, il devient possible de former un marché de niche qui satisfait un petit groupe d’utilisateurs
- Il n’est pas nécessaire de satisfaire tout le monde : on peut définir une stratégie qui répond parfaitement à l’expérience des 20 % d’un groupe précis
Retrouver les 20 % oubliés
- Beaucoup d’entreprises innovantes ciblent précisément des groupes d’utilisateurs spécifiques que les grands acteurs laissent de côté
- Figma s’est concentré sur le fait de dépasser Adobe sur le design collaboratif, tandis que Notion s’est imposé comme un outil hybride optimisé pour certains besoins utilisateurs
- Les logiciels qui réussissent accumulent souvent des fonctions avec le temps, mais ce processus crée aussi des niches où les 20 % de certains utilisateurs finissent par être enfouis
- Les logiciels open source sont particulièrement forts dans ce domaine, car ils permettent de créer des builds personnalisés adaptés à un workflow précis
- Par exemple, il est possible de développer une version allégée de Blender dédiée uniquement à la visualisation architecturale
Concevoir pour les bons 20 %
- Cette philosophie est bien incarnée par VS Code
- Les fonctions de base se concentrent sur l’édition de texte simple, mais les extensions permettent à chacun de composer son propre environnement de développement
- La structure permet à tous les utilisateurs de personnaliser leurs propres 20 %
- Les integrations de Slack et les bots de Discord reposent sur le même principe : donner aux utilisateurs les moyens d’adapter eux-mêmes leur expérience
- Il est difficile de prévoir dès le départ quels seront les 20 % de chaque utilisateur, mais offrir de l’extensibilité et de la personnalisation permet à chacun d’en tirer le meilleur usage
Conclusion : plutôt qu’un produit pour tous, se concentrer sur les « 20 % nécessaires » de chacun
- À vouloir tout bien faire, on aboutit finalement à un logiciel plus lourd et source de davantage de frustration
- Il est important de se concentrer sur le fait que chaque fonction marche parfaitement pour les utilisateurs qui en ont réellement besoin
- Puisque les utilisateurs ne se serviront de toute façon que d’une partie des fonctions, il est souvent plus efficace de se concentrer sur une fonction spécifique réellement excellente
- Il faut reconnaître qu’un logiciel peut être utilisé d’une manière que l’on n’avait pas prévue, et concevoir le produit en intégrant cette diversité
- Au lieu d’imposer toutes les parties du produit à l’utilisateur, il vaut mieux développer en se concentrant seulement sur les parties qui sont véritablement aimées, ce qui conduit à une satisfaction plus forte
2 commentaires
Ils collent ça systématiquement à la loi de Pareto ;; ça pourrait aussi bien être 15 %, non ? hahaha
Avis Hacker News
Dans une entreprise SaaS où j’ai travaillé, on avait essayé d’analyser le produit en se basant uniquement sur la partie des fonctionnalités que les utilisateurs utilisaient réellement. L’idée était de réduire la complexité du produit pour quelques profils d’utilisateurs clés et de supprimer aussi les fonctionnalités pénibles. Au final, hormis l’écran de connexion, les 20 % jugés importants étaient totalement différents d’une personne à l’autre. Le résultat de l’analyse ne valait guère mieux qu’un échantillonnage aléatoire pondéré
Je m’y retrouve complètement. Mais dès qu’on commence à vendre le produit à des clients enterprise, la situation change du tout au tout. L’absence d’une seule « fonctionnalité d’hygiène » peut faire capoter un deal. Et les fonctionnalités indispensables ne sont pas les mêmes pour chaque client enterprise. Ici, « fonctionnalité d’hygiène » désigne le minimum vital dont tout le monde a besoin, par analogie avec des toilettes
Un article du même genre qui rappelle les billets de blog de Spolsky
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
J’ai créé moi-même une petite appli pour un hobby, et il m’arrive de penser que j’aimerais bien la peaufiner puis la publier. Mais comme je n’ai absolument aucune envie de la promouvoir ou de la faire connaître, je considère qu’il n’y a pas vraiment de sens à la publier. En réalité, la raison principale est que je n’ai aucune envie d’implémenter les 80 % restants de fonctionnalités que, moi, je n’utiliserais pas
En marketing, il existe un concept appelé Pareto modifié. Ce n’est pas du 80/20 mais du 60/20. Les 20 % de heavy users consomment 60 % de la valeur du produit, et les 80 % de light users en consomment 40 %. Ce n’est pas une part assez faible pour être ignorée, donc il faut absolument aussi prêter attention aux utilisateurs occasionnels
value-paretos-bottom-80
C’est ce qui se passe. En réalité, il est bien plus important que les utilisateurs aient la perception que le logiciel peut résoudre leur problème. Si vous voulez qu’ils dépensent de l’argent, le logiciel doit aussi donner l’impression de pouvoir résoudre potentiellement divers problèmes qu’ils pourraient avoir. Ces problèmes variés peuvent justement correspondre à des fonctionnalités qu’ils n’utiliseront jamais eux-mêmes. Par exemple, dans un logiciel 3D, un système de rigging peut n’être utilisé que par 2 % des utilisateurs pendant 1 % du temps ; malgré cela, certaines personnes n’envisageront même pas le produit s’il n’existe pas
Comme je suis mauvais pour prévoir la manière dont mon travail sera réellement utilisé, je préfère de loin n’aménager des chemins que là où des trajectoires visibles apparaissent, ce qu’on compare souvent aux « desire paths »
the-road-most-traveled-by-paving
Je suis d’accord avec l’idée qu’« au lieu d’empêcher l’ajout de fonctionnalités, il faut accepter que le logiciel puisse être utilisé de façons qu’on n’avait jamais imaginées ». C’est pour cela que je considère l’interopérabilité comme l’élément le plus important d’un logiciel. Le problème principal soulevé par le texte me semble être le caractère fermé des formats de fichiers propres à chaque logiciel et à chaque version. Personnellement, ça ne me dérange pas de combiner plusieurs outils, mais le vrai problème, c’est qu’ils coopèrent mal dans un pipeline. Le rêve Unix est vraiment difficile à atteindre
Dans une application d’une certaine taille, il est rare que 100 % des fonctionnalités soient utilisées. D’après mon expérience, presque toutes les applications comportent 10 à 30 % de parties totalement sous-utilisées. En général, c’est soit parce que leur fonctionnement n’est compréhensible que par l’équipe de dev, soit parce que le workflow est mauvais et inefficace, soit parce que la fonctionnalité est tellement basique que les entreprises qui en auraient réellement besoin n’ont tout simplement pas les moyens d’acheter ce logiciel
Oui, mais comme beaucoup d’utilisateurs accordent de l’importance à des 20 % de fonctionnalités différents, il faut tout conserver pour maintenir le nombre actuel d’utilisateurs. Cela dit, supprimer les fonctionnalités très peu utilisées qui consomment énormément de temps en maintenance ou en développement augmente malgré tout le ROI
Mais les utilisateurs n’accordent pas forcément de la valeur aux mêmes 20 %. Et il y a aussi une autre chose à considérer : avant d’avoir réellement utilisé l’application, les utilisateurs ne savent pas très bien quelles fonctionnalités elle possède. La décision d’installation se fonde non pas sur les fonctionnalités réellement présentes, mais sur celles qu’ils s’attendent à y trouver avant l’installation. C’est une différence importante. On peut investir beaucoup d’efforts dans des fonctionnalités, mais en pratique, les résultats n’arrivent qu’après avoir acquis les utilisateurs.
Lorsqu’on crée un MVP, c’est particulièrement important : dans la plupart des cas, ce n’est pas le manque de fonctionnalités qui empêche l’installation et l’usage continu. Le problème, c’est généralement le message, le marketing, ou tout simplement l’absence de valeur suffisamment attrayante pour l’utilisateur. Ajouter des fonctionnalités à la chaîne ne résout pas ces problèmes. Ça paraît simple, mais beaucoup d’entreprises passent à côté.
Le MVP le plus simple consiste d’abord à ne rien implémenter du tout et à essayer d’amener les gens à se préinscrire. Cela permet de vérifier si le message passe correctement. S’ils sont déçus après l’inscription, au moins on sait que le message, lui, fonctionnait.
En revanche, cette approche signifie aussi qu’on lance un MVP qui n’est pas à la hauteur de sa promesse, avec le risque de créer de la déception à cause d’une promesse inachevée. Et beaucoup de fonctionnalités sont en réalité dispensables, surtout dans le SaaS, où nombre d’entre elles ne sont pas suffisamment essentielles pour justifier un paiement. Au lieu de prendre immédiatement les demandes clients pour des exigences incontournables, il faut absolument clarifier s’ils y voient une vraie « valeur », s’ils sont réellement prêts à payer pour cela, et si cela résout un point de douleur vraiment important. Comprendre pourquoi une demande client a été formulée est bien plus important que de construire immédiatement la fonctionnalité