Vous êtes plutôt recherches ou expertise (ou les deux) ?

Je suis passé complètement à côté d’un très bon article publié par Dan Saffer d‘Adaptive Path : Research Is a Method, Not a Methodology.

L’auteur y expose son point de vue en matière de méthodologie de projet, et plus précisément sur l’utilisation de recherches et d’expertises. Selon ce dernier :

  • la qualité du résultat final n’est pas directement liée à la durée de la phase de recherche ;
  • 80% des enseignements d’une longue phase de recherche peuvent être anticipé par un expert.

Et ce dernier de citer les faits suivants : les équipes de Microsoft ont effectué une recherche de près de 2 ans avant d’accoucher de Vista alors que celles d’Apple n’en ont pas réalisé pour Mac OS X. Alors attention, je ne suis pas en train de critiquer le travail des équipes de Microsoft ou de comparer Vista à Mac OS X (pas de troll SVP), mais plutôt de vous expliquer pourquoi j’adhère à ce point de vue.

Dans mon quotidien professionnel, je suis persuadé que les méthodes de recherche (tri par carte, interviews qualitatifs…) peuvent apprendre beaucoup de chose (et notamment les lacunes d’un site web), mais qu’il est possible d’en déduire plus de 80 % en faisant appel à son expérience / expertise et à son bon sens.

Le message que je souhaite faire passer est que la phase de recherche ne doit pas nécessairement se faire en amont du projet. Le gros avantage des sites web et services en ligne c’est leur flexibilité. Il est ainsi plus productif (et plus rentable) de faire une refonte en se fondant sur le travail d’un expert puis d’affiner cette refonte avec des travaux de recherche après le lancement (eye-tracking, tests utilisateurs…) plutôt que l’inverse.

En règle générale je préconise l’approche suivante à mes clients :

  1. Compiler et exploiter les données-utilisateurs déjà recueillies (analyse des statistiques, épluchage des messages de réclamation, interview avec les équipes du centre d’appel…) ;
  2. Pratiquer une revue experte du site pour identifier les défauts et points bloquants ;
  3. Réaliser une étude concurrentielle pour nourrir une réflexion sur les choix de conception (le cahier d’exemples est mon instrument de travail favoris) ;
  4. Concevoir et réaliser la nouvelle version du site au sein d’une équipe réduite ;
  5. Lancer le site en le couplant avec un système de feed-back (et d’analyse de la performance) ;
  6. Conduire des études et recherches visant à affiner le travail de conception (tests auprès d’utilisateurs, eye-tracking…).

Cette démarche est de loin celle qui génère les meilleurs résultats en minimisant le temps et le budget. Pour avoir un point de vue similaire mais mieux argumenté, je vous recommande celui de Michael Carpentier : Recherche utilisateur vs expertise.

J’adorerais confronter mon point de vue avec vous, mais j’espère que cela ne va pas dégénérer dans les commentaires…

Un commentaire sur “Vous êtes plutôt recherches ou expertise (ou les deux) ?

  1. Assez d’accord avec toi. Il est trés dur de faire trés bien du premier coup, et l’informatique permet de faire des retouches à postériori. Mais à condition que ces retouches soient purement d’ordre esthétiques. Rien de plus pénible pour une équipe de développement que de devoir changer aprés la bataille le code en profondeur, par exemple le schéma d’une base de données, parce que le système de classification a été mal pensé initialement.

  2. justement, julien, les expert sont ceux qui ont acquis le flair pour détecter les éléments d’une application, susceptible d’être modifié, et qui en conséquence savent monter une architecture logicielle facilement maintenable

  3. Je vais dans le sens d’honsali, un expert sera te dire attention, il y a un risque de modification sur tel module / fonctionnalité, essayes de faire en sorte qu’elle soit le plus modulaire possible. /Fred

  4. Je suis d’accord sur le fait qu’il faille faire les choses les plus modulaires possibles. Mais il n’est pas possible de tout prévoir. C’est pourquoi faire notamment les tests sur un panel d’utilisateurs en amont me semble tout de même souvent plus « prudent » :) afin d’avoir le plus d’éléments figés. Une structure de base de données qui bouge, pour un site complexe cela peut impacter plusieurs dizaines de tables, et cela peut signifier reprendre à zéro le recettage de l’application. Là, je ne parle que des modifications qui découlent des tests post-mise en ligne, pas de modifs demandées par le client à la hussarde. Mais c’est une autre histoire ! a+

  5. Bonjour, C’est le principe de l’ingéniérie concourante ou simultannée : on fait et on ajuste en permanence avec un système de feed-back continu !

  6. En effet, faire cela c’est aussi privilégier les cycles de release courts et fréquents… cf. XP programming, Getting Reals, voire « what is web 2.0 » !

  7. Je pense que se baser sur le mode un expert (donc avec peu d’étude) est possible que si l’on a suffisamment de recul. Typiquement, un chef de projet ou un ergonome qui est amené à travailler en agence sur un portefeuille assez large de sites peut avoir cette démarche. Par contre, être en charge pendant des années sur le même site du côté utilisateur brouille passablement cet esprit critique et le « bon sens » qui est une notion – et c’est bien connue – partagée par tout le monde. Les tests utilisateurs peuvent alors aider à une certaine prise de conscience. Surtout que d’après Nielsen, ces tests peuvent être effectués très rapidement avec un coût très faible (http://www.useit.com/alertbox/fast-methods.html)

  8. Julien > la difficulté des modifs après mise en production dépend énormément de la technologie utilisée. Une appli crée de zéro en .Net ou en Java risque d’être beaucoup moins flexible qu’une appli Rails, par exemple, et nécessitera plus de défrichage en amont. Pour ce genre de développement (d’acrobaties ?), il faut utiliser des technos qui permettent de changer d’avis en cours de route et qui ne font pas re-rentrer dans un cycle de développement long à chaque modification de la structure des données. C’est aussi le rôle de l’expert que d’avertir sur ce genre de choses, amha.

  9. Lanza, D’accord avec toi, au plus on prend une technologie agile, au plus les changements sont faciles.
    Par contre, on peut aussi rendre des technologies comme .net plus ou moins agiles elles aussi, en s’appuyant sur des Data Access Layers (DAL) opensource. C’est ce que nous faisons avec ibatis.
    Par contre, pour d’autres sites, où les budgets ne sont pas les mêmes il ne faut pas se le cacher, on part de technologies plus « hautes » comme dotnetnuke en .net ou Virtuemart en php. Là les changements post-prod s’avèrent beaucoup plus ardus.

  10. Lanza > C’est un peu réducteur… on peut faire du pas souple en Rails et du très souple en .NET. Il faut une architecture adaptée et anticiper raisonnablement les évolutions possibles, c’est tout.

  11. Je suis d’accord avec l’approche proposée par Fred, mais j’y ajouterais un point « 1.5 » qui serait : « Identifier la cible » (peut être déjà implicitement inclus dans le point 1 ?). En effet, j’ai remarqué que les défauts et points bloquants que l’on cherchera au point 2 peuvent différer selon le public auquel le site s’adresse. Cette notion n’est pas forcément primordiale pour un site orienté B2C, domaine ou les règles ergonomiques sont connus, mais devient plus importante avec une orientation B2B ou les « sensibilités » peuvent étonnement varier en fonction des industries.

  12. C’est certain, mais là ça devient plus un problème commercial qu’un problème de R&D. Un client qui achète un DotNetNuke doit savoir ce qu’il achète réellement et quelles sont les possibilités et le coût des modifications futures.

  13. Bien d’accord avec toi Lanza : le client doit savoir quelles sont les possibilitées mais aussi les limites de ce qu’on lui vend :c’est uyne question de confiance mais aussi de crédibilité. Et si on lui vend tel produit, on est sensé savoir l’améliorer si le client le demande, même si ca prendra du temps (s’il connait les limites, il acceptera mieux que telle amélioration prendra plus de temps car on lui avait dit au départ, ensuite il faudra négocier les heures). Concernant la méthode de Fred, je suis aussi de l’avis qu’il faut d’abord essayer d’intervenir avec ses propres connaissances puis ensuite vérifier si celà fonctionne avec des utilisateurs réels pour valider (ou pas) les changements effectués. Par contre, parfois l’on a pas l’occasion (temps, budget, etc) de faire l’étape 6 et si celà est très (trop) fréquent, je pense qu’on risque de perdre le lien à la réalité et aux utilisateurs. Expert c’est bien mais si on n’est jamais en contact avec les utilisateurs, on ne fait pas un objet adapté aux utilisateurs mais on finit par imposer sa vision en croyant que c’est celle des utilisateurs. Si vous avez déjà fait des tests utilisateurs, ces derniers vous ont certainement fait découvrir des problèmes auxquels vous n’auriez jamais pensé lors d’une analyse experte : « tien j’étais certain que ca passait ce genre de chose … » Et grâce à ce genre de « découverte », vous améliorez vos futures expertises puisque vous apprenez. Non ?

  14. Tout à fait d’accord avec toi, Lanza, l’honnêteté envers le client est primordiale, il doit être conscient des limites de ce qu’il achète, d’autant plus si le projet est piloté par un budget serré.

  15. Je suis d’accord avec les thèses exprimées dans votre billet (et par conséquent, celles de l’article que vous mentionné), mais je souhaiterais mettre l’accent sur l’environnement dans lequel se déroule le projet. Ainsi, dans certains environnements, il y a beaucoup de « temps » disponibles (durée, personel en équivalent temps plein, etc), mais peu de « moyens » (argent, expertise, etc). Et donc, le travail de recherche peut être adapté à cet environnement (je pense essentiellement au secteur public). Donc, en ce qui me concerne, je suis plutôt les deux ; et je fais le choix en fonction de l’environnement dans lequel je me trouve.

  16. Bonjour Fred, A mon avis c’est une question de criticité de ce qui est développé… En fonction des objectifs qu’on souhaite donner au site, mieux vaut s’assurer par quelques tests utilisateurs qu’on ne part pas dans la mauvaise direction sur la structure même du site. Après, bien sûr, si la structure est bonne, on peut commencer à programmer puis procéder aux ajustements page par page après. J’en profite pour signaler (attention pub ;-)) que je lance avec un collègue étudiant un blog dédié à la problématique du taux de conversion/taux de transfo: http://www.blog-conversion.com/ Il a été lancé cette semaine ! Nous sommes très preneurs de vos avis éclairés et de vos conseils ! Merci ;-)

  17. Globalement je suis d’accord avec cette approche pragmatique, cela dit ça pose le problème plus général des « experts ». Si on est client et qu’on veut réaliser un site, on n’est en général pas capable de juger la compétence de l’expert. Si l’expert en question est nul (si, ça arrive…), ça peut être un catastrophe pour un projet. La phase de recherche peut effectivement être plus longue, plus coûteuse, mais dans certains cas, elle peut être plus prudente.

  18. Cette approche est similaire, dans sa logique, à celle de la recherche scientifique. Celle-ci se base sur une hypothèse de départ que les travaux de recherche ont pour but de valider. L’hypothèse est souvent produite par l’intuition de l’expert (la pomme de Newton ou le bain d’Archimède). La recherche est alors plus focalisée sur l’obtention d’un niveau acceptable de fiabilité des résultats que sur l’émergence de conclusions originales. La démarche de conseil s’y apparente aussi. Généralement, les conclusions d’une analyse sont connues dès le départ (les prestataires sont parfois même sélectionnés sur cette base de « compréhension »). L’objectif de la recherche est de valider et etayer factuellement les conclusions (voire de les faire « approprier » par les interlocuteurs impliqués dans la recherche). Dans le cas d’un projet de site, l’intuition de l’expert va fonder le nouveau design et la confrontation aux utilisateurs en constituera la validation.

  19. Merci pour ce lien. Il y a effectivement une forte ambigüité sur ce blog, mais la page d’accueil est suffisamment explicite pour que je ne m’en offusque pas. /Fred

Laisser un commentaire