Etat inactif des boutons, cacher ou ne pas cacher ... telle est la question
Sur une application LOB basée sur Windows pour la capture de données. Est-il préférable de masquer complètement un bouton lorsqu'il est inactif, ou simplement d'afficher un état désactivé pour le bouton.
Comme pour tant de questions concernant l'UX, la réponse commence par "Ça dépend". En effet, l'UX est inévitablement basée sur le contexte et l'action.
Quelques arguments pour utiliser un état désactivé:
- Même s'il n'est pas utilisé, l'utilisateur a la possibilité d'apprendre que l'action est possible. Vous pouvez même avoir une info-bulle expliquant les critères d'utilisation.
- L'utilisateur peut savoir où vivent les commandes et les boutons dans l'interface. Cela suppose que si beaucoup sont cachés en même temps, la structure sera moins claire. (Selon votre conception).
Quelques arguments pour cacher le bouton:
- Clarté. Montrer uniquement ce qui est nécessaire pour la tâche à accomplir. L'attention est concentrée.
- Il vous permet de modifier les contrôles, en utilisant le même espace pour différents moyens. Gmail fait cela. C'est pratique quand il se passe beaucoup de choses.
Les questions que vous devez vous poser sont
- "De quoi l'utilisateur a-t-il besoin savoir à ce stade?"
- "De quoi l'utilisateur a besoin pour faire à ce stade?"
N'oubliez pas qu'aucun écran n'est isolé. Chaque cadre permet de raconter l'histoire. Donc, si vous pouvez établir une idée ou un modèle auparavant, les exigences de cet écran peuvent changer.
Alors que la simplicité est un grand objectif (éventuellement en ne montrant pas le bouton), vous ne devez jamais simplifier plus que nécessaire. Par conséquent, si l'utilisateur doit connaître l'existence du bouton ou si vous devez créer le contexte, vous devrez peut-être le considérer.
Un bon régime de test devrait vous le dire.
Je dirais que masquer complètement le bouton peut ajouter de la confusion à l'utilisateur, car les autres options (non masquées) peuvent ne pas avoir autant de sens lorsque vous ne connaissez pas les alternatives.
Permettez-moi de donner un exemple:
Si le bouton que l'utilisateur peut voir est "ancien" et qu'il y a un bouton opposé caché - le bouton caché peut être "nouveau" ou "jeune" car ils sont tous les deux opposés au même mot.
OK, ce n'est pas un exemple idéal, mais je pense que les utilisateurs aiment avoir une vue holistique plus complète de la situation dans laquelle ils se trouvent et cacher des données peut en supprimer.
Certains pourraient dire que si l'autre bouton est désactivé, cela n'a pas d'importance car l'option disponible est toujours la même, mais je dirais toujours qu'un utilisateur devrait recevoir autant d'informations que possible sur sa position dans l'UX.
Je suis d'accord avec Jay que cela dépend. Mais voici une directive que vous voudrez peut-être considérer: Masquer un bouton uniquement si les autorisations de l'utilisateur déterminent qu'il ne peut pas effectuer l'action du bouton. De cette façon, chaque utilisateur aura une vue cohérente du produit, qui peut changer d'un utilisateur à l'autre.
Je suis d'accord avec les réponses cela dépend. Mais pour le décomposer aussi bien que possible dans cette situation, vous devez vérifier quelles informations le bouton communique s'il est masqué ou affiché. Faites un flux d'utilisateur pour cette partie et vous verrez si l'utilisateur peut rester bloqué sur le bouton caché ou non.