La simplicité n'est pas un point de départ
Un produit simple n'est jamais un produit qui a fait peu. C'est un produit qui a beaucoup retiré.
La simplicité est l'une de nos cinq valeurs, et probablement la plus mal comprise — y compris par ceux qui la revendiquent.
Elle est presque toujours entendue comme une contrainte initiale : faire peu, rester minimal, ne pas surcharger. Or un produit qui fait peu n'est pas simple. Il est incomplet. La différence est visible immédiatement à l'usage : un produit incomplet oblige l'utilisateur à faire le travail ailleurs.
La vraie simplicité est un résultat. Elle arrive à la fin, après un travail de réduction.
Le déplacement de la complexité
Tout problème réel a une complexité irréductible. La conformité fiscale est complexe. La gestion documentaire d'une organisation de deux cents personnes est complexe. Aucun produit ne fera disparaître cette complexité.
La seule question qui se pose est : qui la porte ?
Un produit mal conçu la renvoie à l'utilisateur — sous forme de paramétrage, de choix qu'il n'a pas les moyens de faire, d'étapes qu'il doit enchaîner lui-même, ou de règles qu'il doit connaître pour ne pas se tromper.
Un produit bien conçu l'absorbe. Il prend les décisions par défaut qui sont bonnes dans 90 % des cas, il rend les 10 % restants accessibles sans les imposer, et il ne demande jamais à l'utilisateur une information qu'il pourrait déduire.
Cette absorption est du travail. Beaucoup de travail. C'est précisément le travail qu'un produit « simple » a fait et qu'un produit minimal n'a pas fait.
Pourquoi c'est difficile
Retirer est plus dur qu'ajouter, pour trois raisons.
Ajouter est mesurable, retirer ne l'est pas. Une fonctionnalité livrée se démontre. Une fonctionnalité évitée ne laisse aucune trace, et personne ne remercie pour ce qui n'existe pas.
Chaque ajout a son défenseur. Une fonctionnalité correspond toujours à une demande réelle de quelqu'un. Retirer signifie décevoir une personne identifiable au profit d'utilisateurs anonymes.
La complexité s'installe par petites doses. Aucune décision n'est individuellement déraisonnable. C'est leur accumulation qui rend le produit illisible, et à ce stade, aucune décision particulière ne peut être désignée comme responsable.
Ce que nous faisons concrètement
Nous fixons le périmètre par ce qu'il exclut. Un document de cadrage contient une liste explicite de ce que le produit ne fera pas. Cette liste est aussi importante que l'autre, et plus difficile à écrire.
Nous demandons quel usage disparaît. Avant chaque ajout : quel comportement existant est modifié, et pour combien d'utilisateurs ? Un ajout qui complexifie l'écran principal pour servir un cas marginal est presque toujours refusé.
Nous repassons après. Une fois un produit fonctionnel, nous revenons sur les décisions prises. Certaines options existent uniquement parce que nous n'avions pas tranché au bon moment. Elles peuvent être supprimées.
Nous acceptons de dire non par défaut. Le coût d'une fonctionnalité n'est pas son développement. C'est sa maintenance, sa documentation, son interaction avec toutes les autres, et l'espace qu'elle occupe dans l'esprit de l'utilisateur.
Le test
Il existe un test simple pour savoir si un produit est vraiment simple : regarder quelqu'un l'utiliser pour la première fois, sans rien dire.
S'il hésite, ce n'est pas lui qui manque de formation. C'est le produit qui lui a transféré une décision qu'il aurait dû prendre à sa place.
Catégorie BUILD · Temps de lecture 7 minutes