Pourquoi la haute disponibilité du site Web est-elle bonne pour l'UX?
J'essaie de comprendre combien dois-je investir dans la disponibilité du site Web.
Quel impact une mauvaise disponibilité (disons 95% - 18 jours dans un an) a-t-elle sur l'expérience utilisateur.
Pourquoi est-ce si important que les gens ne soient pas satisfaits de 99,999% et recherchent beaucoup plus de "9".
Stephen P. Anderson explique bien pourquoi le temps de disponibilité est nécessaire dans son livre Seductive Interaction Design. Il présente une pyramide basée sur Hiérarchie des besoins de Maslow où vous devez remplir les exigences à la base avant que de plus grandes exigences puissent être remplies. Aarron Walter présente une pyramide similaire dans son livre Designing for Emotion:
Au niveau le plus bas, un site doit être fonctionnel .
Si un site ne fonctionne pas du tout, les utilisateurs ne l'utiliseront pas.
Une fois qu'un site est fonctionnel, il doit être fiable .
Si votre page n'est disponible que par intermittence, les utilisateurs n'y feront pas confiance. Ils partiront pour d'autres sites qui peuvent faire la même chose de manière plus fiable.
UX consiste à rendre les sites utilisables et à les pousser au-delà pour agréables .
Sans la couche de fiabilité sous-jacente sur laquelle s'appuyer, un site n'atteindra jamais le stade d'être utilisable. Vous ne pouvez pas utiliser un site auquel vous ne pouvez pas accéder, et vous ne pouvez certainement pas en profiter!
Lorsqu'un site Web est en panne, ce n'est pas seulement que la personne ne peut pas l'utiliser, mais c'est qu'elle ne peut pas s'y fier , et que ils se souviendront que ce n'est pas le cas.
Prenez une analogie avec une voiture. Si vous avez une voiture qui fonctionne 99% du temps (ou même 99,9%), vous vous souviendrez des fois où elle a échoué et des conséquences de cette défaillance plus que vous vous souviendrez de toutes les fois où elle a fonctionné. Il en va de même pour tout service sur lequel vous comptez.
Un autre exemple est l'électricité aux Pays-Bas. Ici, les fournisseurs ont droit à quelque chose comme 30 secondes par an de défaillance du système électrique (en moyenne par personne). Mais la plupart des gens se souviendront de la dernière fois où l'électricité a été coupée parce que c'est quelque chose sur lequel ils comptent.
Il y a certainement des rendements décroissants pour passer de 99,95% à 99,995% de disponibilité. À la fois parce que ce n'est qu'une infime diminution des temps d'arrêt, mais aussi parce que les coûts supplémentaires pour obtenir ce temps de disponibilité plus élevé ne sont pas négligeables.
La fiabilité d'un service dépend en grande partie de sa nature et des conséquences d'une défaillance . S'il s'agit d'un service médical essentiel, vous aurez peut-être besoin d'une disponibilité de 99,999%.
En guise de remarque, vous devez convertir le temps de disponibilité en unités qui ont un sens pour vos clients , et regarder les échelles de temps. Une disponibilité de 99% par mois est bien meilleure qu'une disponibilité de 99% par an, car vous pourriez avoir le temps d'arrêt de 1% pour l'année en une seule fois. Et un temps de disponibilité de 99% par an se traduit par près de 4 jours (max) d'arrêt à la fois!
Tout d'abord, une disponibilité à 95% ne correspond pas à "quelques jours d'indisponibilité par an" - c'est plus proche de 20 jours par an! Cela représente beaucoup de temps d'arrêt (> deux semaines) et, selon la façon dont le temps d'arrêt est réparti tout au long de l'année, décrit un service très peu fiable. Si, par exemple, ce temps d'indisponibilité de 5% est réparti uniformément pendant les heures de fonctionnement du service (ou si le service est utilisé 24h/24 et 7j/7), environ 1/20 tentatives d'accès au service échoueront (excuses aux mathématiciens). Avec ce type de temps d'arrêt, si vos utilisateurs ont la possibilité d'arrêter d'utiliser votre service, ils le feront.
Bien que l'UX soit une excellente raison de maintenir une haute disponibilité de votre service, il existe de nombreuses raisons tout aussi importantes pour comprendre et quantifier l'impact des temps d'arrêt. Les temps d'arrêt dans les services d'urgence et les services essentiels aux entreprises, par exemple, pourraient entraîner des pertes financières et/ou des risques pour la vie humaine (je suppose que l'on pourrait décrire la perte de vies humaines comme une mauvaise expérience utilisateur). IBM a estimé qu'en 1996, les interruptions de service ont entraîné une perte de 4,54 milliards de dollars pour les entreprises américaines .
Si le temps d'arrêt est hors de votre contrôle, une chose que vous pouvez et devez faire est de déterminer comment ce temps d'arrêt est communiqué à l'utilisateur. Du point de vue UX, il y a un monde de différence entre une page 404 (n sans style) et une explication du temps d'arrêt et un calendrier pour la restauration du service. Une page 404 n'a pas de sémantique significative pour l'utilisateur final. Cela pourrait signifier un problème temporaire ou cela pourrait signifier que vous avez fermé le service pour de bon. Lorsque vos utilisateurs voient un message d'erreur 404, 503 ou similaire, vous avez miné leur confiance dans votre capacité à fournir un service fiable.
C'est mauvais mais ...
De manière réaliste, votre investissement dans la disponibilité du site Web devrait être largement comparable à la proportion de votre entreprise qui dépend de votre site Web. Si vous êtes nouveau sur le Web avec une entreprise qui ne dépend pas du Web, alors pas tant que ça.
Si vous exploitez un site de commerce électronique, il est beaucoup plus important que les gens puissent accéder de manière fiable à votre site, que votre site fonctionne en termes de certificats de sécurité valides et qu'ils reçoivent leurs commandes en temps opportun.
Si votre site fournit un service tel que des recherches, des recherches, des médias sociaux ou maintient un référentiel d'informations sur lequel les gens peuvent compter, alors ce n'est probablement pas aussi important car ces personnes continueront certainement de revenir même si elles rencontrent des problèmes. Surtout si vous proposez un service par abonnement. Cela étant dit, si Facebook était en panne pendant 18 jours, les gens hétéros feraient autre chose.
Si votre site est pour à des fins d'information uniquement (une présence sur le Web), ce n'est pas vraiment un problème (à condition que les jours ne soient pas consécutifs) car la plupart de ces informations ont probablement été exploité et diffusé sur Internet sous diverses formes. Il a probablement également été mis en cache par les principales recherches. Les gens vont appeler et ils vont toujours envoyer un courriel. Ils peuvent également rechercher un fournisseur de remplacement s'ils pensent que vous êtes une autre victime de la récession.
Si le site est un microsite pour une promotion publicitaire de lancement zero-day et que le site est en panne le jour de la promotion, il s'agit d'un échec catastrophique.
Dans une situation similaire, un de mes clients a envoyé un e-mail à leur liste principale de 20 000 noms le jour où l'enregistrement de leur domaine n'a pas été renouvelé. Le site a été indisponible pendant environ 2 heures pendant qu'ils tentaient de comprendre ce qui se passait. Ils m'ont contacté et j'ai retracé le problème rapidement (à distance), mais leur personnel informatique n'était pas copié sur les e-mails de leur registraire (problème de gestion). Leurs principaux services de messagerie électronique ont diminué, les rebonds ne sont pas revenus sur le serveur approprié et de nombreuses personnes de la liste se sont désabonnées (ou l'ont fait peu de temps après). Ils se sont retrouvés sur une liste de blocage des e-mails car ils envoyaient les e-mails à partir du même pool IP que leur serveur de messagerie principal. Il semble qu'au cours d'une autopsie, il s'agissait d'une erreur de 30 000 $ basée sur le potentiel perdu, les temps d'arrêt et l'investissement marketing requis pour reconstruire la liste. Cela aurait valu la peine pour eux d'avoir mis en place une sorte de contrôle de disponibilité. Lorsque vous hébergez avec un hôte partagé ou même un service basé sur le cloud, il est possible que le DNS tombe en panne, provoquant ce même problème. Si l'adresse IP de votre site Web ne peut pas être résolue, vous risquez de perdre ce trafic, votre courrier électronique, etc.
"Quel est l'impact d'une mauvaise disponibilité (disons 95% - 18 jours dans un an) sur l'expérience utilisateur?" Supposons que la prochaine fois que vous vous rendrez à un guichet automatique pour retirer de l'argent de votre compte, vous envisagez la possibilité que votre banque ne soit pas disponible 18 jours par an. Et s'ils étaient consécutifs? Et si cela ne se produisait que les jours à fort trafic (comme le jour de paie).
De nos jours, la plupart des hébergeurs proposent une sorte "d'hébergement cloud partagé". Il n'est pas obligatoire d'utiliser quelque chose d'aussi cher que la colocalisation, mais l'hébergement cloud a ses propres inconvénients . De nombreux hôtes peuvent également remplacer un serveur dans environ une heure maintenant et restaurer une image de sauvegarde à partir d'un SAN en cas de panne d'alimentation, de disque dur ou de batterie défectueuse). Si vous êtes dans un cloud hébergé par une entreprise comme Amazon, vous n'aurez pas votre mot à dire lorsque votre site sera en panne, sauf si vous êtes une influence monétaire majeure. Ils concentreront leurs ressources sur les incendies beaucoup plus importants.
SEO - si c'est votre bouée de sauvetage ...
L'une des autres choses à considérer est que si vos visiteurs ne peuvent pas accéder à votre site Web alors les moteurs de recherche non plus . Les moteurs de recherche exploreront un site au hasard plusieurs fois par mois. Si le site est en panne, ils vont probablement ramper lorsque le site sera de nouveau opérationnel. S'il y a des problèmes avec le site non disponible pour une raison quelconque, le moteur de recherche enverra probablement votre trafic de recherches à quelqu'un qui peut réellement servir les pages .