Preventing issues on web forms

Posted March 9th, 2010 by David Hamill

This post is a follow-up to to my previous post on validating web forms. In that post I gave you tips on helping users recover from validation problems. In this post I give you tips on avoiding the problems in the first place. You can write a whole book on this subject (and many have) so I’m just covering a few examples that come to mind.

Avoid internal/technical language

Think carefully about the language you’re using on your form. You should adopt your user’s vocabulary instead of using any technical or industry terms. Here’s an example below from FreeAgent (a web-based accounting application).

When asking for your payment details, FreeAgent asks for your Card Verification Value. This means nothing to a lot of people. In banking it’s called a Card Verification Value or CVV number. To us normal people, it’s that 3-digit code on the back of our credit or debit card. This label might be a little clearer if it were called “3-digit security code”.

In this instance there are a couple of things that FreeAgent does to remedy the situation. By sizing the text field appropriately, many people will know what’s being asked for. They are now used to providing a 3-digit security number. Some will be happy to assume that this is what the text field is for.

We’ll talk about the other remedy a little later.

Intelligent reformatting

Your internal systems may insist on the strict formatting of some data, but this shouldn’t impact the customer. It’s your job to deal with that, not theirs.

I’ll use an example to demonstrate. When booking a flight with EasyJet, I’m asked for the payment details below. No formatting rules are specified for the card number.

Like many other people, I type in my card number as it appears on the card. The number on my card has spaces that separate the number into groups of four digits. But if I type in my number in this way, EasyJet doesn’t like it.

This is lazy programming. If the spaces can be detected by the form, then they can also be removed by the form. EasyJet should just remove the spaces for me, instead of asking me to go back and fix the problem. Don’t they want my money?

Also, see my post on validating web forms and read why JavaScript alerts are a poor mechanism for form validation.

Only ask for the information you need

Every question you ask on a form is an opportunity for something to go wrong. This is just one of the reasons to only ask for the information you need. You don’t want users dwelling on questions that don’t matter. So don’t ask them in the first place.

I recently wrote a blog post about asking people marketing questions that is related to this point.

Asking inappropriate questions can also create issues with trust. If you ask for information that users don’t want to give you, they may begin to mistrust your motives. When they begin to get suspicious of you they may abort the form completely.

Optional and required fields.

Don’t use the word ‘mandatory’ when talking to users. We say ‘mandatory fields’ because we’re geeky web types. Real people don’t. Use the word ‘required’ if you want them to know what you’re talking about.

There are 2 approaches you can take to displaying required fields.

• All fields are required unless marked as optional
• All required fields are indicated (often with a red star)

If you choose the 2nd option, the placing of the red star is very important. When people fill out web forms, they tend to look only at the questions and then the form fields. So if your star is not in the path of that eye movement, it could easily be ignored.

The three examples pictured below show a red star that is positioned in the path the user’s eye will take when reading and completing the form. So it is likely that users will notice its presence.

The example below shows an approach where the red star is more likely to be overlooked than in previous examples. This is because the user has no reason to look there.

Think before validating optional fields

In most cases, it’s better not to bother adding validation to optional fields. But sometimes you’ll find that it’s necessary.

It’s often better to accept that the data from optional fields will be more prone to errors. The alternative is to validate these fields and introduce the possibility of added friction to the process of completing the form.

If you’re prepared to accept no response to a question then consider also accepting an incorrect response.

Providing hints

It’s often helpful to provide little hints with some questions in order to ease understanding. Let’s go back to FreeAgent’s ‘Card Verification Value’  and see how they manage to resolve the problems that may arise from their choice of labelling.

Despite the fact that Card Verification Value means nothing to the average person, FreeAgent helps to resolve  problems by providing some additional info.

Notice that this hint isn’t hidden behind a question mark link. The advice is short, so there’s no need to hide it. Strictly speaking, this solution would be unnecessary if they’d chosen better labelling in the first place. When using this type of approach, it’s important to consider the flow of the form.

Inline validation

Validating the form while the user enters information is called ‘inline validation’. It can be a good way of helping users through a form in a less obstructive way than validating all of the answers at the end (when the user clicks submit).

However, you usually don’t need to use inline validation on every question. Inline validation can be troublesome if it isn’t implemented well. Luckily Luke Wroblewski wrote an interesting article about inline validation that saves me the bother of having to do it here.

Was this blog post useful?

If you found this useful, here’s a few things you can do:

• Read more posts on my blog
• Donate to my chosen charity
• Hire me to help you improve your website
• Follow me on Twitter
• Join the discussion by commenting below