Man with no Blog

You have built the perfect web site, the colours invoke the right emotional response, the visual imagery leads customers to the relevant information while allowing the audience to personally relate to the site. The content is ideal for the web, not to much but enough to convince people of the service. The major call to actions are in the right locations, and easy to find. Everything is set, the web site is ready to take on the world!

Still no matter how perfect your site is, if the  last step, when they encounter the web form, isn’t streamlined and usable, the rest is a waste of time.

The other day I ran across a web form that was failing, it was suffering from a series of issues that would basically make most users stop in their tracks.

With any identifying markers removed, I would like to share with you some of the issues of this form, and a few simple steps to fix them.

The Form in Question.

The form was being used for membership of a professional organisation, it is broken down into three sections (fieldsets in this case) The Personal Details, the Payment Options and the Acceptance of Conditions, these are presented here, for clarity I have separated them, but normally they appear on one long form.

There are a good number of issues with this form, I’m not going to cover all of them, but here are a few of the common issues:

• Number of Fields  - Only What You Require

  I have a major beef with forms that are just way too long. You know the ones with an endless list of fields.  Clearly this one falls into that category –  when you first encounter it you are filled with dread at having to fill it out.

  You should consider every field that you put in a form to be a major stumbling block for anyone completing it. Research has indicated that people naturally hate forms and the like, as they slow them down to getting to their goal on the web. When you designing a form this long (with 38 fields) you are not really respecting your users time.

  Consideration needs to be given to what is the bare minimum to identify the person joining. Everything else should be removed. If you really want the extra informaiton there are ways of encourging people to complete their online profiles later on.

  Trying to capture all the information for a person at sign up in the worst possible time. People are hesitant, and still deciding on the your website.  A long form is just going to convince them you are a little bureaucratic .

• The Need Print out of the Form

  I do know that in some cases long forms like this are developed so people can complete them, print them off and fax, not ideal, but people do it. What needs to be provided is a fax back PDF form or the like. This should be presented on the same page as the online form –  preferably at the top of the page.

• Fieldsets and Grouping

  Yes the form is broken down into three sections. Sections 2 and 3 are reasonable, it’s just the first one that is a little long. This can be improved if it had been segmented into personal details, work details and joining information.

• Help

  With this example there is very little inline contextual help. In today’s interactive web, people are starting to expect to see contextual help boxes appear when they tab or focus on a field. These can be alternatively just be accessed by clicking on an appropriate  help icon (a question mark maybe). Semantically of course you place this information between the  fields and the associated label.

• Encouragement Along the Way

  Currently there is no inline encouragement on the form at all.

  This is a simple thing to put in place; for example every time a user completes a field or an information block (like the BSB / Account Number pair) they get an acknowledgment for their actions that appears inline on the screen. This could be a small tick, thumbs up or the like – appearing near the relevant field.

  Using this type of positive feedback adds a degree of trust that the organisation cares about the information it is collecting, as well as a sense of achievement and sense of completion for the user.

  Use of this technique can also be extended to inline validation of the form, hence providing instant feedback for any error as well.

• Create Steps

  Even if we removed all the redundant fields  we still have a form that is visually way to long.  In this case we are better of presenting the fields  in distinct groups of related information, one at a time.

  You would present it as two step process –  step one personal details and step two the payments, with the terms and conditions confirmation tacked onto the final section. Of course you would have an indicator showing the users progress through the various steps.

  As the user processes the form the indicator would show where they were up to in the process.  This step wise process allows one to segment a long process into several short chunks that users are more likely to undertake as they are progressing towards their final goal in manageable steps.

• Date of Birth

  There are different ways to ask for the date of birth, different  layouts was work for differently user audiences. It has been shown that it can be easier for some users to select a date of birth from three drop down lists than type it in the format you require.

• Clear Labels

  The labels on a form have to convey  instant meaning for the user, and yet still remain personal so they can relate to them.  The order and grouping of the fields should also follow a logical sequence  (as recommend above).  Labels such as “Optional” mean nothing to a user.  With a field like this, people may not even complete it, after all it’s optional.

• Add White Space

  From a design view point all the yellow fields do wash into one large yellow mass, they would be a lot clearer and easier to read if there was a some white space between the fields. It’s a simple thing, but cramming all the fields up together doesn’t help, if anything it makes the appearance of the form even more intimidating.   Remember white space is your friend.

• Avoid Multiple Columns

  This is one that has been debated quite a bit – should you use multiple column layouts on forms.

  Research has indicated that users really like to just run down the page filling out blocks of information as fast as they can. The don’t like shooting across a page to complete a postcode, like in this case.  However having blocks of fields like the BSB and Account Number field close together is acceptable as these are taken visually as one block of input.

• Terms and Conditions

  Use of a check box to confirm agreement is really redundant if you think about it.  Often these checkboxes are put in place to keep legal teams happy,  teams that usually don’t want the form on the web in the first place.   The checkbox sometimes is also seen as a substitute for a signature.   Still there are improved ways to approach this requirement.   If the agreement is required what can the user do,  join and not agree.  No.   The user has no choice – they have to agree or leave not completing the form.

  Sure the statement can remain, however a better approach would be to have the join button saying “Agree and Join”. That way if you don’t agree it is very clear that you can’t join.

  Using a required checkbox field just forces the issue, frustrates the user, and makes them feel a little like they are being railroaded into agreement.

  Also what if my browser produces a cross not a tick  in the checkbox,  labels like “Tick to accept terms” should be more generic.

• Final Submit Button

  The final submit button, should be easy to find visually and  be in line vertically with the input fields.   This allows for an easier path to completion.

  However on this form it is like it has been tuck in the corner, with a little reminder that seems like an apology. It’s almost like the form is saying – “Sorry to pester you, but if you just click you can join”.

  This doesn’t really fill you with confidence that your membership application is going to be taken seriously.  The submit button should be a big bold statement.  After all you want people to join.

• Processing the Form

  When I tested this form it was something of a shock.

  I just wanted to see what the validation and error handing was like on the form, so I submitted a blank form, expecting to get a screen filled with error messages. That’s not what happened. I was returned with a list of processed fields, which is fine if you have completed to form, which I clearly hadn’t.

  It is really important to validate the required fields at least, check for bad email addresses and the like, and return an error message, preferably near the relevant field. Ideally you should validate inline as the form is being completed and recheck server side when the submit button is pressed.

Accessibility issues

A quick review of the accessibility on the form indicates that it’s no that bad, fieldsets and labels are correctly used, tab order seems fine. However a few sticky points are present:

• Requirement Indicator. The indicator for the field requirement is presented after the field, this will be an issue for some people as they will not be aware of the requirement of the field till after they have moved past it. This should have been placed semantically between the label and the input field. Presentation wise it could remain after the field.

• Data Formatting – The use of data types formatting and hints in the input fields themselves can be an issue, especially if the JavaScript does not clear them.

  After all the user may not have JavaScript turned on.

  It is better practice to present these hints semantically before the input field but after the relevant label.

  Also consider from a usability view, when a user has moved into a field the context of the requirement is lost and can’t be referenced.  This information should be presented anywhere on the form  as long as it’s in close association with the relevant field, and not in the field itself.

• Field Labels – All fields should have labels, even if you don’t want to display the label. There are ways to hide them, but from an accessibility view point they are very important.

Something to consider

Now I have no idea if this has been done with this form or not, still I recommend with a form like this that  you:

• Produce Prototypes

  Using Prototypes would have allowed a development team to work with an interaction designer to produce a form that was within budget and still easy to use.  Any prototypes could have been tested and fine tuned with the respective audience to determine the best completion and conversion rate for a relatively low cost.

• Some User Testing

  Finally user test on a iterative developmental proccess with the final form to produce the best outcome could have been conducted on all of the above points.

Remember

A badly designed web form is like putting a roadblock in the way of your users  - this is something you really want to avoid.

I know there can be internal issues from legal departments, IT, reduced budgets and the like. Still consider if the form isn’t that usable, less people are going to complete it.  Sometimes having a bad form design can be worse than no form at all.

The more friendly and easier to use a form  is the greater conversion and completion you going to get.  Simple really.

Just think about these points next time you’re designing a form.