Ce qu’un audit regarde vraiment
Un audit a une seule mission : trouver où le produit perd les gens, et dire pourquoi. Pas s’il est séduisant — où quelqu’un qui essaie de faire quelque chose cesse de le faire.
« Audit » est un mot qui arrive avec un livrable attaché — une présentation, une liste, une note sur cent — et presque aucun accord sur ce qu’il est censé trouver. D’où le fait que la plupart soient lus une fois puis classés.
Un audit d’expérience produit a une seule mission : trouver où le produit perd les gens, et dire pourquoi. Pas s’il est séduisant, pas s’il suit les conventions du moment. Où quelqu’un qui essaie de faire quelque chose cesse de le faire.
Ce n’est pas une revue de design
Une revue de design demande si le travail est bon. Un audit demande si le travail fonctionne. Les deux produisent des constats différents, et les confondre est la façon la plus courante de rendre un audit inutilisable.
Le test consiste à voir si un constat survit à la question « et qu’est-ce que cela coûte ? ». « Les espacements sont incohérents » n’y survit généralement pas. « L’action principale et l’action destructrice se ressemblent et sont côte à côte » y survit, parce qu’on peut en décrire la conséquence sans deviner.
Chaque constat doit nommer ce qui casse, pour qui, et ce que cela coûte. Un constat sans mécanisme attaché est une préférence.
Il suit des parcours, pas des pages
Auditer un produit écran par écran produit une liste à peu près aussi longue que le produit, classée par rien. L’unité utile est le parcours : une tentative complète de faire une chose, de l’intention au résultat.
Trois parcours portent l’essentiel de la valeur :
- Le premier lancement. Tout ce qui précède l’existence de vos données dans le produit. C’est l’état que l’équipe voit le moins et que les nouveaux venus voient en premier, et c’est là que l’écart entre « démonstration » et « produit » est le plus large.
- La tâche principale. Ce à quoi sert le produit, faite comme la fait un utilisateur régulier — y compris les parties qu’il a appris à contourner. Les contournements sont des constats.
- Le parcours de récupération. Ce qui se passe après un problème : un paiement refusé, une saisie erronée, un élément supprimé. Les produits sont généralement conçus pour le succès et abandonnés au point d’échec, qui est précisément là où la confiance se décide.
Ce qu’il regarde réellement
Les moments d’engagement
Chaque point où quelqu’un cède quelque chose — de l’argent, des données, du temps, la possibilité de revenir en arrière. Ils méritent une attention disproportionnée, parce que l’hésitation y coûte cher et que l’interface les traite d’ordinaire comme n’importe quelle autre étape.
Les états que personne n’a dessinés
Vide, en chargement, partiel, en erreur, trop plein, périmé. C’est là qu’un produit cesse de paraître pensé, et ils sont invisibles dans un fichier de design. Le sujet est développé dans ce que « prêt pour la production » veut dire.
Le vocabulaire
Savoir si le produit emploie un mot par concept, et si ces mots sont ceux de l’utilisateur ou ceux de la base de données. Deux noms pour une même chose est un défaut structurel déguisé en problème de relecture.
Les impasses
Des écrans sans étape suivante, des recherches sans résultat ni suggestion, des refus de permission qui ne disent pas qui peut l’accorder. Chaque impasse est un endroit où la seule action restante est de partir.
Le classement est le livrable
Un audit qui produit quatre-vingts constats a produit un arriéré, et un arriéré n’est pas un conseil. Ce qui le rend utile, c’est le classement — et classer suppose un axe énoncé, car « gravité » ne veut rien dire seul.
Un classement défendable sépare deux choses qui se ressemblent sur une liste :
- Structurel — le produit est organisé de travers par rapport à ce que les gens essaient de faire. Coûteux à corriger, et corriger autre chose d’abord revient à refaire ce travail deux fois.
- Local — un écran, un état ou un contrôle précis est fautif. Peu coûteux, indépendant, et sûr à corriger dans n’importe quel ordre.
Les mélanger produit l’audit que l’on classe : une équipe lit deux constats structurels, les estime, et cesse de lire. Séparés, la liste locale peut être traitée immédiatement pendant que la question structurelle obtient la conversation qu’elle mérite.
Ce qu’un audit ne peut pas vous dire
C’est la partie habituellement omise, et cette omission est la raison pour laquelle les audits sont survendus.
- Ce que tout cela vaut. Un audit est la lecture experte d’un produit, pas une mesure. Attacher un pourcentage à un constat sans dispositif de mesure derrière relève de la décoration.
- Quelle correction faire en premier pour votre entreprise. Il peut classer par coût utilisateur ; il ne connaît ni votre feuille de route, ni vos engagements contractuels, ni ce que votre équipe peut livrer ce trimestre.
- Ce que pensent les utilisateurs. À moins que quelqu’un ne les ait observés, un audit est une prédiction raisonnée sur un comportement. C’est réellement utile, ce n’est pas de la recherche, et les deux ne doivent jamais être présentées sur le même ton.
En mener un sur votre propre produit
L’essentiel de la valeur ne demande personne d’extérieur. Elle demande de regarder le produit comme si vous ne l’aviez jamais vu, ce qui est la partie difficile plutôt que coûteuse.
- Créez un compte réellement neuf et faites la tâche principale sans toucher à ce que vous avez construit. Notez chaque moment d’hésitation — l’hésitation est le signal, avant que vous ne la rationalisiez.
- Refaites la même chose sur un téléphone, sur une connexion lente.
- Cassez quelque chose volontairement : mauvaise carte, mauvais fichier, pas de permission. Lisez la réponse du produit comme si vous ignoriez la cause.
- Notez chaque mot que le produit emploie pour ses objets principaux. Si un concept porte deux noms, c’est le constat.
- Triez ce que vous avez entre structurel et local avant d’en parler à qui que ce soit.
Si vous avez fait cela et souhaitez une seconde lecture de ce que vous avez trouvé, dites-nous ce que vous construisez.
