Les points d'entrée multiples sont-ils bons ou mauvais?
Mon exemple est une application Web, mais je suppose que cela pourrait aller pour n'importe quoi: plusieurs points d'entrée pour la même action, bon ou mauvais?
Mon exemple:
Ajout d'un produit contre un fournisseur (fournisseur).
Cela pourrait potentiellement se faire via:
- Produit -> Cliquez sur "Ajouter un produit fournisseur" (puis sélectionnez le fournisseur)
- Fournisseur -> Cliquez sur "Ajouter un produit" (puis sélectionnez le fournisseur)
- Fournisseur -> Sélectionnez le fournisseur dans la liste des fournisseurs -> Cliquez sur "Afficher les produits des fournisseurs" -> Cliquez sur "Ajouter un produit"
Tous les points d'entrée valides, si nous n'en utilisons qu'un, ont chacun des avantages et des inconvénients qui améliorent l'expérience ou déroutent l'utilisateur. Y a-t-il quelque chose de mal/déroutant à avoir plusieurs points d'entrée pour la même action?
En tant que principe de convivialité général, vous voulez offrir une ouverture et une flexibilité, permettant aux utilisateurs de faire ce qu'ils veulent quand ils le souhaitent. Cela plaide pour fournir plusieurs points d'entrée plutôt que pour forcer les utilisateurs à ne suivre qu'un seul chemin possible qu'ils ne connaissent peut-être pas, ont peut-être oublié ou peuvent ne pas être cohérents avec leur façon de penser.
Le problème est que plusieurs chemins peuvent signifier des menus et une architecture d'informations plus complexes qui ajoutent de l'encombrement, entraînent la perte des utilisateurs et, autrement, peuvent provoquer de la confusion. Il y a quelques variables qui peuvent atténuer cela.
Structures centrées sur l'objet
Tout d'abord, à mesure que les applications deviennent plus complexes, avec plus de tâches et de chemins possibles, vous pouvez contrôler à la fois la complexité des menus et de l'architecture en adoptant une structure centrée sur l'objet , plutôt qu'une structure centrée sur les tâches de type assistant typique de applications Web. Dans une structure centrée sur l'objet, chaque page représente une ou plusieurs classes d'objets pour lesquelles toutes les tâches impliquant ces classes peuvent être accomplies. Dans une structure centrée sur les tâches, chaque page représente une seule tâche ou une seule étape d'une tâche.
Avec une structure orientée objet, vous pouvez avoir une page Produits répertoriant tous les produits, avec le fournisseur pour chacun indiqué dans un champ (sur lequel l'utilisateur peut trier). Alternativement, vous avez une page Fournisseurs répertoriant tous les fournisseurs, qui inclut les produits pour un fournisseur donné dans une arborescence ou une disposition principale. Quoi qu'il en soit, toutes les informations sont sur une seule page, ce qui rend le menu et l'architecture les plus simples et élimine ou au moins réduit le besoin de plusieurs points d'entrée.
Duplication entre les pages (par rapport aux pages)
Deuxièmement, avoir des commandes en double sur deux pages différentes n'est pas aussi problématique que d'avoir des commandes en double à deux endroits différents sur la même page. Avec ce dernier, les utilisateurs se demanderont si les deux commandes sont vraiment identiques ou non. En revanche, les utilisateurs s'attendent souvent à ce que les mêmes commandes apparaissent sur différentes pages (par exemple, dans le menu de la barre latérale).
Selon les tâches que vous devez prendre en charge, il peut être nécessaire d'avoir à la fois une page Produits et une page Fournisseurs même si vous avez une structure centrée sur l'objet. Cependant, avoir un élément de menu Ajouter un produit sur les produits et les fournisseurs pages est probablement correct. Avoir un élément de menu Ajouter un produit sous Produit et fournisseur menus ne l'est probablement pas.
Étiquettes et règles cohérentes
Troisièmement, plusieurs points d'entrée entraînent la moindre complexité s'ils utilisent les mêmes étiquettes et suivent les mêmes règles de base d'interaction. Pour les structures centrées sur l'objet et la plupart des interfaces graphiques de bureau, la règle de base est que si l'utilisateur peut la voir, l'utilisateur peut interagir avec elle. Si les utilisateurs voient des produits sur la page Produits et fournisseurs, ils s'attendent à pouvoir interagir avec eux, y compris en les ajoutant. Cela revient à fournir des liens vers du contenu chaque fois qu'il est cité dans un site Web.
Des étiquettes cohérentes aideront à signaler aux utilisateurs qu'il s'agit de la même commande à un endroit différent, alors assurez-vous de l'appeler systématiquement "Ajouter un produit", pas "Ajouter un produit" à un endroit et "Insérer un produit" à un autre.
Des règles simples et cohérentes peuvent également simplifier vos menus. Si votre application prend en charge le focus d'objet (nécessaire pour les relations maître-détail), vous n'avez besoin que d'un élément de menu Ajouter. Si l'accent est mis sur les produits (sur l'une ou l'autre page), il ajoute un produit. Si l'accent est mis sur les fournisseurs, cela ajoute un fournisseur.
En termes d'architecture d'information, la navigation à facettes est une approche légitime pour amener un utilisateur à la tâche ou à la page qu'il souhaite.
Vous optimisez la structure du site pour l'adapter au modèle mental de l'utilisateur.
- Assurez-vous que l'appel à l'action est clair.
- Assurez une convention de dénomination cohérente pour l'appel aux actions. C'est important pour vous assurer de minimiser la frustration et d'améliorer l'accessibilité. C'est à dire. Si vous avez "Ajouter un produit", assurez-vous que toutes les actions "Ajouter un produit" vont sur la même page.
Une autre note rapide, si vous collectez des informations de l'environnement (telles que le nom du fournisseur) à partir d'un point d'entrée différent, utilisez ces informations pour préremplir le formulaire.
HTH
Mat
En règle générale, plusieurs points d'entrée peuvent entraîner une confusion parmi les utilisateurs. S'ils voient plusieurs façons qui peuvent potentiellement les amener à la même action, ils peuvent ne pas savoir quelles différences il pourrait y avoir entre les deux actions.
Cela dit, cependant, la réponse est vraiment que cela dépend. Chaque situation a ses propres petites bizarreries auxquelles vous devez faire face. Si vous avez deux bases d'utilisateurs distinctes, avec deux flux commerciaux différents, il est parfaitement logique d'avoir deux façons différentes d'arriver au même endroit.
je ne laisserais que les deux premiers, ils semblent logiques dans une relation produit <-> fournisseur, le troisième semble compliqué et un peu redondant pour le second.
- plus tard, vous pouvez tester et voir laquelle de ces personnes utilise (ce ne sera qu'une) et supprimer l'autre.
Je propose toujours plusieurs façons d'atteindre un objectif. Cependant, j'ai une structure. Vous ne devez pas confondre l'utilisateur quant à la nature de la chose ou utiliser une terminologie différente.
Voici ce qui va arriver.
- Les utilisateurs devineront comment faire quelque chose
- Si vous fournissez plusieurs entrées, elles en devineront une et auront raison. GAGNER. Ils continueront alors de le faire de cette façon.
- Alternativement, si vous fournissez une façon de faire les choses, ils devineront mal, seront frustrés, se brouilleront, se brouilleront, se brouilleront, enfin le découvriront et continueront de le faire de cette façon. PERDRE.
D'après mon expérience, c'est définitivement et 100% oui. Cela ne déroute pas l'utilisateur si vous maintenez la cohérence de la langue.
sujet intéressant
il est courant que certaines destinations soient accessibles via> 1 trajets. Un exemple: un utilisateur doit trouver des informations sur une activité (disons golf) à un endroit (disons perth).
Dans cet exemple, l'utilisateur peut arriver ici soit par:
1) naviguer vers un emplacement puis sélectionner une activité 2) naviguer vers une activité puis sélectionner un emplacement
Les deux scénarios sont tout aussi probables, vous ne pouvez donc pas pas concevoir votre architecture d'informations autour d'elle. Le problème avec ce type de comportement de l'utilisateur est que les pistes de navigation sont effondrées et ne fonctionneront pas sauf si vous ajoutez une autre dimension ... mais c'est une autre histoire ...