web-dev-qa-db-fra.com

Options multiples vs interface utilisateur à option unique

Sur le tableau de bord que nous construisons, nous avons 2 ensembles d'options que les utilisateurs peuvent choisir:

Plusieurs options (cases à cocher) enter image description here

et options uniques (comportement des boutons radio)

enter image description here

bien que l'apparence des composants soit similaire, leurs utilisations sont différentes.

Dans les tests d'utilisabilité, les utilisateurs ont utilisé ces composants sans aucune difficulté ou une fois qu'ils ont utilisé et compris les fonctionnalités, ils n'ont eu aucun problème pour les utiliser dans les autres parties du produit.

Mais, mes collègues concepteurs ont fait valoir que les composants devraient être différents et que les utilisateurs doivent comprendre si c'est une case à cocher ou une boîte radio dès le premier coup d'œil.

Mon objectif était de garder la cohérence et de réduire la charge cognitive.

Des réflexions ou des suggestions?

Edit 1: Mise à jour de l'interface utilisateur, merci @ 200_success pour les commentaires

33
Deniz Erdal

Ça dépend. À quelle fréquence vos utilisateurs voient-ils ce formulaire/cette section/ces paramètres?

Les applications à session longue et fréquemment utilisées permettent aux utilisateurs de se souvenir du fonctionnement des contrôles, en particulier ceux fréquemment utilisés.

Une partie de cela a à voir avec Posture d'application .

Une application souveraine est un programme qui monopolise l'attention de l'utilisateur pendant de longues périodes.

Google docs et Microsoft Word sont d'excellents exemples d'applications de posture souveraine : les utilisateurs passent de longues périodes à manipuler des documents.

Les utilisateurs cibles sont généralement des intermédiaires, qui rencontrent ces contrôles à plusieurs reprises au cours d'une longue utilisation.

Certains contrôles qui semblent identiques mais se comportent différemment ne posent pas trop de difficultés après une exposition répétée et prolongée.

La plupart d'entre nous se sont habitués à la barre d'outils, comme l'a souligné un autre post:

enter image description here Un autre exemple est OmniFocus, l'application de gestion des tâches.

Le panneau d'inspection affiche les détails des événements répétés et planifiés. Il a une bascule multi-sélection indiquant les jours de la semaine pour inclure un événement. Cela a le même effet que les cases à cocher:

enter image description here

Le modèle mental des événements est plus clair pour commencer, ce qui aide probablement à utiliser ces contrôles:

Les événements ont:

  • Dates de début
  • Dates de fin
  • Fréquences
  • Répétition

Par exemple, il est clair pour moi que je peux aller en cours de karaté dimanche, lundi et mercredi. Je peux sélectionner plusieurs jours selon mes besoins.

Les formulaires uniques, les pages de paramètres rarement consultées et l'interface utilisateur rarement rencontrée peuvent être difficiles sans étiquettes et/ou contrôles clairs.

Je ne suis pas clair sur votre contexte plus large, mais un étiquetage clair est crucial pour les utilisateurs rencontrant votre formulaire pour la première fois, ou rarement:

enter image description here

Il semble que vous soyez bien placé, comme cela a été confirmé par les tests des utilisateurs. Gardez à l'esprit que dans certains contextes, vous concevrez des perpétuels `` débutants '' qui s'aventurent dans un territoire inconnu.

33
Mike M

Vous n'avez pas besoin de faire des apparences différentes pour ces composants.

Votre cas est similaire à des bascules bien connues dans une barre d'outils de processeurs de texte comme Word. Ces paramètres de police bascule agissent comme des cases à cocher:

enter image description here

Et ces commandes d'alignement de Word agissent comme des boutons radio:

enter image description here

Remarque, ils ont un aspect identique et cela ne produit aucune confusion ni difficulté car dans notre modèle mental (vue de l'utilisateur sur le fonctionnement du système), nous comprenons qu'un morceau de texte peut être en gras, souligné et cursif simultanément, nous nous attendons donc à ce que les bascules doivent agir comme des cases à cocher. Et nous comprenons que le texte ne peut pas être aligné à droite et à gauche simultanément, ce n'est donc pas une surprise pour nous que les commandes d'alignement agissent comme des boutons radio. Nous le savons et nous n'avons pas besoin de rappels supplémentaires à ce sujet.

Vous avez écrit que lors des tests d'utilisabilité, les utilisateurs ont utilisé ces composants sans aucune difficulté. Je pense que cela signifie que le comportement des composants correspond au modèle mental de l'utilisateur, c'est-à-dire que les utilisateurs comprennent et s'attendent à pouvoir choisir plusieurs tranches d'âge et une seule vue (listes ou miniatures).

J'ai pris l'exemple des bascules de Word dans "About Face 3. The Essentials of Interaction Design" d'A. Cooper. Il a écrit à ce sujet comme exemple d'une approche plus graphique et plus économe en espace de la case à cocher ou des boutons radio (voir Chapitre 21: Commandes, cases à cocher (p. 443) et boutons Radio (p. 446)). Et Cooper n'a pas dit que ces deux types de bascules doivent avoir un aspect différent.

52
Lana

Je pense que vos collègues designers ont raison.

Si je regarde maintenant les options, j'ai une idée directe de la façon dont je peux interagir avec elles et de leur utilisation.

enter image description here

enter image description here

L'utilisation des carrés pour les cases à cocher et des cercles pour les boutons radio est très ancienne, courante et reconnaissable pour la plupart des utilisateurs. Donc, cela résout simplement votre problème dans ce cas.

6
Asqan

La plupart des utilisateurs normaux ne connaissent pas la différence entre un bouton radio et un bouton de vérification. Tout au plus, ils s'énervent parfois lorsque vous ne pouvez pas activer plusieurs boutons radio là où cela aurait du sens.

Se passer d'une différence visuelle ne déroutera pas un seul utilisateur - ils verront que dans certains cas, sélectionner une chose supprime l'autre sélection, et dans d'autres cas non. Et ils s'en moquent, surtout si cela a du sens.

Si vous voulez qu'ils aient une différence, pourquoi ne pas utiliser les coins arrondis pour les boutons radio (peut-être même entre les options) et les coins inclinés avec les cases à cocher? La conception reste simple, et les personnes "au courant" peuvent voir la différence immédiatement.

1
Carl Dombrowski