Savoir dire non à une fonctionnalité
Remonter au problème, rendre le coût visible, tester petit : pourquoi ralentir fait partie du travail de product designer.
Ajouter une fonctionnalité est facile. La retirer plus tard est presque impossible. Une partie importante de mon travail de product designer consiste donc à ralentir, et parfois à dire non.
Revenir au problème
Une demande arrive souvent sous forme de solution : « il faudrait un filtre », « il faudrait un export ». Je remonte toujours au problème qu’elle cherche à résoudre. Souvent, une solution plus simple existe.
Le coût caché
Chaque fonctionnalité ajoute des écrans, des états, des cas d’erreur, de la documentation et de la maintenance. Je les liste avant de décider, pour que le coût soit visible.
Ce que coûte vraiment une nouvelle option
- Un réglage de plus à comprendre pour tout le monde
- Des états supplémentaires à concevoir et à tester
- Des combinaisons qui se multiplient avec les options existantes
- Une maintenance qui dure aussi longtemps que le produit
Tester petit
Plutôt que de construire la version complète, je propose une version minimale, ou même un simple lien vers un formulaire. Si personne ne l’utilise, on a économisé des semaines.
Garder une liste
Les idées refusées ne disparaissent pas : elles vont dans une liste partagée. Quand une même demande revient plusieurs fois, c’est un signal qu’elle mérite d’être reconsidérée.
Un bon produit se juge aussi à tout ce qu’il a eu le courage de ne pas faire.
Antoine PineyDirecteur artistique & développeur créatifEn résumé
- Remonter de la solution demandée au problème réel.
- Rendre visible le coût d’une fonctionnalité.
- Tester avec la version la plus petite possible.
- Garder une trace des idées refusées.
