Si vous ne savez pas quoi faire de cette fonctionnalité, proposez la en option...

Depuis des années, j’ai entendu un nombre incroyable de fois en réunion de conception ça… je ne sais pas… t’as qu’à le mettre en option, on ne sait jamais. Soyons clairs tout de suite, c’est une connerie monumentale, et ça n’améliorera en rien l’expérience utilisateur de votre site ou de votre application web, au contraire.

La réflexion ici est pernicieuse. Vous discutez avec votre client d’une fonctionnalité, mais vous demandez s’il est vraiment pertinent de l’inclure dans votre application, car elle ne semble pas indispensable. Côté client, pour peu que le budget suive, cette fonctionnalité lui permettra de se démarquer, ou au moins se mettre à niveau de ses concurrents. Il va donc vouloir l’intégrer. Comme elle n’a pas directement sa place dans l’application, il va proposer de la rendre optionnelle, et ceux qui souhaitent l’utiliser pourront l’activer.

Au risque de me répéter, c’est une connerie, que j’aimerais bien ne plus entendre, que ce soit de la part des clients, ou pire, des commerciaux qui chercheront à étendre les temps de développement. Si vous ne souhaitez pas la proposer par défaut, alors cette fonctionnalité n’a rien à faire sur votre application. À moins évidemment de vouloir mettre en place une usine à gaz que personne ou presque ne sera capable d’utiliser sans une formation de trois semaines.

Il existe évidemment des cas où proposer une fonctionnalité de manière optionnelle peut avoir du sens, bien que cela soit, encore une fois, discutable. Un très bon exemple est celui de l’éditeur de Wordpress, proposé sous forme WYSIWYG ou HTML simple. Wordpress s’adresse en effet à une frange extrêmement large d’utilisateurs, du novice au technophile averti, il semble donc normal d’offrir une alternative à l’éditeur visuel. Et pourtant… avec ses boutons d’ouverture / fermeture des balises, l’éditeur simple de Wordpress pourrait suffire aux deux populations, via un léger temps d’apprentissage, mais ce n’est pas mon propos. Le choix de l’éditeur simple était autrefois une option à cocher dans son profil. C’est aujourd’hui devenu une alternative dans la zone de saisie. Le simple fait d’avoir déplacé ce choix a grandement amélioré l’expérience utilisateur en édition, en rendant évident et pratique une fonctionnalité autrefois enterrée dans les options de configuration.

Vouloir rendre des fonctionnalités optionnelles au lieu de se poser la question de leur pertinence réelle est un réflexe courant, souvent du à un excès de bonne volonté : proposer une application s’adressant à la population la plus large possible, au risque d’en faire trop. Ce travers existe également en programmation : concevoir une usine à gaz afin de gérer tous les futurs cas possibles, et parce que l’on veut faire quelque chose de super générique.

En guise de conclusion, cinq petites recommandations pleines de bon sens :

1. Si ce n’est pas indispensable, c’est inutile.
2. Si vous avez plusieurs manières de le faire, c’est qu’il y en a au moins une de trop.
3. Proposer une alternative peut avoir du sens.
4. Les points 2 et 3 ne sont pas entièrement incompatibles ;-)
5. Votre client a toujours raison… jusqu’au jour où de vrais gens commencent à utiliser son application.

Si cet article vous a plu, n'hésitez pas à me suivre sur Twitter.

2 commentaires sur Si vous ne savez pas quoi faire de cette fonctionnalité, proposez la en option... »

1. 

   Par Armetiz le 15 septembre 2009 à 10h02 :

   
   

   Le client a toujours raison… jusqu’au jour où il viendra vous voir en vous reprochant de ne pas l’avoir suffisamment averti de l’aspect ergonomique.

   Mais comme il a toujours raison, il a déjà signer le cahier des charges et tant pis pour lui.

2. 

   Par Cyroul le 15 septembre 2009 à 19h30 :

   
   

   J’aime bien la philosophie, mais je pense qu’elle est définitivement trop catégorique.

   La complexité peut avoir de l’utilité : 1- utilité fonctionnelle : Il peut être utile d’avoir une page “options de configuration pro” vs “la page options simplifiée”. Ou encore une faq de base inclue dans ton appli et une faq détaillée style wiki/forum en ligne. Deux usages pour deux publics différents. Et ce n’est pas anti-ergo. 2- cosmétisatisation marketing : je ne vais pas faire un cours sur le marketing de la complexité mais pourtant certains vont juger une appli (ou un service) par sa complexité apparente. N’oublie pas que le design d’IHM des années 90 n’est pas loin. Certaines personnes n’auraient jamais parié un centime sur Google à l’époque jugé. “trop simple”. Certes, à l’usage, c’était ce qu’il fallait (et quand on est un peu ergo, on le sait) seulement quand tu veux vendre un service/application à un financier, il veut voir “des choses”. Lui n’est pas ergonome, mais si tu peux pas changer le fond de couleur de ton appli, il ne te financera peut-être pas. Dans ce cas, tu loupes ton objectif.

   Donc, je pense qu’il ne faut pas être si catégorique. La complexité (si tant est, qu’elle est utile), peut servir. L’exemple typique est le jeu vidéo : les plus réussis nécessite une prise en main rapide, mais aussi un approfondissement fonctionnel possible. Si tu loupes un des deux, tu as perdu.

Trackbacks sur Si vous ne savez pas quoi faire de cette fonctionnalité, proposez la en option...

Les trackbacks sont fermés pour cause de spam.