How to get users to read error messages? [closed]

Question

If you program for a nontechnical audience, you find yourself at a high risk that users will not read your carefully worded and enlightening error messages, but just click on the first button available with a shrug of frustration.

So, I'm wondering what good practices you can recommend to help users actually read your error message, instead of simply waiving it aside. Ideas I can think of would fall along the lines of:

• Formatting of course help; maybe a simple, short message, with a "learn more" button that leads to the longer, more detailed error message
• Have all error messages link to some section of the user guide (somewhat difficult to achieve)
• Just don't issue error messages, simply refuse to perform the task (a somewhat "Apple" way of handling user input)

Edit: the audience I have in mind is a rather broad user base that doesn't use the software too often and is not captive (i.e., no in-house software or narrow community). A more generic form of this question was asked on slashdot, so you may want to check there for some of the answers.

Shafting

What audience do you target your software? Eg. few companies, or internet users? Is there a relation that you can establish with users? – Kuska

@WooYek: That would be (in my case) a rather large userbase, but with a limited time of use (i.e. it's not software you use so often, it's more of an "occasional use" with large possible user base). – Endermic

Are these error messages like someone didn't fill out all the fields of a form or error messages like something blew up? – Kelantan

Why do you say "for a nontechnical audience"? Have you already discovered a trick to make technical users read error messages? If so, please share, since that could be helpful in deriving a solution for nontechnical users! – Chun

For a technical audience, the choices are different because they are responsible for their choices. Or should be! – Endermic

Answer 1

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...

Nonparticipation

Interesting about the status bar. I would argue that people do notice those bright colored strips across the top of a web page indicating, e.g., "you just earned a Good Answer badge." This is not equivalent to the status bar, but it does tell me that the position and background color of an error message are significant factors. Oh, and a minor spelling note: it's Fiat Punto. Pinto was a Ford product infamous for it's rear mounted gas tank that sometimes exploded. I would avoid both names :) – Instate

@DanM: Gosh! you're right! It was ford...what was I thinking when I wrote the answer...yeah it was defo Ford Pinto!!! Thanks for the heads up!!! – Nonparticipation

@tommie, don't forget about Nova (as in Chevy Nova). It translates to "No Go" or "Doesn't Go" in Spanish :-P – Instate

@DanM: corrected that - hey that's an interesting one....ouch! Sounds like a wooden car with wooden wheels that wooden go.... :) – Nonparticipation

@DanM, I just read your first comment then looked up and noticed the status bar telling me I have new answers and comments. :/ – Disrepair

"it's akin to waving a red-flag to the bull!" ... I'm a little confused ... is this a reminder than a significant percentage of users are colorblind? – Chun

@Chun a red flag angers a bull, causing it to charge at the flag. It is a simile for bright colors causing the user irritation, not colorblindness (though in a way, they are blinded by the color :) ). – Alienate

Answer 2

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.

Mochun

A big +1 for this. Note that the developer portion can contain the full stack trace and other details. You can even capture application screen shots (particularly for in-house WinForms apps) if desired. – Czardom

I'm a bit reluctant to consider "capture application screenshots" good advice: after all, it sounds like a serious leak of private data (even if your application never was designed to handle NS<nogrep>A-class information in the first place)... – Endermic

I think thats more of a business/policy decision to be handled by domain users than the technical aspects of giving better support by having "black box" crash diagnostic support. I would expect that internal LOB apps have different concerns/goals than external client support relationships with sensitive information might have. – Mochun

Answer 3

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.

Choriocarcinoma

That habit of clicking dialogs away was a real problem with the old IE ActiveX installation dialog. – Bags

Answer 4

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".

Bernardinebernardo

There's a slight danger despite making it fun, your select group of users could take offence, keep the language neutral - what if that was translated to another language? It could p-off a few foreign nationals....the tone of your creativity could backfire spectacularly.... – Nonparticipation

Hence why the first line reads: "Depending on your user base" – Bernardinebernardo

learn how to enter a date!! - Sure but give me an clue. I shouldn't have to guess the proper format. – Bags

... and not only that, don't force me to enter a date in the first place. Make an assumption (). If the assumption is wrong, the worst that happens is you teach the user the consequence of not typing in a date. And if you're only very slightly clever, a good half of your users will accept your guess and you will have saved them time rather than cost them time. () advice not valid for scheduling a missle launch. Or a wedding. – Russi

Not sure I like that kind of message much... After all, why should I have to learn how to enter a date? – Endermic

Instead of requiring users to figure out the date format, take a couple extra minutes and teach your software how to parse dates in multiple formats. The computer is smart -- let it help the user rather than slap their wrists. – Russi

Yuck, never even think about getting humorous with users who are strangers. Even with your friend, change the message to a boring one after 2 or 3 random appearances of the funny one. And never have the funny one show again. Humor is NOT humor the 2nd-10,000th time around. It is stupid. Data entry error messages are utilitarian, therefore, they SHOULD be boring. 'Please enter a value' in a bubble pointing to the field. do NOT avoid boring messages. – Bromism

@Bromism - Humor can definitely help, depending on the site. For example, remember Winamp? [It really whips the lama's ass!] hilarious. Or their site used to say how "it sorta works, we think" That's great stuff. And humorous messages are more likely to be read. – Bernardinebernardo

Answer 5

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."

Drivel

1 and 3 are good. 2 is questionable, for accessibility reasons. System standard controls can be handled specially. Your variants can't. – Wormwood

@Novelocrat, odds are good that if the rest of your application is accessible, your custom error dialog will be too. And if the rest of your application already has accessibility issues, one more dialog with problems will not matter. – Gossipry

@Novelocrat, im mainly talking about web applications, instead of the default JavaScript alert box, you can create a new stylish box, and give it the same properties. But the same idea could go for Desktop applications if the purpose IS to force reading the message – Drivel

Same of Novelocrat, I don't really like the "never use system UI" part of the answer. People want to feel in known territory. – Endermic

And also, accessibility is always better for the system UI. – Endermic

Answer 6

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.

Supersaturated

My problem with that idea is that it breaks the UI uniformity that people expect. Furthermore, how can they know that "empty desk" is a more threatening issue than "coffee-drinking guy"? – Endermic

We make single-purpose systems (emergency control centres), so we only concern ourselves with UI uniformity within that system. No hierarchy of threat is implied here anyway. The purpose is simply to be memorable. Those two graphics actually represent similar inactivity situations (operator stepped away from desk, operator probably on break) so they would be meaningful... but that's not their real purpose. We just want them to be memorable. Maybe I shouldn't mention the dancing mouse :-). – Supersaturated

Answer 7

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.

Russi

Answer 8

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.

Demandant

And then admin/helpdesk/etc hear about the message, and ask "What the hell am I supposed to do about it?". Your second message is generic to the point of uselessness. As for the former, never having used Oracle software (guessing based on the prefix), I can still hypothesize at what I'm supposed to do about it. – Wormwood

Well the helpdesk can inform the developer to fix the problem. Would it help the client or the helpdesk to write the technical message in the error? All the user wants to know at this point is: What happened and where can I get help, if it's not an error he made (wrong input or something). And don't get me wrong, that's of course the message on the presentation layer. In the server logs, there is the specific error message, which will help you fix it. – Demandant

@Novelocrat, precisely. You can often find tech support personnel yelling, "But I am the system administrator, and I have no f*@#& clue what the problem is!" You'd better add a "show me the technobabble" option to your errors. – Gossipry

the helpdesk can't provide much help when it's a commercial off-the-shelf application and the error contains no useful information. – Gossipry

Answer 9

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.

Kuska

Answer 10

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.

Openair

Excellent point! Users read the first sentence, or first half of the sentence, and if it's too complicated in structure, or too technical for them to understand, or seems irrelevant for what they intended to do, they will definitely skip the rest. I'd even add a sentence before the explanatory part saying something like: 'This is what might have happenened' - even better, propose solutions in terms of what the user can do: 'Check if the file has been moved, or if the network drive it's on needs to be reconnected' – Procambium

Answer 11

I often display the error in red (when the design allows it).

Red stands for "alert", etc. so it's more often read.

Crete

and what about people who are colorblind? – Mercurochrome

As someone who is colour blind I am not even sure what the colour "red" looks like. – Mochun

Red isn't universally interpreted as an alert. Some cultures interpret it to mean happiness, for example. Be aware of who your potential users are when choosing colors. – Russi

@MikeJ: clearly, Tyzak should make it blink, instead. That would be way more helpful. There's a difference in value (brightness) between fields other people say are 'red' and those they say are clear, isn't there? – Wormwood

hm, i didn't thought about colorblind, that's a good point. yes the color is universally interpreted (china,india). It depends on audience, right. – Crete

For the US there is ADA section 508 which governs requiring accessibility. I am pretty sure the UK has a similar law as well. you can read more about it here: thirdwave-websites.com/508-accessible.cfm and the WCAG from W3C to implement. – Mochun

@PhilMiller, make it blink? I really hope that's an ironic comment! :-) – Procambium

Answer 12

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/

Celin

Answer 13

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 :)

Reflexion

These "JavaScript-Countdown" is the most annoying thing you can do. The user will hate to "have to wait for a clock to count down" and barely focusing on the error text than his anger. – Demandant

Answer 14

Make them fun. (It seemed relevant, given the site we're on :) )

Baptism

Answer 15

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.

Arsenault

You can search for a relevant Dilbert cartoon here: bfmartin.ca/finder – Holoblastic

Ten seconds? Look at a clock and count off ten seconds. It's an eternity when you're trying to get some damn work done. – Gossipry

Mike, It was meant to be an example, not written in stone. Choose whatever timeout you want. Alternately, have you ever installed a Firefox adon? Does that countdown really annoy you that much? I haven't heard too many people complain about that. – Arsenault

@Roberto - speaking of the Firefox plugin countdown...that DOES annoy me. I just want to click install. Why do I need a count down when I clicked on install a plugin and then now have to wait 10 seconds to confirm the install. – Maidenhood

@Maidenhood precisely because of the reason this Stack Overflow question was asked. Too many people are click happy and don't bother to read messages and their consequences and end up doing something they didn't mean to. Mark, you know and understand what you click on. However, having worked at HP tech support in the past, there are people out there that click on things just because they can. The delay forces the user to stop and take a look at the message, rather than saying "yea, yeah, whatever I'll just click OK, go already" – Arsenault

@Maidenhood & @EveryoneElse Also, I didn't say one should use the 10 second timeout for every single message. What I mean is to use it on messages that are important and are unavoidable. Messages that the programmer wants the user to read, because it affects some important aspect of the application functionality. – Arsenault

&Roberto: the Firefox plugin countdown is utterly annoying; every time I see it, I feel like it is an insult to me (and it actually is!). Maybe, statistically, it makes sense, but if it were in a place I saw it any more often, I'd simply stop using their software! – Endermic

@Everyone, So then we should take a different stance? If the user goes click happy, then its their own fault? I suppose the best alternative would be to do away with confirmation boxes, instead provide a way to "undo" the last action. But what if a particular action is permanent and cannot be undone by nature? such as "Do you want to format your hard drive?" If they accidentally click "yes" just because they were click happy that day, then its the user's own fault? – Arsenault

@Maidenhood @FX @Roberto I always thought the Firefox countdown was so that you wouldn't hit enter and accidentally activate the button... It's a common problem, for example, with the Windows Update "Restart Now" button after updates have installed. Someone is typing a word document, hits enter or space the moment the system asks them to restart, and everything is swept out from under them before they're able to save or cancel. – Alienate

Answer 16

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.

Maidenhood

Some platforms don't let you do this. There are almost good reasons for those restrictions, too. – Wormwood

I strongly second Novelocrat's comment. A standardized UI is good for the users (and thus good for you). I think sticking with the standard button labels achieves something that you don't want to loose, even to capture attention (except maybe in extraordinary cases). – Endermic

You don't need to use JS alerts() to display error messages. You can build your own dialog window. Also the purpose of using verbs rather than just exclamations is because if you see 'Ok' as a button, you'll have to read the contents of the dialog box. The problem is some users won't take the time to do that so they will just click ok. If you use verbs to describe the action then a user will know what is going on without reading the dialog box. – Maidenhood

Close is a verb. You used it in your own sentence; "to close your error messages" – Alienate

But @Mark, this question is all about letting them read it :p – Sheffield

Answer 17

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

Unalloyed

Answer 18

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.

Lab

Answer 19

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:

1. What the problem is and why it happened.
2. 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.

Folkmoot

Answer 20

We told users their manager had been contacted (which was a lie). It worked a little too well and had to be removed.

Shadbush

Answer 21

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.

Crownwork

Answer 22

"ATTENTION! ATTENTION! If you do not read error message you WILL DIE!"

Frightened

Answer 23

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.

Shafting

Answer 24

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.

Canary

Your two paragraphs seem contradictory: give immediate feedback, but gather it at the end of the page? – Endermic

@FX, The idea was that you do both things- warn the user immediately, but, since he/she might still ignore it, gather all the mistakes at the end of the page. – Canary

Answer 25

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.

Prophase

The point is to have users deal with the errors themselves, at least where possibile. Such a button would be a declaration of total failure of the intent. – Finfoot