L'audit dans la phase de discovery

On ne va pas se mentir, la recherche utilisateur est encore trop souvent vue comme “optionnelle” et beaucoup d’entreprises, quand elles veulent sortir un produit numérique, vont faire l’impasse là dessus.

Souvent, quand je demande pourquoi on ne fait pas de recherche, on me répond “je connais mes utilisateurs, je sais ce qu’ils veulent” ou “à part coûter de l’argent, ça ne sert à rien”.

Ouch.

Et encore que ?

Ont-ils vraiment tord ?

Reprenons les bases …

C’est quoi la recherche utilisateur ?

Il y a deux types de recherche utilisateur :

• La phase discovery qui sert à découvrir (lol) les utilisateurs, leurs besoins, leurs freins, etc
• La phase de test qui sert à confirmer ou infirmer ce que qu’on a créé, toutes les hypothèses que l’on a faites.

Et ces deux phases ne servent pas les mêmes besoins.

Quand les clients viennent me voir et me disent “mon site ne marche pas, je ne sais pas pourquoi” ou “mes opérationnels n’arrêtent pas de dire que l’outil est nul, mais normalement, il devrait faire tout comme on veut”, là on a besoin de discovery.

Quand ils me disent “Les utilisateurs n’aiment pas le bleu, on leur a mis du rouge et ils sont toujours pas content” ou “on a tout bien fait, on a demandé, on a solutionné le problème utilisateur et ça ne marche toujours pas”, là c’est du test.

Les deux sont à faire. Certes pas au même moment, mais l’un comme l’autre, ils sont importants. Ce n’est pas parce qu’on parle à nos utilisateurs qu’on va répondre à leur problème de la façon dont ils en ont besoin. D’où l’importance de tester après coup.

Mais je m’égare. Aujourd’hui, on parle de l’audit

L’audit se fait de façon horizontal et vertical, humain et outil.

Je m’explique.

Quand on cherche à connaitre les besoins et les freins des utilisateurs, il faut prendre en compte deux hypothèses :

• L’outil (site, webapp, logiciel) ne fonctionne pas comme il le devrait (sur un point ergonomique ou technique)
• Les process ne permettent pas la complétion de la tache (que ce soit des process globaux comme des process interne à l'outil)

Ça a l’air bête, mais des fois, les process et les outils ne sont pas alignés. On a un outil qui permet de faire une tache A puis B et uniquement dans cet ordre, mais dans mon process, je dois commencer par C puis B puis A. Donc forcément, pour remplir la tâche sur l’outil, je n’ai pas d’autre choix que de trouver une parade. Et donc, je vais dire que l'outil ne marche pas. 

Et ça, ça fait perdre du temps et donc de l’argent.

En auditant de façon très horizontale les process et le calque outil on va déjà voir apparaitre les premiers soucis.

Ah, quand je parle de process, je parle de process de bout en bout. Vraiment de bout en bout.

Même si c’est pluri-services.

Relou ?

Bien au contraire, en étudiant le process dans son intégralité on peut mettre aussi en valeur les problèmes de passage de l’information entre service, les dysfonctionnements humains ou outils.

Parce que c’est chouette que le service A fonctionne parfaitement, mais si le service B galère comme un fou et perd du temps à récupérer l’info, bah ça ne sert à rien.

Et on sait tous que des dysfonctionnement de communication existent dans touuuuuutes les entreprises.

Au moins, là, on peut pointer les moments exacts où ça se produit.

Et comme on le voit, on peut le corriger.

Mais

L’audit se fait aussi sur un plan vertical.

Imaginez, vous souhaitez comprendre pourquoi votre e-commerce ne marche pas.

OK, le bouton est un peu caché, les clients finaux galèrent un peu à mettre au panier.

Super

Mais ce n’est pas tout. Parce qu’il n’y a pas que les utilisateurs qui ont un lien avec le site.

Qu’en est-il du service marketing ?
Ont-ils la main pour parler avec les utilisateurs ?
Comment les font-ils aller sur le site ?
Et la logistique ?
Comment sait-elle qu’une commande a été faite ?
Comment répond-elle à la demande ?
Et l’approvisionnement ?
Ca se passe comment ?

Et on peut aller encore plus loin.

Et la direction ?
Sur quelles données se base-t-elle pour vérifier que sa stratégie fonctionne ?
Comment prévoie-t-elle l’introduction d’un nouveau produit ?
Comment l’ajout d’un nouveau produit se fait dans la chaine verticale (de la stratégie à la l’utilisation du produit par le client final en passant par touuuuuute la chaine de l’entreprise ?) ?

Ça à l’air too much ?

En réalité, c’est vraiment comme ça qu’on peut améliorer les choses.

Parce que même si vous améliorez la visibilité du bouton ou que vous facilitez le passage au panier, il faut que tout le reste fonctionne correctement.

• Votre client final ne se lève pas le matin en se disant “aujourd’hui, je vais acheter ce produit”
• Votre équipe logistique ne se dit pas tout naturellement “tiens, je vais envoyer tel produit à telle adresse, comme ça, parce que j'en ai envie”

Si dans la chaine verticale comme horizontale vous avez une défaillance, alors vous allez avoir rapidement un problème.

Et les “on fait comme ça parce que ça a toujours tenu” ne fonctionneront plus si jamais quelque chose change (une popularité soudaine par exemple).

Comment faire pour ne pas exploser le budget sur l’audit

Je suis d’accord, ça peut très vite coûter cher.

Mais on peut travailler en cycles.

Etape 1 : définir les macros process

On regarde comment tout s’articule (horizontal et vertical) sans vraiment rentrer dans les détails.

Le but : Mettre le(s) process en face de(s) outils et voir où ça coince en premier.

Là, vous vous dites “gnagnagna, si je t’appelle pour mon site, c’est pas pour que tu travailles sur mon logiciel de logistique”.

Oui mais si le site qui ne fonctionne pas n’était que l’un des symptômes ?

Et si le fait que la logistique galère de fou à faire livrer le produit ne soit pas annonciateur d’un problème plus important ?

Il faut vraiment penser vertical. Si dans mon échelle, il manque un barreau, alors c’est tous les étapes inférieurs qui en pâtissent.

Etape 2 : Trouver des quick wins

Ce mot est très relou à prononcer, mais il est vital.

En se concentrant sur les choses facilement réalisables et qui vont montrer leurs effets bénéfiques rapidement, on va pouvoir dégrossir le tout.

Quand on en arrive à se demander s’il vaut mieux du bleu ou du turquoise pour le bouton, c’est qu’on a réglé beaucoup de choses en amont.

Etape 3 : Aligner l’humain et l’outil dans les quick wins

Surprise.

Trouver des quick wins ne signifie pas qu’ils soient "outils" automatiquement. Ils peuvent très bien être "humains" aussi.

Ce qu’il faut c’est que dans la roadmap de correction du problème, on aligne toujours le process (l’humain) et l’outil pour éviter de créer un autre problème.

Le but, ce n’est pas de coller des sparadraps partout. Le but c’est de soigner.

Petit à petit.

Etape 4 : On recommence et avec le sourire

Couche après couche, on va creuser de plus en plus pour corriger, améliorer et faciliter la vie de tout le monde.

On se sert de nos petites victoires pour s’encourager et pour montrer que ça fonctionne.

Le tout, c’est d’être un peu patient. On ne règle pas tous les problèmes en 1 mois, malgré toute la bonne volonté du monde.

Mais avec cette méthode cyclique, on peut contrôler, mettre en pause si besoin ou revenir en arrière. Et surtout, en divisant par petites couches, le changement est moins fort et donc fait moins peur.

Parce que si demain, j’arrive et je vous dit qu’on va TOUT changer, je pense que vous me mettrez à la porte en moins de deux.

Et techniquement, comment je fais mon audit ?

On en a déjà un peu parler sur l’article des analyses comportementales, mais l’audit, il se fait sur plusieurs tableaux :

• En interne avec les équipes, on va auditer les process via de merveilleux ateliers pas du tout créatifs.
  Leur but : poser à plat ce qui se passe, étape par étape.
  => Si on décide de travailler sur un outil interne, c’est là qu’on va pouvoir rentrer dans l’outil avec un audit ergonomique, un audit comportemental et après aller plus loin dans la discovery avec nos entretiens et tout.

• En externe, avec les utilisateurs, on va aller chercher plusieurs sources : le site/webapp bien sur en audit comportemental et ergonomique mais aussi les avis, les retours clients, etc. On va auditer tous les points de contact avec l’utilisateur avant d’aller lui parler et de se lancer dans la phase d’entretiens et tout et tout.

Dans les premiers cycles d’audit, je pense qu’on peut trouver rapidement des choses à corriger avant même d’aller parler directement aux utilisateurs. Parce qu’ils se seront déjà exprimés là dessus.

Je comprends plus rien. L’audit, c’est pas la discovery, si ?

Où sont mes entretiens, mes observations ? Mon audit, si je peux le faire en chambre, alors je suis pas dans la discovery.

Alors.

Calme-toi petit scarabée.

L’UX ce n’est pas un schéma figé qu’il faut respecter à la lettre. Il y a autant d’UX designers que de méthodes.

Pour moi, auditer, c’est déjà entrer dans la phase de discovery … tout simplement parce que tu vas quand même découvrir des problèmes, des besoins.

Même si ce n’est pas forcément ceux là que tu cherchais.

Mais surtout, l’audit va te permettre de vraiment rentrer dans le sujet, de mieux comprendre l’écosystème global.

Un site e-commerce n’est pas seul, il a un CRM, un ERP peut-être, une CDP, et il a un outil de logistique, un service client, etc. Si tu pars bille en tête sur tes utilisateurs du site et qu’ils te disent tous “moi je veux bien commander, mais on me livre pas”, bah t’auras fait déplacer tout le monde pour quelque chose que tu aurais déjà dû savoir.

Donc tu auras perdu du temps … et de l’argent.

Donc 1, tu audites (et n’oublie pas les process 😉😉😉)

et 2 tu questionnes.

Et si tu ne sais pas comment faire, bah tu m'appelles et on en discute !