Après presque 4 ans dans le monde de l’Edition Logicielle à travailler sur l’ergonomie d’applications métiers et sur les méthodes de développement, me voici de retour dans l’univers du Conseil.
AU PROGRAMME,
Evidemment:
Ergonomie informatique (web et logicielle) et Expérience utilisateur
Agilité et bonnes pratiques SCRUM, UP, XP…
Mais aussi, accompagner les équipes, les organisations sur des sujets qui me tiennent à coeur aujourd’hui:
La pratique efficiente de l’ergonomie dans des contextes Agile et CMMI
La mise en place et l’utilisation efficace d’une potion “Méthodes Agiles / CMMI”, pertinente dans pas mal de contextes
Une approche transversale et continue de la qualité
Bien entendu, Qualitystreet continue …
Bref, je vous en dirai plus dans quelques semaines … en attendant, bonnes fêtes de fin d’année à tous, et surtout gardez l’Esprit Agile !
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)
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é !
Pourtant le modèle de Kano a presque 25 ans…
mais vous pouvez toujours aussi facilement l’appliquer, à vos propres réalisations, comme aux nouvelles applications en ligne de Google ou à tout autre service ou produit IT.
Les clés de son succès : sa simplicité, et surtout le recours aux UTILISATEURS qui font de ce modèle d’aide à la décision un pur outil de Conception Centrée Utilisateurs, utilisable notamment par l’ergonome ou les chefs de produit.
En bref, le modèle de KANO se propose de mettre en relation satisfaction des exigences (réponse aux besoins) et satisfaction Client, en distinguant notamment 3 types d’exigences, véritables piliers stratégiques, dont le degré de mise en oeuvre influencera différemment le degré de satisfaction du Client.
Ces exigences basiques ne sont pas toujours exprimées; elles sont pourtant évidentes pour le Client et doivent être impérativement satisfaites. Ce n’est pas un levier de satisfaction , en revanche si vous les avez pas, “vous êtes mort !” Elles ne sont pas forcément prioritaires en terme de développement mais devront être là le jour J.
(ex: Freins d’une voiture; un lit dans une chambre d’hôtel …)
Le besoin est exprimé et la satisfaction du client est proportionnelle au niveau de performance (et de qualité) de ce qui est implémenté. C’est un fort levier de satisfaction Client et un axe prioritaire pour le Développement, à faire valider très vite par les Utilisateurs.
(ex: la taille d’une chambre d’hôtel…).
Ces exigences correspondent à un besoin pas forcément exprimé, parfois inconscient. C’est l’heureuse surprise qui peut faire la différence, source de satisfaction importante parfois à peu de frais ! En revanche, l’absence de cette fonctionnalité ne sera pas source d’insatisfaction, de frustration. En terme de développement, elles ne sont donc pas prioritaires (sauf stratégie produit spécifique).
(ex: la coupe de champagne à l’arrivée, le wifi dans l’avion …).
C’est aussi le levier de l’innovation par excellence.
Évidemment une fois établi, le modèle n’est pas figé et telle ou telle fonction aura tendance à descendre (vers le Must have) au bout de quelques temps. Regardez ce qui se passe dans l’univers mobile.
AU FAIT, COMMENT CA MARCHE ?
C’est très simple, sélectionnez un panel d’utilisateurs représentatif (20…30), passez leur un questionnaire, analysez les réponses et prenez les bonnes décisions.
Temps 1: Consultation des utilisateurs (par questionnaires principalement) sur chaque fonction par l’intermédiaire d’une paire de questions (fonctionnelle et dysfonctionnelle)
Temps 2: Analyse des réponses pour chaque fonction et pour chaque utilisateur interrogé : au final 6 catégories possibles (I= Indifférente; Q=Incertaine; R=Inversée, et les 3 principales)
Temps 3 : Distribution et résultat final de chaque fonction.
La fonction x est un “Must Have”
La fonction y est un besoin exprimé “Linear”
La fonction z est une exigence attractive “Exciter”
…
La synthèse vous apportera entre autres de précieux éléments pour définir l’ordre d’implémentation des exigences.
Alors Convaincus ?
La video (en anglais) se suffit à elle-même ; au début cela fait « cheap » mais dés que les demos commencent c’est assez impressionnant. Un immense whiteboard interactif, ça me donne même des idées …
Et tout cela à partir d’une « simple » Wiimote ! (et sur n’importe quelle surface…)
Petit rappel, une User story est une exigence du système à développer, formulée en une ou deux phrases dans le langage de l’utilisateur.
Exemple : “En tant que recruteur, je peux déposer des offres d’emploi”.
Et voilà l’essentiel : une User Story est donc courte, discutée (détail écrit sur une carte) et confirmée par des tests d’acceptation rédigés au même moment que celle-ci (au dos de cette même carte).
Fervent supporter depuis des années (en tant que rédacteur et destinataire) des Use Cases (ou cas d’utilisation), j’ai toujours mené un travail d’évangélisation quant à ceux-ci et à leur bible « Rédiger des cas d’utilisation efficaces » … mais certains éléments me poussent actuellement à revoir mon jugement…
Alors mauvais usage, causes plus profondes ou tout simplement concurrent de haute valeur ( « User Stories ») ?
Voilà ce qui a tendance à me gêner avec les Use Cases (cas d’utilisation) et qui plaide en faveur des User Stories :
Ce n’est pas un bon support d’échanges et de discussion entre le Client et les équipes
Le format reste intimidant pour beaucoup de développeurs (et clients), même dans un format standardisé, allégé et bien présenté
La mise à jour (et il y a souvent mise à jour) est laborieuse
Les équipes de Développement, avec qui je collabore, en tirent seulement les règles métier et les données, pour le reste elles se fondent essentiellement sur les spécifications Ergonomiques (cinématique ; wireframe…)
Le focus ne peut réellement être mis sur tel ou tel scénario
Certaines extensions d’importance peuvent se perdre dans la masse
Le diagramme des Use Cases est rarement proposé (vous me direz, oui mais parfois il n’y a que le diagramme des cas d’utilisation !!!)
Il y a parfois redondance avec d’autres artefacts
En résumé et si je réfléchis à la fois en termes de création de valeur, de gaspillage et d’efficience… la balance penche vite pour les User stories !! Cela même dans des contextes où je ne les attendais pas.
Je reste perplexe devant le dernier billet, “Usabiliy is not a verb”, de Scott Berkun, l’auteur de “The art of Projet Management“, dans lequel il évoque ses débuts en tant que spécialiste “Usability” (tiens je ne savais pas) et sa trés rapide (et intentionnelle) réorientation vers des fonctions de management, afin de mieux servir (soit disant) la facilité d’utilisation.
Des éléments me parlent …
Pas entendu ou consulté tardivement, je l’ai été …
Dépendant des bonnes dispositions de tel ou tel chef de produit, je l’ai été …
Sens politique, art de la persuasion, cela me semble nécessaire en effet…
La vision de Scott Berkun est très pragmatique (presque trop) mais un peu réductrice; selon lui, seulement deux solutions pour se faire entendre :
SOLUTION 1: se focaliser sur une seule compétence, la plus importante, balance de sens politique, persuasion et négociation
SOLUTION 2: endosser des fonctions managèriales et occuper des postes de décision (grâce à des cours du soir, MBA … contexte US…), pour ensuite, décrocher des budgets, convaincre et faire avancer la cause (de ses pairs, ergonomes, designers …).
Bref, je proposerais bien à Scott Berkun, une troisième voie : l’AGILITE … ces projets agiles, des contextes favorables, dans lesquels un ergonome plus polyvalent, plus proche du Client, au sein d’une équipe projet soudée et motivée, peut réellement faire entendre sa voix.
