On est aveugle quand on achète une auto

J’ai acheté une auto en janvier dernier. Ils avaient peu de modèles en inventaire dans la province et ils ont donc dû la commander en usine. Le délai de livraison est entre 6 à 8 semaines. C’est long. Toutefois, ça parait encore plus long puisque je suis dans le noir.

Je pourrais appeler mon concessionnaire. Ils ne doivent pas plus le savoir que moi. Ils devront faire des appels téléphoniques à leur tour.

Il ne faut jamais négliger l’importance de la rétroaction dans un processus d’affaires. Quand on développe un système informatique, il faut tenir nos usagers informés en tout temps. Si vous devez concevoir un traitement long, pensez à une mécanique quelconque où vous journalisez chaque étape. Affichez ensuite la progression à votre utilisateur.

par spakattacks sur Flickr

par spakattacks sur Flickr

Si l’on revient au fabricant automobile, pourquoi l’état de ma commande n’est pas acheminé à moi? L’usine doit certainement être munie d’un beau système à la SAP (si ce n’est pas ça). Toutes les étapes de commande, de fabrication, d’inspection et d’expédition sont suivies à la lettre par leur logiciel ERP. Ça serait techniquement facile d’offrir des mises à jour par courriel ou sur un site extranet. Ils ont mon courriel dans ma fiche client. Ça fait partie des informations complémentaires qu’ils nous demandent quand ils créent notre dossier chez le concessionnaire.

Amenons la réflexion encore plus loin. Si ça était un extranet, pourquoi ne pas l’interfacer à des réseaux sociaux sur internet? L’usager accepterait probablement de partager son achat à ses amis sur ces réseaux. On n’a qu’à penser à Facebook Connect et ses possibilités d’inscrire des mises à jour avec rétroliens sur le mur du profil de son client. Ils ont certainement besoin de la promotion gratuite ces temps-ci, le bouche à oreille piqué aux stéroïdes est certaintement à considérer.

La technologie existe, mais je trouve ça désolant de voir comment certains sont atteints d’immobilisme. Les sites web des fabricants d’autos ne sont que de très belles démonstrations d’animations Flash. Actuellement, leurs seules transactions en ligne sont la soumission en ligne et le formulaire « contactez-vous ». Espérons que la crise actuelle va les forcer à réinventer leurs façons d’interagir avec leur clientèle.

Sans utilisateurs, on est rien

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.

Least useful error yet par Ben Garney sur Flickr

"Least useful error yet" par Ben Garney sur Flickr

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.