Meilleures pratiques pour l'aide en ligne
nous développons actuellement un portail Web assez complexe. Pour améliorer l'expérience utilisateur, nous voulons fournir un système d'aide en ligne contextuel qui peut aider l'utilisateur à comprendre certains aspects du site.
Dans notre cas, le site a une variété de widgets qui affichent toutes sortes de données tabulaires, graphiques, etc. Par exemple, un tel widget peut afficher le VIX et le système d'aide offrirait une brève description de ce qu'est le VIX.
Maintenant, j'ai regardé autour d'Internet et trouvé des articles intéressants tels que Design Checklists for Online Help , mais la plupart de ce que j'ai trouvé semble assez obsolète. Ce qui m'intéresse particulièrement, ce sont les problèmes de conception tels que ceux-ci:
- si (ou quand) utiliser des popups, des divs ou des liens vers des pages externes
- dans quelle mesure l'aide devrait-elle être complète? combien l'utilisateur moyen est-il prêt à lire?
- quelle est la bonne façon de donner accès au système d'aide? l'encombrement de l'interface utilisateur avec des icônes de point d'interrogation n'est certainement pas optimal
- si l'entrée d'aide doit être chargée à la demande avec AJAX (un peu nul, vous voulez les informations tout de suite) ou la précharger (provoquant des tonnes de trafic inutile)
- autres choses à faire et à ne pas faire
Les réponses à certaines de ces questions peuvent sembler évidentes, mais en ce qui concerne la convivialité, j'ai fait l'expérience que la réponse intuitive n'est pas toujours la meilleure. Deuxièmement, je suis développeur de logiciels et en tant que tel, j'ai tendance à regarder les choses du point de vue d'un ingénieur. Et je pense que nous savons tous que c'est, le plus souvent, un angle assez mauvais pour aborder la conception d'une interface utilisateur. C'est pourquoi j'aimerais beaucoup obtenir des commentaires de personnes plus expérimentées dans ce domaine.
Je vais apporter une réponse étroite, donc je ne vais pas répondre à toutes vos questions.
Une recherche rapportée par Andrea Ames il y a quelques années lors d'une mini-conférence au campus du centre-ville de l'UBC, a suggéré que l'aide intégrée et la convivialité sont meilleures que l'aide. Elle a raconté comment elle a comparé trois méthodes différentes de fourniture d'aide avec/dans un logiciel financier domestique. Les utilisateurs ne perçoivent pas l'assistance intégrée comme une forme d'aide et signalent qu'ils "utilisaient simplement le logiciel", plutôt que d'utiliser les informations qui les instruisent et les guident à travers le logiciel. Lorsque les utilisateurs sont confrontés à un problème, souvent, la dernière chose qu'ils veulent faire est de se désengager et de démarrer autre chose. Pour de nombreux utilisateurs, le démarrage de l'aide correspond à la catégorie "autre chose", quelle que soit l'illogisme. La dernière fois que j'ai entendu, Andrea travaillait pour IBM. Par assistance intégrée je ne fais pas référence aux étiquettes et aux noms de boutons, mais au texte qui apparaît directement dans une interface utilisateur dont la fonction est d'orienter, d'expliquer, d'instruire et de fournir un contexte.
Lois Hawk a rendu compte d'une réponse involontaire dans le cerveau appelée réaction de stimulation imminente. Lorsque quelque chose change de façon inattendue dans votre champ visuel - comme un tigre - votre cerveau réagit comme suit: 1) effacer la mémoire à court terme, 2) libérer de l'adrénaline pour se préparer à l'action, et 3) effectuer une nouvelle analyse visuelle de l'environnement. Vous pouvez probablement imaginer que si une fenêtre contextuelle déclenche également cette réponse involontaire, et donc vider la mémoire à court terme de vos utilisateurs avec vos fenêtres contextuelles d'aide, et augmenter leur stress, elles ne sont pas va être sûr pourquoi ils n'aiment pas l'expérience, mais ils ne l'aiment pas, ils le feront. Ce document de recherche fait partie des travaux de la conférence conjointe STC des régions 7 et 8 à Honolulu, en 2000 (je pense que c'était l'année). Il est difficile d'en trouver une copie.
Il peut être difficile d'amener les gens à lire. Parfois, ils supposeront qu'ils savent ce que vous voulez et refuseront de lire l'aide. La réponse évidente serait de rendre votre application si simple qu'elle ne nécessite aucune explication. Mais ce n'est pas toujours aussi simple et c'est quelque chose avec lequel je me bats depuis longtemps.
Mais en termes d'aide contextuelle, j'ai choisi de faire apparaître l'aide chaque fois que vous vous concentrez sur une zone de texte. Par exemple, la zone orange ci-dessous n'est visible que lorsque la zone de texte Code postal a le focus ... 
De cette façon, l'utilisateur n'a pas à cliquer sur une icône pour que l'aide apparaisse. Cela apparaîtra naturellement alors qu'ils remplissent l'application.
Cela ne fonctionne pas pour tout, bien sûr. Cela ne fonctionnera pas pour les boutons radio ou les cases à cocher, vous devrez donc inventer votre propre mécanisme pour ceux-ci. Les petites icônes d'informations i fonctionnent bien à côté d'une question.
Je vais essayer de répondre à certaines de vos autres questions ...
si (ou quand) utiliser des popups, des divs ou des liens vers des pages externes
Personne n'aime les popups. Si possible, essayez de trouver un endroit vide à côté de chaque champ où l'aide peut apparaître comme illustré ci-dessus. De cette façon, cela ne couvre rien. Gardez tout (y compris votre aide) aussi concis que possible tout en faisant passer le message.
si l'entrée d'aide doit être chargée à la demande avec AJAX (un peu nul, vous voulez les informations tout de suite) ou la précharger (provoquant des tonnes de trafic inutile)
Vous devrez évaluer vos options ici en fonction de la quantité de texte d'aide que vous traitez. Si vous utilisez la compression gzip de toute façon, ce n'est peut-être pas un gros problème de tout garder dans le HTML.
Je n'aime pas trop les info-bulles ou appeler des zones toujours visibles qui donnent des instructions de base, puis un lien vers une aide contextuelle plus avancée. Les info-bulles ont tendance à être sur des points d'interrogation ou sur d'autres, mais si vous en avez besoin, préférez utiliser une zone de légende simple qui est dans la conception initiale à cet effet.
L'info-bulle ou la légende utilise un ID pour activer la navigation vers l'élément d'aide correct. Je n'ouvre pas de nouvelle fenêtre/onglet/pop-up/div, mais s'ils veulent une aide avancée, je les amène à cette page avec un lien important RETOUR qui utilise l'ID d'écran et l'ID info-bulle/légende pour les retourner à le bon endroit, en gardant toutes les formes remplies.
Comme il s'agit d'une aide avancée, j'ai toujours tendance à recourir au style d'aide "RoboHelp", où il y a des liens vers des éléments connexes et une navigation d'aide complète. Étant donné que la plupart des applications sur lesquelles je travaille sont authentifiées avec différents niveaux d'accès/types d'utilisateurs/attributs de rôle, ce qui est disponible pour naviguer dans l'aide examine le jeton Utilisateurs pour décider quelles informations afficher.
J'espère que certains de ces renseignements seront utiles à la plupart de vos destinataires.
Lorsque votre application se concentre sur un sujet spécifique et est remplie d'acronymes/termes étranges, les utilisateurs sauront qu'il s'agit d'une application ciblée (qui peut leur donner une certaine productivité s'ils l'apprennent) et voudront s'engager dans une expérience d'apprentissage. Le problème est que cette volonté est juste pour la première rencontre avec le troisième.
Pour la première utilisation, vous pouvez demander à l'utilisateur s'il souhaite un tutoriel guidé. Vous pouvez faire cela comme un assistant, en étapes qui présentent des éléments en surbrillance, ou vous pouvez écouter ce sur quoi l'utilisateur clique/se concentrer et fournir de l'aide pour l'élément actuel. IMO c'est comme une expérience de jeu tutoriel, vous apprenez les commandes, vous obtenez l'objectif. L'utilisateur doit pouvoir quitter ce tutoriel à tout moment, revenir s'il le souhaite et vérifier de ne plus voir l'invitation du tutoriel. Cette expérience devrait être offerte à un utilisateur débutant.
Pour les utilisateurs moyens/avancés, je pense que les acronymes et les éléments de titre/info-bulle sont juste suffisants (c'est-à-dire si vous avez une IA claire et des éléments intuitifs/cohérents). Les info-bulles ne gênent pas l'utilisateur, mais y a-t-il toujours besoin de l'aide de l'utilisateur, sans être gênant. Ils devraient être de style assez discret, mais toujours observables.
Ceci est un lien vers l'utilisation du chat en direct comme outil d'aide en ligne, j'espère que cela aide https://www.experienceux.co.uk/ux-blog/2017/05/30/6-steps -à-livrer-première-classe-live-chat-expérience-utilisateur /
Résumé du poste:
Rendez l'appel à l'action Live Chat facilement visible/accessible (par exemple, en bas à droite du site Web).
Attirez davantage l'attention sur l'appel à l'action en le chargeant après le reste du contenu de la page (par exemple quelques secondes plus tard).
Aidez à surmonter la barrière "est-ce un vrai humain?" En montrant le nom et la photo de la personne.
Facilitez la navigation en parallèle des utilisateurs en chargeant la fenêtre de discussion in situ dans la fenêtre du navigateur et en permettant aux utilisateurs de la minimiser.
Réduisez la nécessité pour les utilisateurs d'apprendre de nouvelles choses en suivant les modèles de conception des services de messagerie familiers comme Facebook Messenger et WhatsApp.
Autorisez la fenêtre de discussion Web à être réduite tout en affichant la notification des nouveaux messages.