Les vrais mensonges des interfaces utilisateur optimistes

Trois interfaces utilisateur (UI) vont dans un pub. Le premier commande un verre, puis plusieurs autres. Quelques heures plus tard, il demande l'addition et quitte le pub ivre. La deuxième UI commande une boisson, la paie d'avance, commande une autre boisson, la paie et ainsi de suite, et en quelques heures quitte le pub ivre. La troisième interface utilisateur sort du pub déjà ivre immédiatement après y être entrée – elle sait comment fonctionnent les pubs et est suffisamment efficace pour ne pas perdre de temps. Avez-vous entendu parler de ce troisième ? C'est ce qu'on appelle une «interface utilisateur optimiste».

Récemment, après avoir discuté de l'optimisation des performances psychologiques lors de plusieurs conférences consacrées à la fois au développement front-end et à l'expérience utilisateur, j'ai été surpris de voir à quel point le sujet de la conception d'interface utilisateur optimiste est peu abordé dans la communauté. Franchement, le terme lui-même n'est même pas bien défini. Dans cet article, nous découvrirons sur quels concepts il est basé, et nous examinerons quelques exemples ainsi que son arrière-plan psychologique. Après cela, nous passerons en revue les préoccupations et les principaux points concernant la façon de garder le contrôle sur cette technique UX.

Lectures complémentaires sur SmashingMag :

• L'utilisateur est le concepteur Web anonyme
• Conception d'interfaces utilisateur basées sur des cartes
• Interfaces conversationnelles : où en sommes-nous aujourd'hui ?
  

Mais avant de commencer, à vrai dire, rien ne peut être qualifié d '«interface utilisateur optimiste». C'est plutôt le modèle mental derrière la mise en œuvre d'une interface. La conception optimiste de l'interface utilisateur a sa propre histoire et sa propre justification.

Il était une fois

Il y a longtemps — quand le mot « tweet » s'appliquait surtout aux oiseaux, Apple était au bord de la faillite et les gens mettaient encore des numéros de fax sur leurs cartes de visite — les interfaces web étaient assez ascétiques. Et la grande majorité d'entre eux n'avaient même pas une once d'optimisme. Une interaction avec un bouton, par exemple, pourrait suivre un scénario similaire au suivant :

1. L'utilisateur clique sur un bouton.
2. Le bouton est déclenché dans un état désactivé.
3. Un appel est envoyé à un serveur.
4. Une réponse du serveur est renvoyée à la page.
5. La page est rechargée pour refléter l'état de la réponse.

Cela pourrait sembler assez inefficace en 2016 ; Cependant, de manière assez surprenante, le même scénario est toujours utilisé dans de nombreuses pages Web et applications et fait toujours partie du processus d'interaction pour de nombreux produits. La raison en est qu'elle est prévisible et plus ou moins à l'épreuve des erreurs : l'utilisateur sait que l'action a été demandée au serveur (l'état désactivé du bouton le laisse entendre), et une fois que le serveur a répondu, la page mise à jour indique clairement la fin de cette interaction client-serveur-client. Les problèmes avec ce type d'interaction sont assez évidents :

• L'utilisateur doit attendre. À présent, nous savons que même le plus court délai dans le temps de réponse du serveur a un effet négatif sur la perception de l'utilisateur sur l'ensemble de la marque, et pas seulement sur cette page particulière.
• Chaque fois que l'utilisateur reçoit une réponse à son action, celle-ci est présentée de manière assez destructrice (une nouvelle page se charge, au lieu de mettre à jour la page existante), ce qui rompt le contexte de la tâche de l'utilisateur et peut affecter son cheminement de pensée. Même si on ne parle pas forcément de multitâche dans ce cas, tout changement de contexte mental est désagréable. Ainsi, si une action n'est pas intrinsèquement destinée à changer de contexte (le paiement en ligne est un bon exemple de cas où un changement est naturel), le changement créerait un ton de dialogue hostile entre l'utilisateur et le système.

Les bons jours pas si vieux

Ensuite, le soi-disant Web 2.0 est arrivé et a fourni de nouveaux modes d'interaction avec les pages Web. Le noyau de ceux-ci était XMLHttpRequest et AJAX. Ces nouveaux modes d'interaction ont été complétés par des "spinners": la forme la plus simple d'indicateur de progression, dont le seul but était de communiquer à l'utilisateur que le système est occupé à effectuer une opération. Maintenant, nous n'avons pas eu besoin de recharger la page après avoir reçu une réponse du serveur ; nous pourrions simplement mettre à jour une partie de la page déjà rendue à la place. Cela a rendu le Web beaucoup plus dynamique, tout en permettant des expériences plus fluides et plus engageantes pour les utilisateurs. L'interaction typique avec un bouton pourrait maintenant ressembler à ceci :

1. L'utilisateur clique sur un bouton.
2. Le bouton est déclenché dans un état désactivé, et un spinner quelconque est affiché sur le bouton pour indiquer que le système fonctionne.
3. Un appel est envoyé au serveur.
4. Une réponse du serveur est renvoyée à la page.
5. L'état visuel du bouton et de la page sont mis à jour en fonction de l'état de la réponse.

Ce nouveau modèle d'interaction a résolu l'un des problèmes susmentionnés de l'ancienne méthode d'interaction : la mise à jour de la page se produit sans action destructrice, en gardant le contexte pour l'utilisateur et en l'engageant dans l'interaction bien mieux qu'auparavant.

Ce type de modèle d'interaction a été largement utilisé partout dans les médias numériques. Mais un problème demeure : les utilisateurs doivent encore attendre une réponse du serveur. Oui, nous pouvons faire en sorte que nos serveurs répondent plus rapidement, mais peu importe à quel point nous essayons d'accélérer l'infrastructure, les utilisateurs doivent encore attendre. Encore une fois, les utilisateurs n'aiment pas attendre, c'est un euphémisme. Par exemple, des recherches montrent que 78 % des consommateurs ressentent des émotions négatives à la suite de sites Web lents ou peu fiables. De plus, selon une enquête menée par Harris Interactive pour Tealeaf, 23 % des utilisateurs avouent avoir insulté leur téléphone, 11 % leur ont crié dessus et 4 % ont en fait jeté leur téléphone lorsqu'ils ont rencontré un problème avec une transaction en ligne. Les retards font partie de ces problèmes.

Même si vous affichez une sorte d'indicateur de progression pendant que l'utilisateur attend, à moins que vous ne soyez très créatif avec l'indicateur, de nos jours, cela ne suffit tout simplement pas. Pour la plupart, les gens se sont habitués aux spinners indiquant la lenteur d'un système. Les spinners sont désormais davantage associés à une attente purement passive, lorsque l'utilisateur n'a d'autre choix que d'attendre la réponse du serveur ou de fermer complètement l'onglet ou l'application. Alors, proposons une étape pour améliorer ce type d'interaction ; regardons ce concept d'une interface utilisateur optimiste.

Interface utilisateur optimiste

Comme mentionné, une interface utilisateur optimiste n'est rien de plus qu'un moyen de gérer l'interaction homme-ordinateur. Pour comprendre les idées principales derrière cela, nous nous en tiendrons à notre scénario "l'utilisateur clique sur un bouton". Mais le principe sera le même pour à peu près n'importe quel type d'interaction que vous voudrez peut-être rendre optimiste. Selon le dictionnaire anglais Oxford :

op-ti-mis-tic , adj. plein d'espoir et confiant en l'avenir.

Commençons par la partie « confiant dans l'avenir ».

Qu'en pensez-vous : à quelle fréquence votre serveur renvoie-t-il une erreur sur une action de l'utilisateur ? Par exemple, votre API échoue-t-elle souvent lorsque les utilisateurs cliquent sur un bouton ? Ou peut-être échoue-t-il souvent lorsque les utilisateurs cliquent sur un lien ? Franchement, je ne pense pas. Bien sûr, cela peut varier en fonction de l'API, de la charge du serveur, du niveau de gestion des erreurs et d'autres facteurs que vous, en tant que développeur front-end ou spécialiste UX, pourriez ne pas vouloir impliquer. Mais tant que l'API est stable et prévisible et que le frontal communique correctement les actions légitimes dans l'interface utilisateur, le nombre d'erreurs en réponse aux actions initiées par l'utilisateur sera assez faible. J'irais jusqu'à dire qu'il ne faut jamais dépasser 1 à 3 %. Cela signifie que dans 97 à 99 % des cas, lorsque l'utilisateur clique sur un bouton sur un site Web, la réponse du serveur devrait être un succès, sans erreur. Cela mérite d'être mieux relativisé :

Pensez-y un instant : si nous étions sûrs à 97 à 99 % d'une réponse réussie, nous pourrions être confiants quant à l'avenir de ces réponses - enfin, au moins beaucoup plus confiants quant à l'avenir que ne l'était le chat de Schrödinger. Nous pourrions écrire une toute nouvelle histoire sur l'interaction des boutons :

1. L'utilisateur clique sur un bouton.
2. L'état visuel du bouton est déclenché instantanément en mode succès.

C'est ça! Du moins du point de vue de l'utilisateur, il n'y a rien de plus - pas d'attente, pas de regard sur un bouton désactivé, et pas encore un autre spinner ennuyeux. L'interaction est transparente, sans que le système n'intervienne grossièrement pour rappeler à l'utilisateur ce qu'il est.

Du point de vue du développeur, le cycle complet ressemble à ceci :

1. L'utilisateur clique sur un bouton.
2. L'état visuel du bouton est déclenché instantanément en mode succès.
3. L'appel est envoyé au serveur.
4. La réponse du serveur est renvoyée à la page.
5. Dans 97 à 99% des cas, nous savons que la réponse sera un succès, et nous n'avons donc pas besoin de déranger l'utilisateur.
6. Ce n'est qu'en cas d'échec de la demande que le système prendra la parole. Ne vous en souciez pas pour l'instant - nous y reviendrons plus tard dans l'article.

Regardons quelques exemples d'interactions optimistes. Vous connaissez probablement les boutons "J'aime", comme on en trouve sur Facebook et Twitter. Jetons un coup d'œil à ce dernier.

Cela commence, évidemment, avec le clic du bouton. Mais notez l'état visuel du bouton lorsque l'utilisateur n'appuie plus ou ne survole plus le bouton. Il passe instantanément à l'état de réussite !

Voyons ce qui se passe dans l'onglet "Réseau" des outils de développement de notre navigateur en ce moment même.

L'onglet "Réseau" indique que la requête du serveur a été envoyée mais est toujours en cours. Le nombre de compteurs "likes" n'a pas encore été incrémenté, mais avec le changement de couleur, l'interface communique clairement le succès à l'utilisateur, avant même d'avoir obtenu une réponse du serveur.

Une fois qu'une réponse réussie est reçue du serveur, le compteur est mis à jour, mais la transition est beaucoup plus subtile que le changement de couleur instantané. Cela offre à l'utilisateur une expérience fluide et ininterrompue, sans aucune attente perçue.

Un autre exemple d'interaction optimiste est vu sur Facebook, avec son propre bouton "J'aime". Le scénario est assez similaire, sauf que Facebook met à jour le compteur instantanément, ainsi que la couleur de succès du bouton, sans attendre la réponse du serveur.

Une chose à noter ici, cependant. Si on regarde le temps de réponse du serveur, on s'aperçoit qu'il est d'un peu plus d' 1 seconde . Considérant que le modèle RAIL recommande 100 millisecondes comme temps de réponse optimal pour une simple interaction, ce serait normalement beaucoup trop long. Cependant, l'utilisateur ne perçoit aucun temps d'attente dans ce cas en raison de la nature optimiste de cette interaction. Agréable! Ceci est un autre exemple d'optimisation des performances psychologiques .

Mais avouons-le : il y a toujours 1 à 3 % de chances que le serveur renvoie une erreur. Ou peut-être que l'utilisateur est simplement hors ligne. Ou, plus probablement, peut-être que le serveur renvoie ce qui est techniquement une réponse de succès, mais la réponse contient des informations qui doivent être traitées ultérieurement par le client. Par conséquent, l'utilisateur n'obtiendra pas d'indicateur d'échec, mais nous ne pouvons pas non plus considérer la réponse comme un succès. Pour comprendre comment traiter de tels cas, nous devons comprendre pourquoi et comment les interfaces utilisateur optimistes fonctionnent psychologiquement en premier lieu.

La psychologie derrière les interfaces utilisateur optimistes

Jusqu'à présent, je n'ai entendu personne se plaindre des interactions optimistes susmentionnées sur les principaux réseaux sociaux. Alors, disons que ces exemples nous ont convaincus que les interfaces utilisateur optimistes fonctionnent. Mais pourquoi fonctionnent-ils pour les utilisateurs ? Ils fonctionnent simplement parce que les gens détestent attendre. C'est tout, les amis ! Vous pouvez passer à la partie suivante de l'article.

Mais si vous lisez encore, alors vous êtes probablement intéressé à savoir pourquoi il en est ainsi. Alors, creusons un peu plus profondément dans le fondement psychologique de cette approche.

Une interface utilisateur optimiste a deux ingrédients de base qui méritent une analyse psychologique :

• la réponse rapide à l'action de l'utilisateur ;
• la gestion des pannes potentielles sur le serveur, sur le réseau et ailleurs.

Réponse rapide à l'action de l'utilisateur

Lorsque nous parlons de conception d'interface utilisateur optimiste, nous parlons d'un temps de réponse optimal dans l'interaction homme-ordinateur. Et des recommandations pour ce type de communication existent depuis aussi loin que 1968. À l'époque, Robert B. Miller a publié son article phare "Response Time in Man-Computer Conversational Transactions" (PDF), dans lequel il définit jusqu'à 17 différents types de réponses qu'un utilisateur peut obtenir d'un ordinateur. L'un de ces types que Miller appelle une "réponse à l'activation du contrôle" - le délai entre l'enfoncement d'une touche et le retour visuel. Même en 1968, il n'aurait pas dû dépasser 0,1 à 0,2 seconde. Oui, le modèle RAIL n'est pas le premier à le recommander - le conseil existe depuis environ 50 ans. Miller note, cependant, que même ce court délai de retour peut être beaucoup trop lent pour les utilisateurs expérimentés. Cela signifie que, idéalement, l'utilisateur devrait obtenir un accusé de réception de son action dans les 100 millisecondes . Cela entre dans la gamme de l'une des actions inconscientes les plus rapides que le corps humain puisse accomplir - un clin d'œil. Pour cette raison, l'intervalle de 100 millisecondes est généralement perçu comme instantané. "La plupart des gens clignent des yeux environ 15 fois par minute et un clignement des yeux dure en moyenne 100 à 150 millisecondes", explique Davina Bristow, de l'Institut de neurologie de l'University College London, ajoutant que cela "signifie que, globalement, nous passons au moins 9 jours par an à cligner des yeux". ”

En raison de sa réponse visuelle instantanée (avant même que la demande réelle ne soit terminée), une interface utilisateur optimiste est l'un des exemples des techniques d'achèvement précoce utilisées dans l'optimisation des performances psychologiques. Mais le fait que les gens aiment les interfaces qui répondent en un clin d'œil ne devrait pas surprendre la plupart d'entre nous, vraiment. Et ce n'est pas difficile à réaliser non plus. Même autrefois, nous désactivions les boutons instantanément après avoir cliqué dessus, et cela suffisait généralement à reconnaître l'entrée de l'utilisateur. Mais un état désactivé dans un élément d'interface signifie une attente passive : l'utilisateur ne peut rien y faire et n'a aucun contrôle sur le processus. Et c'est très frustrant pour l'utilisateur. C'est pourquoi nous ignorons complètement l'état désactivé dans une interface utilisateur optimiste - nous communiquons un résultat positif au lieu de faire attendre l'utilisateur.

Gestion des défaillances potentielles

Passons au deuxième aspect psychologique intéressant de la conception optimiste de l'interface utilisateur - la gestion des échecs potentiels. En général, de nombreuses informations et articles sont disponibles sur la façon de gérer au mieux les erreurs d'interface utilisateur. Cependant, bien que nous verrons comment gérer les échecs plus loin dans cet article, ce qui compte le plus dans une interface utilisateur optimiste n'est pas la façon dont nous gérons les erreurs, mais quand nous le faisons.

Les humains organisent naturellement leur activité en bouquets, terminés par la réalisation d'un objectif ou d'un sous-objectif défini subjectivement. Parfois, nous appelons ces amas un «train de pensée», un «flux de pensée» (PDF) ou simplement un «flux». L'état de flux est caractérisé par un plaisir maximal, une concentration énergétique et une concentration créative. Lors d'un flux, l'utilisateur est complètement absorbé par l'activité. Un tweet de Tammy Everts illustre bien cela :

Sur le web, les durées de tels amas d'activité sont beaucoup plus courtes. Revenons un instant sur le travail de Robert B. Miller. Les types de réponses qu'il cite incluent :

• une réponse à une simple demande d'informations répertoriées ;
• une réponse à une demande complexe sous forme graphique ;
• une réponse à "Système, tu me comprends?"

Il relie tous ces éléments au même intervalle de 2 secondes dans lequel l'utilisateur doit obtenir le type de réponse approprié. Sans creuser plus loin, notons que cet intervalle dépend également de la mémoire de travail d'une personne (c'est-à-dire le laps de temps pendant lequel une personne peut garder une certaine quantité d'informations dans sa tête et, plus important encore, être capable de la manipuler). Pour nous, en tant que développeurs et spécialistes UX, cela signifie que dans les 2 secondes suivant l'interaction avec un élément, l'utilisateur sera dans un flux et concentré sur la réponse qu'il attend. Si le serveur retourne une erreur pendant cet intervalle, l'utilisateur sera toujours en "dialogue" avec l'interface, pour ainsi dire. C'est comme un dialogue entre deux personnes, où vous dites quelque chose et l'autre personne n'est pas d'accord avec vous. Imaginez si l'autre personne a passé un long moment à hocher la tête en signe d'accord (l'équivalent de notre indication d'un état de réussite dans l'interface utilisateur) mais qu'elle vous a finalement dit "non". Gênant, n'est-ce pas ? Ainsi, une interface utilisateur optimiste doit communiquer l'échec à l'utilisateur dans les 2 secondes du flux.

Armé de la psychologie de la façon de gérer les échecs dans une interface utilisateur optimiste, arrivons enfin à ces 1 à 3 % de demandes ayant échoué.

Le côté pessimiste de la conception d'interface utilisateur optimiste

De loin, la remarque la plus courante que j'entends est que la conception optimiste de l'interface utilisateur est une sorte de motif noir - triche, si vous voulez. Autrement dit, en l'employant, nous mentons à nos utilisateurs sur le résultat de leur interaction. Légalement, n'importe quel tribunal soutiendrait probablement ce point. Pourtant, je considère la technique comme une prédiction ou un espoir. (Vous vous souvenez de la définition de « optimiste » ? C'est ici que nous laissons une certaine place à la partie « optimiste ».) La différence entre « mentir » et « prédire » réside dans la façon dont vous traitez ces 1 à 3 % de demandes ayant échoué. Regardons comment le bouton optimiste "J'aime" de Twitter se comporte hors ligne.

Tout d'abord, conformément au modèle d'interface utilisateur optimiste, le bouton passe à l'état de réussite juste après avoir été cliqué - encore une fois, sans que l'utilisateur n'appuie ou ne survole plus le bouton, exactement comme le bouton se comporte lorsque l'utilisateur est en ligne.

Mais comme l'utilisateur est hors ligne, la demande échoue.

Ainsi, dès que possible dans le flux de l'utilisateur, l'échec doit être communiqué. Encore une fois, 2 secondes est généralement la durée d'un tel flux. Twitter communique cela de la manière la plus subtile possible, simplement en inversant l'état du bouton.

Le lecteur consciencieux pourrait dire ici que cette gestion des pannes pourrait être poussée un peu plus loin, en notifiant en fait à l'utilisateur que la requête n'a pas pu être envoyée ou qu'une erreur s'est produite. Cela rendrait le système aussi transparent que possible. Mais il y a un hic – ou plutôt une série de problèmes :

• Toute sorte de notification qui apparaît soudainement à l'écran changerait le contexte de l'utilisateur, l'invitant à analyser la raison de l'échec, une raison qui serait probablement présentée dans le message d'erreur.
• Comme pour tout message ou notification d'erreur, celui-ci doit guider l'utilisateur dans ce nouveau contexte en fournissant des informations exploitables.
• Cette information exploitable établirait encore un autre contexte.

OK, maintenant nous pouvons tous convenir que cela devient un peu compliqué. Alors que cette gestion des erreurs serait raisonnable pour, disons, un grand formulaire sur un site Web, pour une action aussi simple que de cliquer sur un bouton J'aime, c'est exagéré - à la fois en termes de développement technique requis et de mémoire de travail des utilisateurs.

Donc, oui, nous devrions être ouverts sur l'échec d'une interface utilisateur optimiste, et nous devrions le communiquer dès que possible afin que notre optimisme ne devienne pas un mensonge. Mais cela doit être proportionnel au contexte. Pour un échec comme, ramener subtilement le bouton à son état d'origine devrait suffire - c'est-à-dire, à moins que l'utilisateur n'aime le statut de son autre significatif, auquel cas il vaut mieux que la chose fonctionne tout le temps.

Pessimisme extrême

Une autre question peut se poser : que se passe-t-il si l'utilisateur ferme l'onglet du navigateur juste après avoir reçu un indicateur de succès, mais avant que la réponse ne soit renvoyée par le serveur ? Le cas le plus désagréable serait que l'utilisateur ferme l'onglet avant même qu'une requête ait été envoyée au serveur. Mais à moins que l'utilisateur ne soit extrêmement agile ou ait la capacité de ralentir le temps, cela n'est guère possible.

Si une interface utilisateur optimiste est implémentée correctement et que les interactions ne sont appliquées qu'aux éléments qui n'attendent jamais plus de 2 secondes pour une réponse du serveur, l'utilisateur devra alors fermer l'onglet du navigateur dans cette fenêtre de 2 secondes. Ce n'est pas particulièrement difficile avec une frappe au clavier; cependant, comme nous l'avons vu, dans 97 à 99% des cas, la requête aboutira, que l'onglet soit actif ou non (c'est juste qu'aucune réponse ne sera retournée au client).

Ainsi, ce problème peut survenir uniquement pour les 1 à 3% qui obtiennent une erreur de serveur. Là encore, combien d'entre eux se précipitent pour fermer l'onglet en 2 secondes ? À moins qu'ils ne participent à une compétition de vitesse de fermeture d'onglets, je ne pense pas que le nombre sera significatif. Mais si vous pensez que cela est pertinent pour votre projet particulier et pourrait avoir des conséquences négatives, utilisez des outils pour analyser le comportement des utilisateurs ; si la probabilité d'un tel scénario est suffisamment élevée, limitez l'interaction optimiste aux éléments non critiques.

Je n'ai intentionnellement pas mentionné les cas dans lesquels une demande est artificiellement retardée ; ceux-ci ne relèvent généralement pas de la conception optimiste de l'interface utilisateur. De plus, nous avons passé plus qu'assez de temps sur le côté pessimiste des choses, alors résumons quelques points principaux sur la mise en œuvre d'une bonne interface utilisateur optimiste.

Règles de base

J'espère sincèrement que cet article vous a aidé à comprendre certains des principaux concepts derrière la conception optimiste de l'interface utilisateur. Peut-être que vous êtes intéressé à essayer cette approche dans votre prochain projet. Si oui, voici quelques éléments à garder à l'esprit avant de commencer :

• Une condition préalable à tout ce dont nous avons parlé jusqu'à présent : assurez-vous que l'API sur laquelle vous comptez est stable et renvoie des résultats prévisibles. Assez dit.
• L'interface doit détecter les erreurs et les problèmes potentiels avant qu'une requête ne soit envoyée au serveur. Mieux encore, éliminez totalement tout ce qui pourrait entraîner une erreur de l'API. Plus un élément d'interface utilisateur est simple, plus il sera simple de le rendre optimiste.
• Appliquez des modèles optimistes à des éléments simples de type binaire pour lesquels rien de plus qu'une réponse de succès ou d'échec n'est attendue. Par exemple, si un clic sur un bouton suppose une réponse du serveur telle que "oui", "non" ou "peut-être" (qui peuvent tous représenter un succès à des degrés divers), un tel bouton serait mieux sans un modèle optimiste.
• Connaissez les temps de réponse de votre API. C'est crucial. Si vous savez que le temps de réponse pour une requête particulière ne descend jamais en dessous de 2 secondes, il est probablement préférable de saupoudrer d'abord un peu d'optimisme sur votre API. Comme mentionné, une interface utilisateur optimiste fonctionne mieux pour les temps de réponse du serveur inférieurs à 2 secondes. Aller au-delà de cela pourrait conduire à des résultats inattendus et à de nombreux utilisateurs frustrés. Considérez-vous averti.
• Une interface utilisateur optimiste ne se limite pas aux clics sur les boutons. L'approche pourrait être appliquée à différentes interactions et événements au cours du cycle de vie d'une page, y compris le chargement de la page. Par exemple, les écrans squelettes suivent la même idée : vous prédisez que le serveur répondra avec succès afin de remplir les espaces réservés à montrer à l'utilisateur dès que possible.

La conception d'interface utilisateur optimiste n'est pas vraiment une nouveauté sur le Web, ni une technique particulièrement avancée, comme nous l'avons vu. C'est juste une autre approche, un autre modèle mental, pour vous aider à gérer la performance perçue de votre produit. Étant ancrée dans les aspects psychologiques de l'interaction homme-ordinateur, la conception d'interface utilisateur optimiste, lorsqu'elle est utilisée intelligemment, peut vous aider à créer de meilleures expériences plus fluides sur le Web, tout en nécessitant très peu de mise en œuvre. Mais, afin de rendre le modèle vraiment efficace et d'empêcher nos produits de mentir aux utilisateurs, nous devons comprendre les mécanismes d'une conception d'interface utilisateur optimiste.

Ressources

• « Temps de réponse dans les transactions conversationnelles homme-ordinateur » (PDF), Robert B. Miller, Fall Joint Computer Conference, 1968
• "Présentation de RAIL : un modèle de performance centré sur l'utilisateur", Paul Irish, Paul Lewis, Smashing Magazine, 2015
• "Stress du Web mobile : l'impact de la vitesse du réseau sur l'engagement émotionnel et la perception de la marque", Tammy Everts, Radware Blog, 2013
• Applications du flux dans le développement humain et l'éducation , Mihaly Csikszentmihalyi, 2014
• "Détails de conception mobile : évitez le spinner", Luke Wroblewski, 2013
• "Pourquoi la performance est importante, partie 2 : gestion de la perception", Denys Mishunov, Smashing Magazine, 2015