Un message d'avertissement peut-il contenir plusieurs messages?
Contexte: J'évalue actuellement une candidature pour une entreprise médicale. Cette application permet certaines tâches à travers le matériel (dispositif médical) pour les patients.
En repensant les messages utilisateur (avertissement, erreur, notifications, etc.), je suis tombé sur un message d'avertissement dans l'application existante, qui doit être affiché pour l'utilisateur (opérateur d'application médicale) du point de vue de la sécurité et de la conformité.
Le problème: l'intention du message est Avertissement. Le titre ressemble à une autorisation. La zone de contenu du message se compose de: 1. Icône d'avertissement et message 2. Icône d'instruction et lien texte pour y accéder 3. Choix du bouton radio et appel à l'action pour "confirmer et démarrer"
La structure du message semble incorrecte à tant de niveaux. Pendant que je ressens ça. Je voudrais valider si cela est vrai et apprécierais vraiment certaines perspectives à ce sujet. D'où la question.
Pour mieux comprendre, un message d'utilisateur de cette nature peut-il être associé à un autre message? 
Doivent-ils toujours exister indépendamment uniquement? Quelqu'un peut-il éclairer une directive de message d'avertissement évoluée?
Pouvez-vous? [~ # ~] oui [~ # ~]
Devriez-vous? Eh bien, cela dépend de nombreux facteurs, mais la réponse rapide est [~ # ~] non [~ # ~] .
Il existe de nombreux articles écrits sur le sujet (un bon début pourrait être celui-ci , qui est très précis mais drôle et facile à lire), mais l'important est de garder ces conseils à l'esprit:
- être informatif sur ce qui s'est passé et ce qui a déclenché l'avertissement
- aide les utilisateurs à savoir quoi faire pour résoudre le problème
- essayez de résoudre le problème par vous-même chaque fois que possible
- alléger l'ambiance et ne blâmer JAMAIS l'utilisateur. L'humour est une bonne idée pour rendre les messages d'erreur plus conviviaux. Et même si vous êtes convaincu que c'est la faute de l'utilisateur, c'est toujours la vôtre. Ou du moins, c'est ce que vous devez dire à l'utilisateur.
En ce qui concerne le degré d'information nécessaire, il suffit de fournir LE PLUS DE BESOINS ET LE PLUS PEU POSSIBLE. Vous pouvez proposer d'étendre les informations si nécessaire, mais la plupart des utilisateurs n'auront besoin que d'un bref. Jetez un œil à l'exemple de Google ci-dessous:
dans ce cas, Google n'affiche que la partie supérieure: Titre et une brève description. Cependant, vous pouvez voir qu'il y a beaucoup plus d'informations une fois développées (l'image montre le statut étendu). Ainsi: vous avez une brève description, mais vous proposez à l'utilisateur d'en lire plus si nécessaire. Je pense que votre cas pourrait être assez similaire à cela.
Avertissement vs action de l'utilisateur
Votre maquette montre la possibilité d'agir sur l'avertissement, ce que vous pouvez faire, et cela se fait assez souvent. Cependant, ce n'est pas une bonne idée, car vous éduquez les utilisateurs à être sujets aux erreurs .
S'ils peuvent résoudre les problèmes des avertissements, non seulement vous mélangez les avertissements et les actions, MAIS vous apprenez à l'utilisateur que s'il commet une erreur, il pourra le corriger une fois qu'il le fera. C'est évidemment faux à plusieurs niveaux. De plus, d'un point de vue de la programmation, vous aurez besoin d'un système qui fonctionne dans un "normal" façon, pour ainsi dire, et une autre qui interagit avec les avertissements, ce qui est fou et beaucoup de charge de travail supplémentaire et complètement inutile.
Ainsi, je recommanderais de dire à vos utilisateurs les étapes appropriées à suivre à partir d'une zone appropriée (par exemple, les paramètres). En outre, si nécessaire, assurez-vous que les rôles et les autorisations sont correctement définis. Par exemple: ces actions sur le matériel sont-elles basées sur des autorisations?
De cette façon, en créant une zone où les utilisateurs peuvent choisir ces paramètres, vous pouvez centraliser tout ce qui concerne le comportement/l'interaction du matériel ET les utilisateurs peuvent revenir dans cette zone en cas de besoin. Sinon .... ils devraient faire une erreur pour avoir la possibilité de le résoudre!
Généralement, la règle principale pour afficher un message d'erreur/d'avertissement est de le garder court .
Vous voulez que votre utilisateur puisse lire et concevoir le message d'erreur sans être submergé ou contrecarré. Quelques-unes des façons simples et efficaces de montrer l'erreur avec l'instruction:
- Soulignez le champ de saisie (en cas de) en rouge plutôt que de mettre en surbrillance ou d'afficher une boîte d'alerte.
- Mentionnez l'erreur dans une seule phrase (pas plus que cela) et suivez-la avec le correctif
- Indiquez à l'utilisateur comment corriger l'erreur plutôt que d'expliquer l'erreur
- Dans le cas où l'instruction est trop volumineuse pour être assimilée dans une phrase, avertissez-la avant que l'utilisateur n'entre les données
- Mentionnez toujours le problème/la conséquence plutôt que l'avertissement/l'erreur littérale (comme, il est préférable d'écrire Cette action prendra plus de temps à s'exécuter plutôt que Le téléchargement en masse peut prendre jusqu'à 10 minutes ou plus selon la connexion Internet
Voici un bon exemple d'erreur:
et un mauvais exemple: 
J'espère que cela t'aides