Vouloir économiser à tout prix le nombre de clics sur une interface n’est pas toujours une bonne idée. C’est même souvent un faux problème.

Récemment, pour argumenter ce propos auprès d’un collègue, je prenais l’exemple des tracés d’itinéraires sur les sites de cartographie en ligne. (Au passage, savez-vous qu’OpenStreetMap offre désormais la fonction itinéraire ?)

Or donc, pour aller d’un point à un autre, votre site de cartographie propose très certainement plusieurs options :

  • le trajet le plus rapide (en temps) ;
  • le trajet le plus court (en kilomètres) ;
  • le type de transport (à pied, en vélo, en voiture) ;
  • le type de voie à emprunter/éviter (autoroute, route, chemin…) ;
  • le prix de revient (péages, carburant…) ;
  • la possibilité de modifier délibérément le trajet.

Avec ces options, c’est vous qui décidez quel trajet sera le plus pertinent selon vos critères (prendre la rocade sera plus long en kilométrage mais plus court en temps).

Pour une interface web (prenons l’exemple d’un formulaire assez conséquent à remplir, ou d’une série d’actions complexes), c’est le même propos : il s’agit d’effectuer un trajet d’un point A à un point B. La différence est que vous n’avez la plupart du temps aucune option à choisir et que le trajet vous est imposé par le concepteur web.

Et souvent, ce concepteur fait le choix du trajet le plus court, où les kilomètres sont transformés en nombre de clics.

Malheureusement, ce trajet ne sera pas forcément le plus rapide en temps, en voie empruntée ou en prix de revient. L’utilisateur devra peut-être fournir davantage d’énergie mentale (charge cognitive) pour comprendre l’interface si l’information a été condensée (pour économiser du clic). Cela ralentira sa progression (temps), et le trajet sera peut-être plus difficile (type de voie).

L’interface propose un voyage. À nous, concepteurs, de le rendre le plus agréable et léger possible en choisissant un trajet approprié dont la qualité ne se résume pas uniquement à un nombre de kilomètres/clics.