An Accidental Encyclopedia


Error messages

From the Web and UX Design Accidental Encyclopedia

If you have any screen shots of really esoteric error messages, please send me them (the contact form is at the bottom of the page.)

We all remember the “Abort, Retry, Fail?” or “Bad command or file name” – errors in MS-DOS. Notorious in their confusing and unhelpful messages. Other infamous messages are “HTTP 404” – (A file not found error seen on the Web), “Lp0 on fire” (UNIX warning that the printer may be on fire), “Not a typewriter” – A UNIX error message. In this day and age, the user expects more from a website than ambiguous and esoteric one-liners. And this is the problem, error messages often lie hidden in the developer’s code and are sometimes not even known until the user makes an error. Error messaging is probably one of the most important aspects of UX design. Most errors occur when the user is interacting with the website –this means he or she is engaging and doing what you want them to do. Great! Finally! – They are applying for the job, buying the shoes, subscribing to a newsletter, ordering your stuff!!!


However, the right error message is critical. You need to capture a lot of information for this whole thing to work. Unlike a bricks and mortar shop where you grab what you want, swipe some plastic and leave, the on-line user has a lot of information to give before anything happens.

The user needs to input data like post address, register accounts, and credit card details – you name it. And all error free. It’s your job to be preemptive, that is, try to avoid all confusion and ambiguities. Then when the user does screw up, to gently guide them to doing the right thing without making them feel defensive, or even leave the site. You need to give them clues to correct the problem and move on. Also, an unclear error message will not help the user and may result in extra calls to your helpdesk, pushing up your costs.
I’ve made a form to show some classic errors made in error messaging. Also remember, the user’s data needs to be unified if it is to be used elsewhere. You don’t want a postal address, a date or a phone number inputted in 10 different ways. You don’t want to hand-edit 5000 state and zip codes so they make sense. So guide the user gently to deliver the data in a way that you need, or make your form flexible enough to capture in different ways. Don’t let your website code limit your UX in such a way that you end up losing customers.
Remember, when designing anything that requires user input – Don’t make the software decide how the data should be inputted. Don’t make the error message esoteric. Don’t make the user feel as if he is doing something wrong. Don’t ask the user questions (like where they were born) if you are not going to do anything with the information, don’t waste their time.

Welcome to It has the worst form to fill in, so let’s see what we can do. Remember one thing, with every field a user has to fill in his ROUI, his return on user investment is plummeting. He has to be really motivated to go through all this, and you may lose him halfway – which would be a crying shame, you worked so hard to get him to this crucial point. Let’s walk through it.



1: This is an error message quietly sitting at the top of the page. It’s almost invisible to the user, he doesn’t see it and will get frustrated if there are no other prompts. Remember, some of the errors may be below the fold, out of the user’s view.

2: A useful trick if your form goes over several pages is to show a timeline – this is helpful and gives hope to the user that the hell of form filling will soon be over. Remember, however, that if there is an error at the submit stage, the user might not know on which page the error is.

3: So if you want to tell the user there is an error, don’t use geek language that 90% of the users don’t understand. Help him help you, advise him how to correct the problem.

4: Don’t give a generic response to an error, this will never be helpful, especially with multiple errors. Also remember, for some people, a field is where a farmer grows crops.

5: Give the user time to fill in the form, he may be distracted or need to look something up. If you time him out, he won’t come back to fill in the form again, he will go away.

6: Don’t be hysterical, be nice to your user – don’t shout – they are not doing something wrong, they are trying to do something right.

7: A pet peeve of mine. Often there is an asterisk (*) to denote that the field is required, but there is no explanation. Be wary of names – especially if you are open to the global market. In labeling, be cautious that some things are named differently, some people don’t know what a surname is (last name).  Also, a prefix can be spelled many different ways, so limit this by use of a drop-down menu.

8: Here the label “House Address” is in the field, this is fine and becoming more popular, even taking the place of the field labeling. However, make sure that when the user clicks on this field to enter his data, the text is deleted or it might end up in the user’s data. Don’t make the user manually delete all the labels in the field. Also, if the user forgets to enter something and clicks in a different field, the labeling should return, otherwise he won’t know what to enter.

9: A second street field should be available, but is often not needed so don’t make it required.

10: If your market is a single country then you can limit the zip (postal) code, but you need to keep this flexible for a multinational website. Remember, folks that live in England, or Dubai, don’t live in a State, and so don’t force them to choose one. By adding a country drop down you can make your form contextual. It’s best to offer a drop down instead of an input field as there are many ways of spelling a country. Also, I am British, English, I am from the UK, Great Britain, the United Kingdom and also England. All valid choices. If 90% of your users are from one country, put them at the top of the drop-down list. I wonder how many pairs of shoes have been sent to Afghanistan?

11: An email address follows a clear set of parameters and this can be validated by most forms, but make sure that if a user inputs an invalid email address, the error message explains why in clear language.

12: Confirming an inputted email address is common these days (as many typos in emails have led to missed leads) but be clear that if the emails don’t match and that this is the reason for the error, and how to correct it

13: As with countries, phone numbers follow different rules, the land code for the US (+1) is different than that of England (+44). Don’t make fax number required, these are not as common as they used to be.

14: This shows how the designer of the form can help the user input the data in the right way, making it easy for the user and the data inputted uniform and accurate. A “more information” icon is also available, and being in the field itself is contextual.

15: If the user has to agree to terms and conditions (and they usually do) then make sure that they can easily do that.

16 and 17: Don’t be crafty by sticking in stuff that the user may not want, it’s a distraction and makes him suspicious. He is already doing lots of work for you already, don’t push it.

18: Get the wording right – What is the right answer to this question, YES or NO? – It’s at best badly worded and at worst manipulative.

19 and 20: Password creation and input is a science unto itself, and tooltips like this version from Apple, helps the user create a good password. Also, your system may make minimum demands on password complexity. If so, make sure if the user creates a password that does not meet these criteria then he is helped to create one that does and is not left guessing. Consider if the user needs a password at all, why put him or her through it?

21 and 22: As with countries, dates are very difficult to input. In the US, the month comes first, in Europe, the day. This means a date like 08/04/2015 can mean August 4 or April 8. Some people may type in the text as a word or as an abbreviation (August or Aug.), the date as 8th or the eighth. Constrain them as much as possible but make it clear what the constraints are. Again, if you need the date in a database, you don’t want to have to hand-edit thousands of inputted dates. Also, what are you going to do with this data – if nothing, then don’t ask in the first place? Using a pop-up calendar is often a useful help, but always ask yourself if this is information you really need.

OK, the meat and potatoes. 24 and 25: the credit card details.
Lets create a persona –  Frank, he’s had a few beers and he’d decided to buy his mother a present because he forgot it’s her birthday. It’s a spontaneous act and he’s struggled through your form to get the order complete. Deep down inside him, there’s a little buyer’s remorse already creeping in. You need him to input that credit card and click submit as quickly as possible. He pops another beer and then blurringly types the digits. Make sure he knows what card type you accept without him having to use trial and error. Don’t ask him unnecessary questions to delay him (like what type of card is it – the first four digits of the number of the card has the answer).

Be aware that some cards have the date like JUL/14, while others have 07/14. So help him out by making a drop down where both are given – 01 (JAN) 02 (FEB) etc. If the billing address is the same as the address he has already inputted, make that simple for him to state that. If the product needs to be delivered elsewhere, then inputting another address is the only option, but keep that as simple as possible.
Some websites add a Captcha element to block spamming. Really? Is this his problem? Why to make him work even harder by giving him a puzzle to solve. His ROUI (return on user investment) is really plummeting, especially if he gets it wrong. Imagine his frustration if he has to re-enter all the card details just because he screwed up the captcha field. Don’t add a captcha element if spam is not a real problem, or can be filtered out on the back end. Don’t do something just because you can, or other people do it. Less is much, much more in this case.
Then there is the submit button. Some forms gray this out until all the fields are properly inputted. This may be fine on a short form, but if the submit button is below the fold, the user doesn’t have an overview and may not get why he cannot click on the button. Also, don’t put a cancel button close to the submit button – imagine if Frank accidentally clicks cancel instead of submitting. He will give up and buy some flowers at the gas station instead of your product. Consider if a cancel button is even necessary.
And submit? Never use the word submit, use the right call to action like “complete purchase”, “subscribe” or “download the brochure”.

Lastly 27: don’t distract him with links to other things. He is focused on doing something that is the whole purpose of him being on the site – buying product – so don’t let him click a link that will take him off somewhere else and maybe lose all that hard inputted data… The form page should be devoid of all distractions. If the user wants to buy something, don’t lead him astray with links about mission statements or privacy policies.
Here are just a few things that show how difficult it is for a smooth interaction between user and website. Again, SSCC – keep your form simple, structured, consistent and concise.

Good luck, I hope Frank’s mother likes your product.

Please send me any classic error messages for my Error Message Museum.

Your Name (required)

Your Email (required)

[Sample for Your Error Message Museum]

Your Message

An Accidental Encyclopedia

Leave a comment