Le fait de forcer le temps de réponse au temps moyen au minimum améliorera-t-il l'UX?
J'ai une situation où mon temps de réponse aux appels Ajax peut varier de 14 ms à 600 ms, en raison de la complexité d'une requête qu'ils peuvent effectuer.
D'après mon expérience, les utilisateurs tiennent pour acquis ces allers-retours de 20 à 80 ms et s'attendent à avoir la même vitesse tout le temps et partout, en réalité dans mon projet particulier, c'est impossible.
J'ai donc eu l'idée que je pouvais forcer les utilisateurs à toujours attendre au moins x temps avant d'obtenir des résultats.
La question est: Dois-je utiliser une moyenne de mes propres données de réponses aller-retour déjà collectées ou dois-je simplement utiliser un temps de réponse autorisé le plus élevé convenu publiquement pour une action Utilisateurs?
D'après ce dont je me souviens, c'était entre 100 et 200 ms, je ne me souviens plus maintenant.
Vous ne devez pas retarder artificiellement le temps qu'un utilisateur doit attendre. Ne punissez pas une réponse rapide en les ralentissant à une "moyenne". Laissez toutes les requêtes se terminer naturellement, pour des durées de requête plus longues, vous pouvez envisager les éléments suivants ...
Jakob Nielson a fait des recherches sur les temps d'attente en 1993. De " Temps de réponse: les 3 limites importantes " -
(1) 0,1 seconde correspond à la limite permettant à l'utilisateur de sentir que le système réagit instantanément, ce qui signifie qu'aucune rétroaction spéciale n'est nécessaire, sauf pour afficher le résultat.
(2) 1,0 seconde correspond à la limite pour que le flux de pensée de l'utilisateur reste ininterrompu, même si l'utilisateur remarquera le retard. Normalement, aucune rétroaction spéciale n'est nécessaire pendant les retards supérieurs à 0,1 mais inférieurs à 1,0 seconde, mais l'utilisateur perd la sensation de fonctionner directement sur les données.
(3) 10 secondes est à peu près la limite pour maintenir l'attention de l'utilisateur concentrée sur le dialogue. Pour des délais plus longs, les utilisateurs voudront effectuer d'autres tâches en attendant la fin de l'ordinateur, donc ils devraient recevoir des commentaires indiquant quand l'ordinateur s'attend à ce que cela soit fait.
Ces chiffres montreraient que votre temps d'attente moyen prévu (100-200 ms) ne nécessiterait généralement aucun retour d'information supplémentaire pour l'utilisateur afin qu'il puisse le percevoir comme "instantané". Même avec des temps d'attente allant jusqu'à 1,0 seconde, aucune rétroaction spéciale n'était normalement requise, même si l'utilisateur peut "perdre un peu l'impression d'opérer directement sur les données".
Il est important de noter que l'étude et les temps ci-dessus ne sont pas non associés à des interactions sur le web ! Ces chiffres représentent les temps d'attente bruts pour l'engagement des utilisateurs. Ne tombez pas dans le piège "ces données sont si anciennes, le web était si jeune"! Ce qui précède n'est pas "sur le Web", il s'agit de "combien de temps un utilisateur attendra-t-il pour se désengager" d'une tâche.
Qu'est-ce que ça veut dire? Au pire, cela signifie prendre les chiffres tels qu'ils sont (les utilisateurs Web s'attendent à une réponse de plus en plus rapide de nos jours). Au mieux, cela signifie que vous avez un peu d'espace supplémentaire, car les utilisateurs vous donneront un peu d'espace supplémentaire sur le Web.
En fait, Nielson n'arrêtait pas de poser des questions sur "qu'en est-il sur le Web" et a légèrement mis à jour la réponse en 2014:
0,1 seconde: limite pour les utilisateurs ayant le sentiment qu'ils manipulent directement des objets dans l'interface utilisateur. Par exemple, il s'agit de la limite entre le moment où l'utilisateur sélectionne une colonne dans un tableau jusqu'à ce que cette colonne soit mise en surbrillance ou indique autrement qu'elle est sélectionnée. Idéalement, ce serait également le temps de réponse pour trier la colonne - si tel est le cas, les utilisateurs sentiront qu'ils trient la table. (Par opposition au sentiment qu'ils ordonnent à l'ordinateur de faire le tri pour eux.)
1 seconde: limite pour les utilisateurs se sentant qu'ils naviguent librement dans l'espace de commande sans avoir à attendre indûment l'ordinateur. Un délai de 0,2 à 1,0 seconde signifie que les utilisateurs remarquent le délai et sentent donc que l'ordinateur "travaille" sur la commande, par opposition à ce que la commande soit un effet direct des actions des utilisateurs. Exemple: si le tri d'un tableau en fonction de la colonne sélectionnée ne peut pas être effectué en 0,1 seconde, il doit certainement être effectué en 1 seconde, ou les utilisateurs auront le sentiment que l'interface utilisateur est lente et perdra le sens du "flux" en effectuant leur tâche. Pour les retards de plus d'une seconde, indiquez à l'utilisateur que l'ordinateur travaille sur le problème, par exemple en changeant la forme du curseur.
10 secondes: limite pour les utilisateurs gardant leur attention sur la tâche. Tout ce qui est plus lent que 10 secondes nécessite un indicateur de pourcentage terminé ainsi qu'un moyen clairement indiqué pour l'utilisateur d'interrompre l'opération. Supposons que les utilisateurs devront se réorienter lorsqu'ils reviendront dans l'interface utilisateur après un délai de plus de 10 secondes. Les retards de plus de 10 secondes ne sont acceptables que pendant les pauses naturelles dans le travail de l'utilisateur, par exemple lors des changements de tâches.
Pourtant, avec vos moyennes attendues, un utilisateur sentira qu'il "manipule directement" les données ou remarquera le retard mais n'a pas nécessairement besoin d'être informé car il "sent que l'ordinateur" travaille "sur la commande". Ce n'est que si vos requêtes prennent le relais (ou se rapprochent régulièrement de 1,0 seconde) qu'une notification sera nécessaire.
Mais ce n'est peut-être pas toute l'histoire. Un article de NYTimes, " Pour les utilisateurs Web impatients, un œil clignote trop longtemps pour attendre " a discuté du travail effectué par Google et Microsoft sur la durée pendant laquelle les utilisateurs sont prêts à attendre une page quand "comme des services " sont disponibles.
De l'article:
Les gens visiteront un site Web moins souvent s'il est plus lent qu'un concurrent proche de plus de 250 millisecondes (une milliseconde est un millième de seconde).
Cela ne vous dit pas d'inclure une notification ou non, mais souligne l'importance des temps de réponse pour les utilisateurs! Si vous gonflez artificiellement les temps d'attente, vous pousserez potentiellement les utilisateurs vers un concurrent!
Il y a plus de 30 ans, j'étais ce que nous appelions à l'époque un programmeur système, s'occupant d'un réseau de mini-ordinateurs avec quelques dizaines d'utilisateurs. À cette époque, les affichages étaient essentiellement 80x25 "texte seulement".
Lorsque nous avons mis à niveau les liens de communication entre le mini-ordinateur et les écrans, plusieurs utilisateurs ont commencé à se plaindre que le système était plus lent , même si nous savions que rien n'avait changé au serveur, et les liens eux-mêmes étaient en réalité plusieurs fois plus rapides . Nous savions également qu'en cas de faible charge du système, les liaisons de communication d'origine étaient souvent le principal goulot d'étranglement.
Il s'est avéré que le lien plus rapide provoquait l'arrivée et l'affichage de chaque "paquet" de données d'affichage (512 octets, soit moins d'un écran de 2 Ko) bien avant l'arrivée du prochain paquet. Même si le débit total était en fait plus rapide, ces pauses visibles ont donné aux utilisateurs l'impression qu'il était plus lent. À court terme, nous avons reconfiguré la vitesse de liaison de communication plus lente d'origine pour tous les utilisateurs qui se plaignaient, jusqu'à ce que nous puissions ajouter de la mémoire à l'extrémité du serveur (extrêmement coûteuse à l'époque) nous permettant d'augmenter la taille du paquet de liaison.
Je sais que cela ne reflète pas exactement les circonstances de l'OP, mais je pense que cela fait partie d'un principe général selon lequel les perceptions des utilisateurs de la "réactivité" sont toujours "relatives". ". Nos utilisateurs ne se souciaient pas qu'un écran prenne 6 secondes pour s'afficher lorsqu'il se remplissait à une vitesse constante, mais ils n'aimaient pas voir 4 "morceaux" affichés instantanément à des intervalles de 1 seconde.
De même, je pense que si certaines requêtes produisent des réponses "instantanées", les utilisateurs sont plus susceptibles de classer ( toutes d'autres requêtes comme "lentes", car elles se compareront à la chose la plus rapide ils voient, pas la moyenne . Il est probablement pertinent de noter que je suppose que la plupart des utilisateurs n'auront pas une grande idée des requêtes qu'ils pourraient s'attendre à ce que soit plus rapide ou plus lent (s'ils fait, cela pourrait changer les choses).
J'aime la réponse acceptée et je conviens que vous ne devez rien retarder artificiellement.
Cependant, compte tenu de vos temps d'attente prévus, je ferais ce que vous pouvez pour améliorer les performances perçues. Par exemple, afficher un spinner pendant le chargement des résultats aide. Mais selon cette étude , il est optimal d'attendre 0,4 seconde avant de montrer le spinner.
Il y a une autre technique que j'aime parfois. Si le fait de cliquer sur un lien ou un bouton aboutit finalement à afficher une nouvelle page ou interface, alors allez-y et amenez immédiatement l'utilisateur sur cette page pendant le chargement des données en arrière-plan. De cette façon, l'utilisateur voit quelque chose se produire immédiatement, puis peut-être que les données remplissent la nouvelle interface une demi-seconde plus tard.
En général, chaque fois que vous pouvez créer un retour visuel instantané contribuera à améliorer la perception de la vitesse et de la réactivité.
Il existe des recherches suggérant que, au moins pour certains types d'applications (jeux de stratégie en temps réel, pour être exact), les utilisateurs peuvent trouver un temps de réponse lent mais cohérent préférable à un temps variant de manière imprévisible.
Plus précisément, permettez-moi de citer l'article "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond" par Mark Terrano et Paul Bettner ( accentuation le mien):
"Pour les jeux RTS, 250 millisecondes de latence de commande n'ont même pas été remarquées - entre 250 et 500 msec était très jouable, et au-delà de 500, cela a commencé à être perceptible. Il était également intéressant de noter que les joueurs ont développé un" rythme de jeu "et un l'attente mentale du décalage entre le moment où ils ont cliqué et le moment où leur unité a répondu. Une réponse plus lente cohérente était meilleure que l'alternance entre une latence de commande rapide et lente (disons entre 80 et 500 msec) - dans ce cas, une latence de commande cohérente de 500 msec était jouable, mais celle qui variait était considérée comme "saccadée" et difficile à utiliser.
En termes réels, cela a dirigé beaucoup d'efforts de programmation vers la fluidité - il valait mieux choisir une longueur de virage plus longue et être certain que tout restait fluide et cohérent plutôt que de fonctionner aussi rapidement que possible avec des ralentissements occasionnels. Toute modification de la vitesse devait être graduelle et le plus petit possible. "
Bien que cet effet puisse être particulièrement perceptible dans les jeux, je ne vois aucune raison de supposer qu'il ne pourrait pas se produire également dans d'autres applications. En effet, il semble bien correspondre à anecdote du mini-ordinateur de FumbleFingers , ce qui suggère qu'il pourrait bien y avoir un effet plus général en jeu ici.
Un cas où il peut être avantageux d'ajouter un délai est celui où l'utilisateur peut ne pas réaliser autrement que quelque chose a changé. Je l'ai déjà implémenté sur un site - nous avons déjà les résultats de la requête prêts, mais si nous le modifions sans délai, l'utilisateur ne se rendra probablement pas compte qu'un changement s'est produit. Nous ajoutons donc un faux délai avec une brève animation de "chargement".
Bien que le délai dans ce cas devrait être très faible - juste assez pour que le cerveau de l'utilisateur pense "oh quelque chose change!", Et à la fin de cette réalisation, le contenu a changé.
Bien que je sois entièrement d'accord avec la réponse acceptée, et qu'il est déjà tard, j'aimerais offrir une autre perspective, en se concentrant plutôt sur le "temps d'attente perçu" (c'est-à-dire le problème de comportement), au lieu du "temps d'attente réel" (c'est-à-dire le problème d'ingénierie) ).
Cet article Signal vs bruit a cité l'exemple classique de la gestion de la perception du temps d'attente. Le simple fait d'ajouter un miroir dans l'ascenseur a complètement supprimé le nombre énorme de plaintes des gens concernant la lenteur de l'ascenseur. Les miroirs aidaient ceux qui attendaient à se regarder ou à se regarder, réduisant ainsi l'ennui associé à l'attente.
Le livre de Steven Seow Designing and Engineering Time: The Psychology of Time Perception in Software a fourni de nombreuses informations très intéressantes sur la psychologie de l'attente et comment gérer la perception de l'attente par les utilisateurs.
Cet article récemment publié a cité plusieurs de ces idées. En particulier, les plus pertinentes pour votre question sont:
Règle 1: Ne laissez jamais vos utilisateurs regarder la soupe bouillir: Recherchez les endroits où vos utilisateurs attendent et tentez de remplir ce moment avec quelque chose de significatif.
Règle 3: Assurer la transparence tout au long du processus: S'assurer qu'ils savent combien de temps l'attente se fera en utilisant des systèmes de numérotation ou des systèmes pour leur faire savoir où ils se trouvent le processus.
- Règle 4: Fixez des objectifs que vous pouvez atteindre ou battre: Sous-promettez et sur-livrez pour réduire les attentes, puis les dépasser. Les restaurants sont réputés pour avoir légèrement surestimé le temps d'attente. Ils le font afin d'être sûrs qu'ils respecteront leur estimation ou même de la battre.
- Règle 5: Concevez soigneusement le début et la fin du processus: Évaluez ce que votre utilisateur voit ou ressent lorsqu'il rencontre votre produit, service ou interface pour le première fois et comment l'expérience se termine pour eux. Les souvenirs des événements sont fortement façonnés par le début et la fin de l'événement.
Donc, en répondant directement à votre question: Est-ce que forcer le temps de réponse au temps moyen au minimum améliorera l'UX?, je dirais que non. Le forcer n'améliorera pas l'UX.
Cependant, en appliquant la règle 4, vous pourriez éventuellement donner aux utilisateurs un nombre surestimé, puis fournir les résultats avant cela. En le combinant avec d'autres règles, et vos utilisateurs se sentiront peut-être même heureux d'attendre. :)