Est-il nécessaire d'inclure les "fonctions cachées" d'une interface dans le manuel / l'aide?
Contexte
Une interface bien conçue permet à tout type d'utilisateur, débutant, avancé ou expert, d'atteindre rapidement son objectif. Dans la plupart des cas, les informations d'aide contiennent la description des éléments et des fonctions destinés aux utilisateurs de niveau débutant. Il permet de gérer rapidement une interface inconnue. De plus, il existe souvent de nombreuses "possibilités cachées" qui permettent à un utilisateur de réduire considérablement le temps passé pour atteindre son objectif. L'exemple le plus répandu en est HotKeys/Shortcuts.
D'autres exemples incluent glisser-déverrouiller à partir du centre de notification dans iOS5 et sélectionner rapidement une date de mois en double-cliquant sur l'en-tête dans Google Analytics 
Dans la plupart des cas, des informations sur des fonctionnalités similaires sont tirées de l'interaction avec/découverte des interfaces ou sur des forums Web pour les utilisateurs avancés.
Question
Y a-t-il des règles sur la création des fichiers d'aide dans de telles situations et est-il nécessaire d'annoncer des fonctions cachées? Et est-il possible de fournir ces informations aux utilisateurs avancés tout en expliquant les fonctions de base de l'application pour les utilisateurs novices?
L'idée que l'aide est pour les débutants est erronée. Les novices n'utilisent pas d'aide ; les utilisateurs avancés le font. Les novices n'utilisent pas l'aide car:
Nous sommes victime de notre propre succès . Nous avons créé des applications et des sites Web que les utilisateurs peuvent utiliser sans aide, c'est donc ce qu'ils attendent. Et, en effet, une application devrait être conçue de sorte que le nouvel utilisateur moyen puisse être productif sans ouvrir l'aide en premier.
Utiliser l'aide est en soi une compétence. Les utilisateurs ont besoin d'expérience avec une application pour savoir par où commencer avec l'aide. Ils ont besoin de connaître les termes, l'architecture et la logique interne pour réussir. Au lieu de rechercher dans l'Aide, les nouveaux utilisateurs se tournent vers leurs collègues, amis et famille (nous y sommes tous allés, non?). Les novices peuvent être aidés par une brève documentation de "mise en route", mais même cela peut être ignoré.
De l'aide devrait être écrite pour cette réalité. Les utilisateurs avancés utilisent généralement l'aide lorsqu'ils connaissent la plupart de la solution mais sont bloqués sur un certain point. L'aide devrait concerner les détails avancés du système, ventilés et organisés pour faciliter la recherche et la numérisation .
Les capacités "masquées", telles que celles effectuées par glisser-déposer, double-cliquer et touches accélératrices, peuvent être mises en évidence dans l'aide dans une section "Conseils", "Conseils" ou "Raccourcis" dans l'aide sur une fonction ou une tâche particulière. Vous ne voulez pas les mélanger avec d'autres contenus sur une fonctionnalité, car les utilisateurs sont confus en essayant d'apprendre deux façons différentes de faire la même chose.
Cependant, le vrai problème avec les raccourcis est que les utilisateurs ne savent pas qu’ils en ont besoin. Les utilisateurs vont généralement aider lorsqu'ils sont bloqués, non pas parce qu'ils veulent travailler plus efficacement. Étant donné la faible facilité d'utilisation de tant de choses sur le marché, pourquoi les utilisateurs devraient-ils s'attendre à une méthode de travail plus efficace?
Pour les fonctionnalités cachées, vous souhaiterez peut-être utiliser aide dynamique en ligne d'indications ultra-brèves (par exemple, une info-bulle apparaît indiquant "Double-cliquez pour par défaut" lorsque l'utilisateur réinitialise manuellement un champ par défaut) . L'aide en ligne est également la seule aide que les nouveaux utilisateurs peuvent lire, vous pouvez donc envisager de remplacer les conseils novices par des conseils avancés au fur et à mesure de la progression de l'utilisateur. Cependant, cela devient compliqué et expérimental.
Personnellement, je pense que si un manuel est nécessaire pour utiliser quelque chose, il est déjà trop complexe.
Dans le scénario de recherche ou de filtrage d'un rapport, le problème courant est qu'il y a trop de résultats. Dans ces scénarios, il est préférable de voir comment les gens utilisent la recherche de base et pourquoi essaient-ils d'obtenir une vue précise de ce que la recherche de base a renvoyé.
Un article de Boxes and Arrows, Advancing Advanced , peut vous aider ici. Il examine les suggestions de ce problème et voici quelques-uns de mes conseils d'expérience personnelle.
- Ajoutez des conseils, par exemple. "Vous en avez trouvé trop? Vouliez-vous restreindre votre catégorie"
- Affichage des filtres associés dans vos résultats de recherche, c.-à-d. les recherches d'hôtels indiquent le niveau d'étoiles d'un hôtel dans les résultats
- Faire en sorte que les résultats de la saisie semi-automatique contiennent plus de données dans la fenêtre de suggestion (c'est-à-dire Yahoo's Search
- Autoriser l'ajout de requêtes complexes dans la zone de recherche (à l'aide d'une requête Web standard)
Parfois, les gens ne savent pas ce qu'ils recherchent et l'ajout de ces éléments aidera les débutants à rechercher comme une personne avancée. L'idée ici est de déterminer le flux de recherche, ce qu'ils essaient de trouver et s'ils ne l'ont pas trouvé, quelles données particulières manquent. Répondez à ces questions et vous découvrirez comment intégrer la recherche avancée à votre recherche de base.
Les utilisateurs n'aiment pas penser - et en particulier ils n'aiment pas lire (en particulier tout ce qui a une page de contenu et un index).
Comme discuté dans cet article classique:
Le paradoxe de l'utilisateur actif
Fondamentalement (puisque, étant un article académique, sa lecture n'est pas facile pour commencer):
... les utilisateurs ne sont pas une `` ardoise vierge '': ils évitent de lire, numérisent du texte à l'écran, sont pressés de faire avancer les choses et ont leurs propres idées préexistantes sur la façon dont quelque chose devrait fonctionner.
C'est pourquoi c'est un paradoxe: - si les utilisateurs étaient une liste vierge, ils liraient correctement les instructions et en apprendraient plus.
Je travaillerais sur la base que plus vous écrivez de mots - moins ils sont susceptibles d'être lus car les utilisateurs passeront en mode `` Je vais le découvrir moi-même ''.