Getting Web Forms Right

It still surprises me when you speak to experienced developers and designers and they consider form design as a simplistic afterthought.  It’s quite common for the form fields required to be clearly defined often derived from the chosen database schema, followed by the common expression of “form validation” to solve all input problems.    Validation which is often reliant heavily on client side javascript.  Speaking recently to an associate on this subject, the idea of planning a form beyond this level was an inconceivable idea and a pointless exercise.  They considered forms to be a simple process and a laborious chore which is part of standard development.  Personally I am a firm believer in the age old expression “Failing to plan is planning to fail”.

As websites and web based applications require more information from users, forms become more in demand.  Some forms are well presented with clear thought of structure which include step by step guides and visual aids, others are very long winded and complex where the very sight of them can deter users.  What is often overlooked is that we are trying to invite the customers/users to the business to spend money.  Sometimes forms are optional processes for customers and unless you have a super brand with incredibly loyal customers, failing to consider user experience when creating forms could be losing you custom and therefore money.  In the real world this is the moment where the sales person usually sharply dressed sits you down at the desk and offers you a cup of coffee before asking you some personal information.    Now offering a cup of coffee isn’t an option on the web, but considering the users experience is.

To enhance the users experience web forms should aim to be simple for the user to understand and navigate and quick for the users to complete.  This is easier said than done in the real world.  If we look at a simple phone number as an example, what variations could we expect?  It would be common to check for numeric values only and string length to validate the entry.  However let’s look at a simple UK phone number (029 20123456)  and see how the rule would apply if we simply looked at numeric values.  Here are some examples how users may enter this phone number on a form:

1. 029 20123456
2. 02920123456
3. 29 20123456
4. +442920123456
5. +4429-20123456
6. 029-20123456
7. 02920 123456
8. +4402920123456

This small example clearly shows that the assumption of checking for just numeric values in validation would fail in a lot of cases.  This could end up frustrating the user or provide poorly formatted data to the system/recipient.  This example although confined to phone numbers extends to all fields specified.

With this in mind I have compiled a list of common issues to consider when designing forms.

Lengthy Forms

Although forms should be concise where possible, sometimes there are occasions where the user will need to submit a great deal of information.  This is commonly seen when providing details for insurance quotations.  If you require allot of information try constructing the form to allow the user to return at a later date to complete the details and break the form into logical structures/steps to help orientate the user.  This could mean you have to save the form details for that user.

You might also want to consider re-using data where possible to assist the user.  An example of this is a persons address.  If they have an address stored in the system, give them the option to use a default address rather than assume they will have to type the same address twice or more in different locations of the site across multiple forms.

Filter Input

As with the phone number example above try to “expect the unexpected”.  Don’t assume that the user will provide a format which you expect.  Research all the possible variants that users could provide through such methods as user testing prior release.  A good way to do this is to create physical forms asking your colleagues,associates,family or friends to fill in the data on a sheet of A4 and analyse the formats they use.  When you have what you consider to be a definitive list build the rules into your logic.  You can filter the input using the variants found to create a common format to enter the database, providing you with a higher value in data integrity.

Highlight Required Fields

Although you would like as much information as possible from users, some users value their time highly.  In this scenario it would be better obtain what you deem to be essential information from  many users rather than obtain more detailed information from a less users.  Over time if the users which see a value in your product they will provide more information anyway.

To achieve this goal, break your form into what you feel are required fields.  These are the fields which need to be completed for the user to move onto the next stage.  When you have identified these fields, highlight them clearly to the user before they start entering data. For example if they see 5 essential fields in a form with 20 fields they will be more willing to submit their information.  You often see forms using the * symbol to highlight essential fields.

Visually presents the user with the fields required.

Present Field Limitations

If you have restrictions on fields such as where usernames have to be between 8-20 characters, present this to the user up front.  Don’t make the user fill out the form, submit their entry then present them with an error message.  This slows the process down and frustrates the user.

Presents users upfront information about limits within the field and helps avoid frustration.

Restrict Entries

Similar to the phone number example above some fields could be entered in countless formats.  If possible restrict the ranges in select lists forcing the user to choose a value rather than enter one.  A good example of this is dates.  There are only 12 months in a year so why not give the user a list of 1 to 12.  This avoids confusion and allows you to gather data in a consistent format.  In the date example you could go a step further and provide a small calender.

Provides a valid format to the system and helps the user choose a valid date clearly.

Disable Action Buttons

Most forms contain buttons of some description.  Some include helpers such as postcode/zip code look ups.  When a user clicks a button or invokes an action provide feedback on the current status to prevent confusion.  An example would be when a user invokes a postcode/zip code lookup, present a message such as ‘Locating address’ to the user and disable the action until the response is obtained.  This prevents the user requesting more than one action at a time.  Another good example of this is disabling the ’submit’ button on a form when pressed.  If the data is in the process of being submitted, not disabling the ’submit’ button could result in the user accidentally submitting the form twice.  In the event this is a payment submission this could result in two orders depending upon the way you handle submissions.

Lets the user knows in real time an action is being carried out in response to their action.

Save User Data

No matter how much you present hints and cater for various formats a user could enter, users will make mistakes when entering data through a form.  There is nothing more frustrating to users than submitting a lengthy form to find out they missed a field and all the data they just entered has to be entered again.  It would add considerable value to the user experience to save the submitted data and re-populate the form fields using the data when the form is refreshed.  This would avoid frustration and save you and the user time obtaining/submitting the data.

Provide Help and Hints

It’s easy for tech savvy designers, developers and businesses to assume too much and expect users to know the internal company jargon.  It’s safer to assume not everyone knows what an OpenID is or what your internal company number is and this will add value to your form.   Where possible provide helpers and hints with clear examples of valid formats.  For example if you require a date, give an example such as 12/05/09 or dd/mm/yy.  This will help the users enter the data in a valid format and is a step closer to preventing user frustration.

The links below the field give the users an option/help to learn more about the field value.

The above guidelines are not definitive.  There is a lot to consider when designing forms.  Essentially what your aiming to do is obtain as much information as possible without deterring or frustrating users.  If you aim to satisfy this task you will achieve better customer satisfaction and higher submissions from your users, adding value to your site.

If you want to read more on this subject or about general defensive design issues for websites, I highly recommend reading this great book from 37signals (Defensive Design For The Web)

Please feel free to comment on this post.  If you think I’m missing anything obvious and adds value, feel free to post a comment.