Réparer une interface sans la refaire : par où commencer

Quand une interface ne fonctionne pas, la proposition qui arrive est presque toujours la même : tout refaire. C’est la réponse la plus chère, la plus lente, et celle qui a le plus de chances de reproduire le défaut, puisque personne n’a encore établi où il se trouve.

La plupart de ce qu’on prend pour un problème de conception est un problème de mots. Une part de ce qui survit à cette correction est un problème d’ordre. Ce qui survit aux deux demande un développeur, et c’est une minorité — mais c’est la seule couche que la proposition initiale envisageait.

Cet article traite de cette recherche et de ces réparations : distinguer un défaut de dessin d’un défaut de vitesse, dresser la liste des blocages en regardant plutôt qu’en supposant, classer les corrections par coût, et savoir mesurer quand on est trop petit pour mesurer.

L’article qui l’accompagne traite de la conception elle-même — la tâche comme critère, le pouce, la taille des cibles, l’arabe qui n’est pas du français retourné, les états que personne ne dessine. Il vaut mieux l’avoir lu : il dit comment on fait une interface, celui-ci dit quoi faire de celle que vous avez.

Le diagnostic ne se fait ni en réunion ni sur des statistiques. Il se fait en regardant cinq personnes essayer d’accomplir une tâche précise sur l’interface telle qu’elle est, et en notant l’endroit exact où chacune s’arrête, hésite ou demande de l’aide.

La méthode est décrite dans l’article qui accompagne celui-ci et il ne faut pas la refaire ici. Ce qui compte pour la réparation est la sortie : une liste d’endroits, pas une liste d’impressions. « La page d’accueil est confuse » n’est pas un blocage ; « quatre personnes sur cinq ont cherché le prix dans la description avant de trouver le bouton » en est un.

Notez chaque blocage avec trois informations : où il se produit, combien de personnes sur cinq y ont buté, et ce qu’elles cherchaient à ce moment-là. La troisième est celle qu’on oublie et c’est elle qui indique la correction — un blocage est toujours l’écart entre ce que la personne cherchait et ce que l’écran offrait.

Une remarque sur le nombre : cinq personnes ne donnent pas une statistique et ne prétendent pas en donner une. Elles donnent une liste d’endroits, et une liste d’endroits est exactement ce qu’il faut pour réparer. La statistique viendrait après, et la section 7 explique pourquoi elle ne viendra pas.

Terminez en éliminant les blocages qui n’en sont pas. Une personne qui hésite deux secondes et trouve n’a rien signalé ; une personne qui commente à voix haute qu’elle « n’aime pas la couleur » n’a rien signalé non plus. Ce qui compte est un arrêt, pas une opinion.

La deuxième couche ne crée rien et ne supprime rien : elle déplace. Remonter un élément au-dessus du pli, séparer deux blocs qui se lisaient comme un seul, rapprocher un libellé de son champ, retirer trois choses d’un écran qui en portait onze.

Le retrait est l’opération la plus efficace de cette couche et la plus difficile à faire accepter, parce que chaque élément a été ajouté par quelqu’un pour une raison. La question à poser n’est pas « est-ce utile » — presque tout l’est un peu — mais « est-ce utile à la tâche que cette page sert ».

La proximité est la deuxième opération, et elle règle une famille entière de blocages sans que personne comprenne pourquoi. Deux éléments proches sont lus comme liés et deux éléments éloignés comme indépendants, quelle que soit la logique du contenu. Un prix loin de son produit est un prix qui appartient à autre chose.

L’ordre est la troisième, et il n’a qu’une règle utile ici : ce que la personne cherche en premier vient en premier. Cela paraît évident et c’est presque toujours violé, parce que l’ordre d’une page reflète en général l’ordre dans lequel l’entreprise pense à ses sujets, pas l’ordre dans lequel le visiteur se pose ses questions.

Une réparation a un effet local voulu et des effets à distance qu’on ne cherche pas. C’est la principale raison de corriger par petits lots plutôt qu’en une fois : un lot de trois corrections dont une casse quelque chose se diagnostique, un lot de trente ne se diagnostique pas.

Trois effets à distance reviennent régulièrement. Élargir un élément pour le rendre visible en pousse un autre sous le pli. Raccourcir un libellé en français le laisse correct et casse la mise en page en arabe, où le même mot est plus long ou plus court. Et retirer un élément jugé inutile supprime le seul chemin qu’une partie des gens empruntait.

Le cas de l’arabe mérite d’être isolé parce qu’il est systématique sur ce site comme sur ceux de nos clients : toute correction de mots ou d’espacement doit être vue dans les trois langues avant d’être déployée. Une correction validée dans une seule langue est une correction validée sur un tiers de vos visiteurs.

Gardez enfin une trace : une ligne par correction, la date, ce qui a été changé, et le blocage qu’elle visait. C’est ce qui permet de revenir en arrière avec précision quand un effet inattendu apparaît trois jours plus tard, et c’est aussi ce qui empêche de corriger deux fois la même chose dans deux directions opposées.

Ce que nous faisons est délimité. Nous écartons d’abord la vitesse, nous menons l’observation à cinq personnes, nous en tirons une liste de blocages localisés, nous classons les corrections par couche, et nous corrigeons de la moins profonde vers la plus profonde en remesurant entre les deux.

Nous refusons de prendre un cahier des charges de refonte avant que la couche des mots ait été essayée. C’est un refus qui réduit ce que nous facturons, et il tient parce que le contraire est vérifiable : dans la plupart des cas, une semaine de réécriture retire de la liste la moitié de ce qui justifiait la refonte.

Nous refusons aussi d’annoncer un pourcentage d’amélioration sur un trafic qui ne peut pas en produire un. Ce que nous rapportons à cette taille est le nombre de personnes qui butaient au même endroit avant et après, et c’est une mesure moins flatteuse et plus vraie.

Et nous ne déployons pas une correction validée dans une seule langue, parce qu’une mise en page qui tient en français peut casser en arabe sur le même mot. Il y a par ailleurs un travail que vous pouvez mener sans nous et qui vaut la moitié de tout ceci : regarder cinq personnes utiliser votre interface, sans les aider, et noter où elles s’arrêtent.