Même si je ne peux affirmer que 100% des programmeurs sont de mauvais designers, il faut avouer en général que d'exceller dans les deux domaines est rare, et que c'est pourtant crucial dans la réussite d'un projet de ce genre. Comment travaillons nous donc? Et est-ce que cela peut vous être utile d'une manière ou d'une autre?

Après quelques tâtonnements les premiers mois, nous avons finalement décidé que de fait, même si les idées sont là, le code est une de mes spécialités, et le code CSS ou HTML n'est pas un problème, mais de choisir les bonnes couleurs, les bons effets, j'en suis bien incapable. Après donc avoir essayé de séparer les taches en limitant Marc à la réalisation de PSDs avec son Photoshop favori, et à me laisser faire non seulement la programmation de la plateforme mais également d'en intégrer les éléments graphiques, force était de constater que le résultat n'était pas toujours optimal, et pas forcément toujours rapide.

Qui plus est, même si un graphiste (même s'il est impossible de réduire Marc à un rôle de graphiste) aime bien son premier design, une fois qu'il est en production souvent il a quelques regrets et voudrait en changer l'une ou l'autre courbe ou couleur... et repasser par le programmeur est une perte réelle d'efficacité. On a donc opté pour une méthodologie de séparation stricte des rôles : la programmation pure et dure pour ma part, avec des formulaires et autres données brutes en texte non formaté sur une page, et la folie créative de l'interface pour Marc, qui combine Photoshop et framework CSS maison pour pouvoir faire évoluer son design suivant son inspiration. Nous avons également adopté cette séparation au niveau de la programmation front-end : là où l'expérience d'un "pur" programmeur est primordiale, je développe les modules et les blocs nécessaires en Javascript (par exemple pour la génération des statistiques - mais nous y reviendrons), et Marc s'occupe du scripting "d'interface" en jQuery.

Une règle: la simplicité

A la base de notre projet, nous visions les commerces de proximité. Ayant envie d'une interface simple, nous avons fait et refait des dizaines de fois les écrans de vente avant de pouvoir réussir une première version utilisable. L'idée était simple: avoir un design le plus intuitif possible pour n'avoir besoin que de peu de formation pour l'utilisation et d'avoir une prise en main rapide aussi bien par un informaticien qu'une vendeuse, voir carrément d'une personne n'ayant jamais touché un ordinateur de sa vie (et oui, nous avons initié quelques commerçants à l'informatique, une expérience assez intéressante pour tout développeur/designer).

Plutôt que de rester dans sa tour de verre, lors des premières mises en production nous avons pris notre sac à dos, et nous nous sommes postés nous, ainsi que nos premiers employés, derrière une caisse pendant quelques heures pour observer l'utilisation de notre plateforme par les vendeuses en plein travail. Expérience très riche en enseignements, qu'il faudrait selon moi obliger à tout développeur/designer après une mise en production ou en cours de développement pour bien se rendre compte des problèmes rencontrés par l'utilisateur final face à l'aboutissement de notre travail. Car, même si tout nous paraît évident, et c'est bien logique, il n'en est pas toujours de même pour un utilisateur lambda.

Une... enfin, une deuxième règle: la remise en question

Deuxième enseignement appris au cours de notre vie professionnelle précédente, l'utilisateur trouvera toujours le moyen de se tromper. Et si il se trompe, c'est de votre faute. Ce que j'essaie d'expliquer par là, c'est que même si un écran vous paraît parfait, simple, et efficace, si une poignée d'utilisateurs n'arrivent pas à l'utiliser ou vous posent plusieurs fois la question via le support sur une fonctionnalité, c'est que vous vous êtes plantés sur le design.

Cela fait donc des années que chaque jour, nous essayons d'écouter les retours de nos utilisateurs pour modifier les écrans. Que ce soit un petit clic par ci pour une fonctionnalité, une icône pas assez en valeur, ou un texte pas lisible, dès qu'une question se répète plus d'un certain nombre de fois via notre support, il est temps de réagir pour améliorer la situation visuellement parlant. Et force est de constater que oui, cela engendre un coup de développement bien plus important, mais que ce coût est récupéré très largement en satisfaction de l'utilisateur final mais bien plus encore dans le coût du support qui ne doit servir que pour les problèmes réels d'utilisation et non pour expliquer une interface prétendue simple à l'utilisateur final.

Sébastien