Absence de rétroaction négative vs présence de rétroaction positive
Quelqu'un connaît-il des recherches ou des lignes directrices sur le fait de savoir si/quand s'appuyer sur l'absence de rétroaction négative est plus approprié que de fournir une rétroaction positive explicite?
Contexte: Je travaille sur une interface utilisateur riche en informations avec de nombreux tableaux et autres, ce qui est bien pour le public pour lequel nous concevons. Pour le moment, le seul type de message d'état que vous êtes susceptible de voir sur la page est lorsqu'un élément a généré un avertissement ou une erreur. Si aucun avertissement ou erreur n'est visible, alors tout va bien.
Nous avons eu une conversation aujourd'hui pour savoir si cela suffit, ou si ce serait plus rassurant si on vous montrait explicitement qu'il n'y avait aucun avertissement ou erreur. Toutes choses étant égales par ailleurs, j'imagine que ce serait probablement le cas. Mais dans un affichage riche en informations où chaque pixel est un élément immobilier de premier plan, et tout devrait être "bien" la plupart du temps, trouver l'espace pour afficher qu'il n'y a pas d'avertissement ou d'erreur serait inévitablement signifie devoir réduire légèrement la quantité d'autres informations que nous pourrions afficher.
Bien sûr, nos utilisateurs seront les arbitres ultimes pour lesquels les informations sont les plus importantes pour eux, mais nous nous efforçons de prendre les meilleures décisions de conception possibles jusqu'à ce que nous leur montrions des prototypes :)
EDIT: En réponse à l'une des réponses ci-dessous, il convient de noter que l'interface utilisateur ne surveille pas en permanence les erreurs/avertissements, mais interroge plutôt rarement. En fait, il est fort probable que vous ne vous connectiez au système qu'une ou deux fois par semaine pour vérifier les erreurs/avertissements, plutôt que de le surveiller tout le temps.
Une autre méthode pour fournir le "tout clair" est le prototype de "boîte de notification". C'est une méthode bien reconnue et compatible pour transmettre des messages aux utilisateurs (voir la barre supérieure de StackExchange, la barre supérieure de Google, Facebook, etc.)
- Utilisez une petite quantité d'espace pour une icône et un peu plus pour une condition signalée pour indiquer quand il y a du nouveau contenu.
- En survolant ou en cliquant, l'utilisateur obtient la liste:
- Erreurs et notifications
- Quand ils sont arrivés
- Que l'utilisateur l'ait déjà vu ou pas
- Laissez l'utilisateur effacer les messages individuellement ou en masse.
Cela vous donne également la possibilité d'envoyer des messages sans erreur à l'utilisateur via le même canal de communication commun, ce qui augmente encore la densité des informations et l'utilité de l'outil.
La rétroaction se produit en réponse à un stimulus. Que vous ayez un "feu vert" qui change quand il y a un problème, ou simplement un espace où on leur dit si quelque chose change, ce qui importe, c'est que le seul retour d'information existe quand un changement se produit. Assurez-vous que lorsque des commentaires ont lieu, ils sont visibles et détectables.
Modifier: Compte tenu de votre mise à jour, je vous suggère de voir comment votre système peut prendre en charge les flux de travail de notification - envoyer à l'utilisateur un e-mail, un message texte, une messagerie instantanée (si tous/la plupart des utilisateurs seront sur une plate-forme de discussion accessible comme Lync ou Jabber ). S'ils ne se connectent que quelques fois par semaine pour voir si quelque chose ne va pas, ils ne pourront pas agir en temps opportun.
Il vaut donc mieux que le système fasse le meilleur logiciel, à savoir l'automatisation du stimulus associé au changement d'état. Lorsqu'un événement à signaler se produit, contactez-les et prévenez-les afin qu'ils puissent aller le vérifier.
Le courrier électronique vous donne tout l'espace dont vous avez besoin pour décrire la condition et est vraiment facile à configurer dans la plupart des langues/plates-formes Web. De plus, vous pouvez le faire indépendamment d'avoir à discuter dans une salle de conférence sur les changements d'interface visuelle pour les notifications dans l'application (qui peuvent ensuite être des fenêtres contextuelles, des modaux div, etc. qui ne déplacent pas les éléments existants).
S'il y a un processus continu qui se déroule en arrière-plan ou que vous surveillez, il est logique d'avoir une rétroaction positive continue (le feu vert!).
La rétroaction de toute nature est en réponse à un déclencheur. Elle peut être déclenchée par l'utilisateur ou par le système. Si le déclencheur est continu, je suggérerais également une rétroaction continue.
La manifestation de la rétroaction peut être différente dans différentes situations:
Ordinateurs portables: Apple a supprimé tout indicateur que l'ordinateur portable est allumé (dans les macros de la rétine). Bien qu'il soit un bon argument que lorsqu'un ordinateur portable fonctionne, l'utilisateur peut voir l'écran, c'était un morceau d'accessibilité qui était toujours pratique, par exemple: lorsque votre écran était éteint.
Moniteurs/téléviseurs: ces appareils utilisent toujours un signal visuel pour déclarer leur état, allumé/en veille/éteint (où éteint est l'absence de tout signal)
Bien qu'une rétroaction toujours active puisse être remplacée par une rétroaction conditionnelle (erreur), vous souhaiterez peser tous les scénarios et utilisations avant de passer à cette décision.
La norme de facto que j'ai toujours utilisée est que si rien ne va, l'utilisateur continuera généralement à faire ce qu'il fait. Cependant, lorsque vous avez les avertissements et erreurs appropriés en place et que l'utilisateur glisse et reçoit un avertissement ou une erreur, il convient à ce stade d'avertir l'utilisateur lorsque leur entrée est correcte.
c'est-à-dire si aucune erreur ou avertissement, pas besoin de dire "vous avez raison". Si l'utilisateur provoque une erreur/un avertissement, informez-le lorsque son entrée est acceptable.