Music for the masses

Mes lectures matinale m’ont ramené vers des sujets qui me sont chères, et que j’avais un peu délaissées depuis un an : la conception de services ou d protocoles, et les leviers d’adoption, notamment dans les domaines innovants.

Courbe d'adoption de l'innovation de Rogers

La courbe de Rogers montre que – si on n’a pas fait d’erreurs – l’adoption passe par les innovateurs, early adopters, la majorité proactive, la majorité réactive, les retardataires.

Une erreur très fréquente dans la mise en place d’un service ou d’un protocole est la conception pour une adoption de masse que le site de l’Indie Web Camp considère même comme un anti pattern, c’est à dire une fausse bonne idée conduisant à l’opposé du résultat espéré : expérience utilisateur déplorable et mise en place de silos technologiques.

Au contraire, l’innovation doit d’abord être tournée vers ses propres besoin dans une saine expérience de self dogfooding, avant d’évoluer en fonction de la demande de ceux qui l’adoptent.

The methodology of attempting to design directly for “mass adoption” is an antipattern and will likely be an obstacle to actually designing something useful, especially for yourself (vis-a-vis self-dogfooding).

Concevoir un service en vue d’une adoption de masse relève de l’illusion qu’il est possible de créer rapidement et immédiatement quelque chose et d’en faire un quasi standard en très peu de temps.

On se heurte en fait à trois obstacles inévitables :

  1. Ce mode de conception se base sur de pures hypothèses selon lesquelles la majorité des gens a besoin de telle ou telle chose, sans partir de données réelles ou de cas d’usages. Et non, une étude de marché n’est pas un ensemble de données réelles, c’est au mieux une manière de se rassurer quant au fait que l’on prenne bien ses désirs pour des réalités.
  2. Il entraine fatalement un tunnel de réalisation sans qu’il soit possible de valider ses assomptions en route afin de pivoter en cas d’erreur. Il est incompatible avec les méthodes agiles, itératives, qui permettent de changer de cap en quelques jours ou tout au plus quelques semaines.
  3. Le passage à l’implémentation se heurte forcément à des digressions dues à la rencontre de personnes normales (sic), qui expriment des souhaits particuliers considérés à tort comme l’avis général

C’est un piège dans lequel nous sommes tombés il y a deux ans avec Publify. En observant ce que faisait la concurrence en termes d’outils de publication Web, nous avons ajouté des fonctionnalités – à priori – voulues par le plus grand nombre. Le résultat a été doublement catastrophique :

  1. Nous avons ajouté des fonctionnalités qu’aucun d’entre nous n’utilise. Elles ont donc été mal pensées, mal codées (donc buggées), et mal maintenues, personne ne s’assurant de leur réel fonctionnement et de leur intégration dans le produit. L’expérience utilisateur s’en est dégradée d’autant.
  2. Nous avons ajouté des fonctionnalités que personne n’a jamais utilisé, parce qu’elles venaient d’assomptions non vérifiés, et non de demandes précises de nos utilisateurs.

La conséquence directe de tout ça, et je pense que nous ne sommes pas les seuls, c’est la perte d’utilisateurs fidèles et actifs, ainsi qu’une certaine forme de désaffection de notre part.

La solution pour éviter ce piège dans lequel tombent de nombreux produits et de nombreux projets open source passe par un sain self dogfooding, des évolutions en fonction de l’évolution des utilisateurs (early adopters etc…), dans un cycle itératif qui permet de modifier les éléments proposées en fonction des retours au lieu d’apporter des solutions génériques et forcément complexes à des problèmes qui n’existent que dans votre imagination.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: