J'adore travailler avec des entrepreneurs qui fourmillent d'idées.
C'est toujours très stimulant de créer de nouveaux trucs, d'explorer de nouveaux usages. Coder, c'est passer de l'idée à l'action : on voit les projets se concrétiser.
A un moment, on atteint une sorte de palier dans le projet. Le produit est suffisamment complet pour une version 1. Les premiers utilisateurs ont perçu la valeur qu'ils pouvaient en retirer, sans investir trop de temps à apprendre comment l'utiliser.
Sans trop de fonctions, ça reste intuitif.
Surgit alors la question de la version 2. Celle qui sera mieux. Qui comblera les manques de la v1.
Et ça me rappelle un article de Paul Jarvis.
Qui est Paul Jarvis ?
C'est l'auteur du livre "Company of One: Why Staying Small Is the Next Big Thing for Business".
Assez connu chez les freelances, il décrit un modèle d'entreprise qui n'est pas guidée par l'objectif de croissance des effectifs, mais vers l'efficacité , l'agilité, et le bien-être conjoint de l'entrepreneur et de ses clients.
Il est le cofondateur de Fathom, un logiciel SaaS de mesure d'audience auquel je m'intéresse car c'est un peu la même idée que Fairlytics.
Son produit marche bien, tout en restant dans la modeste épure d'un truc codé par 2 amis sans lever de fonds.
Face à l'intention de doter le produit d'une nouvelle fonctionnalité, il décrit un blocage survenu un dimanche matin :
Mais le problème était que j'avais l'impression que c'était trop. Trop de composants sur l'interface. Trop de clics nécessaires pour l'utiliser. Trop de temps pour répondre aux questions des utilisateurs et pour leur expliquer comment utiliser correctement la nouvelle fonctionnalité.
Pourtant, le principe d'un projet IT consiste à itérer : on écoute le retour des utilisateurs, on priorise les améliorations qui leur apportent le plus de valeur, on code, on livre, et on recommence.
En ajoutant de nouvelles fonctionnalités, on se démarque des produits concurrents, et on fidélise ses utilisateurs. On avance.
Mais en ajoutant de nouvelles fonctionnalités, on rend le produit compliqué à utiliser, alors que c'était son atout au départ. Cette évolution lente est difficile à percevoir. Parce qu'on "baigne" dans le produit toute la journée.
Il est facile de manquer de recul, et de percevoir combien coûte la simplicité perdue.
Exemple : les outils d'envoi d'email
Avant j'utilisais MailChimp pour envoyer des emails. J'ai arrêté pour parce que je ne comprenais plus rien.
Au départ, MailChimp ne faisait qu'une seule chose : envoyer des emails à une liste d'abonnés. Maintenant il permet de créer un site Internet, une landing page, des publicités ciblées, des processus d'automatisation complexes, et plus encore...
Beaucoup de logiciels suivent cette trajectoire. La version 1 était simple. Elle a su conquérir son audience, et résolvant un problème principal.
Puis les utilisateurs réclament des fonctionnalités supplémentaires (et sont prêts à les payer). Et on ne demande pas mieux que de répondre positivement et de coder frénétiquement, pour entretenir la satisfaction d'entendre que "c'est vraiment cool de pouvoir faire ça dans cette nouvelle version".
De nouveaux écrans. De nouvelles données. Plus de clics. Plus d'options. Davantage de charge cognitive pour l'utilisateur. Davantage de bugs.
Mais à quel moment faut-il arrêter ?
A quel moment la complexité induite par la nouveauté se fait-elle au détriment de l'accessibilité ?
Soustraire plutôt qu'ajouter
A votre avis, avec quel vélo apprend-on le plus vite à faire du vélo ?
Et quel est le plus "moderne" des deux ?
C'est celui de droite. Il permet à l'enfant de trouver plus rapidement son équilibre.
C'est fou comme notre cerveau est conditionné pour ajouter des trucs en plus lorsqu'on souhaite résoudre un problème.
Comme il est plus simple d'acheter un truc nouveau plutôt que de faire du ménage dans notre bazar.
Lire un livre en plus, et écouter un podcast supplémentaire pour réfléchir.
Comme on tend naturellement à ajouter du code et des données à nos logiciels.
A ajouter des stabilisateurs plutôt que d'enlever les pédales.
A construire des plans d'actions qui alourdissent encore davantage nos processus.
La soustraction est une démarche intellectuelle plus difficile que l'addition. Il ne s'agit pas de faire moins, mais de trouver une façon de faire mieux avec moins.
Coder sobrement
Un code qui prend de l'ampleur devient un monstre de complexité. On sent à un moment qu'il faut faire le ménage, enlever des lignes, supprimer des dépendances.
Parce que les choix d'architecture du début (au plus simple, en tirant profit à fond des fonctionnalités prêtes à l'emploi du framework) ne sont plus adaptés à un projet qui grossit.
Mais peut-être faut-il aussi garder le contrôle pour éviter l'obésité fonctionnelle. Par exemple avec une règle simple : quand on ajoute une nouvelle fonctionnalité, alors on en retire une autre.
Ça force à être imaginatif. Astucieux. Mais aussi à prendre soin de ses utilisateurs en leur évitant de présenter mille options de configurations réparties dans dix menus.
Ça force à prendre position. A ne retenir qu'une seule façon de faire (la bonne), bien réfléchie, plutôt que d'inonder de possibilités ("on verra bien celle qui plaît"). Inutile de délèguer aux utilisateurs les questions auxquelles on ne sait pas répondre nous-mêmes.
La soustraction est un gisement d'innovation :
- le téléphone SANS clavier → iPhone
- la cigarette SANS tabac → cigarette électronique
- la voiture SANS volant → la tesla autonome
Enlever un élément qui semble "clé" dans l'interface utilisateur force à imaginer une solution technique pour le compenser.
A répondre à plusieurs problèmes simultanément avec une même solution.
A coder avec le moins de lignes possibles.
