Le design centré sur l’utilisateur semble pour moi une évidence… Un bon design serait forcément « centré sur l’utilisateur », pas sur une technologie, pas sur une tendance, pas sur un préjugé. C’est donc une façon de voir le design, de l’aborder. La méthode « Agile » (très en vogue en ce moment) repose quant à elle sur un cycle de développement itératif, incrémental et adaptatif.

design2

Pour Alexandre Bujold et Sarah Morin-Paquet de l’Université Laval, ces deux approches peuvent se rejoindre. En effet, le design centré sur l’utilisateur et la méthode Agile partagent des caractéristiques communes. Les deux approches reposent notamment sur un processus itératif. Aussi, elles accordent beaucoup d’importance à la qualité des livrables, à la place de l’humain dans le processus de création et dans les tests utilisateurs.

Pour l’instant, je déplore le manque de design centré utilisateur dans les structures dites « Agiles », mais cela, j’en suis sûr, n’est qu’une question de temps, d’ouverture d’esprit et de curiosité.

Introduction

« La popularité grandissante des méthodes de développement Agile préoccupe certains designers d’expérience utilisateur qui veulent s’assurer que les produits informatiques, peu importe la méthode utilisée pour les concevoir, soient conçus pour l’utilisateur (SY 2007 : 113). En effet, les techniques utilisées par les développeurs qui suivent la méthode Agile sont souvent, selon les spécialistes en design centré sur l’utilisateur, inadéquates pour documenter les comportements complexes des utilisateurs.

Le développement Agile est un groupe de méthodes qui partagent une philosophie commune. Cette philosophie met de l’avant l’individu, l’interaction, le logiciel fonctionnel, la collaboration avec le client et l’adaptation au changement. Elle s’oppose aux méthodes traditionnelles de développement, dites Waterfall, qui sont accusées par les adhérents des méthodes Agiles de mettre l’emphase sur les procédés, les outils, la documentation exhaustive, la négociation de contrats et l’adhésion à un plan.

deisng

 Les méthodes de design centré sur l’utilisateur, traditionnellement, fonctionnent plutôt dans des processus utilisant une méthode Waterfall. Ceux-ci impliquent deux grandes phases au début du processus : une phase d’étude sur l’utilisateur et son contexte, puis une phase de design. Les méthodes Agiles, au contraire, n’ont pas de phase dédiée au design. En théorie, chaque phase contient une part de recherche et de design, mais en pratique, les techniques de recherche et de design utilisées se basent surtout sur l’opinion des utilisateurs et la rétroaction, alors que l’observation et d’autres techniques de design centré sur l’utilisateur seraient plus adéquates pour certains problèmes (SY 2007 : 113).

Étant donné la popularité grandissante des méthodes Agiles et l’incompatibilité apparente de ces deux approches, il semble pertinent de s’intéresser aux tentatives de rapprochement entre celles-ci en contexte d’entreprise. Premièrement, afin de mieux comprendre la problématique, nous allons nous attarder aux différences entre les deux approches. Ensuite, pour voir où elles sont compatibles, nous ferons ressortir les points communs entre celles-ci. Finalement, afin d’avoir un aperçu des manières utilisées pour les réconcilier, nous allons nous intéresser aux démarches entreprises en contexte réel pour intégrer le design centré sur l’utilisateur aux méthodes de développement Agile. »

Design centré sur l’utilisateur et développement Agile: perspectives de réconciliation

Pour résumer, le design centré sur l’utilisateur et la méthode Agile sont différents sur de nombreux points mais se recoupent dans une partie de leur processus et de leurs valeurs. J’imagine donc une réconciliation entre ces deux approches avec, du côté du designer, une volonté de suivre un rythme plus rapide : celui d’un projet Agile… et du côté des méthodes Agiles, une volonté de flexibilité pour intégrer le design centré sur l’utilisateur dans les structures du travail.

Tentés ?




8 commentaires

  1. J’ai pu participer à la création et refonte d’outils intranet en méthode SCRUM adaptée. Voilà ce que j’en retiens en bref :
    -> tout est dans l’expression du besoin : développeurs et web designers ont tendance a bosser « dans l’idéal ». Rien ne valait ici un « vis ma vie » pour comprendre l’environnement réel des utilisateurs avant même l’expression du Propriétaire du produit.
    ->grille de relecture commune claire et partagée: la vision du produit final doit réellement être commune au risque de dérives d’intentions (le « je pense que » ne sert à rien, seule l’argumentation est valable »)
    -> le web designer doit être au niveau du dev et de l’inté donc unifié par le Scrum Master (neutre, hors services) sinon cette méthode est inutile.
    -> un process adaptable : j’entends parler ensuite de cycles courts, cycles longs, les méthodes ne sont bonnes qu’adaptées au projet et équipes.

    Ce n’est que mon retour d’expérience, pas des « règles » ou conventions 😉

  2. Je vais compléter un peu ce que j’ai pu mettre sur mon premier post et rebondir sur ce que vient d’écrire Coreygraphe.
    Le design et l’agilité me semble être pour ma part un sujet plutôt bien avancé. En fait, j’ai été assez surpris de le voir réapparaitre sur le blog de Geoffrey.

    La place du designer dans un projet agile est à la droite du product owner. Il est garant des besoins des utilisateurs au cours de l’ensemble des cycles de vie du produit. Et attention, il ne se substitue jamais au product owner.
    Cette place est très confortable pour le designer car elle lui permet :
    – De se positionner proche du client et de défendre ses intérêts (avoir un bon produit).
    – D’être proche du product owner, et de pouvoir accéder aux « utilisateurs » (et surtout de ne pas faire tous les ateliers avec les commanditaires. Par expérience, ils sont souvent très mal renseigné et plein d’à priori. Et là, même en essayant de faire des jeux de rôle il est impossible de deviner ce dont à besoin un utilisateur).

    Le designer c’est aussi un facilitateur. Son rôle est de fédérer par sa méthode, il doit communiquer et partager la Vision du produit.

    Et un dernière chose, on en parle jamais et pourtant c’est le plus important pour le designer : les tests. Tester c’est essayer le produit, pouvoir toucher et s’assurer que les solutions apportées en V0 sont acceptables. Et on a du bol, chaque sprint intègre ses tests. Le designer dois tester, proposer de nouvelles solution si besoin au product owner. C’est aussi un moyen pour lui de suivre la réalisation du projet. On connait tous le pitfall suivant : le designer réalise l’expression du besoin, la conception et une fois que le produit part en réalisation… On en entend plus parler.

  3. Encore une petite chose :), l’article fait une bonne photo de l’état actuel des choses. Par contre, pour moi il manque des choses : L’aspect financier. Et c’est une contrainte plutôt importante à tous les niveaux, que se soit pour le client ou pour l’équipe en charge de la conception (qui plus est si c’est un prestataire). Des choses bêtes comme la difficulté de rassembler développeurs, designer, etc. Pour la simple raison que cette réunion qui doit se dérouler toutes les semaines va enfoncer le budget du projet.
    Les mauvaises habitudes sont aussi coriaces, avec des cahiers des charges qui sont souvent pris pour argent content et avec un client qui ne comprendra pas pourquoi son travail est remis en cause. L’impact direct c’est donc un cdc pris comme un contrat et l’incapacité et la peur des prestas de prendre un projet en mode agile et en mode design.

    Il y a d’autres points mais je dois démarrer le BBQ 😉

  4. @geoffrey merci a toi pour tous ces articles porteurs de sens.
    pour rebondir a mon tour sur les propos de @xavier, avant l’expression de charge il y a l’expression du besoin ou on doit integrer l’ux. Le bon sens et un maximum de donnees clients aident (et oui le fold desktop de vos client n’est plus celui d’il y a trois ans!…).
    Les personas et tris de carte sont par contre a considerer avec recul car souvent très orientes, c’est du a la methode même. J’ai la chance de pouvoir compter sur les magasins des marques pour lesquelles je bosse pour questionner les conseillers de ventes, souvent excellents, et voir et parler avec clients en vrai: pour moi cela reste l’ideal.
    Un point egalement essentiel: la/les grille(s) de relecture commune pour eviter une iteration sans fin.
    Bref si on balise sa base (vision produit +ux) alors la methode agile prend tout son sens!

  5. Oui c’est vrai une bonne vision est essentielle. Mais faire une vision sur un produit aujourd’hui en France c’est avoir la chance de faire une amoa. Du coup on voit bien le problème, souvent il n’y en a pas et c’est le client lui-même qui fera un cdc avec très souvent les erreurs que l’on connaît.
    Oui l’agilité et l’ux sont clairement fusionnable, et c’est même essentiel. Le soucis se sont finalement les clients (français) qui sont rassurés par un chiffrage sur la base d’un cdc et qui ne voit pas encore l’ux et l’agilité comme un moyen d’obtenir un produit de qualité. Et c’est pas faute d’expliquer…


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *