Le syndrome du développeur

Je rencontre souvent chez mes confrères développeurs une manie que j’ai pris l’habitude d’appeler le syndrome du développeur. Cette manie consiste à restituer des données telles qu’elles sont à la source. J’appelle ça le syndrome du développeur, mais je pourrais appeler ça le syndrome du technicien, car ce n’est clairement pas limité à cette catégorie professionnelle, et encore moins à l’informatique. Laissez-moi vous donner des exemples.

Le syndrome du plombier

Dans les toilettes de mon boulot, les robinets du lavabo sont arrangés comme ci-dessus (cette photo a été prise par Kev Adams, ce qui me rends un peu triste et honteux d’être tombé dessus et de m’en servir comme exemple). Cette disposition n’est évidemment pas du tout pratique à utiliser. Mais il n’est pas difficile d’imaginer pourquoi ça a été installé ainsi : un tuyau d’eau chaude et un tuyau d’eau froide en entrée, un robinet pour l’eau chaude et un robinet pour l’eau froide en sortie.

Pour améliorer ça, il semble donc évident de devoir se séparer d’un robinet, pour n’avoir qu’une seule sortie d’eau. Mais là encore, les différentes installations qu’on croise dans notre quotidien sont loin d’être parfaites.

Une première solution consiste à conserver deux robinets mais une seule sortie d’eau (ci-dessous à gauche). Mais là encore, il s’avère difficile de jauger et d’ajuster la température. La meilleure solution est d’utiliser un robinet ajustable, permettant de contrôler très facilement le débit et la température de l’eau (ci-dessous à droite).

Encore des robinets

Si je vous parle de robinetterie, ce n’est pas à cause d’une soudaine passion naissante pour la plomberie. Mais c’est parce que je rencontre exactement le même genre de problèmes partout sur le web. A chaque fois, une donnée enregistrée est restituée telle quelle ou presque, sans chercher à savoir si elle est pertinente pour l’internaute.

Un exemple courant concerne l’affichage de dates. La solution la plus facile et la plus courante pour un développeur, c’est d’afficher une date au format « JJ/MM/AAAA HH:MM ». Cette solution semble naturelle, mais s’avère dans bien des cas complexe à comprendre pour l’internaute. Par exemple, en me connectant à mon compte Last.fm, je découvre les morceaux que j’ai récemment écoutés et qui ont été ajoutés à ma bibliothèque.

Une première présentation des dates sur Last.fm

C’est bien, mais ça ne m’avance pas à grand chose. « C’est qui ces groupes ? Quand est-ce que j’ai écouté ça ? Le 9 mai, c’était quand ça ? Et est-ce que la chanson de Gary Wright parle du logiciel d’Adobe ? »

En allant dans ma bibliothèque, je découvre une présentation différente des dates, beaucoup plus pratique.

La deuxième (et bonne) façon de présenter des dates

« Ah, c’était mercredi après-midi. Donc c’est surement ma copine qui a allumé mon ordi et qui a lancé des playlists. » Oh, et la chanson Dream Weaver, c’est dans la B.O. de Wayne’s World.

Un autre exemple que je croise souvent sur le web, ce sont les lignes panier des sites e-commerce. Le but d’une page panier, c’est de présenter les informations importantes de tous les produits, et de permettre certaines actions (suppression, modification de coloris/taille/quantité). Voici un magnifique exemple chez La Redoute.

Un tableau d'une page panier ayant subi le syndrome du développeur

Essayez de distinguer facilement les 3 maillots de bain que vous venez d’ajouter à votre panier. Le visuel n’est pas assez grand pour distinguer quoi que ce soit. Et les libellés des produits ont tous été tronqués et sont quasiment identiques. Admirez également au passage la très utile colonne « Offre spéciale ».

Vous pouvez très bien mettre en ligne un site tout à fait correct rempli des symptômes du syndrome du développeur, tout comme il est courant de rencontrer des robinets comme dans mon premier exemple. Mais si vous réfléchissez à ce qui est mieux pour l’utilisateur, vous apporterez une meilleure expérience utilisateur. Et ce travail, ce n’est pas qu’au développeur ou à l’intégrateur de s’en préoccuper, mais aussi et surtout au chef de projet et au graphiste.

  1. Integrateur, le

    Bonjour,

    L’idéal est de proposer un système de personnalisation à l’internaute, comme un onglet « préférences » qui lui permet de choisir le tri et le format des données qu’il préfère.

    Belle playlist sinon ;-) J’ai vu My Brightest Dianond live il y a quelques semaines, une performance exceptionnelle…

  2. webaaz, le

    Bon article mais je ne suis pas fan du titre.
    Finalement tous ces exemples ne sont souvent pas le fait du développeur mes souvent du client au travers de spécifications mal/pas pensées.
    Si on y ajoute le travail d’un ergonome/concepteur d’interface, tout va mieux :-)

    ps : le vert sur le formulaire m’a coûté un œil :-/

  3. Aurélien, le

    Article pertinent merci.

    J’ajouterai l’ergonome dans ta conclusion :)

  4. tony, le

    C’est bien vrai. Le métier d’ UX designer répond pour une partie à cette problématique.

  5. LeMoussel, le

    Problématique posé mais la réalité est toute autre. Que veux exactement le client ?
    Bien souvent celui-ci a une idée peu précise sur le sujet / la restitution.
    En conséquence pour être, à peu prés, dans la cible on met 2 robinets !

  6. Magicyoyo, le

    Je rejoins Webaaz. Ce qui transparaît ici est pour moi l’absence d’un travail fin sur l’interface.
    Pour faire cela, il une personne détachée de la technique, pour que l’interface ne soit pas structurée par ce qu’il y a sous le capot.
    Par ailleurs, dans le processus, ce travail ergonomique doit intervenir AVANT le développement. Si tu donnes au développeur l’interface cible, y’a plus de problèmes. Et en plus, ça permet de tester facilement.

  7. Bartdude, le

    En l’occurence le développeur renvoie les données qu’on lui demande. Si la personne qui a designé l’interface a prévu la donnée X à un endroit et la donnée Y à un autre endroit et dans un format déterminé, le développeur est censé suivre ca.

    Si tu cherches à démontrer que les développeur sont de piètres ergonomes, ca n’est pas forcément faux, mais ca n’est pas non plus une vérité absolue. Et quand-bien même ca serait le cas, c’est finalement assez compréhensible car ce n’est pas leur métier.

    Je suis de mon côté assez indulgent quand un designer ou intégrateur me demande de débugger un code dégeulasse qu’il a bricolé sur base d’un copier-coller douteux.

    Bref plutôt que d’entretenir une guéguerre bien inutile, il vaudrait mieux que chacun des métiers soient plus à l’écoute des problématiques de l’autre, de manière à s’améliorer et faire que, même si ca n’est pas notre métier, on ne soit pas complètement nul dans une matière X ou Y. Par exemple, sans être un intégrateur, j’ai je pense une bonne maîtrise de l’intégration et de la sémantique, sans-doute parce que je ne me suis pas dit dès le début « quels chieurs ces intégrateurs » mais que j’ai saisi l’occasion de moi-même devenir un peu moins ignorant en la matière :-)

  8. César, le

    Mwoué… pas convaincu. Facile d’attaquer le développeur, il a d’autres problématiques à adresser en priorité franchement.
    Il suffit de le spécifier au développeur, par exemple pour reprendre l’exemple Last.fm des dates, en intégrant ces exemples (« il y a 2 minutes », « hier », « le 09/05/2012 ») dans l’intégration HTML / CSS. Ceci lui mettra facilement la puce à l’oreille.

  9. Chris, le

    Quand on regarde le résultat d’un oeil extérieur je suis d’accord avec toi mais je serai curieux de savoir dans quelles conditions cet écran a été réalisé …

    Je ne serai pas surpris d’apprendre qu’au départ il n’y avait aucune spéc, aucune maquette et qu’on lui a simplement demandé « un écran de récapitulatif de panier », qu’il s’agit du 38ème essai car le client (qui n’a pas voulu prendre 5 min pour y réfléchir) n’est pas satisfait de la couleur du bouton modifier et que c’est l’assistant du client qui a tenu à ce que son idée de génie (la colonne ‘Offre Spéciale’) soit impérativement mis en place.

    Au premier essai le gars a certainement fait son possible pour réfléchir et proposer un bon écran mais à la fin quand on te prend sérieusement pour un con tu deviens aussi con que les autres et tu balances les résultats cash en attendant la remarque du client (qui de toute façon t’en fera une).

  10. Hervé, le

    Parce qu’il y a encore des personnes qui pensent que nous les développeurs nous savons faire de belles choses, visuelles ? ;-)

  11. Rémi, le

    Bon. Alors qu’on soit clair, cet article n’est pas une tirade contre les développeurs. J’appelle ça le syndrome du développeur, ou syndrome du technicien, parce que j’ai souvent l’occasion de retrouver ses symptômes chez mes camarades développeurs. Mais en réalité, c’est une manie qui nous touche tous, qu’on soit graphiste, chef de projet, intégrateur ou développeur (cf dernier paragraphe). Le but de cet article était de montrer qu’on peut se contenter de faire ce qui est demandé (comme un robinet avec de l’eau chaude et de l’eau froide), mais qu’en réfléchissant un peu on peut grandement améliorer l’expérience pour ses utilisateurs, sans pour autant modifier les fonctionnalités.

  12. cobolian, le

    Le développeur développe :) Et c’est déjà pas mal. L’idéal serait de faire comprendre a tout le monde que faire des interfaces c’est un autre job ;)

  13. Arnaud, le

    Il ne faut pas oublier qu’il y a la contrainte du temps et donc du prix. Je suis souvent confronté a des devis ou les concurrents chiffres 1j sur un ecran ou je vais plutot etre a 1,5j. Comment expliqué au client que l’on va présenter la même information mais que ca prendra plus de temps s’il passe par nous.
    Un formulaire de contact peut prendre 3 fois plus de temps a faire s’il est ingénieux.

    En tout cas, pour ma part, je m’interesse depuis longtemps a l’ergonomie, je prototype des interfaces, je fais également un peu de webdesign et ca ne m’empêche pas d’être un développeur web plutot expérimenté. Je ne pense pas etre unique dans ce genre.

  14. mlb, le

    bon je suis un peu hors sujet, mais je serais curieux d’avoir ton profil last.fm, car si je m’en tiens à ce début de liste, j’ai comme l’impression qu’il y’a du potentiel dans la compatibilité musicale :)

  15. YoPHP, le

    Ne mélangeons pas le développeur avec le chef de projet fonctionnel. Ce n’est pas au développeur de faire cette tâche de lui même, mais au chef de projet fonctionnel d’en décider (si celui-ci fait son boulot) et selon le budget signé.

  16. Xavier, le

    Oui très bon article, le web serait morose et pas pratique sans les chefs de projets et les graphistes. Par contre sans les techniciens il serait beau et pratique mais ne servirait à rien.

  17. Paul, le

    Est-ce toujours vrai que les écoles d’info enseignent l’économie et la compta mais pas l’ergonomie ni le prototypage ?

  18. LegZ, le

    Je rejoins YoPHP sur le fait que ce n’est *pas* au développeur de prendre ces initiatives.
    Le développeur développe, le concepteur conçoit (et la MOA/client décide en prenant des décisions souvent perfectibles)

  19. Paul, le

    YoPHP et LegZ, l’initiative personnelle n’est pas interdite.

  20. Bartdude, le

    Paul > d’accord avec toi… d’autant qu’on n’a pas toujours une équipe complète avec des spécialistes en ceci ou cela sous la main. Cela dit si l’initiative personnelle est qualifiée de « syndrôme » si elle n’est pas 100% inspirée, c’est un peu démotivant… Sans compter que l’exemple des robinets est assez criant : le modèle 2 n’est sans doute pas le plus pratique, mais est à priori moins cher que le modèle 3 :-)