* * * * *

Abonnez-vous !

Innovablog, Le Web où l’Innovation ordinaire : design, ergonomie, interfaces riches, web 2.0, eCommerce,…

  • A propos de l’auteur
  • Archives
  • Contacts
  • 8
    mar 08
    Catégorie : Web application

    Ecouter ses utilisateurs. Rêve ou réalité ?



    Me voici de retour après un insoutenable silence d’une semaine, au plus mauvais moment : Innovablog rentre dans le top 100 des blogs Wikio High-tech, pas mal de visites cette semaine, et pas de contenu pour les lecteurs… Mais les mises en productions importantes côté pro prennent le pas sur le blog. Et justement pour rebondir sur mon actualité, j’ai envie de revenir sur une question posée fréquemment dans l’écosystème du développement / design : faut-il ou non écouter ses utilisateurs ?

    Application web

    La question sous ses airs provocants n’est pas si anodine. On parle ici évidemment de design, d’ergonomie et d’utilisabilité.

    Rappalez-vous la parabole de Jakob Nielsen, pape de l’utilisabilité pragmatique, qui dès 2001 évangélisait (First Rule of Usability? Don’t Listen to Users) :

    However, when collecting preference data, you must take human nature into account. When talking about past behavior, users self-reported data is typically three steps removed from the truth:

    • In answering questions (particularly in a focus group), people bend the truth to be closer to what they think you want to hear or what’s socially acceptable.
    • In telling you what they do, people are really telling you what they remember doing. Human memory is very fallible, especially regarding the small details that are crucial for interface design. Users cannot remember some details at all, such as interface elements that they didn’t see.
    • In reporting what they do remember, people rationalize their behavior. Countless times I have heard statements like “I would have seen the button if it had been bigger.” Maybe. All we know is that the user didn’t see the button.

    Ainsi même en optant pour une démarche participative et tournée volontairement vers les utilisateurs, ceux-ci produiront des réponses parfois biaisées :

    • Les utilisateurs tendent à produire la réponse que l’on veut entendre et qui va dans le sens attendu par l’enquêteur.
    • Une analyse digne de ce nom ne peut se baser que sur les réponses apportées par les utilisateurs : même pleins de bonne volonté, ceux-ci ne peuvent apporter une réponse exhaustive à la question. D’une part leur mémoire n’est pas infaillible, et d’autre part, des éléments cruciaux de l’interface ont fort bien pu leur échapper lors de la mise en situation.

    Creative Commons License photo credit: webschepper

    Ainsi dans les phases de pilotage on ne peut se limiter à questionner les utilisateurs. Une collecte d’éléments formels, chiffrés est indispensable. Cela peut passer par différentes méthodes.

    Interrogez la base de données

    La base de données est remplie d’informations. A vous de savoir “la faire parler”. En effet, les données enregistrées en disent parfois bien plus long que ce que pourrait le faire l’utilisateur qui les a produit.

    Creative Commons License photo credit: Patrick Powers

    Une méthodologie d’audit peut / doit être mise en place : analyser le contenu d’une facture, ligne par ligne, montant par montant et quantité par quantité se révèlera un excellent complément des informations recueillies auprès des utilisateurs.

    Traquez vos utilisateurs

    Toujours dans l’optique d’affiner l’analyse et de compléter les déclarations des utilisateurs, traquez leur comportements. Plusieurs méthodes peuvent être employées.

    • Les traces. Mettez en place un recueil de toutes les actions entreprises par l’utilisateur. Chaque action de formulaire peut être taquée et produire des données d’une richesse incomparable selon un format assez simple :
      • Date / heure,
      • Utilisateur : Identifiant + login,
      • Action effectuée : Insert / Update + Type d’action (rubrique de l’application / du site concernée)
      • Bonus : valeurs modifiée. Si vos développeurs sont brillants (comme ceux avec qui je travaille), ils vous développeront un gestionnaire d’erreur capturant les seules valeurs modifiées lors du post du formulaire.
    • Les logs d’erreurs. Chaque erreur produite sur l’application / le site doit être tracée 500, 404, etc.). Si celà est effectué initialement en mode debug pour le développeur, cette source d’information ne doit pas être négligée par la suite puisque là encore riche d’enseignements.
    • Les outils marketing. Des outils merveilleux sont mis à notre disposition, parfois même de façon gratuite. Si ces outils sont à la base utilisés pour des sites B2C, n’hésitez pas à les implémenter sur vos applications web. Les Xiti, Google Analytics produiront des données d’une incomparable richesse notamment dans notre cas dans l’étude du parcours de l’internaute sur l’application / le site. Un goulot d’étranglement, une page perturbante, un formulaire défiant les lois de l’utilisabilité seront rapidement repérés. Dans la même veine, les outils de Eye-tracking (voir cette étude) comme Clic Density, Crazy Egg ou encore Analytics vous mettrons en évidence les zones chaudes de votre application.

    Eye tracking

    L’analyse : croiser ses sources

    Le travail du détective peut ainsi débuter. Pourquoi ce type d’action à effectuer semble poser problème ? Ce formulaire est mal compris par les utilisateurs ? Utilisons ainsi tout le matériel à notre disposition.

    1. La première source sera donc les remontées / feedback des utilisateurs finaux. Leur ressenti est en effet primordial.
    2. Afin de parfaire l’analyse, croiser cette première information avec les autres sources de données, cette fois-ci plus statistiques que sont les logs et le contenu de la base de données comme vu ci-dessus.

    On pourra ainsi mettre en comparaison les feedbacks terrain, source de données à chaud, affectives, émotives et parfois subjectives, à des données froides, numéraires et statistiques.

    Ecouter ses utilisateurs est donc possible et n’est pas une pure fiction, du domaine du rêve. Dans certaines conditions…

    A lire également :

    Cet article vous a plu ? Ne perdez plus aucune info : abonnez-vous gratuitement !

    A vous de jouer ! Laissez un commentaire :

    XHTML: Vous pouvez utiliser ces tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

    Innovablog motorisé par WordPress
    Theme Wordpress par Olivier Favre
    Site Map
    RSS Feed
    Contenu intégralement sous licence Creative Commons