La voix de l’utilisateur: entre recueil du besoin et gestion de l’incertitude

Consulter, interroger vos utilisateurs c’est bien … mais croyez-vous que vos utilisateurs vont tout vous dire ? Croyez vous vraiment que votre Client et /ou vos utilisateurs vont pouvoir et savoir décrire précisément ce dont ils ont besoin ? ce qu’ils veulent ? de manière claire et ordonnée ? Saurez-vous mesurer et gèrer l’incertitude qui les entoure ?

Certes, un questionnement pertinent est d’abord indispensable (bon c’est notre boulot me direz-vous ! c’est inclus dans notre démarche ergonomique), certes il est nécessaire de ne pas perdre de vue ces quelques règles d’or liées à l’entretien, mais le plus important dans un objectif de conception, c’est bien de faire le tri, d’analyser, de classer la masse d’informations recueillie pour alimenter PERSONAS, USER STORIES, USE CASES, LISTE D’EXIGENCES

Pour nous aider dans cette tâche, rien ne vaut selon moi, la catégorisation proposée par Karl Wiegers pour classer « l’input utilisateur »:

Les 9 catégories proposées:

  • Exigences Business (ce qui est lié à des bénéfices Business, notamment financiers)
  • Scénarios et cas d’utilisation (buts, tâches et activités des utilisateurs … c’est sur ces éléments que nous autres Ergonomes mettons l’accent; « en quoi consiste votre travail ? » cela vous dit sans doute quelque chose…)
  • Règles métier (dés qu’une activité est réalisée sous certaines conditions de type « si …alors », c’est certainement une règle métier)
  • Exigences fonctionnelles (ce qui relève du comportement observable du système et services rendus permettant à l’utilisateur de faire quelque chose… là il faut vraiment creuser, c’est la base)
  • Attributs de qualité (vous savez ceux issus par exemple de la norme ISO 9126, fiabilité, utilisabilité, portabilité, sécurité… ces éléments alimenteront vos exigences non fonctionnelles: ils sont essentiels)
  • Interfaces externes (communication du système avec d’autres interfaces et systèmes)
  • Contraintes (techniques, technologiques, physiques …)
  • Données (tous ce qui est relatif au type, format, valeurs des données)
  • Idées et solutions (les propositions de solutions… des sources à ne surtout pas négliger)

Au fait, j’espère que vous ne vous dites pas que tout cela, vous n’aurez à le faire qu’une seule fois … Ce questionnement et cette analyse, vous devrez les mener, certes à des degrés divers, tout au long de votre projet. Pourquoi ?

Car il vous faudra gérer ces besoins ou plus exactement GÉRER l’INCERTITUDE liée à ceux-ci.

Il est illusoire en effet de croire que nos clients et utilisateurs savent précisément ce qu’il veulent au tout début d’un projet; leurs besoins ÉVOLUERONT, le plus souvent en réaction à ce que nous proposerons. Alors, acceptons, ou plus exactement maîtrisons le changement et guidons cette évolution!!

Considérons le comme un atout (nous serons de plus en plus précis), GARDONS l’ESPRIT AGILE, et recherchons au plus vite le feedback au travers de User Stories, de maquettes, de prototypes et de livraisons fréquentes et rapides (« Deliver Fast« , c’est un élément du Lean Thinking, c’est aussi une valeur, un des facteurs de réussite de Google, « It’s all about speed, faster is better than slow » à envisager pas seulement au niveau des algorithmes…).

Les bénéfices sont nombreux et incontestables, d’ailleurs sur cette question du feedback, je vous conseille le récent article de Thierry Cros nous rappelant ses différentes dimensions dans une perspective Agile.

Par ce feedback, vous donnerez de la visibilité, de là vous rassurerez puis créerez de la satisfaction , et quand client et utilisateurs sont satisfaits, tout va ! Bon, OK, mon raisonnement est un peu simpliste…

Plus sérieusement, cherchons à créer de la VALEUR pour notre Client dès le départ, dés le recueil des besoins, et pas seulement à fin de notre projet, une fois le produit livré !