如果您为非技术受众编程，您会发现自己面临很高的风险，即用户不会阅读您措辞谨慎且富有启发性的错误消息，而只是沮丧地单击第一个可用的按钮。
所以，我想知道你可以推荐什么好的做法来帮助用户真正阅读你的错误信息，而不是简单地放弃它。我能想到的想法将遵循以下原则：
编辑：我心目中的受众是一个相当广泛的用户群，他们不经常使用该软件并且没有被俘虏（即，没有内部软件或狭窄的社区）。这个问题的一个更通用的形式是在slashdot上提出的，所以你可能想在那里查看一些答案。
这是一个很好的问题，值得我 +1。尽管问题很简单，但它涵盖了最终用户性质的许多方面。它归结为许多因素，这些因素将使您和软件本身受益，当然还有最终用户。
编辑：特别感谢gnibbler，他还提到了另一个非常重要的点！
编辑#2：我的错！哎呀，多亏了DanM提到这辆车，我把名字弄混了，是福特平托……我的错……
编辑#3：由ed突出显示以指示附加或附录，并记入其他人的输入...
编辑#4：回应 Ken 的评论 - 这是我的看法......不，不是，使用中性标准 Windows 颜色......不要追求华丽的颜色！坚持使用带有黑色文本的普通灰色背景，这是 Microsoft 规范中的普通标准 GUI 指南。请参阅UX 指南( ed )。
如果您坚持使用华丽的颜色，至少要考虑到潜在的色盲用户，即可访问性，这对于残障人士来说是另一个重要因素，屏幕放大友好的错误消息，色盲，患有白化病的人，他们可能对华丽的颜色敏感，癫痫患者也很敏感......谁可能患有可能引发癫痫发作的特定颜色......
向他们展示信息。尽职调查等等，但将每个错误记录到文件中。用户不记得他们在做什么或事件发生后几秒钟的错误消息是什么，这就像犯罪者的目击证人。
提供一种允许他们通过电子邮件发送或将日志上传给您的好方法，以便您可以帮助他们解决问题。如果它是一个 Web 应用程序：更好的是，您可以在任何人报告问题之前收到有关情况的信息。
简短的回答：你不能。
不那么简短的答案：让它们可见、相关和上下文相关（突出显示它们搞砸的地方）。但是，您仍然在打一场失败的战斗。人们不会在电脑屏幕上阅读，他们会扫描，而且他们已经被训练去点击按钮，直到对话框消失。
根据您的用户群，编写有趣/粗鲁/个人的错误消息可能会很好。
例如，我编写了一个应用程序，它允许我们的人力资源人员更好地跟踪员工的雇用/解雇日期。[我们是一家小公司，非常悠闲]。
当他们输入错误的日期时，我会写：
嘿笨蛋，学习如何输入日期！
编辑：当然，更有用的消息是说：“请输入日期为 mm/dd/yyyy”，或者在代码中尝试找出他们输入的内容，以及他们是否输入“blahblah”以显示错误。但是，对于我个人认识的 HR 人员来说，这是一个非常小的应用程序。因此，人们再次阅读这篇文章的第一行：取决于您的用户群......
我最近在一个艺术学院的项目上工作，所以错误信息是针对观众的，例如：
巴洛克时期之前的大多数艺术品都没有签名。但是，我们现在已经过了巴洛克时期，所以必须完成所有领域。
如果可能的话，基本上将它提供给你的听众，避免无聊，因为所有超乎寻常的一般错误，例如：“请输入电子邮件”或“请输入有效的电子邮件”。
警报/弹出窗口很烦人，这就是为什么每个人都会点击他们看到的第一个按钮。
让它不那么烦人。示例：如果用户输入了错误的日期，或者输入了需要数字的文本，则不要弹出消息，只需突出显示该字段并在其周围写一条消息。
制作自定义消息框。永远不要使用系统的默认消息框，例如 Windows XP 的消息框本身就很烦人。制作一个新的彩色消息框，其背景颜色与系统默认颜色不同。
非常重要：不要坚持。有些消息框使用模态对话框并坚持让你阅读它，这很烦人。如果您可以使消息框显示为警告消息，那就更好了，例如，堆栈溢出消息出现在页面顶部，通知但不烦人。
更新
使信息有意义和有用。例如，不要写“找不到键盘，请按 F1 继续”之类的内容。
我们在错误框中放了一个简单易记的图形：不是一个图标，一个相当大的位图，和标准的 Windows 消息图标完全不同。没有人能记住消息框的措辞（如果框有可以按下的“确定”按钮，大多数人甚至不会阅读），但大多数人确实记得他们看到的图片。所以我们的支持人员可以问客户“你看到那个喝咖啡的人了吗？” 或“你看到空桌子了吗？”。至少这样我们就大致知道出了什么问题。
最好的 UI 设计将是您几乎从不显示错误消息的地方。软件应该适应用户。使用这种设计，错误消息将是新颖的，并会引起用户的注意。如果你用无意义的对话来吸引用户，你就是在明确地训练他们忽略你的消息。
根据我的观点和经验，不阅读错误消息的是高级用户。我认识的非技术观众最仔细地阅读屏幕上的每条信息，而此时的问题主要是：他们不理解它。
这一点可能是你经历的原因，因为在某些时候他们会停止阅读它们，因为“他们无论如何也不明白”，所以你的任务很简单：
使错误消息尽可能易于理解，并将技术部分隐藏在幕后。
例如，我传输这样的消息：
ORA-00237：快照操作不允许：新创建的控制文件原因：尝试调用 cfileMakeAndUseSnapshot 与当前已安装的控制文件是用 CREATE CONTROLFILE 新创建的。行动：安装当前控制文件并重试操作。
类似于：
由于数据库暂时出现问题，无法处理此步骤。请联系（您的管理员|帮助台|可以联系开发人员或管理员解决问题的任何人）。带来不便敬请谅解。
向用户表明错误消息是有意义的，这是向他们提供帮助的一种方式，他们会阅读它。如果它只是行话或一般的废话信息，他们将学会快速地忽略它们。
我了解到，包含一个错误对话框和默认操作以发送（例如通过电子邮件）详细诊断信息是非常好的做法，如果您快速回复这些电子邮件并提供有价值的信息或解决方法，他们会崇拜您。
这也是一个很好的学习工具。在未来的版本中，您可以解决已知问题或至少提供就地解决方法信息。在那之前，用户将了解到这条消息是由 X 引起的，而问题可以由 Y 解决——这一切都是因为有人向他们解释过。
当然，这不适用于大型应用程序，但在拥有数百名用户的企业应用程序中以及在精益敏捷、经常提前发布的环境中运行良好。
编辑：
由于您拥有广泛的用户群，因此我建议您提供能够满足用户/可以期望的软件，例如。如果电话号码格式不正确，请不要向他们显示错误消息，如果为他们重新格式化。
我个人喜欢不会让我思考的软件，当你（开发人员）偶尔无法解释我的意图时，提供一个写得很好（并由实际用户审查）的消息。
众所周知，人们不阅读文档（当您插入家用电器时，您是否背靠背阅读说明？），他们尝试一种快速获得结果的方法，当失败时您必须引起他们的注意（例如。暂时禁用默认按钮）提供有意义且有用的信息。他们不关心你的软件故障，他们想现在就得到结果。
我学到的一个很好的技巧是你应该写一个像报纸文章一样的对话框。不是在大小意义上，而是在重要性意义上。让我解释。
您应该首先编写最重要的要阅读的内容，然后提供更详细的信息。
换句话说，这不好：
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?
相反，更改顺序：
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.
这样，用户可以随心所欲地阅读，或者打扰，并且仍然对所询问的内容有所了解。
我经常将错误显示为红色（当设计允许时）。
红色代表“警报”等，因此更常被阅读。
首先，编写用户可以真正理解的错误消息。“错误：1023”不是很好的例子。我认为更好的方法是记录错误，而不是用一些“花哨”的代码向用户展示。或者，如果无法进行日志记录，请为用户提供正确的方式将错误详细信息发送给支持部门。
另外，要简短明了。不要包含一些技术细节。不要向他们展示他们无法使用的信息。如果可能，请提供该错误的解决方法。如果不提供默认路由，则应采用该路由。
如果您的应用程序是 Web 应用程序，那么设计自定义错误页面是一个好主意。他们对用户的压力较小，以 SO 为例。您可以在这里获得一些如何设计一个好的错误页面的想法：http ://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/
根据我的经验：您不会让用户（尤其是非技术用户）阅读错误消息。无论您显示的消息多么清晰易懂、粗体、红色和闪烁，大多数用户只会点击他们不习惯的任何内容，即使它是“您真的要删除所有内容吗？”。我看到用户点击“窗口关闭”图标而不是“确定”或“取消”，即使他们甚至不知道他们这样做选择了哪个选项......
如果您确实需要强制用户阅读您所显示的内容，我建议您使用 JavaScript 倒计时，直到按钮可点击为止。这样，用户就有希望利用等待时间来真正阅读他应该阅读的内容。不过要小心：大多数用户会对此更加恼火:)
我还喜欢你的“阅读更多”链接的想法，尽管我怀疑这会让用户更感兴趣，只是想通过各种方式摆脱消息......
仅作记录：有些用户确实会阅读错误消息，但害怕他们不会对它做任何事情。我曾经接到一个支持电话，客户会向我读到一条错误消息，问我他应该怎么做。“嗯，你有什么选择？”，我问。“这个窗口只有一个‘OK’按钮。”他回答道。...嗯，很难的一个:)
让他们变得有趣。（考虑到我们所在的网站，这似乎很相关:)）
除非您可以为用户提供一些简单的解决方法，否则根本不要费心向用户显示错误消息。没有意义，因为 90% 的用户不会关心它说什么。
另一方面，如果您实际上可以向用户展示一个有用的解决方法，那么强制他们阅读它的一种方法是让 OK 按钮在 10 秒左右后变为启用状态。每当您尝试安装新插件时，Firefox 是如何做到的。
如果这是一个你无法从容地恢复的完全崩溃，那么用非常外行的方式通知用户说：
“很抱歉我们搞砸了，我们想发送一些关于这次崩溃的信息，你能允许我们这样做吗？是/否”
另外，尽量不要让你的错误信息超过一个句子。当人们（包括我）看到一整段都在谈论这个错误时，我的大脑就会停止工作。
在如此多的社交媒体和信息超载的情况下，当人们看到一堵文字墙时，他们的思想就会冻结。
有人最近还建议使用连环画以及您想要显示的任何信息。例如来自Dilbert的内容可能与您可能遇到的错误类型接近。
我想补充一件事。
为您的操作按钮使用动词来关闭您的错误消息而不是感叹号，例如不要使用“Ok！” “关闭”等
我们告诉用户他们的经理已被联系（这是一个谎言）。它工作得有点太好了，不得不被删除。
好吧，直接回答你的问题：不要让你的程序员写你的错误信息。如果您遵循这条建议，您将累计节省数千小时的用户焦虑和生产力以及数百万美元的技术支持成本。
然而，真正的目标应该是设计您的应用程序，以便用户不会犯错误。不要让他们采取导致错误消息并要求他们备份的操作。举个简单的例子，在需要填写所有字段的 Web 表单中，当用户单击“发送”按钮时不会弹出错误消息，在所有字段都包含有效内容之前不要启用“发送”按钮。这意味着在背面有更多的工作，但它会带来更好的用户体验。
当然，这有点理想化的世界。有时，程序错误是不可避免的。当它们确实发生时，您需要提供清晰、完整和有用的信息，最重要的是，不要将系统暴露给用户，也不要责怪用户的行为。
一个好的错误信息应该包含：
您可以做的最糟糕的事情之一就是将系统错误消息传递给用户。例如，当您的 Java 程序抛出异常时，不要简单地将程序员语言传递给 UI 并将其公开给用户。抓住它，并让您的用户帮助开发人员创建一个清晰的消息，您可以将其呈现给您的用户。
我很幸运，在我的上一份工作中，与一个不会考虑编写自己的错误消息的程序员团队一起工作。每当他们发现自己处于需要一个程序并且无法设计程序来避免它（通常是因为资源有限）的情况下，他们总是来找我，解释他们需要什么，并让我创建一条错误消息，清晰并遵循公司风格。如果这是每个程序员的默认思维方式，那么计算世界将是一个更好的地方。
更少的错误
如果应用程序定期向您抛出呕吐物，您就会对它免疫，并且错误会成为令人讨厌的背景音乐。如果错误是罕见的事件，它将引起更多关注。
Quosh 任何不是大事的事情，扔掉所有这些警告，找到理解用户意图的方法，尽可能地做出决定。我有一些应用程序，我会继续以这种方式精简它们。开发人员认为每个错误都很重要，但从用户的角度来看并非如此。寻找用户对问题的共同响应并捕获它，并将其部署为您的响应。
如果您确实需要提出错误：简短、简洁、恐怖系数低、没有感叹号。段落失败。
没有灵丹妙药，但您需要进行社会工程以使错误变得重要。
添加一个启用更多技术细节的“高级”按钮将激励那些认为自己是技术的目标受众阅读它
我建议您在犯错后立即提供反馈（说明用户犯了错误）。（例如，在输入日期字段的值时，检查该值，如果错误，使输入字段在视觉上有所不同）。
如果页面上有错误（我更喜欢 Web 开发，因此我将其称为“页面”，但它也可以称为“表单”），显示“错误摘要”，解释那里是错误和究竟发生了什么错误的项目符号列表。但是，如果每条消息的字数超过 5-6 个，则不会被阅读/理解。
如何将按钮设置为“单击此处与将帮助您解决此问题的支持技术人员交谈”。
有许多网站提供与真人交谈的选项。
我读到了 slashdot 上最可怕的解决方案的候选人：
我们发现，让用户对错误负责的唯一方法是惩罚他们迫使错误消失。对于初学者，在可能的情况下，除非我们输入管理员密码以使其消失，否则错误不会真正为他们关闭，如果他们重新启动以摆脱它（任务管理器在所有客户端 PC 上被禁用），机器将不会打开崩溃 15 分钟的应用程序。当然，这一切都取决于您正在处理的用户类型，因为技术更熟练的用户不会接受这种系统，但在尝试了几年后让用户对崩溃负责并确保 IT 部门意识到他们为了在问题变得难以管理之前解决问题，这些是唯一有效的步骤。现在，
“注意！注意！如果你不阅读错误信息，你会死！”
尽管接受的答案中有所有建议，但我的用户继续点击他们能找到的第一个按钮。所以现在我展示这个：
用户必须在 OK 按钮出现之前做出选择
如果他选择第三个选项，他可以继续，否则应用程序退出。