Comment amener les utilisateurs à lire les messages d'erreur?

Si vous programmez pour un public non technique, vous courez un risque élevé que les utilisateurs ne lisent pas vos messages d'erreur soigneusement formulés et éclairants, mais cliquez simplement sur le premier bouton disponible avec un haussement d'épaules de frustration.

Je me demande donc quelles bonnes pratiques vous pouvez recommander pour aider les utilisateurs à lire réellement votre message d'erreur, au lieu de simplement le renoncer. Les idées auxquelles je peux penser seraient du type:

• Formatage bien sûr aide; peut-être un message simple et court, avec un bouton "En savoir plus" qui mène au message d'erreur plus long et plus détaillé
• Avoir tous les messages d'erreur liés à une section du guide de l'utilisateur (quelque peu difficile à réaliser)
• Ne publiez pas de messages d'erreur, refusez simplement d'exécuter la tâche (une manière un peu «Apple» de gérer les entrées utilisateur)

Edit: le public que j'ai en tête est une base d'utilisateurs assez large qui n'utilise pas le logiciel trop souvent et qui n'est pas captive (c'est-à-dire pas de logiciel interne ou de communauté restreinte). Une forme plus générique de cette question a été posée sur slashdot , vous voudrez peut-être y vérifier certaines des réponses.

C'est une excellente question digne d'un +1 de ma part. La question, bien que simple, couvre de nombreux aspects de la nature des utilisateurs finaux. Cela se résume à un certain nombre de facteurs qui seraient avantageux pour vous et le logiciel lui-même, et bien sûr pour les utilisateurs finaux.

• Ne placez pas de messages d'erreur dans la barre d'état - ils ne les liront jamais même s'ils sont agrémentés de couleurs, etc. ils les manqueront toujours! Peu importe à quel point vous essaierez ... À un moment donné lors du test de l'interface utilisateur Win 95 avant son lancement, MS a mené une expérience pour lire l'interface utilisateur ( ed - il convient de noter que le message explicitement indiqué dans le contexte de `` Regardez sous la chaise '' ), avec un billet de 100 dollars collé sous la chaise sur laquelle les sujets étaient assis ... personne n'a repéré le message dans la barre d'état!
• Faites des messages courts, n'utilisez pas de mots intimidants tels que `` Alerte: le système a rencontré un problème '', l'utilisateur final va appuyer sur le bouton panique et réagira de manière excessive ...
• Peu importe vos efforts, n'utilisez pas de couleurs pour identifier le message ... psychologiquement, cela revient à brandir un drapeau rouge au taureau!
• Utilisez des mots neutres pour exprimer une réaction minimale et comment procéder!
• Il peut être préférable d'afficher une boîte de dialogue répertoriant le message d'erreur neutre et d'inclure une case à cocher indiquant `` Souhaitez-vous voir plus de ces messages d'erreur à l'avenir? '', La dernière chose qu'un utilisateur final souhaite, c'est de travailler au milieu du logiciel pour être bombardés de messages popup, ils seront frustrés et seront désactivés par l'application! Si la case est cochée, enregistrez-la plutôt dans un fichier ...
• Tenez les utilisateurs finaux informés des messages d'erreur qu'il y aura ... ce qui implique ... formation et documentation ... maintenant c'est difficile à faire passer ... vous ne voulez pas qu'ils pensent qu'il y aura être des «problèmes» ou des «pépins» et que faire dans ce cas ... ils ne doivent pas savoir qu'il y aura des erreurs possibles, délicates en effet.
• Toujours, toujours, n'ayez pas peur de demander des commentaires lorsque le sans incident se produit - comme `` Lorsque cette erreur numéro 1304 est apparue, comment avez-vous réagi? Quelle était votre interprétation '- le bonus avec cela, l'utilisateur final pourra peut-être vous donner une explication plus cohérente au lieu de' Erreur 1304, objet de base de données perdu! ', Au lieu de cela, il pourra peut-être dire' J'ai cliqué dessus et ainsi, alors quelqu'un a accidentellement tiré le câble réseau de la machine », cela vous indiquera comment y faire face et peut modifier l'erreur pour dire« Ooops, connexion réseau déconnectée »... vous obtenez la dérive.
• Enfin, si vous souhaitez cibler un public international, prenez en compte l'internationalisation des messages d'erreur - c'est pourquoi le garder neutre, car alors il sera plus facile à traduire, évitez les synonymes, les mots d'argot, etc. la traduction n'a pas de sens - par exemple, Fiat Ford, le constructeur automobile vendait sa marque Fiat Ford Pinto, mais a remarqué qu'aucune vente n'avait lieu en Amérique du Sud, il s'est avéré que Pinto était un argot là-bas pour `` petit pénis '' et donc aucune vente ...
• ( Ed ) document la liste des messages d'erreur à prévoir dans une section distincte de la documentation intitulée « Messages d'erreur » ou « actions correctives » ou similaires, la liste des numéros d'erreur dans l'ordre avec une déclaration ou deux sur la façon de procéder. ..
• ( ed ) Merci à Victor Hurdugaci pour sa contribution, gardez les messages polis, ne faites pas que les utilisateurs finaux se sentent stupides. Cela va à l'encontre de la réponse de Jack Marchetti si la base d'utilisateurs est internationale ...

Edit: Un mot spécial de remerciement à gnibbler qui a également mentionné un autre point extrêmement vital!

• Permettez à l'utilisateur final de pouvoir sélectionner / copier le message d'erreur afin qu'il puisse, s'il le souhaite, l'envoyer par courrier électronique à l'équipe d'assistance ou de développement.

Edit # 2: Mon mauvais! Oups, grâce à DanM qui a mentionné qu'à propos de la voiture, j'ai confondu le nom, c'était Ford Pinto ... mon mauvais ...

Edit # 3: Ont mis en évidence par ed pour indiquer des ajouts ou des addenda et crédités à d'autres pour leurs contributions ...

Edit # 4: En réponse au commentaire de Ken - voici mon avis ... Non, ce n'est pas le cas, utilisez des couleurs Windows standard neutres ... n'allez pas pour les couleurs flashy! Tenez-vous-en à la couleur de fond grise normale avec du texte noir, qui est une directive GUI standard standard dans les spécifications Microsoft .. voir UX Guidelines ( ed ).

Si vous insistez sur les couleurs flashy, au moins, prenez en compte les utilisateurs potentiels daltoniens, c'est-à-dire l' accessibilité qui est un autre facteur important pour ceux qui ont un handicap, les messages d'erreur favorables au grossissement de l'écran, le daltonisme, ceux qui souffrent d'albinos, ils peuvent être sensibles aux couleurs flashy, et aux épileptiques aussi ... qui peuvent souffrir d'une couleur particulière qui pourrait déclencher une crise ...

Montrez-leur le message. Dilligence raisonnable et tout, mais enregistrez chaque erreur dans un fichier. Les utilisateurs ne se souviennent pas de ce qu'ils faisaient ou du message d'erreur quelques secondes après l'événement, c'est comme des témoignages oculaires de perpatrateurs.

Fournissez un bon moyen de leur permettre de vous envoyer un e-mail ou de télécharger le journal afin que vous puissiez les aider à résoudre le problème. S'il s'agit d'une application Web: mieux encore, vous pouvez recevoir des informations sur la situation avant que quiconque ne signale le problème.

Réponse courte: vous ne pouvez pas.

Réponse moins courte: rendez-les visibles, pertinents et contextuels (mettez en évidence ce qu'ils ont raté). Mais encore, vous menez une bataille perdue. Les gens ne lisent pas sur les écrans d'ordinateur, ils numérisent et ils ont été formés pour cliquer sur les boutons jusqu'à ce que les boîtes de dialogue disparaissent.

Nous mettons un graphique simple et mémorable dans la boîte d'erreur: pas une icône, un bitmap assez grand et rien de tel que les icônes de message Windows standard. Personne ne peut jamais se souvenir du libellé d'une boîte de message (la plupart ne la liront même pas si la boîte a un bouton "OK" sur lequel ils peuvent appuyer), mais la plupart des gens se souviennent de l'image qu'ils ont vue. Ainsi, nos collaborateurs peuvent demander au client "Avez-vous vu le type qui boit du café?" ou "avez-vous vu le bureau vide?". Au moins de cette façon, nous savons à peu près ce qui n'a pas fonctionné.

Selon votre base d'utilisateurs, écrire des messages d'erreur drôles / grossiers / personnels peut très bien fonctionner.

Par exemple, j'ai rédigé une application qui a permis à nos RH de mieux suivre les dates d'embauche / licenciement des employés. [nous étions une petite entreprise, très décontractée].

Quand ils entraient de mauvaises dates, j'écrivais:

Hé idiot, apprends à entrer une date!

EDIT: Bien sûr, un message plus utile est de dire: "Veuillez entrer la date sous forme de mm / jj / aaaa" ou peut-être dans le code pour essayer de comprendre ce qu'ils ont entré et s'ils ont entré "blahblah" pour afficher une erreur. Cependant, c'était une toute petite application pour une personne des ressources humaines que je connaissais personnellement. Par conséquent, encore une fois les gens, lisez la première ligne de cet article: Selon votre base d'utilisateurs ...

J'ai récemment travaillé sur un projet Art Institute, donc les messages d'erreur étaient orientés vers le public, tels que:

La plupart des œuvres d'art avant la période baroque n'étaient pas signées. Cependant, nous sommes maintenant au-delà de la période baroque, donc tous les champs doivent être remplis.

En gros, adaptez-le à votre public si possible, et évitez l'ennui comme toutes les erreurs générales surnaturelles telles que: «veuillez entrer un e-mail» ou «veuillez saisir un e-mail valide».

Les alertes / popups sont ennuyeux, c'est pourquoi tout le monde clique sur le premier bouton qu'il voit.

Rendez-le moins ennuyeux . Exemple: si l'utilisateur a mal saisi la date ou saisi un texte où des chiffres sont attendus, NE PAS afficher de message, il suffit de mettre en surbrillance le champ et d'écrire un message quelque part autour de lui.

Créez une boîte de message personnalisée . N'utilisez jamais la boîte de message par défaut du système, par exemple les boîtes de message de Windows XP sont elles-mêmes ennuyeuses. Créez une nouvelle boîte de message colorée, avec une couleur d'arrière-plan différente de celle par défaut du système.

Très important: n'insistez pas . Certaines boîtes de message utilisent la boîte de dialogue Modal et insistent pour vous la faire lire, c'est très ennuyeux. Si vous pouvez faire apparaître la boîte de message comme un message d'avertissement, ce serait mieux, par exemple, les messages Stack Overflow qui apparaissent juste en haut de la page, informant mais pas ennuyeux.

MISE À JOUR
Rendre le message significatif et utile . Par exemple, n'écrivez pas quelque chose comme «Aucun clavier trouvé, appuyez sur F1 pour continuer».

La meilleure conception d'interface utilisateur sera celle où vous n'afficherez pratiquement jamais de message d'erreur. Le logiciel doit s'adapter à l'utilisateur. Avec ce type de conception, un message d'erreur sera nouveau et attirera l'attention des utilisateurs. Si vous parez l'utilisateur de dialogues insensés comme celui-là, vous l'entraînez explicitement à ignorer vos messages.

À mon avis et selon mon expérience, ce sont les utilisateurs expérimentés qui ne lisent pas les messages d'erreur. Le public non technique que je connais lit chaque message à l'écran avec le plus grand soin et le problème à ce stade est principalement: ils ne le comprennent pas.

Ce point peut être la cause de votre expérience, car à un moment donné, ils cesseront de les lire, car "ils ne le comprennent pas de toute façon", donc votre tâche est facile:

Rendre le message d'erreur aussi simple que possible à comprendre et garder la partie technique sous le capot.

Par exemple, je transfère un message comme celui-ci:

ORA-00237: opération d'instantané interdite: fichier de contrôle nouvellement créé Cause: Une tentative d'appel de cfileMakeAndUseSnapshot avec un fichier de contrôle actuellement monté qui a été nouvellement créé avec CREATE CONTROLFILE a été effectuée. Action: montez un fichier de contrôle actuel et recommencez l'opération.

à quelque chose comme:

Cette étape n'a pas pu être traitée en raison de problèmes momentanés avec la base de données. Veuillez contacter (votre administrateur | le helpdesk | toute personne pouvant contacter le développeur ou l'administrateur pour résoudre le problème). Désolé pour le dérangement.

Montrez aux utilisateurs que le message d' erreur a une signification , et c'est un moyen de leur fournir de l'aide et ils le liront. S'il ne s'agit que d'un jargon-bable ou d'un message générique, ils apprendront à les rejeter rapidement.

J'ai appris que c'est une très bonne pratique d'inclure une boîte de dialogue d'erreur avec une action par défaut pour envoyer (par exemple par e-mail) des informations de diagnostic détaillées, si vous répondez rapidement à ces e-mails avec des informations précieuses ou une solution de contournement, ils vous adoreront.

C'est aussi un excellent outil d'apprentissage. Dans les versions futures, vous pouvez résoudre les problèmes connus ou au moins fournir des informations de contournement sur place. Jusque-là, les utilisateurs apprendront que ce message est causé par X et le problème peut être résolu par Y - tout cela parce que quelqu'un leur a expliqué.

Bien sûr, cela ne fonctionnera pas sur une application à grande échelle, mais fonctionne très bien dans les applications d'entreprise comptant quelques centaines d'utilisateurs, et dans un environnement Lean Agile, à libération anticipée souvent.

ÉDITER:

Étant donné que vous avez une large base d'utilisateurs, je recommande de fournir un logiciel qui fait ce que les utilisateurs sont / peuvent s'attendre à faire, par exemple. ne leur montrez pas de message d'erreur si le numéro de téléphone n'est pas bien formaté, reformatez-le si c'est pour eux.

Personnellement, j'aime les logiciels qui ne me font pas réfléchir , et quand parfois vous (le développeur) ne pouvez rien faire pour interpréter mon intention, fournissez des messages très bien écrits (et examinés par les utilisateurs réels).

Il est communément admis que les gens ne lisent pas la documentation (avez-vous lu les instructions dos à dos quand vous avez branché un appareil électroménager?), Ils essaient un moyen d'obtenir des résultats rapidement, en cas d'échec, vous devez attirer leur attention (par exemple. désactiver le bouton par défaut pendant un certain temps) avec des informations significatives et utiles . Ils ne se soucient pas de l'échec de votre logiciel, ils veulent obtenir des résultats, maintenant.

Rendez-les amusants . (Cela semblait pertinent, compte tenu du site sur lequel nous sommes :))

Pour commencer, rédigez des messages d'erreur que les utilisateurs peuvent réellement comprendre. "Erreur: 1023" n'est pas un bon exemple. Je pense que le meilleur moyen est de consigner l'erreur, que de la montrer à l'utilisateur avec un code "sophistiqué". Ou si la journalisation n'est pas possible, donnez aux utilisateurs un moyen approprié d'envoyer les détails de l'erreur au service d'assistance.

Aussi, soyez suffisamment bref et clair. N'incluez pas certains détails techniques. Ne leur montrez pas d'informations qu'ils ne peuvent pas utiliser. Si possible, fournissez une solution de contournement pour l'erreur. Sinon, fournissez un itinéraire par défaut, cela devrait être pris.

Si votre application est une application Web, la conception de pages d'erreur personnalisées est une bonne idée. Ils stressent moins les utilisateurs, prenez SO par exemple. Vous pouvez obtenir quelques idées pour concevoir une bonne page d'erreur ici: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Une chose que j'aimerais ajouter.

Utilisez des verbes pour vos boutons d'action pour fermer vos messages d'erreur plutôt que des exclamations, par exemple, n'utilisez pas "Ok!" "Fermer" etc.

Un bon conseil que j'ai appris est que vous devriez écrire une boîte de dialogue comme un article de journal. Pas dans le sens de la taille, mais dans le sens de l'importance. Laissez-moi expliquer.

Vous devez d'abord écrire les choses les plus importantes à lire, puis fournir des informations plus détaillées.

En d'autres termes, ce n'est pas bon:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Au lieu de cela, changez l'ordre:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

De cette façon, l'utilisateur peut lire autant qu'il le souhaite, ou le dérange, tout en ayant une idée de ce qui lui est demandé.

Voir également les réponses des utilisateurs de Slashdot ici .

À moins que vous ne puissiez fournir à l'utilisateur une solution simple, ne vous souciez pas du tout d'afficher un message d'erreur à l'utilisateur. Cela ne sert à rien, car 90% des utilisateurs ne se soucient pas de ce qu'il dit.

D'un autre côté, si vous POUVEZ montrer à l'utilisateur une solution de contournement utile, une façon de le forcer à la lire est d'activer le bouton OK après environ 10 secondes. Voici comment Firefox le fait chaque fois que vous essayez d'installer un nouveau plug-in.

S'il s'agit d'un crash total dont vous ne pouvez pas récupérer gracieusement, informez l'utilisateur en termes très simples en disant:

" Je suis désolé que nous ayons foiré, nous aimerions envoyer des informations sur ce crash, nous permettrez-vous de le faire? OUI / NON "

De plus, essayez de ne pas rendre vos messages d'erreur plus longs qu'une phrase. Quand les gens (moi y compris) voient un paragraphe entier parler de l'erreur, mon esprit s'arrête.

Avec autant de médias sociaux et de surcharge d'informations, l'esprit des gens se fige lorsqu'ils voient un mur de texte.

ÉDITER:

Quelqu'un a récemment suggéré d'utiliser des bandes dessinées avec le message que vous voulez montrer. Comme quelque chose de Dilbert qui peut être proche du type d'erreur que vous pourriez avoir.

D'après mon expérience: vous n'obligez pas les utilisateurs (en particulier les utilisateurs non techniques) à lire les messages d'erreur. Même si le message que vous affichez est clair et compréhensible, gras, rouge et clignotant, la plupart des utilisateurs cliquent simplement sur tout ce à quoi ils ne sont pas habitués, même si c'est "Voulez-vous vraiment tout supprimer?". J'ai vu des utilisateurs cliquer sur l'icône "Fermer la fenêtre" au lieu de "OK" ou "Annuler" même s'ils ne savaient même pas quelle option ils avaient choisie en le faisant ...

Si vous avez vraiment besoin de forcer les utilisateurs à lire ce que vous affichez, je suggérerais un compte à rebours JavaScript jusqu'à ce qu'un bouton soit cliquable. De cette façon, l'utilisateur utilisera, espérons-le, le temps d'attente pour vraiment lire ce qu'il est censé faire. Attention cependant: la plupart des utilisateurs seront encore plus agacés par cela :)

J'aime en outre votre idée d'un lien "en savoir plus", même si je doute que cela intéressera davantage les utilisateurs qui veulent simplement se débarrasser du message par tous les moyens ...

Juste pour mémoire: il y a des utilisateurs qui lisent les messages d'erreur mais qui ont tellement peur de ne rien faire avec. Une fois, j'ai eu un appel de support où le client me lisait un message d'erreur, me demandant ce qu'il devait faire. "Eh bien, quelles sont vos options?", Ai-je demandé. "La fenêtre n'a qu'un bouton" OK "", répondit-il. ... mmh, difficile :)

J'affiche souvent l'erreur en rouge (lorsque le design le permet).

Le rouge signifie «alerte», etc. donc il est plus souvent lu.

Eh bien, pour répondre directement à votre question: ne demandez pas à vos programmeurs d'écrire vos messages d'erreur. Si vous suivez ce conseil, vous économiserez, cumulativement, des milliers d'heures d'angoisse et de productivité des utilisateurs et des millions de dollars en frais de support technique.

Le véritable objectif, cependant, devrait être de concevoir votre application afin que les utilisateurs ne puissent pas faire d'erreur. Ne les laissez pas prendre des mesures qui conduisent à des massages d'erreur et les obligent à reculer. À titre d'exemple simple, dans un formulaire Web qui nécessite que tous ses champs soient remplis, au lieu d'afficher un message d'erreur lorsque les utilisateurs cliquent sur le bouton Envoyer, n'activez pas le bouton Envoyer tant que tous les champs ne contiennent pas de contenu valide. Cela signifie plus de travail à l'arrière, mais cela se traduit par une meilleure expérience utilisateur.

Bien sûr, c'est un peu un monde idéal. Parfois, des erreurs de programme sont inévitables. Lorsqu'elles se produisent, vous devez fournir des informations claires, complètes et utiles et, surtout, ne pas exposer le système à l'utilisateur et ne pas blâmer les utilisateurs pour leurs actions.

Un bon message d'erreur doit contenir:

1. Quel est le problème et pourquoi c'est arrivé.
2. Comment résoudre le problème.

L'une des pires choses que vous puissiez faire est simplement de transmettre des messages d'erreur système aux utilisateurs. Par exemple, lorsque votre programme Java lève une exception, ne transmettez pas simplement le programmeur à l'interface utilisateur et l'exposez à l'utilisateur. Attrapez-le et faites créer un message clair par votre développeur d'assistance utilisateur que vous pouvez présenter à votre utilisateur.

J'ai eu la chance, lors de mon dernier travail, de travailler avec une équipe de programmeurs qui ne penserait pas à écrire ses propres messages d'erreur. Chaque fois qu'ils se trouvaient dans une situation où il en fallait un et que le programme ne pouvait pas être conçu pour l'éviter (souvent en raison de ressources limitées), ils venaient toujours me voir, m'expliquaient ce dont ils avaient besoin et me permettaient de créer un message d'erreur qui était clair et suivi du style de l'entreprise. Si c'était la mentalité par défaut de tout programmeur, le monde informatique serait un endroit bien, bien meilleur.

Moins d'erreurs

Si une application vous jette régulièrement du vomi sur vous, vous en devenez immunisé et les erreurs deviennent un fond irritant. Si une erreur est un événement rare, elle attirera plus d'attention.

Quosh tout ce qui n'est pas un problème majeur, jetez tous ces avertissements, trouvez des moyens de comprendre l'intention de l'utilisateur, prenez les décisions dans la mesure du possible. J'ai quelques applications que je continue de rationaliser de cette manière. Les développeurs considèrent chaque erreur comme importante, mais ce n'est pas vrai du point de vue de l'utilisateur. Recherchez la réponse commune des utilisateurs à un problème et capturez-la, déployez-la comme votre réponse.

Si vous devez signaler une erreur: bref, concis, faible facteur de terreur, pas de point d'exclamation. Les paragraphes sont ratés .

Il n'y a pas de solution miracle, mais vous devez faire de l'ingénierie sociale pour rendre les erreurs importantes.

Nous avons dit aux utilisateurs que leur responsable avait été contacté (ce qui était un mensonge). Cela fonctionnait un peu trop bien et devait être enlevé.

L'ajout d'un bouton "Avancé" qui permet d'obtenir des détails plus techniques incitera à le lire pour la partie du public cible qui se considère comme technique

Je vous suggère de donner votre avis (indiquant que l'utilisateur a commis une erreur) immédiatement après l'erreur. (Par exemple, lors de la saisie d'une valeur d'un champ de date, vérifiez la valeur et, si elle est erronée, rendez le champ de saisie visuellement différent).

S'il y a des erreurs sur la page (je suis plus dans le développement Web, donc je parle de "page", mais cela peut aussi être appelé "formulaire"), montrez un "résumé des erreurs", en expliquant que là étaient des erreurs et une liste à puces de ce qui s'est produit exactement. Cependant, s'il y a plus de 5 à 6 mots par message, ceux-ci ne seront pas lus / compris.

Que diriez-vous de faire en sorte que le bouton indique «Cliquez ici pour parler à un technicien de support qui vous aidera à résoudre ce problème».

Il existe de nombreux sites Web qui offrent la possibilité de parler à une personne réelle.

J'ai lu un candidat pour la solution la plus horrible sur slashdot:

Nous avons constaté que la seule façon de responsabiliser les utilisateurs pour les erreurs est de leur infliger une pénalité pour avoir forcé l'erreur à disparaître. Pour commencer, dans la mesure du possible, l'erreur ne se fermera pas pour eux à moins que nous n'entrions un mot de passe administrateur pour le faire disparaître, et s'ils redémarrent pour s'en débarrasser (le gestionnaire de tâches est désactivé sur tous les PC clients), la machine n'ouvrira pas le application qui a planté pendant 15 minutes. Bien sûr, tout dépend du type d'utilisateurs avec lesquels vous avez affaire, car des utilisateurs plus techniquement compétents n'accepteraient pas ce type de système, mais après avoir essayé pendant des ANNEES littéralement de responsabiliser les utilisateurs en cas de crash et de s'assurer que le service informatique est au courant. afin de résoudre le problème avant qu'il ne devienne trop difficile à gérer, ce sont les seules étapes qui ont fonctionné. Maintenant,

"ATTENTION! ATTENTION! Si vous ne lisez pas le message d'erreur, vous MOURREZ!"

Malgré toutes les recommandations de la réponse acceptée, mes utilisateurs ont continué à cliquer sur le premier bouton qu'ils pouvaient trouver. Alors maintenant, je montre ceci:

L'utilisateur doit faire un choix avant que le bouton OK n'apparaisse

S'il sélectionne la 3ème option, il peut continuer, sinon l'application se ferme.