Afficher l’état « en traitement » immédiatement après l’action des utilisateurs

Publié le 23 novembre 2023

Cet article fait partie d’une série sur les micro-interactions avec les interfaces utilisateur et la manière dont elles affectent l’expérience utilisateur.

This article is also available in English.

« Ai-je cliqué sur le bouton ? Ma demande est-elle prise en compte par le système ? »

C’est le genre de questions que de nombreux utilisateurs pourraient se poser si l’interface ne réagit pas immédiatement après avoir interagit avec un composant.

Plusieurs chercheurs se sont penchés sur quel était le délai acceptable avant qu’une réaction ne soit pas perçue comme instantanée. Dans son article intitulé Response Times: The 3 Important Limits (traduction : « les délais de réaction : trois limites importantes »), Jakob Nielsen offre un bon aperçu :

• 0,1 seconde est à peu près la limite pour que l’utilisateur ait l’impression que le système réagit instantanément, ce qui signifie qu’aucun retour d’information particulier n’est nécessaire, si ce n’est l’affichage du résultat.
• 1,0 seconde est à peu près la limite pour que le fil de pensée de l’utilisateur reste ininterrompu, même si l’utilisateur remarque le délai. Normalement, aucun retour d’information particulier n’est nécessaire pendant les délais supérieurs à 0,1 mais inférieurs à 1,0 seconde, mais l’utilisateur perd la sensation d’opérer directement sur les données.
• Un délai de 10 secondes est à peu près la limite pour garder l‘attention de l’utilisateur concentrée sur le dialogue. Pour les délais plus longs, les utilisateurs voudront effectuer d’autres tâches en attendant que l’ordinateur ait terminé, et il faudra donc leur donner un retour d’information indiquant le moment où l’ordinateur s’attend à avoir terminé. Le retour d’information pendant le délai est particulièrement important si le temps de réponse est susceptible d’être très variable, car les utilisateurs ne sauront alors pas à quoi s’attendre.

Dans des contextes autres que l’interaction homme-machine (IHM), ces valeurs peuvent changer. Par exemple, les musiciens peuvent percevoir des délais de seulement 5 millisecondes !

Afin d’éviter toute confusion pour les utilisateurs quant au succès ou à l’échec de leur interaction avec l’interface, il vaut mieux toujours afficher l’état « en traitement » immédiatement après que les utilisateurs aient interagi avec un composant qui doit attendre la fin d’un événement. Pas après que le back-end ait reconnu avoir été contacté, immédiatement après l’interaction.

Illustrons ce design par quelques exemples.

Exemple : séquence non idéale pour mettre à jour l’interface après l’action des utilisateurs

Ce modèle de conception est devenu populaire, ou du moins plus visible, depuis l’apparition des environnements de développement JavaScript réactifs (reactive front-end JavaScript frameworks) au cours des quinze dernières années. Le modèle de conception que les développeurs suivent avec ces frameworks tend à lier directement chaque interaction avec un élément d’interface à une mise à jour immédiate de la base de données.

Par exemple, dans un formulaire, au lieu d’attendre que les utilisateurs cliquent sur un bouton « soumettre », chaque fois qu’un utilisateur finit de mettre à jour un champ de saisie, les valeurs sont envoyées directement à la base de données par l’intermédiaire d’un appel à des services back-end. Il s’agit évidemment d’une simplification, mais elle explique le modèle de conception.

Dans de tels cas, les développeurs mettent rarement à jour le front-end pour informer les utilisateurs qu’un processus est en cours, le plus souvent parce qu’ils pensent que ces petites mises à jour sont immédiates.

Cependant, comme l’illustrent les recherches mentionnées plus haut, l’immédiateté est une période très courte et, à moins de pouvoir garantir un délai inférieur à 100 millisecondes, nous sommes susceptibles de concevoir des systèmes dans lesquels les interfaces ne communiquent pas aux utilisateurs que leur interaction a été prise en compte, parce que des développeurs on choisi d’attendre que le back-end ait été contacté. Ce n’est pas l’idéal comme expérience.

Exemple : séquence idéale pour mettre à jour l’interface après l’action des utilisateurs

Au lieu d’attendre que le back-end reconnaisse que les utilisateurs aient interagi avec l’interface, tout élément qui attend la fin du processus de ce système devrait être placé dans l’état « en traitement » immédiatement après que les utilisateurs aient interagit.

Dans la série d’événements illustrée ci-dessus, les utilisateurs cliqueraient sur le bouton « soumettre », qui les informerait immédiatement que leur action a été prise en compte. Pas de délai, pas de période de doute pour l’utilisateur.

En plus, dans le cas d’un formulaire comportant plusieurs champs, il pourrait être idéal de désactiver les champs du formulaire durant la période de traitement, ce qui renforcerait l’assurance donnée aux utilisateurs que leurs données sont en cours de traitement. Par contre, il vaut mieux examiner ce type de design au cas par cas, puisque le besoin pourrait changer dépendant du composant ou du besoin des utilisateurs.

Références et lectures additionnelles

Articles

Defining “Instantaneous” as part of usability acceptance criteria | User Experience – StackExchange

Designing Better Loading and Progress Indicators UX | Vitaly Friedman – LinkedIn

Designing Fluid Interfaces | Apple

Powers of 10: Time Scales in User Experience | Jakob Nielsen – Nielsen Norman Group

Response Times: The 3 Important Limits | Jakob Nielsen – Nielsen Norman Group

What is the shortest perceivable application response delay? | Stackoverflow

What is the threshold where actions are perceived as “instant”? | Psychology & Neuroscience – StackExchange

Recherche

Behavioral and emotional consequences of brief delays in human–computer interaction | Szameitat, A. et al. – Elsevier

Delays in Human-Computer Interaction and Their Effects on Brain Activity | Korhs et al. – Pub Med

Delays and user performance in human-computer-network interaction tasks | Caldwell, B. and Wang E. – Pub Med

Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI’91 Conf. (New Orleans, LA, 28 April-2 May), 181-188.

Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277.

Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI’85 Conf. (San Francisco, CA, 14-18 April), 11-17.

Mis à jour le 26 janvier 2024