Qui peut le plus peut le moins. Les logiciels professionnels dits “de bureau” ont pour la plupart été conçus dans cette perspective : beaucoup de fonctionnalités dans le but de couvrir tous les besoins de l’utilisateur, y compris les mineurs, y compris les plus rares. Le tout servi par une interface grise à onglets ou à multiples menus de navigation. Généralement servi froid avec son guide d’utilisation.
Ce réflexe est encore présent. Pourquoi ?
Parce que la simplicité d’usage n’est pas toujours bien vécue. Faire simple, c’est accepter de faire moins, de reléguer, voir même de supprimer. « Que diront nos clients si nous retirons des fonctionnalités ? Ils auront l’impression que le logiciel est moins complet ! »
N’ayez pas peur. En écartant le superflu au profit des fonctionnalités essentielles, le contenu devient plus simple à organiser, l’application plus simple à utiliser. Un choix trop important augmente le temps de prise de décision et par conséquence le temps d’apprentissage. Ce rapport entre le nombre de choix et le comportement de l’utilisateur a été scientifiquement établi (Loi de Hick). À partir du moment où l’on se place du point de vue de l’utilisateur, les réponses sont évidentes : notre préférence va toujours vers le plus simple, le plus efficace ou le plus rapide.
Mais la tentation ne vient pas toujours de l’intérieur, elle prend aussi la forme d’une lame récurrente de demandes clients. C’est là une autre difficulté : être capable de faire évoluer l’application tout en préservant sa simplicité d’utilisation. Jason Fried et David Heinemeier Hansson, les deux fondateurs de 37 Signals, éditeur de l’application de gestion de projet Basecamp, ont exploré le sujet en profondeur dans leur ouvrage Getting Real (gratuit). Au risque de paraître péremptoire, leur position est de ne pas intégrer les demandes d’ajout de fonctionnalités remontées par leurs clients afin de maintenir une vision claire et cohérente de leur produit.
« C’est la raison pour laquelle vous commencez par dire non. Chaque nouvelle demande de fonctionnalité qui nous parvient - ou qui vient de chez nous - est rejetée. Nous écoutons mais nous ne la prenons pas en compte. Notre première réponse est « pas maintenant ». Si une demande revient régulièrement, c’est à partir de ce moment là que nous commençons à nous y intéresser. Ensuite, et seulement ensuite, nous nous penchons dessus sérieusement. Et que répondre aux personnes qui se plaignent lorsque vous ne donnez pas suite à leur proposition de fonctionnalité ? Rappelez-leur la raison principale pour laquelle ils aiment cette application. «Vous l’aimez parce que nous disons non. Vous l’aimez parce qu’elle ne fait pas une centaine de choses à la fois. Vous l’aimez parce qu’elle n’essaie pas de satisfaire tout le monde tout le temps. »
Jason Fried - Traduit librement de Getting Real