Form Design Blunders and Faux Pas on the Web

We’re filling out more forms than ever in our day to day activities. Whether it be sending an update to your favorite social network, a new social network you’re signing up for, or even sending a message to someone you haven’t spoken to in 10 years on a social network; forms are being used a lot. All kidding aside, the Web has evolved into a much more participatory environment, and with that come design considerations which may someday result in best practices.

Forms have been viewed as an area of Web design which has much room to improve. From the markup itself to general design guidelines, there are some trends which have evolved surrounding their implementation. Forms may be something you view as a smaller aspect of your overall design, but I’ve got to be honest when I say that seeing a well designed form is not something I often come across. When I do see a form which has been very well implemented, I try to take some notes to keep in mind for future projects. It’s difficult for me to express in words what it is that impresses me about well designed forms, but it’s quite a different story for me to jot down a few things which I find irritating.

Poor choices for field defaults

Providing a field default is, in my opinion, usually something that should be avoided. There are certain circumstances where it’s a necessity, such as using the input itself to reflect what would otherwise be represented by a label. Including a default input value is a significant annoyance if not implemented properly. Always keep in mind that if you are going to provide a field default, make sure you add it with progressive enhancement in mind. I say that because more important is making sure your default is cleared out upon input focus. I can’t count the times I’ve gone to enter data in a field with a default value and ended up typing within the default string itself. It’s a show-stopping event.

Field defaults are in no way limited to text inputs or textareas. A peeve of mine which has developed over the past few months is finding a default entry in a select. For example, stumbling across a form which has a select for the state in which I live. This particular select has a default value of “(Choose One)”. Why? The widget itself is designed visually to communicate that there are a number of values to choose from. A select is not an uncommon interaction with a form, why is it necessary? If nothing else, it requires you to apply otherwise unneeded validation on the element. I can possibly understand that it may be used as a method for ensuring the reader has taken the time to choose a value from the select, but to me that’s a stretch. What’s worse is seeing “(Choose One)” as the default entry with “Other” or “No answer” as the bottom choice. For selects without required data, why not make “No answer” the default?

At the end of the day, if the select is required data, you’re creating extra work for all parties involved by trying to hook an answer with “(Please Choose)”. From the start, you’re going to need to validate that field. Continuing, if a reader is maliciously trying to submit bunk data, when notified of the required field, an entry will simply be chosen at random, which now looks like a more legitimate answer than “Other”.

Another issue I’d like to bring up with form defaults is one that has to do with radio buttons. Interaction here is very similar to that of selects but in this case, my annoyance happens to be an absence of a default value. The purpose of a series of radio buttons is to have a reader choose one of the available choices. Why leave this section of your form without a default?

Validation issues

Form validation is an art form. There are some really fantastic ways to validate forms which not only benefits your server, but also the user experience as well. With the widespread arrival of unobtrusive JavaScript, form validation on the client side has been improved exponentially, but there are still some pitfalls which can result in a very frustrating process for your readers.

Most importantly is being upfront about what data is required when filling out your form. On top of that, you should provide relevant information regarding any syntax required for entering data. Information such as phone numbers, credit card numbers, and dates come to mind. Readers are likely to follow instructions on formatting, and be much happier doing so as opposed to seeing they entered a date wrong because you failed to provide syntax.

A huge peeve of mine when it comes to form validation can only stem from laziness on the part of the developer. It doesn’t take much to check whether each field was populated already on a page load, so be sure to include the submitted data as a ‘default’ value when exercising validation. There’s nothing worse than taking time to fill out a form only to have the page reload saying I forgot a digit in my phone number, but the rest of my data is missing.

Finally, on the side of form validation, make sure your error notice copy is up to snuff. Ensure the notice is contextual and you’re not taking the easy way out by dumping the errors at the top of the page, leaving the reader to hunt for information to correct. Make sure each error description is accurate and easy to interpret. If a credit card number was entered incorrectly, do more than classify the data as “invalid”. Explain, using syntax if applicable, why the entry does not validate.

Avoiding general frustrations

There are number of other issues to consider when designing forms. Something I continue to run into time after time is the classic case of recursive selects. I will despise this implementation until the end of time. I can understand that it may be a way to de-clutter the UI a bit, but at a serious cost to usability.

Another frustration that often surfaces is poor use of tabindex. Browsers are quite good at figuring out a logical order for tabindex if the developer hasn’t implemented one, but they’re not perfect. There are many (high profile) websites with terrible implementations of tabindex, dragging readers here & there in a very disorienting manner. Issues with form jumping can be easily avoided with a quick implementation of a logical tabindex.

I know I’m not alone when I say I’ve got a few annoyances when interacting with forms on a daily basis. What is it that truly bothers you about poor form design? What tricks do you have up your sleeve which have worked out really well in practice?