Le design d’interface, à l’instar du processus de développement qui l’englobe, ne peut être qu’itératif.
Plus qu’un constat, une réalité, à laquelle nous sommes confrontés tous les jours.
En effet, faire du design d’interface:
- C’est prendre le temps d’envisager plusieurs possibilités, plusieurs solutions, pour aboutir à la solution finale (souvent mélange des précédentes ou fruit d’un compromis). Que toutes ces solutions, ces essais soient parfaits est évidemment impensable !
- C’est aussi accepter que les besoins de nos clients, utilisateurs évoluent, le plus souvent en réaction à ce que nous proposons. Il est illusoire en effet de croire que nos interlocuteurs savent précisément ce qu’il veulent au tout début d’un projet.
- C’est enfin s’appuyer sur les autres et aller chercher le feedback pour comprendre, avancer, simplifier, améliorer les interfaces qu’on propose. La première interface est rarement la bonne.
Autrement dit, collaboration, feedback et contrôle du changement sont devenus des dimensions clés de nos métiers; des éléments qui ont du mal à s’exprimer dans des cadres trop rigides (tout est dans la mesure) ou trop cloisonnés…
Quand j’ai découvert les Méthodes Agiles il y a quelques années, j’ai immédiatement accroché la dessus … feedback (recherché, intégré … permanent), collaboration amplifiée, acceptation du changement, tous trois placés au centre des débats, identifiés dans plusieurs bonnes pratiques et « institués en tant que principes de base. Waou !!!
Il est clair que l’ergonomie, le design d’interface peuvent trouver dans l’agilité (XP, SCRUM, OpenUP) des leviers inespérés, alors pourquoi dans la pratique, design d’interface et Agilité ont-ils tant dans de mal à cohabiter !
Comment y remédier ?
Quelques éléments de réponse dans mon manifeste pour une ergonomie Agile…
Par expérience dans mon Master IHM, le mot Agile a fait peur à beaucoup de mes enseignants : l’idée reçue de la programmation extrême a la vie dure. La communauté IHM a apparemment une culture très "Big Design UpFront", où on fait beaucoup de maquettes et de conception (la partie "noble") avant de déléguer la réalisation du produit final (la partie "technique").
L’Agilité, c’est pourtant la même idée, mais en plus concret : faire un petit morceau, le montrer aux utilisateurs finaux, puis ajuster. Au delà des livraisons de fin d’itération, dans Scrum les pratiques d’ingénierie à l’intérieur de ces itérations ne sont pas spécifiées, justement pour laisser la place à celles qui sont le plus adaptées aux spécificités du projet.
Alors pourquoi ne pas injecter ici du maquettage papier avec les utilisateurs, du prototypage fonctionnel, des mini-évaluations d’utilisabilité, etc ?
Bref, je suis aussi partisan du rapprochement de ces deux domaines, mais c’est loin d’être gagné 🙂