Il y a presque 2 ans, j’avais écrit un article intitulé simplement Faire des choix. Mon propos était alors de dire que lorsqu’on crée un service ou un produit, il faut faire en sorte que l’ergonomie (ou l’affichage, ou les fonctionnalités, …) proposée par défaut soit adaptée au plus grand nombre d’utilisateur.
Plutôt que de noyer l’utilisateur sous des options qui l’obligeront à choisir la manière dont il souhaite manipuler l’outil, il est préférable d’analyser les choses finement pour proposer quelque chose d’exploitable immédiatement et sans effort.
Il y avait eu un certain nombre de commentaires intéressants à l’époque, dont quelques-uns qui remettaient en question cette vision des choses. De manière assez amusante, je sais que certains de ces commentateurs sont par ailleurs dithyrambiques sur la manière dont Apple mène ses designs, justement en restreignant les options et en s’attachant à proposer les meilleurs choix par défaut…
Bref, je viens de tomber sur un lien très intéressant :
http://www.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/
L’histoire est édifiante. Afin de savoir si les utilisateurs modifient les options de leurs logiciels, ils ont demandé à des utilisateurs de Word d’envoyer le fichier de configuration présent sur leur machine. Plusieurs centaines ont répondu.
Résultat : 95% des utilisateurs utilisaient les réglages par défaut.
On pourrait penser que cela ne fait que montrer à quel point Microsoft avait bien fait son travail, et avait réussi à proposer un outil qui soit parfaitement fonctionnel pour le plus grand nombre. Et pourtant c’est complètement l’inverse !
À cette époque, l’auto-enregistrement était désactivé par défaut. Si votre ordinateur plantait, vous perdiez tout votre travail, à moins que vous n’ayez activé cette option. Cette fonctionnalité était déjà perçue comme quelque chose de particulièrement utile. Malgré cela, l’écrasante majorité des utilisateurs ne faisaient pas l’effort de contraindre le logiciel à faire ce qu’ils voulaient.
Pourquoi ? Parce qu’ils se disaient que Microsoft étant expert en la matière (ce qui semble normal, vu que c’est Microsoft qui édite le logiciel), il devait y avoir une bonne raison pour que cette fonctionnalité soit désactivée par défaut. Le problème n’était pas que les utilisateurs ne connaissaient pas l’existence de l’option ; ils expliquaient ne simplement pas vouloir y toucher.
On pourra m’objecter que cette étude doit dater de plus de 10 ans. Quand bien même, je pense que le comportement des utilisateurs n’a pas changé d’un iota à ce niveau. Et on ne peut pas dire que Word soit un logiciel difficile à prendre en main ; ce n’est pas un CRM ou un modeleur 3D.
Je ne le martèlerai donc jamais assez : Faites des choix à la place de vos utilisateurs.
Si vous avez peur de vous tromper, commencez par vous mettre à leur place ; utilisez votre produit, apprenez à le connaître ; comparez avec les produits concurrents, faites le tri entre ce qui fonctionne quasiment tout le temps et la cerise sur le gâteau qui ne sera utilisée que par les power-users.
Je suis à 100% d’accord avec cela.
Le choix d’une option se fait toujours au détriment de la simplicité d’utilisation. Le pire cas est Eclipse : tout est entièrement configurable, cela répond à toute les situations. Mais le produit devient de plus en plus inutilisable (50 choix possible pour chacun des 10 menus…).
Le gros problème, c’est que souvent les prescripteurs sont dans les 5% qui recherche les options, les produits sans beaucoup de possibilité de configuration ont alors peu de chance d’être connu …
Proposer un produit « User Friendly » en somme…
Savoir se rapprocher de ses utilisateurs est une idée portée par les méthodes agiles; en plaçant l’utilisateur au coeur des développements, en l’impliquant dans la création de son outil, on arrive à rationaliser ses besoins.
A l’inverse un éditeur optimise ses coûts en limitant les versions donc en partant de la maxime « qui peut le plus peut le moins » on arrive à des outils 100% paramétrables qui sont sous exploités par la majorité des utilisateurs…
Il faut trouver le juste milieu 😉
@Eric : On est d’accord. Ta remarque concernant les prescripteurs est intéressante.
@Marc : Hum, la méthodologie agile prévoit le contentement du client (au sens, celui qui paye le développement). S’il est intelligent, celui-ci cherchera à contenter ses propres clients/utilisateurs.
Mais effectivement, tout est question de savoir où placer le curseur, sachant qu’il n’est pas facile de faire simple.
Perso je suis un grand fan. Je serais intéressé de voir s’il y a un lien entre le métier des commentateurs de ce post et leur avis. Un développeur aura tendance à coller des boutons et options partout. Le marketeux aura tendance à over simplifier. Je dis ça d’expérience. Mais je dis rien :-).
Eh, Bertrand ! Ça fait plaisir de te voir passer par ici ! 🙂
Et toi, tu te vois comme un développeur, ou comme un marketeux ? 😉
@Béber.
C’est très amusant car je pense exactement le contraire ! C’est à dire que les développeurs essayent d’avoir un produit épuré, mais que les commerciaux essayent de vendre n’importe quoi au client en rajoutant tout un tas d’options qui viendrons complexifier le produit.
En ce qui me concerne, je suis développeur et j’essaye de ne jamais mettre d’option dans mes produits jusqu’à ce qu’on me force.
Hum, je comprends quand même le point de vue de Bertrand. J’ai vu pas mal de développeur (souvent des inexpérimentés) qui « jetaient » leurs nouvelles fonctionnalités sans réfléchir à l’ergonomie. À leur décharge, ce travail aurait sûrement dû être fait en amont, mais ce n’est pas une excuse pour ne pas s’y intéresser.
Mais bon, j’ai aussi l’expérience inverse, avec des « fonctionnels » qui préconisaient de fournir des tonnes d’options et de laisser l’utilisateur choisir ce qu’il voulait. Là encore, c’était plutôt des juniors.
Un développeur expérimenté rechignera souvent à ajouter de nouvelles fonctionnalités. En partie pour garder une ergonomie correcte ; mais surtout (et c’est son travail) pour s’assurer que son code restera maintenable, évolutif et sans bug. Il est plus facile de garder un code propre et facile à modifier si on ne l’alourdit pas avec des choses inutiles.