We all remember the “Abort, Retry, Fail?” or “Bad command or file name” – errors in MS-DOS. Notorious for 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), and “Not a typewriter” – A UNIX error message. The user expects more from a website than ambiguous and esoteric one-liners in this day and age. 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, and ordering your stuff!!!

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 on 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 the 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 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 on 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, so don’t force them to choose one. By adding a country drop, 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, from the UK, Great Britain, the United Kingdom, and 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 most forms can validate this, 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 numbers 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; don’t push it.
18: Get the wording right – What is the right answer to this question, YES or NO? – It’s badly worded and manipulative at worst.
19 and 20: Password creation and input is a science unto itself, and tooltips like this version from Apple help the user create a good password. Also, your system may make minimum demands on password complexity. If so, make sure that if the user creates a password that does not meet these criteria, 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 data 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.
Let’s 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, a little buyer’s remorse is 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 have the answer).
Be aware that some cards have a 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. 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 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 products – 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.