The best UI design will be where you virtually never show an error message. The software should adapt to the user. With that sort of a design, an error message will be novel and will grab the users attention. If you pepper the user with senseless dialogs like that you're explicitly training them to ignore your messages.
In my opinion and experience, it's the power users, who do not read error messages. The nontechnical audience I know reads every message on the screen most carefully and the problem at this point mostly is: They don't understand it.
This point may be the cause of your experience, because at some point they will stop reading them, because "they don't understand it anyway", so your task is easy:
Make the error message as easy to understand as possible and keep the technical part under the hood.
For example I transfer a message like this:
ORA-00237: snapshot operation disallowed: control file newly created
Cause: An attempt to invoke cfileMakeAndUseSnapshot with a currently mounted control file that was newly created with CREATE CONTROLFILE was made.
Action: Mount a current control file and retry the operation.
to something like:
This step could not be processed due to momentary problems with the database. Please contact (your admin|the helpdesk|anyone who can contact the developer or admin to solve the problem). Sorry for the inconvenience.
Show users that the error message has a meaning, and it's a way to provide assistance to them and they will read it. If it's just jargon-bable or generic nonsense message they will learn to dismiss them quicly.
I have learned that is very good practice to include an error dialog with default action to send (eg. via email) detailed diagnostic info, if you quickly respond to those emails with valuable information or workaround, they will worship you.
This is also a great learning tool. In future versions you can solve known-issues or at least provide in-place workaround info. Until then users will learn that this message is caused by X and the problem can by solved by Y - all because someone did explain it to them.
Of course this won't work on a large scale application, but works very well in enterprise applications with few hundred users, and in a lean agile, release early release often, environment.
EDIT:
Since you have a broad user base I recommend to provide software that does what users are/can expect it to do, eg. do not show them eroror message if phone number is not formatted well, reformat if for them.
I personally like software that does not make me think, and when occasionally there is nothing you (the developer) can do to interpret my intention, provide a very well written (and reviewed by actual users) messages.
It's common knowlege that people do not read documentation (did you read instructions back-to-back do when you did plugged in household appliance?), they try a way to get results quickly, when failed you have to grab their attention (eg. disable default button for a while) with meaningful and helpful info. They don't care about your sofware failure, they want to get results, now.
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.
这样，用户可以想读多少就读多少，或者不用费心，但仍然知道所问的内容。
One good tip I've learned is that you should write a dialog box like a newspaper article. Not in the size-sense, but in the importance-sense. Let me explain.
You should write the most important things to read, first, and provide more detailed information second.
In other words, this is no good:
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?
Instead, change the order:
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.
This way, the user can read just as much as he wants, or bothers, and still have an idea about what's being asked.
To start, write error messages that users can actually understand. "Error: 1023" is not good example. I think better way is logging the error, than showing it to the user with some "fancy" code. Or if logging is not possible, give the users proper way to send the error details to the support department.
Also, be short and clear enough. Do not include some technical details. Do not show them information that they cannot use. If possible provide a workaround for the error. If not provide a default route, that should be taken.
Unless you can provide the user some simple work-around, don't bother showing the user an error message at all. There is just no point, since 90% of users won't care what it says.
On the other hand If you CAN actually show the user a useful workaround, then one way to force them to read it is make the OK button become enabled after 10 seconds or so. Sort of how Firefox does it whenever you are trying to install a new plug-in.
If it is a total crash that you cannot gracefully recover from, then inform the user in very layman terms saying:
"I'm sorry we screwed up, we would like to send some information about this crash, will you allow us to do so? YES / NO"
In addition, try not to make your error messages longer than a sentence. When people (me included) see a whole paragraph talking about the error, my mind just shuts off.
With so much social media and information overload, people's mind freeze when they see a wall of text.
EDIT:
Someone once also recently suggested using comic strips along with whatever message you want to show. Such as something from Dilbert that may be close to the type of error you may have.
From my experience: you don't get users (especially non-technical ones) to read error messages. No matter how clear and understandable, bold, red and flashing the message is, that you display, most users will just click anything away that they're not used to, even if it's "Do you really want to delete everything?". I have seen users click the "window close"-icon instead of "OK" or "cancel" even though they didn't even know which option they chose by doing so ...
If you really need to force users to read what you're displaying, I'd suggest a JavaScript-Countdown until a button is clickable. That way the user will hopefully use the waiting time to really read what he's supposed to. Be careful though: most users will be even more annoyed by that :)
I furthermore like your idea of a "read more"-link, although I doubt that will get users more interested that just want to get rid of the message by all means ...
Just for the record: there are users that DO read error messages but are so afraid that they won't do anything with it. I once had a support call where the customer would read an error message to me, asking me, what he should do. "Well, what are your options?", I asked. "The window only has an 'OK'-button.", he replied. ... mmh, hard one :)
然而，真正的目标应该是设计您的应用程序，使用户不会犯错误。不要让他们采取导致错误消息并要求他们备份的操作。举一个简单的例子，在需要填写所有字段的 Web 表单中，当用户单击“发送”按钮时不会弹出错误消息，而是在所有字段都包含有效内容之前不要启用“发送”按钮。这意味着背面需要做更多的工作，但会带来更好的用户体验。
Well, to answer your question directly: Don't have your programmers write your error messages. If you follow this one piece of advice, you'd save, cumulatively, thousands of hours of user angst and productivity and millions of dollars in technical support costs.
The real goal, however, should be to design your application so users can't make mistakes. Don't let them take actions that lead to error massages and require them to back up. As a simple example, in a web form that requires all its fields to be filled in, instead of popping up an error message when users click on the Send button, don't enable the Send button until all the field contain valid content. It means more work on the back side, but it results in a better user experience.
Of course, that's a bit of an ideal world. Sometimes, program errors are unavoidable. When they do occur, you need to provide clear, complete, and useful information, and most importantly, don't expose the system to user and don't blame users for their actions.
A good error message should contain:
What the problem is and why it happened.
How to resolve the problem.
One of the worst things you can do is simply pass system error messages through to users. For example, when your Java program throws an exception, don't simply pass the programmer-ese up to the UI and expose it to the user. Catch it, and have a clear message created by your user assistance developer that you can present to your user.
I was lucky enough, on my last job, to work with a team of programmer who wouldn't think of writing their own error messages. Any time they found themselves in a situation where one was required and the program couldn't be designed to avoid it (often because of limited resources), they always came to me, explained what they needed, and let me create an error message that was clear and followed company style. If that was the default mindset of every programmer, the computing world would be a far, far better place.
If an application throws vomit at you on a regular basis, you become immune to it, and errors become irritating background muzak. If an error is a rare event, it will garner more attention.
Quosh anything which isn't a major deal, throw out all those warnings, find ways of understanding user intent, take out the decisions wherever possible. I have a few apps which I continue to streamline in this way. Developers see every error as important, but this is not true from a user perspective. Look for the users' common response to a problem and capture that, deploy that as your response.
If you do need to raise an error: short, concise, low terror factor, no exclamation marks. Paragraphs are fail.
There's no silver bullet, but you need to socially engineer to make errors important.
Adding an "Advanced" button that enables some more technical details will provide an incentive to read it for the part of the target audience that thinks itself as technical
I'd suggest that you give feedback (stating that the user made a mistake) immediately after the mistake is made. (For instance, when entering a value of a date field, check the value and, if it is wrong, make the input field visually different).
If there are errors on the page (I'm more into web development, hence I'm referring to it as a "page", but it can be also called "form"), show an "error summary", explaining that there were errors and a bulleted list of what exactly errors happened. However, if there are more than 5-6 words per message, those won't be read/understood.
I read a candidate for the most horrific solution on slashdot:
We have found that the only way to
make users take responsibility for
errors is to give them a penalty for
forcing the error to go away. For
starters, where possible, the error
wont actually close for them unless we
enter an admin password to make it go
away, and if they reboot to get rid of
it (Task Manager is disabled on all
client PC's) the machine will not open
the application that crashed for 15
minutes. Of course, this all depends
on the type of users you are dealing
with, as more technically adept users
wouldnt accept this kind of system,
but after trying for literally YEARS
to make users take responsibility for
crashes and making sure the IT
department is aware of them in order
to fix the issue before it gets too
hard to manage, these are the only
steps that worked. Now, all of our end
users are aware that if they ignore
errors, they are going to suffer for
it themselves.
That is an excellent question worthy of a +1 from me. The question despite being simple, covers many aspects of the nature of end-users. It boils down to a number of factors here which would benefit you and the software itself, and of course for the end-users.
Do not place error messages in the status bar - they will never read them despite having it jazzed up with colours etc....they will always miss them! No matter how hard you'll try... At one stage during the Win 95 UI testing before it was launched, MS carried out an experiment to read the UI (ed- it should be noted that the message explicitly stated in the context of 'Look under the chair'), with a $100 dollar bill taped to the underside of the chair that the subjects were sitting on...no one spotted the message in the status bar!
Make the messages short, do not use intimidating words such as 'Alert: the system encountered a problem', the end-user is going to hit the panic button and will over-react...
No matter how hard you try, do not use colours to identify the message...psychologically, it's akin to waving a red-flag to the bull!
Use neutral sounding words to convey minimal reaction and how to proceed!
It may be better to show a dialog box listing the neutral error message and to include a checkbox indicating 'Do you wish to see more of these error messages in the future?', the last thing an end-user wants, is to be working in the middle of the software to be bombarded with popup messages, they will get frustrated and will be turned off by the application! If the checkbox was ticked, log it to a file instead...
Keep the end-users informed of what error messages there will be...which implies...training and documentation...now this is a tricky one to get across...you don't want them to think that there will be 'issues' or 'glitches' and what to do in the event of that...they must not know that there will be possible errors, tricky indeed.
Always, always, be not afraid to ask for feedback when the uneventful happens - such as 'When that error number 1304 showed up, how did you react? What was your interpretation' - the bonus with that, the end-user may be able to give you a more coherent explanation instead of 'Error 1304, database object lost!', instead they may be able to say 'I clicked on this so and so, then somebody pulled the network cable of the machine accidentally', this will clue you in on having to deal with it and may modify the error to say 'Ooops, Network connection disconnected'... you get the drift.
Last but not least, if you want to target international audiences, take into account of internationalization of the error messages - hence that's why to keep it neutral, because then it will be easier to translate, avoid synonyms, slang words, etc which would make the translation meaningless - for example, Fiat Ford, the motor car company was selling their brand Fiat Ford Pinto, but noticed no sales was happening in South America, it turned out, Pinto was a slang there for 'small penis' and hence no sales...
(ed)Document the list of error messages to be expected in a separate section of the documentation titled 'Error Messages' or 'Corrective Actions' or similar, listing the error numbers in the correct order with a statement or two on how to proceed...
(ed) Thanks to Victor Hurdugaci for his input, keep the messages polite, do not make the end-users feel stupid. This goes against the answer by Jack Marchetti if the user base is international...
Edit: A special word of thanks to gnibbler who mentioned another extremely vital point as well!
Allow the end-user to be able to select/copy the error message so that they can if they do so wish, to email to the help support team or development team.
Edit#2: My bad! Whoops, thanks to DanM who mentioned that about the car, I got the name mixed up, it was Ford Pinto...my bad...
Edit#3: Have highlighted by ed to indicate additionals or addendums and credited to other's for their inputs...
Edit#4: In response to Ken's comment - here's my take...
No it is not, use neutral standard Windows colours...do not go for flashy colours! Stick to the normal gray back-colour with black text, which is a normal standard GUI guideline in the Microsoft specifications..see UX Guidelines (ed).
If you insist on flashy colours, at least, take into account of potential colour-blind users i.e. accessibility which is another important factor for those that have a disability, screen magnification friendly error messages, colour-blindness, those that suffer with albino, they may be sensitive to flashy colours, and epileptics as well...who may suffer from a particular colours that could trigger a seizure...
提供一个好方法，让他们通过电子邮件或上传日志给您，以便您可以帮助他们解决问题。如果它是一个 Web 应用程序：更好的是，您甚至可以在任何人报告问题之前就收到有关情况的信息。
Show them the message. Due dilligence and all, but log every error to a file. Users can't remember what they were doing or what the error message was seconds after the event, it's like eye-witness accounts of perpatrators.
Provide a good way to allow them to email or upload the log to you so that you can assist them in reconciling the issue. If it's a web application: even better, you can be receiving information about the situation ahead of anyone even reporting the problem.
Less short answer: Make them visible, relevant, and contextual (highlight what they messed up). But still, you're fighting a losing battle. People don't read on computer screens, they scan, and they've been trained to click the buttons until the dialog boxes go away.
我们在错误框中放置了一个简单易记的图形：不是一个图标，而是一个相当大的位图，与标准的 Windows 消息图标完全不同。没有人能记住消息框的措辞（如果消息框有一个可以按下的“确定”按钮，大多数人甚至不会阅读它），但大多数人确实记得他们看到的图片。因此，我们的支持人员可以询问顾客“你看到那个喝咖啡的人了吗？”或者“你看到空桌子了吗？”。至少这样我们就能大致知道出了什么问题。
We put a simple memorable graphic in the error box: not an icon, a fairly large bitmap, and nothing like the standard Windows message icons. Nobody can ever remember the wording of a messagebox (most won't even read it if the box has an "OK" button they can press), but most people DO remember the picture they saw. So our support people can ask the customer "did you see the coffee-drinking guy?" or "did you see the empty desk?". At least that way we know roughly what went wrong.
Depending on your user base, writing funny/rude/personal error messages can work great.
For instance, I wrote an application which allowed our HR people to better track the hire/fire dates of employees. [we were a small company, very laid back].
When they entered wrong dates I would write:
Hey dumb ass, learn how to enter a date!
EDIT: Of course a more helpful message is to say: "Please enter date as mm/dd/yyyy" or perhaps in code to try and figure out what they entered and if they entered "blahblah" to show an error. However, this was a very small application for an HR person I knew personally. Hence again people, read the first line of this post: Depending on your user base...
I recently worked on an Art Institute project, so the error messages were geared towards the audience, such as:
Most art before the Baroque period was
unsigned. However, we’re beyond the
Baroque period now, so all fields must
be completed.
Basically gear it to your audience if at all possible, and avoid boring as all unearthly general errors such as: "please enter email" or "please enter valid email".
Alerts/popups are annoying, that's why everyone hits the first button they see.
Make it less annoying. Example: if the user entered the date incorrectly, or entered a text where numbers are expected, then DON'T popup a message, just highlight the field and write a message somewhere around it.
Make a custom message box. Do not ever use the default message box of the system, for example Windows XP message boxes are annoying themselves. Make a new colored message box, with a different background color than system default.
Very Important: do not insist. Some message boxes use the Modal dialog and insist on making you read it, this is very annoying. If you can make the message box appear as a warning message it would be better, for example, Stack Overflow messages that appear right on the top of the page, informing but not annoying.
UPDATE Make the message meaningful and helpful. For example, do not write something like, "No Keyboard found, press F1 to continue."
发布评论
评论（25）
最好的 UI 设计是几乎不会显示错误消息。软件应该适应用户。通过这种设计，错误消息将会新颖并吸引用户的注意力。如果你向用户提供诸如此类毫无意义的对话，那么你就是在明确地训练他们忽略你的消息。
The best UI design will be where you virtually never show an error message. The software should adapt to the user. With that sort of a design, an error message will be novel and will grab the users attention. If you pepper the user with senseless dialogs like that you're explicitly training them to ignore your messages.
根据我的观点和经验，高级用户不会阅读错误消息。我认识的非技术受众会非常仔细地阅读屏幕上的每条消息，而此时的问题主要是：他们不理解它。
这一点可能是你经历的原因，因为在某些时候他们会停止阅读它们，因为“他们无论如何也不明白”，所以你的任务很简单：
使错误消息尽可能容易理解并保持引擎盖下的技术部分。
例如我传输这样的消息：
像这样的东西：
In my opinion and experience, it's the power users, who do not read error messages. The nontechnical audience I know reads every message on the screen most carefully and the problem at this point mostly is: They don't understand it.
This point may be the cause of your experience, because at some point they will stop reading them, because "they don't understand it anyway", so your task is easy:
Make the error message as easy to understand as possible and keep the technical part under the hood.
For example I transfer a message like this:
to something like:
向用户表明错误消息有意义，这是向他们提供帮助的一种方式，他们会阅读它。如果只是行话或一般的无意义信息，他们会学会快速驳回它们。
我了解到，包含一个带有默认操作的错误对话框来发送（例如通过电子邮件）详细的诊断信息是非常好的做法，如果您快速回复那些包含有价值的信息或解决方法的电子邮件，他们会崇拜您。
这也是一个很棒的学习工具。在未来的版本中，您可以解决已知问题或至少提供就地解决方法信息。在此之前，用户将了解到此消息是由 X 引起的，而问题可以由 Y 解决 - 所有这些都是因为有人向他们解释了这一点。
当然，这不适用于大规模应用程序，但在具有数百个用户的企业应用程序以及精益敏捷、经常提前发布的环境中效果很好。
编辑：
由于您拥有广泛的用户群，我建议提供能够完成用户正在/可以期望它执行的操作的软件，例如。如果电话号码格式不正确，请不要向他们显示错误消息，如果为他们重新格式化。
我个人喜欢不会让我思考的软件，并且偶尔会有您（开发人员）无法解释我的意图，无法提供写得很好（并由实际用户审核）的消息。
众所周知，人们不阅读文档（当您插入家用电器时，您是否连续阅读说明？），他们尝试一种快速获得结果的方法，当失败时，您有通过有意义和有用信息吸引他们的注意力（例如暂时禁用默认按钮）。他们不关心你的软件故障，他们想立即得到结果。
Show users that the error message has a meaning, and it's a way to provide assistance to them and they will read it. If it's just jargon-bable or generic nonsense message they will learn to dismiss them quicly.
I have learned that is very good practice to include an error dialog with default action to send (eg. via email) detailed diagnostic info, if you quickly respond to those emails with valuable information or workaround, they will worship you.
This is also a great learning tool. In future versions you can solve known-issues or at least provide in-place workaround info. Until then users will learn that this message is caused by X and the problem can by solved by Y - all because someone did explain it to them.
Of course this won't work on a large scale application, but works very well in enterprise applications with few hundred users, and in a lean agile, release early release often, environment.
EDIT:
Since you have a broad user base I recommend to provide software that does what users are/can expect it to do, eg. do not show them eroror message if phone number is not formatted well, reformat if for them.
I personally like software that does not make me think, and when occasionally there is nothing you (the developer) can do to interpret my intention, provide a very well written (and reviewed by actual users) messages.
It's common knowlege that people do not read documentation (did you read instructions back-to-back do when you did plugged in household appliance?), they try a way to get results quickly, when failed you have to grab their attention (eg. disable default button for a while) with meaningful and helpful info. They don't care about your sofware failure, they want to get results, now.
我学到的一个好技巧是，您应该像报纸文章一样编写对话框。不是在规模意义上，而是在重要性意义上。让我解释一下。
您应该首先写下最重要的阅读内容，然后提供更详细的信息。
换句话说，这不好：
相反，改变顺序：
这样，用户可以想读多少就读多少，或者不用费心，但仍然知道所问的内容。
One good tip I've learned is that you should write a dialog box like a newspaper article. Not in the size-sense, but in the importance-sense. Let me explain.
You should write the most important things to read, first, and provide more detailed information second.
In other words, this is no good:
Instead, change the order:
This way, the user can read just as much as he wants, or bothers, and still have an idea about what's being asked.
首先，编写用户可以真正理解的错误消息。 “错误：1023”不是一个好例子。我认为更好的方法是记录错误，而不是用一些“花哨”的代码向用户显示错误。或者，如果无法进行日志记录，请为用户提供将错误详细信息发送给支持部门的正确方法。
另外，要足够简短和清晰。不要包含一些技术细节。不要向他们展示他们无法使用的信息。如果可能，请提供错误的解决方法。如果没有提供默认路由，则应采用该默认路由。
如果您的应用程序是 Web 应用程序，那么设计自定义错误页面是一个好主意。他们对用户的压力较小，以SO为例。您可以在这里获得一些如何设计良好错误页面的想法：http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/
To start, write error messages that users can actually understand. "Error: 1023" is not good example. I think better way is logging the error, than showing it to the user with some "fancy" code. Or if logging is not possible, give the users proper way to send the error details to the support department.
Also, be short and clear enough. Do not include some technical details. Do not show them information that they cannot use. If possible provide a workaround for the error. If not provide a default route, that should be taken.
If your application is a web app, designing custom error pages is a good idea. They stress users less, take SO for example. You can get some ideas how to design a good error page here: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/
让它们变得有趣。 （考虑到我们所在的网站，这似乎是相关的:)）
Make them fun. (It seemed relevant, given the site we're on :) )
我想补充一件事。
使用动词作为操作按钮来关闭错误消息，而不是感叹号，例如不要使用“Ok！” “关闭”等。
One thing I'd like to add.
Use verbs for your action buttons to close your error messages rather than exclamations, example don't use "Ok!" "Close" etc.
除非您可以为用户提供一些简单的解决方法，否则根本不要向用户显示错误消息。毫无意义，因为 90% 的用户不会关心它说什么。
另一方面，如果您可以实际上向用户展示了一个有用的解决方法，那么强制他们阅读它的一种方法是在 10 秒左右后启用“确定”按钮。就像你尝试安装新插件时 Firefox 的做法一样。
如果这是一次您无法正常恢复的彻底崩溃，请用非常通俗的语言通知用户：
“很抱歉我们搞砸了，我们想发送一些有关这次崩溃的信息，您可以允许我们吗？是/否”
此外，尽量不要使错误消息长于句子。当人们（包括我）看到一整段都在谈论这个错误时，我的思绪就停止了。
社交媒体如此之多，信息超载，当人们看到一堵文字墙时，他们的思维就会冻结。
编辑：
最近有人还建议使用连环漫画以及你想展示的任何信息。例如来自 Dilbert 的内容可能与您可能遇到的错误类型接近。
Unless you can provide the user some simple work-around, don't bother showing the user an error message at all. There is just no point, since 90% of users won't care what it says.
On the other hand If you CAN actually show the user a useful workaround, then one way to force them to read it is make the OK button become enabled after 10 seconds or so. Sort of how Firefox does it whenever you are trying to install a new plug-in.
If it is a total crash that you cannot gracefully recover from, then inform the user in very layman terms saying:
"I'm sorry we screwed up, we would like to send some information about this crash, will you allow us to do so? YES / NO"
In addition, try not to make your error messages longer than a sentence. When people (me included) see a whole paragraph talking about the error, my mind just shuts off.
With so much social media and information overload, people's mind freeze when they see a wall of text.
EDIT:
Someone once also recently suggested using comic strips along with whatever message you want to show. Such as something from Dilbert that may be close to the type of error you may have.
根据我的经验：您不会让用户（尤其是非技术人员）阅读错误消息。无论您显示的消息多么清晰易懂、粗体、红色和闪烁，大多数用户都会单击他们不习惯的任何内容，即使是“您真的要删除所有内容吗？”。我见过用户点击“窗口关闭”图标而不是“确定”或“取消”，即使他们甚至不知道他们选择了哪个选项......
如果你真的需要强迫用户阅读你的内容正在显示，我建议使用 JavaScript 倒计时，直到按钮可单击。这样，用户就有希望利用等待时间来真正阅读他应该阅读的内容。不过要小心：大多数用户会对此更加恼火:)
我还喜欢你的“阅读更多”链接的想法，尽管我怀疑这会让用户更感兴趣，只想通过各种方式摆脱该消息...
仅供记录：有些用户确实阅读了错误消息，但非常害怕他们不会对其进行任何操作。我曾经接到一个支持电话，客户会向我读一条错误消息，询问我他应该做什么。 “那么，你有什么选择？”我问。 “窗口只有一个‘确定’按钮。”他回答道。 ...嗯，很难:)
From my experience: you don't get users (especially non-technical ones) to read error messages. No matter how clear and understandable, bold, red and flashing the message is, that you display, most users will just click anything away that they're not used to, even if it's "Do you really want to delete everything?". I have seen users click the "window close"-icon instead of "OK" or "cancel" even though they didn't even know which option they chose by doing so ...
If you really need to force users to read what you're displaying, I'd suggest a JavaScript-Countdown until a button is clickable. That way the user will hopefully use the waiting time to really read what he's supposed to. Be careful though: most users will be even more annoyed by that :)
I furthermore like your idea of a "read more"-link, although I doubt that will get users more interested that just want to get rid of the message by all means ...
Just for the record: there are users that DO read error messages but are so afraid that they won't do anything with it. I once had a support call where the customer would read an error message to me, asking me, what he should do. "Well, what are your options?", I asked. "The window only has an 'OK'-button.", he replied. ... mmh, hard one :)
我经常将错误显示为红色（当设计允许时）。
红色代表“警报”等，因此更常被阅读。
I often display the error in red (when the design allows it).
Red stands for "alert", etc. so it's more often read.
好吧，直接回答你的问题：不要让你的程序员写下你的错误消息。如果您遵循这一建议，您将累计节省数千个小时的用户焦虑和生产力，以及数百万美元的技术支持成本。
然而，真正的目标应该是设计您的应用程序，使用户不会犯错误。不要让他们采取导致错误消息并要求他们备份的操作。举一个简单的例子，在需要填写所有字段的 Web 表单中，当用户单击“发送”按钮时不会弹出错误消息，而是在所有字段都包含有效内容之前不要启用“发送”按钮。这意味着背面需要做更多的工作，但会带来更好的用户体验。
当然，这有点理想化的世界。有时，程序错误是不可避免的。当它们确实发生时，您需要提供清晰、完整和有用的信息，最重要的是，不要将系统暴露给用户，也不要责怪用户的行为。
一个好的错误消息应该包含：
最糟糕的事情之一就是简单地将系统错误消息传递给用户。例如，当您的 Java 程序抛出异常时，不要简单地将程序员的语言传递给 UI 并将其公开给用户。抓住它，并由您的用户帮助开发人员创建一条清晰的消息，您可以将其呈现给您的用户。
在我的上一份工作中，我很幸运能够与一群不会想到编写自己的错误消息的程序员一起工作。每当他们发现自己处于需要的情况并且程序无法设计来避免这种情况时（通常是因为资源有限），他们总是来找我，解释他们需要什么，并让我创建一条错误消息，清晰并遵循公司风格。如果这是每个程序员的默认心态，那么计算世界将会变得更加美好。
Well, to answer your question directly: Don't have your programmers write your error messages. If you follow this one piece of advice, you'd save, cumulatively, thousands of hours of user angst and productivity and millions of dollars in technical support costs.
The real goal, however, should be to design your application so users can't make mistakes. Don't let them take actions that lead to error massages and require them to back up. As a simple example, in a web form that requires all its fields to be filled in, instead of popping up an error message when users click on the Send button, don't enable the Send button until all the field contain valid content. It means more work on the back side, but it results in a better user experience.
Of course, that's a bit of an ideal world. Sometimes, program errors are unavoidable. When they do occur, you need to provide clear, complete, and useful information, and most importantly, don't expose the system to user and don't blame users for their actions.
A good error message should contain:
One of the worst things you can do is simply pass system error messages through to users. For example, when your Java program throws an exception, don't simply pass the programmer-ese up to the UI and expose it to the user. Catch it, and have a clear message created by your user assistance developer that you can present to your user.
I was lucky enough, on my last job, to work with a team of programmer who wouldn't think of writing their own error messages. Any time they found themselves in a situation where one was required and the program couldn't be designed to avoid it (often because of limited resources), they always came to me, explained what they needed, and let me create an error message that was clear and followed company style. If that was the default mindset of every programmer, the computing world would be a far, far better place.
错误更少
如果应用程序定期向您抛出呕吐物，您就会对其免疫，并且错误会变成令人恼火的背景音乐。如果错误是罕见事件，它将引起更多关注。
放弃任何不重要的事情，扔掉所有这些警告，找到理解用户意图的方法，尽可能地做出决定。我有一些应用程序，我继续以这种方式简化它们。开发人员认为每个错误都很重要，但从用户的角度来看并非如此。查找用户对问题的常见响应并捕获该响应，将其部署为您的响应。
如果你确实需要提出错误：简短、简洁、低恐怖因素、没有感叹号。段落失败。
没有什么灵丹妙药，但你需要通过社会工程来让错误变得重要。
Less errors
If an application throws vomit at you on a regular basis, you become immune to it, and errors become irritating background muzak. If an error is a rare event, it will garner more attention.
Quosh anything which isn't a major deal, throw out all those warnings, find ways of understanding user intent, take out the decisions wherever possible. I have a few apps which I continue to streamline in this way. Developers see every error as important, but this is not true from a user perspective. Look for the users' common response to a problem and capture that, deploy that as your response.
If you do need to raise an error: short, concise, low terror factor, no exclamation marks. Paragraphs are fail.
There's no silver bullet, but you need to socially engineer to make errors important.
我们告诉用户我们已经联系了他们的经理（这是一个谎言）。它的效果有点太好了，不得不被移除。
We told users their manager had been contacted (which was a lie). It worked a little too well and had to be removed.
添加一个“高级”按钮来启用一些更多的技术细节，这将激励那些认为自己是技术人员的目标受众阅读它
Adding an "Advanced" button that enables some more technical details will provide an incentive to read it for the part of the target audience that thinks itself as technical
我建议您在犯错后立即给出反馈（指出用户犯了错误）。 （例如，当输入日期字段的值时，检查该值，如果错误，则使输入字段在视觉上有所不同）。
如果页面上有错误（我更喜欢网络开发，因此我将其称为“页面”，但也可以称为“表单”），请显示“错误摘要”，解释那里是错误以及具体发生的错误的项目符号列表。但是，如果每条消息的字数超过 5-6 个，系统将无法阅读/理解这些字词。
I'd suggest that you give feedback (stating that the user made a mistake) immediately after the mistake is made. (For instance, when entering a value of a date field, check the value and, if it is wrong, make the input field visually different).
If there are errors on the page (I'm more into web development, hence I'm referring to it as a "page", but it can be also called "form"), show an "error summary", explaining that there were errors and a bulleted list of what exactly errors happened. However, if there are more than 5-6 words per message, those won't be read/understood.
如何将按钮设置为“单击此处与支持技术人员交谈，他们将帮助您解决此问题”。
有许多网站提供与真人交谈的选项。
How about making the button state "Click here to speak with a support technician who will assist you with this issue."
There are many websites that provide the option to speak with a real person.
我在slashdot上读到了最可怕的解决方案的候选者：
I read a candidate for the most horrific solution on slashdot:
“注意！注意！如果你不阅读错误消息，你就会死！”
"ATTENTION! ATTENTION! If you do not read error message you WILL DIE!"
尽管已接受的答案中有所有建议，但我的用户继续单击他们能找到的第一个按钮。所以现在我展示这个：
用户必须在确定之前做出选择按钮出现
如果他选择第三个选项，他可以继续，否则应用程序退出。
Despite all the recommendations in the accepted answer, my users continued to click the first button they could find. So now I show this:
The user has to make a choice before the OK button appears
If he selects the 3rd option, he can continue, otherwise the application quits.
这是一个很好的问题，值得我+1。尽管这个问题很简单，但涵盖了最终用户性质的许多方面。它归结为许多因素，这些因素将使您和软件本身受益，当然还有最终用户。
菲亚特福特，汽车公司正在销售其品牌菲亚特福特平托，但注意到南美洲没有销售，结果是， Pinto 是“小阴茎”的俚语，因此没有销售...编辑：特别感谢 < em>gnibbler还提到了另一个极其重要的点！
编辑#2：我的错！哎呀，多亏DanM提到了这辆车，我把名字搞混了，它是福特平托...我的错...
编辑# 3：由ed突出显示以指示附加内容或附录，并记入其他人的输入...
编辑#4：回应肯的评论 - 这里是我的看法...
不，不是，使用中性标准 Windows 颜色...不要选择华丽的颜色！坚持使用普通的灰色背景色和黑色文本，这是 Microsoft 规范中的普通标准 GUI 指南。请参阅 用户体验指南（编辑）。
如果您坚持使用华丽的颜色，至少要考虑到潜在的色盲用户，即对于那些有残疾的人来说，可访问性是另一个重要因素，屏幕放大友好的错误消息，色盲，那些患有白化病的人，他们可能对华丽的颜色敏感，还有癫痫症患者......他们可能患有可能引发癫痫发作的特定颜色......
That is an excellent question worthy of a +1 from me. The question despite being simple, covers many aspects of the nature of end-users. It boils down to a number of factors here which would benefit you and the software itself, and of course for the end-users.
FiatFord, the motor car company was selling their brandFiatFord Pinto, but noticed no sales was happening in South America, it turned out, Pinto was a slang there for 'small penis' and hence no sales...Edit: A special word of thanks to gnibbler who mentioned another extremely vital point as well!
Edit#2: My bad! Whoops, thanks to DanM who mentioned that about the car, I got the name mixed up, it was Ford Pinto...my bad...
Edit#3: Have highlighted by ed to indicate additionals or addendums and credited to other's for their inputs...
Edit#4: In response to Ken's comment - here's my take...
No it is not, use neutral standard Windows colours...do not go for flashy colours! Stick to the normal gray back-colour with black text, which is a normal standard GUI guideline in the Microsoft specifications..see UX Guidelines (ed).
If you insist on flashy colours, at least, take into account of potential colour-blind users i.e. accessibility which is another important factor for those that have a disability, screen magnification friendly error messages, colour-blindness, those that suffer with albino, they may be sensitive to flashy colours, and epileptics as well...who may suffer from a particular colours that could trigger a seizure...
向他们展示消息。尽职调查等等，但将每个错误记录到文件中。用户不记得他们在做什么，也不记得事件发生后几秒钟的错误消息是什么，这就像肇事者的目击证词一样。
提供一个好方法，让他们通过电子邮件或上传日志给您，以便您可以帮助他们解决问题。如果它是一个 Web 应用程序：更好的是，您甚至可以在任何人报告问题之前就收到有关情况的信息。
Show them the message. Due dilligence and all, but log every error to a file. Users can't remember what they were doing or what the error message was seconds after the event, it's like eye-witness accounts of perpatrators.
Provide a good way to allow them to email or upload the log to you so that you can assist them in reconciling the issue. If it's a web application: even better, you can be receiving information about the situation ahead of anyone even reporting the problem.
简短的回答：你不能。
简短的回答是：让它们可见、相关且与上下文相关（突出显示它们搞砸的地方）。但你仍然在打一场必败的仗。人们不会在电脑屏幕上阅读，而是进行扫描，并且经过训练，他们会单击按钮，直到对话框消失。
Short answer: You can't.
Less short answer: Make them visible, relevant, and contextual (highlight what they messed up). But still, you're fighting a losing battle. People don't read on computer screens, they scan, and they've been trained to click the buttons until the dialog boxes go away.
我们在错误框中放置了一个简单易记的图形：不是一个图标，而是一个相当大的位图，与标准的 Windows 消息图标完全不同。没有人能记住消息框的措辞（如果消息框有一个可以按下的“确定”按钮，大多数人甚至不会阅读它），但大多数人确实记得他们看到的图片。因此，我们的支持人员可以询问顾客“你看到那个喝咖啡的人了吗？”或者“你看到空桌子了吗？”。至少这样我们就能大致知道出了什么问题。
We put a simple memorable graphic in the error box: not an icon, a fairly large bitmap, and nothing like the standard Windows message icons. Nobody can ever remember the wording of a messagebox (most won't even read it if the box has an "OK" button they can press), but most people DO remember the picture they saw. So our support people can ask the customer "did you see the coffee-drinking guy?" or "did you see the empty desk?". At least that way we know roughly what went wrong.
根据您的用户群，编写有趣/粗鲁/个人的错误消息可能会很有用。
例如，我编写了一个应用程序，允许我们的 HR 人员更好地跟踪雇用/解雇日期的员工。 [我们是一家小公司，非常悠闲]。
当他们输入错误的日期时，我会写：
编辑：当然，更有用的消息是说：“请输入日期为 mm/dd/yyyy”或者可能在代码中尝试弄清楚他们输入的内容以及他们是否输入“blahblah”来显示错误。然而，对于我个人认识的人力资源人员来说，这是一个非常小的应用程序。因此，人们再次阅读这篇文章的第一行：取决于您的用户群...
我最近参与了一个艺术学院项目，因此错误消息是针对观众的，例如：
如果可能的话，基本上将其适合您的受众，并避免无聊，因为所有神秘的一般错误，例如：“请输入电子邮件”或“请输入有效的电子邮件”。
Depending on your user base, writing funny/rude/personal error messages can work great.
For instance, I wrote an application which allowed our HR people to better track the hire/fire dates of employees. [we were a small company, very laid back].
When they entered wrong dates I would write:
EDIT: Of course a more helpful message is to say: "Please enter date as mm/dd/yyyy" or perhaps in code to try and figure out what they entered and if they entered "blahblah" to show an error. However, this was a very small application for an HR person I knew personally. Hence again people, read the first line of this post: Depending on your user base...
I recently worked on an Art Institute project, so the error messages were geared towards the audience, such as:
Basically gear it to your audience if at all possible, and avoid boring as all unearthly general errors such as: "please enter email" or "please enter valid email".
警报/弹出窗口很烦人，这就是为什么每个人都会点击他们看到的第一个按钮。
让它不那么烦人。示例：如果用户输入的日期不正确，或者输入了需要数字的文本，则不要弹出一条消息，只需突出显示该字段并在其周围的某处写一条消息即可。
制作自定义消息框。永远不要使用系统默认的消息框，例如Windows XP消息框本身就很烦人。制作一个新的彩色消息框，其背景颜色与系统默认颜色不同。
非常重要：不要坚持。有些消息框使用模态对话框并坚持让您阅读，这很烦人。如果您可以使消息框显示为警告消息，那就更好了，例如，Stack Overflow 消息出现在页面顶部，通知但不烦人。
更新
使消息有意义且有帮助。例如，请勿编写类似“未找到键盘，请按 F1 继续”之类的内容。
Alerts/popups are annoying, that's why everyone hits the first button they see.
Make it less annoying. Example: if the user entered the date incorrectly, or entered a text where numbers are expected, then DON'T popup a message, just highlight the field and write a message somewhere around it.
Make a custom message box. Do not ever use the default message box of the system, for example Windows XP message boxes are annoying themselves. Make a new colored message box, with a different background color than system default.
Very Important: do not insist. Some message boxes use the Modal dialog and insist on making you read it, this is very annoying. If you can make the message box appear as a warning message it would be better, for example, Stack Overflow messages that appear right on the top of the page, informing but not annoying.
UPDATE
Make the message meaningful and helpful. For example, do not write something like, "No Keyboard found, press F1 to continue."