Parfois quand on travaille dans des équipes de développement hermétiques où seulement certains côtoient les utilisateurs, on oublie parfois pour qui on travaille. On prend des petites décisions sur des aspects du système qui ne se retrouve pas toujours dans les cahiers de charge ou les dossiers fonctionnels (spécifications).

Mais, l’utilisateur est celui qui a besoin de votre système. Il est le demandeur. Le développeur est le serviteur. Vous pouvez trouver plein de nuances à ce que je dis, mais à la base la relation est telle.

Vous avez peut-être un rôle-conseil au niveau de l’optimisation du temps de développement. Plus précisément, vous pouvez proposer de retirer certaines fonctionnalités ou simplifier certains aspects de l’application. Ceci dans le but d’éviter des honoraires de développeurs ou parfois pour prévenir les problèmes sur une solution déjà fragile. Mais, vous le faites pour aider l’organisation client et non les utilisateurs finaux. Soyez conscients de ça.

Je suis tombé sur la Charte des droits des utilisateurs sur le blogue de Stéphanie Le Rouzic. J’ai beaucoup aimé la liste des points qu’elle a dressée. Mon attention s’est surtout portée sur le point suivant :

L’utilisateur a le droit d’être informé par le système sur son état par rapport à la tâche qu’il effectue et par rapport au progrès accompli vers la complétion de la tâche, de façon claire, compréhensible et précise.

La journalisation est souvent le talon d’Achille de toute solution. Le premier pas est de journaliser toutes les erreurs sévères du système (crashs, plantages). Deuxièmement, il faut afficher le message d’erreur à l’utilisateur final. « System error » ou “Une erreur est survenue » ne vaut rien pour lui. Il vous confie des données d’une très grande importance dans votre système et vous n’avez pas l’obligeance de lui dire ce qui se passe clairement?

Mettez-vous à sa place, aimez-vous ça quand la lumière « Check Engine » allume dans votre auto? Si le mécanicien peut lire le code avec un lecteur ODB-II le message d’erreur, pourquoi les constructeurs n’affichent pas le message sur un petit écran DEL sur le tableau de bord? Ils affichent déjà la température et l’heure! Cette industrie ne respecte pas ainsi l’utilisateur et vous pouvez alors comprendre comment l’utilisateur final se sent.

Si vous êtes trop gêné d’afficher le vrai message d’erreur, alors concentrez-vous à faire un système de qualité. C’est la meilleure solution.

Billet précédent: Cloud computing dans le contexte du SOA

Billet suivant: On est aveugle quand on achète une auto

Mots clés: journalisation, Qualité, utilisabilité, utilisateurs

Ce billet a été publié le 27 février 2009 à 8:30. Il est classé sous Développement informatique, Vie de consultant. Vous pouvez suivre les commentaires à ce billet à l'aide de son fils fils RSS. Les commentaires sont présentement désactivés