Faire reconnaître à l'utilisateur qu'il écrit une note / un message public plutôt qu'une note / un message privé
Nous créons une application métier personnalisée à laquelle le personnel interne a accès et les clients y ont également un accès limité.
Il y a une option pour le personnel de laisser un commentaire/message à l'autre, et il y a aussi une option pour le personnel de laisser un message au client.
Ce que je ne veux pas, c'est que le personnel pense qu'il se laisse un message, mais en fait c'est un message au client.
L'interface utilisateur est actuellement un tableau comme ci-dessous, cliquer sur les carrés verts ouvre un modal de notes où ils peuvent laisser des messages sur chaque élément (chaque élément est une ligne dans le tableau).
Quel serait un moyen d'avertir les utilisateurs du personnel qu'ils sont sur le point de laisser une note client plutôt qu'une note interne?
Je pensais à une sorte de confirmation sur les notes du client, ou quelque chose de similaire à un captcha (pas si compliqué cependant, quelque chose comme une simple question mathématique, donc ils doivent s'arrêter et réfléchir), mais cela semble un peu exagéré.
Je commencerais par des icônes différentes (et plus grandes) pour les notes dans le tableau/la grille, par exemple.
- une icône de note avec un cadenas pour les notes internes
- et l'icône d'un symbole de chat pour les notes externes
Ensuite, j'envisagerais de rapprocher les icônes, pour rendre les différences entre elles plus visibles (pour empêcher l'utilisateur d'en remarquer une seule). Assurez-vous cependant qu'ils ne sont pas trop proches des écrans tactiles.
Ensuite, je changerais l'interface utilisateur de la note d'écriture pour inclure l'icône dans le titre, suivie de "Write note interne " ou "Write note aux clients ".
Ensuite, je permettrais de changer le type de note si l'utilisateur se confondait en cliquant sur un bouton [changer] qui apparaît à la fin du titre.
Enfin, j'envisagerais d'ajouter une boîte de confirmation pour les notes externes, peut-être l'afficher uniquement aux nouveaux utilisateurs ou aux utilisateurs avec des statistiques spécifiques (par exemple, les utilisateurs qui n'ont pas créé beaucoup de notes).
Exemple de dialogue:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Notez qu'il existe des différences dans:
- l'icône
- le titre
- le texte "ajouter une note"
- le texte du bouton
- le verbe du bouton (enregistrer vs envoyer)
- un lien différent pour les utilisateurs qui ont entré la mauvaise boîte de dialogue
Éditer:
Vous pouvez également ajouter une case à cocher indiquant "Cette note est prête à être publiée" à côté du bouton Envoyer pour vous assurer que personne ne manque la différence.
Je dirais que vous devriez les étiqueter explicitement comme tels:
Peut-être même faire une notification popover de type bootstrap quand ils survolent l'icône verte, Notes du client, qui indique explicitement que These notes are visible to the client!
Mise à jour
Après avoir lu votre commentaire, je voudrais mettre à jour la réponse pour mentionner que l'ajout d'alertes, de confirmations, de captchas, etc. ne sont que des barrages routiers que les utilisateurs apprendront finalement à dépenser le minimum d'efforts requis pour les sortir de leur visage.
Une question mathématique ou Captcha ne se traduit pas nécessairement par Are you sure you should be doing this? mais plutôt We don't want spam so complete this mindless task please.
Éduquer l'utilisateur jusqu'au point d'économiser est, à mon avis, la meilleure voie car il devrait invoquer un processus de réflexion pendant tout le temps plutôt que de simplement se produire quelque chose à la dernière seconde.
Cela dit, je peux également recommander d'ajouter une ligne de texte rouge sous la zone de texte indiquant quelque chose comme These notes will be visible to the client.
Tout d'abord, ne comptez jamais sur les utilisateurs pour lire quoi que ce soit. Ne pas. À. Tout. Ils ne le feront pas, et au moment où vous leur expliquez que l'étiquette était Bon! Là! Sur! Leur! Écran!, le mal est déjà fait.
Envisagez de rendre la micro-interaction pour composer une note visible par le client très différente - et légèrement plus difficile - que d'écrire une note interne.
Par exemple, vous pouvez autoriser les utilisateurs à composer une note interne simplement en cliquant sur l'une des icônes de la colonne "Design Notes".
Dans la colonne "Notes client", vous pouvez leur demander de cliquer et de maintenir enfoncé pour afficher un menu déroulant qui dit "Composer une note client" (ou la langue appropriée). Les icônes de la colonne peuvent être accompagnées du symbole "▾" familier pour leur faire savoir qu'il s'agit d'un menu, pas d'un simple bouton.
Rendre le style d'interaction plus facile pour les notes internes "sûres" que les notes clients potentiellement "dangereuses" donne à vos utilisateurs une pause momentanée pour se rappeler qu'ils écrivent pour un public différent.
Request Tracker (un système de ticket d'incident) gère très bien cela.
Il contient à la fois des commentaires (qui sont des messages internes) et de la correspondance (qui est envoyée aux utilisateurs finaux).
Lors de la rédaction d'un message, l'arrière-plan de la zone de texte est blanc pour les commentaires et rouge clair (#fcc) pour la correspondance.
La couleur d'arrière-plan rouge vous fait vous arrêter un instant et réfléchit à qui vous envoyez cela - ce qui fonctionne bien. L'envoi accidentel d'un message client au personnel n'est pas un gros problème, mais l'envoi de messages personnel au client peut l'être.
Voici quelques captures d'écran de la façon dont Request Tracker le gère, légèrement censurées:
Commentaire - Communication interne
Correspondance - Communication client
Comme vous pouvez le voir sur les captures d'écran, la couleur de la zone de texte change. Vous avez également la possibilité de basculer entre le commentaire et la correspondance à partir de cet écran et d'ajouter des personnes à CC. Grâce au changement de couleur, nous ne l'obtenons presque jamais en arrière et n'envoyons que des commentaires au personnel à nos clients.
Je pense que la solution la plus simple et la plus efficace serait de changer les étiquettes et l'interface des deux modaux. Il y a donc une différence contextuelle et visuelle entre les deux fonctions. Parce que maintenant les deux fonctions différentes sont presque les mêmes en termes de Look & Feel, les gens sont susceptibles de penser que cela fonctionnera de la même manière et confondra la sortie des deux fonctions différentes.
Je suggère d'étiqueter les notes de conception internes de la même manière: "Notes de conception" et les notes du client sur: "Messages au client". Laissez les "Design Notes" ressembler à de vraies notes collantes (jaunes). Modifiez l'interface des "Messages au client" en bulles, pour qu'elle ressemble à un message.
Les notes aux clients sont-elles également montrées en interne aux autres membres du personnel? Les notes aux clients ont-elles la même structure et les mêmes informations que les notes utilisées en interne?
Si c'est le cas, sur l'écran de rédaction du message, pensez à utiliser une simple case à cocher juste avant le bouton "Publier" qui dit:
[] Mettre cette note à la disposition du client
[Note de poste] annuler
Sur la table que vous avez, envisagez de combiner la note de conception et les notes client ensemble dans une seule colonne comme le type de note et affichez "Conception (privée)" ou "Client (public)". Différentes couleurs seraient bonnes.
Utilisez des principes de conception fondamentaux pour créer une distinction visuelle entre les éléments.
En utilisant la couleur, la mise en page, la typographie et l'échelle, vous pouvez indiquer à l'utilisateur à un niveau fondamental qu'il existe deux types de notes différents.
La plupart des autres commentateurs ont souligné l'un de ces concepts (mise en page), mais n'ont pas abordé les autres principes fondamentaux de la conception afin de créer une distinction visuelle. Pour la solution de conception la plus efficace, vous devez utiliser tous ces éléments pour indiquer à l'utilisateur qu'il existe deux types de notes en cours de création. Je suis d'accord avec @dland que vous ne devez jamais compter sur l'utilisateur pour lire quoi que ce soit (cela devrait être un signal visuel secondaire), c'est pourquoi vous devez communiquer visuellement la distinction.
Bien que je n'ai pas le temps de vraiment concevoir cela pour vous, jetez un œil à cette image et notez les différences entre elle et ci-dessus:
Avec de simples modifications, il devient plus clair intuitivement que vous regardez des choses différentes. Ajouter de la couleur aux colonnes signifie visuellement que ce sont des choses différentes. De plus, l'utilisation d'une nuance de rouge indique que cela peut être quelque chose qui pourrait être potentiellement dangereux. L'utilisation d'une iconographie différente est également une indication visuelle supplémentaire que ces deux types d'éléments sont différents.
Ces repères visuels, une fois reportés dans les dialogues modaux, renforcent encore la distinction entre les éléments:
Bien que ceux-ci soient au mieux rudimentaires, vous pouvez voir où je veux en venir. Le problème de conception, en fin de compte, est qu'il n'y a pas suffisamment de contraste pour indiquer qu'il s'agit de deux éléments distincts. En utilisant et en manipulant les principes de conception fondamentaux, vous créez une meilleure solution de conception.
Sur une autre note, je pense que le problème pourrait être résolu plus simplement en améliorant l'architecture de l'information. Étant donné que les notes aux clients sont plus potentiellement dangereuses, peut-être y accéder se trouverait-il dans une autre partie de l'application. Peut-être plutôt que d'accéder aux fonctionnalités des notes aux clients dans l'objet lui-même, vous pourriez avoir un système de messagerie où vous composez un message, puis sélectionnez le ou les objets auxquels appliquer ce commentaire.
Inverser la structure relationnelle du message rendra plus intuitif, en outre, que vous créez un type de message différent. À mon avis, ce serait la meilleure solution globale:
Pour composer une note de conception, vous accédez à l'objet , puis vous y joignez une note
Pour composer une note client, vous accédez d'abord à la note puis y attachez un objet
De plus, puisque théoriquement la même note client pourrait s'appliquer à plusieurs objets, cela permettrait à un utilisateur d'attacher une seule note à plusieurs objets. Sinon, ils devraient entrer à nouveau ou copier-coller afin de joindre la même note à plusieurs objets client. Cela peut être pertinent ou non pour votre application, bien sûr, mais d'un point de vue théorique est applicable.
En fin de compte, en améliorant l'architecture de l'information (c'est-à-dire en accédant aux différents types de notes dans différents domaines) ainsi qu'une amélioration de vos concepts de conception fondamentaux (couleur, typographie, échelle, mise en page), vous produirez une application bien conçue.
Bien que je ne sois pas un fan d'eux, si cela est suffisamment important pour que vous ayez eu des discussions internes envoyées au client dans le passé, la boîte d'alerte ye olde peut être la plus appropriée ici:
Si cela a été dommageable dans le passé, cela peut entraîner une modification du flux de travail, c'est-à-dire que les notes des clients restent masquées jusqu'à ce qu'un gestionnaire/superviseur les ait examinées.
Je pense que vous devriez essayer de différencier les colonnes plus distinctement, quelque chose comme ça (j'ai également déplacé les deux colonnes dans une seule pseudo-colonne):
Sur l'image ci-dessus:
- J'ai utilisé des liens numérotés pour montrer combien de commentaires sont attachés aux éléments: l'utilisation de nombres au lieu des icônes similaires améliorera la perception.
- J'ai utilisé différentes couleurs pour rendre ces colonnes visuellement différentes.
Concernant les dialogues "Nouveau message". Je pense que vous pouvez faire la même astuce: utilisez des couleurs différentes pour les titres ou pour les boutons "soumettre" pour les rendre plus visuellement distincts.
Voici une approche complètement différente, mentionnée jusqu'ici. Si nous considérons l'idée que les notes à l'utilisateur qui les soumet sont toujours la même chose, il s'agit donc de savoir où ils soumettent.
Voici un exemple du populaire programme agile JIRA
Lorsque vous écrivez un commentaire sur le côté du bouton d'envoi, une liste déroulante "public cible" est définie par l'application, de sorte que les personnes qui ne sont pas supposées voir les notes ne le font pas, mais les personnes avec tous les accès voient toutes les notes.
Je voudrais donc modifier votre modal comme suit:
télécharger la source bmml - Wireframes créés avec Balsamiq Mockups
Où (1) est le nouveau menu déroulant dans la fenêtre modale, que lorsque vous sélectionnez chaque public (2) sera mis à jour avec le type de note que vous soumettez. Par programmation, vous n'avez désormais plus qu'une seule fenêtre à gérer et à travers AJAX mettez à jour chaque fenêtre en fonction du public cible.
De plus, vous ne pouvez pas soumettre avant d'avoir sélectionné le public, une fois que vous l'avez, vous voyez le bouton ajouter une note.
Qu'en est-il de changer le texte du bouton "Enregistrer" en "Enregistrer public" et "Enregistrer privé" respectivement (ou quelque chose de similaire). Si vous voulez le rendre encore plus clair, donnez-leur différentes couleurs. Après un certain temps, vos utilisateurs associeraient les couleurs à des messages privés/publics.
Quelques options
- Fournissez un filigrane dans la zone de texte où ils entrent
- Sur l'onglet, prévenez-les
- quand ils commencent à saisir du texte, mettez en surbrillance la bordure de la zone de texte d'une manière spécifique
Notre objectif ici est de donner une certaine reconnaissance au personnel interne à qui ils notent. Il ne sert donc à rien de modifier le modal. Laissez le même modal être utilisé à la fois pour le client interne et le client (bien sûr, le titre du contenu sera séparé). Cela gardera également le code optimisé et la redondance peut être évitée.
Permet à la place de faire un seul changement dans le rendu du tableau.
- Fusionner les deux colonnes de notes en une seule colonne
- En haut de cette colonne fusionnée, ajoutez une liste déroulante avec des options comme sélectionner des notes/notes internes/notes client
Comment cela vous aidera:
- Chaque fois que le personnel devra aller dans la liste déroulante, sélectionnez l'option appropriée et seules les notes seront affichées.
- Il n'y aura pas de confusion lors de l'envoi de notes car à la fois seul type de notes est visible.
Cela peut être l'un des moyens les moins chers en termes de modifications de conception et de code. Me fait connaître tout visuel requis, mais cela devrait être compréhensible.
J'ai l'impression que vous pouvez simplement afficher la fenêtre contextuelle quand ils cliquent pour créer une note et après avoir terminé la note, ils peuvent ensuite appuyer sur un bouton d'envoi qui inviterait une alerte disant "Cette note sera pour le client, cliquez sur oui pour continuer "ou" Ceci est pour l'équipe de conception, cliquez sur oui pour continuer. En cliquant sur oui, ils sont ramenés à cette page, presque un système à sécurité intégrée. Juste une suggestion, j'espère que cela vous aidera.
Dans le tableau, je suivrais @alexeypegov pour indiquer si (et combien) de notes existent dans les catégories respectives. Si vous découvrez qu'il n'y a pas de note client après avoir cliqué sur l'icône, vous avez perdu un temps et une énergie précieux.
En ce qui concerne la conception pop-up, je n'aime pas l'approche pour compliquer les notes des clients (par des cases à cocher à publier ou - horriblement - voulez-vous-vraiment-vouloir-publier-cette-note). La tâche est simple et devrait donc être la conception de l'interaction.
À cette fin, je voudrais concevoir les différentes boîtes de dialogue clairement différentes: Dans les notes du client, ajoutez "TO:" plus le nom du client (image, adresse, tout ce que vous avez), tandis que dans les notes du personnel, mettez simplement dans "<nom_utilisateur> a dit:". Utilisez des termes différents pour le bouton d'envoi, par exemple "Enregistrer" (court) contre "Publier au client" (long). Selon la façon dont vous pouvez jouer, utilisez des éléments visuels comme le fond de papier brouillon par rapport à la disposition des lettres.
Pensez à deux pièces, une où vous parlez au personnel et une où vous parlez aux clients: il y a généralement des meubles différents, l'un a du café, mais la porte fonctionne de manière identique. Présentez les différentes boîtes de dialogue avec suffisamment de différences pour que l'utilisateur ressent immédiatement la présence du client.
Je vous suggère de vous débarrasser de ces gros textes en rouge. Utilisez plutôt une couleur spécifique (par exemple orange clair) pour l'arrière-plan de la zone de texte ainsi que pour la colonne Notes du client. Et utilisez "Partager avec le client" au lieu de "Enregistrer".
Quel est le problème avec simplement changer les titres modaux:
(Privé) Notes de conception
et..