Skip to navigation | Skip to content



Micro-optimisation can reap macro-conversion

The other night I was finally sorting out a new mobile phone plan for my daughter, who manages to send text messages at an ever increasing rate.  So one of the new fixed top-up “unlimited” deals seemed the way to go.

Diving online with one major carrier appeared to provide a surprisingly quick and simple experience – until I clicked the submit button and received the following:

Example of poor form validation and error message handling
Example of poor form validation and error message handling

Huh?  ‘Contact’ number?  ‘Valid’?  Do they mean the telephone number?  If so, why isn’t that field flagged up or highlighted in some way?  And what’s wrong with the number anyway?

After a brief scan, the only thing left to try was to remove the spaces in the telephone number.  Bingo.

Dear oh dear.  It takes some effort to create a barrier on a form this straightforward.  And what a missed opportunity on such a short transaction process.  After all, getting customers through this form and the SIM card in their hand is the engine which drives these offers.  Ouch.

The ROI on the modest amount of effort to fix this is likely be…well…stratospheric.

Get the basics right

  • Take the effort to write a bit of code to cope with the slight variations in how users will enter data.  As with credit card numbers, customers may want to break longer number strings into groups to aid with entry.
  • Flag up the actual field which needs attention
  • Ensure error messages reference the actual field label, as seen by the customer.
  • Use plain language in describing any errors, not ‘tech-speak’.

Not only do we repeatedly see examples similar to this in our regular testing and research, but a recent econsultancy article has been posted about these issues as well.

The knowledge to design and code fully optimised forms has been around for a long time, over 20 years.  So it’s always surprising to still see these problems in the wild considering the impact they have on conversion.

2 comments

  1. It’s nice to see focus on usability and accessibility instead of the usual tacky gimmicky items.

    You may be interested in my article about Enquiry forms

    Thanks
    Jez D
    (I know my URI needs changing :-) )

    Posted December 11th 2009 at 7:19 am  |  Permalink

  2. I agree completly with everything being said here.
    Handling phone number variations requires minimal coding (you just need to strip any character that is not a number).

    I had a lot of similar issues on many occasions. Here’s just some examples:

    - Phone # with a country code (00386) is not excepted.
    - Phone # with a ‘+’ sign in the country code (+386) is not excepted.
    - Correct postal # is not excepted.
    - Required ZIP code for non-US citizens.
    - No UTF-8 support (for special characters), while requesting exact data (i.e. from my bank account).
    - Correctly formed email, not getting accepted.
    - Password strength checker, not allowing me to proceed, because my 20-character password (using mixed chars including special chars and numbers) is marked as weak. It accepted ‘123456′ as a good password.

    It is plain stupidity, to neglect form usability.
    Here’s another idea: use warnings, instead of error messages.
    This way users may double-check the data, but still be able to proceed(override the validation), when “smart-ass” algorithms think something is wrong with it.

    Posted April 13th 2010 at 3:40 pm  |  Permalink

Post a comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>