S'appuyer sur la sensibilisation des utilisateurs en sélectionnant automatiquement ou inciter l'utilisateur à choisir activement?
Je suis tombé sur un petit dilemme dans mon développement, à savoir si en tant que concepteur, je devrais compter sur un utilisateur pour examiner activement les paramètres avant de soumettre une action, justifiant ainsi qu'elle soit prédéfinie, ou laisser l'utilisateur choisir activement le paramètre avant de soumettre.
Un exemple hypothétique:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Considérez les exemples ci-dessus. L'utilisateur effectuera une action assez sensible et devra sélectionner quelle entreprise doit être propriétaire d'un actif précieux. La zone de liste déroulante contiendra une petite quantité d'articles, plusieurs fois elle n'en contient qu'un et rarement plus de cinq. Dans le cas où un utilisateur choisit le mauvais propriétaire, cela entraînera des efforts supplémentaires et des maux de tête pour régler la situation.
Remarque, il s'agit d'un scénario hypothétique.
Les exemples ci-dessus diffèrent par le fait que l'auto supérieur sélectionne l'élément supérieur dans la zone de liste déroulante avec la possibilité qu'il soit le propriétaire prévu et l'utilisateur puisse continuer immédiatement. Dans le deuxième exemple, la zone de liste déroulante n'a pas de sélection et l'utilisateur ne peut pas continuer avant qu'une sélection n'ait été effectuée.
Lequel de ces deux exemples serait le plus approprié dans cette situation? J'ai couru avec le second depuis que l'action a été introduite, mais je me suis récemment demandé s'il devait être prédéfini ou non. Surtout après avoir remarqué que mon service bancaire a des combobox prédéfinies sur quel compte je souhaite effectuer des transactions et vers quel compte l'argent doit également être effectué chaque fois que j'effectue une transaction en ligne. Apparemment, ils tiennent pour acquis que l'utilisateur examinera les paramètres avant de continuer et les a donc prédéfinis.
La meilleure option dépend en grande partie de:
- Avec quelle facilité cela peut être annulé sans effet néfaste
- Dans quelle mesure votre choix est-il intelligent (a-t-il une valeur par défaut raisonnable, comme la dernière option utilisée?)
- Combien de fois ils vont rencontrer ça
D'après votre question, je suppose que cela ne peut pas être facilement annulé sans conséquences, donc # 1 est théorique. Si cela pouvait facilement être annulé, je serais plus enclin à autoriser une option "par défaut" si il s'agit d'une action souvent répétée. Comme il ne le peut pas, vous devriez déjà vous méfier de la prudence.
S'il n'y a pas de valeur par défaut logique, n'utilisez pas de valeur par défaut. L'ordre alphabétique/le premier élément de la boîte n'est pas un défaut logique; ne remplissez pas la liste déroulante avec le premier élément comme celui-ci. L'ordre alphabétique est effectivement un ordre aléatoire dans ce cas.
Si votre boîte va préremplir, elle doit être quelque chose comme "Je modifie cette société, donc par défaut pour cette société" ou "la dernière entrée de cette même session était X, je remplirai le champ avec X". Même si c'est le cas, nous devons encore considérer le point # 3, la fréquence d'utilisation.
Si c'est une action rare et dangereuse qui se produit peut-être une fois par semaine ou même une fois par jour, je forcerais certainement un choix. Si une action est rare et dangereuse, la certitude supplémentaire est vitale. Vous privilégiez l'heuristique et l'efficacité à l'efficacité, car le gain d'efficacité est mineur et les risques sont majeurs. Les actions rares ont le problème supplémentaire que les utilisateurs peuvent oublier des détails importants comme l'endroit où votre application obtient la valeur par défaut, donc s'il y a une chance que votre utilisateur oublie, ne faites pas d'hypothèses risquées.
À partir d'ici, c'est un jeu de chiffres; si je vais remplir ce formulaire 500 fois avec les mêmes données et que vous ne le remplissez pas par défaut, ça va être frustrant. Si je vais le remplir 500 fois avec des valeurs différentes presque à chaque fois, un défaut serait frustrant! Trouvez le cas d'utilisation le plus courant, mais faites preuve de prudence sauf si vos utilisateurs ou vos données indiquent que vous êtes trop prudent.
Normalement, je suis fan de l'utilisation de préréglages appropriés pour faciliter les progrès. Cependant, cette déclaration me signale qu'une action de forçage peut être requise:
Dans le cas où un utilisateur choisit le mauvais propriétaire, cela entraînera des efforts supplémentaires et des maux de tête pour régler la situation.
Si l'effort requis pour nettoyer une erreur est bien plus important que l'effort de confirmation de la sélection, je serais enclin à y penser avec le deuxième exemple.
Pour cette réponse, je suppose que vous avez pris en compte ces facteurs:
- Toutes les interactions précédentes dans le flux qui restreignent le choix des entreprises. (C'est-à-dire que la liste déroulante n'afficherait que les entreprises éligibles. Réduire la gêne)
- Il n'y a pas de fenêtre après l'action quand elle peut être facilement annulée.
Il y a une très grande partie du livre de Robert Hoekman Jr Designing the Evvious qui met l'accent sur la prévention des erreurs, également connu sous le nom de "poke Yoke".
Je pense qu'un bon exercice serait de tester ces deux interfaces et de déterminer combien d'erreurs sont commises. Je pense généralement qu'il est préférable de donner le contrôle à l'utilisateur s'il s'agit d'une étape importante et impossible à annuler plutôt que de présélectionner la vitesse.