La sève doit trouver son chemin...
Un Système d’Information doit être le reflet de l’Organisation pour laquelle il a été conçu. Lorsqu’un informaticien se penche sur les difficultés d’un service de l’organisation, il cherchera souvent en priorité du côté du jeu d’outils métiers qu’il aura lui même déployé, voire développé. Parfois, il se lancera même dans la traque d’un bug malicieux qui défie sa logique de programmeur. Un peu comme si le code défiait son créateur, en quelque sorte… privant les utilisateurs des résultats escomptés, et l’informaticien de message d’erreur… C’est ce qui se passe pour vous ? Et si vous preniez du recul ?
D’où vient le problème ?
Et s’il n’y avait pas de message d’erreur, simplement par ce qu’il n’y a pas d’erreur ? Et si vos utilisateurs n’obtenaient pas de résultat, simplement parce que leurs besoins ont évolué et que votre programme ne les couvre pas encore ? Un service de l’organisation peut se trouver en carence d’information sans même s’en apercevoir. Le responsable SI qui détecte ce type de problème doit concevoir des solutions.
Proposez l’évaluation de l’outil pour obtenir une nouvelle vision des besoins
Avec des utilisateurs « la tête dans le guidon », ne détournant donc que très peu leur regard de leurs objectifs, il est souvent très difficile de communiquer. Pour obtenir leur attention, il peut être parfois nécessaire d’envoyer un e-mail à propos d’un « moment spécial » dans le cycle de vie de leur logiciel métier… Sans provoquer la panique cela peut suffire à générer en eux une prise de conscience quant à un éventuel changement dans leur pratique quotidienne. A l’aide d’un questionnaire de satisfaction savamment préparé à l’avance et portant sur les fonctionnalités de leur joujou favoris, vous recueillerez non seulement une photographie de « l’expérience utilisateur »… mais vous récolterez surtout un cliché du service et de son évolution à un instant T. Un entretien avec le chef d’équipe sur la base de ces résultats permettra de confirmer les nouvelles tendances qui vous permettront de dessiner les futures évolutions du programme.
Repérez les fonctionnalités appréciées et dupliquez leur ergonomie
Si certaines manipulations réalisées à partir de votre logiciel rencontrent une excellente note à l’évaluation par les utilisateurs, alors conservez-en l’ergonomie et hissez là au rang de vos meilleurs modèles de développement. Un utilisateur va toujours naturellement vers ce qui facile…
Retirez ce qui n’est pas utilisé pour le simplifier
Parfois même ce qui est facile à utiliser dans un logiciel peut faire un flop, car soit le besoin n’est simplement pas là, soit le niveau d’abstraction atteint à la conception est tel, que personne n’arrive à cerner le besoin originel. Une remise à plat de certaines fonctions peut s’imposer et un bon ménage… aussi ! Une seule chose à faire dans ces cas-là : se débarrasser du superflu et revenir à l’essentiel – Toujours – du point de vue de l’utilisateur.
Et enfin…
Donnez de l’autonomie, de la sécurité, et observez encore et encore !
