Form Errors – Validating phone numbers and the importance of hand testing

Nothing replaces hand testing forms

I fill out a lot of forms during the day, some on existing sites and others as new internal forms that need review. When testing I have a habit of submitting forms with every error combination possible. I know there are automated tools for this but nothing beats seeing it from the users prospective. It is different to run a command line tool and get a number of fails and successes as it is to spend 2 minutes to fill in a bunch of fields and get some weird screen state, odd colors or wording that doesn’t make sense.

That is exactly what is happening above. I clearly filled out the form to my best understanding and still got an error.

Things I notice about this error:

  1. There is something wrong with these three fields, but it doesn’t point out which one(s)
  2. The wording of the error forces me to look up and then scan down to see where the field is
  3. In my mind I did place the area code in the phone field
  4. There is no explanation of the preferred format for the phone number

After understanding that my method isn’t working and they were not going to automatically transform my format to their preferred format I tried every phone number combination I could think of. In the end none of them worked. Being the curious person I am I ended up digging through their validation javascript and found this regular expression it was validating against:

^((\\(\\d{3}\\) ?)|(\\d{3}[-\\s]))?\\d{3}[-\\s]\\d{4}$

Doing a little more investigation I found that it didn’t work at all. Try every combination you can think of at:

Good error messages should include:

  1. A summary at the top of the page of all the errors (long forms usually push the user back to the top of the page)
  2. A highlight around each field with an error
  3. An explanation with an example or clear direction where the visitor went wrong
  4. Not be nit-picky about formatting, transform as much as possible automatically

In the end I brought this issue up to Groupon and they fixed it within an hour. The issue was not with their code, but on the survey vendor’s site. It got me thinking about the time and effort the user has gone through to get to this point and end up confronted with a road block. These small things have the potential to be a huge turn off for the average user. Command line tools may be great but nothing replaces what you can learn by testing things by hand.

* Note, that is not my real phone number 😉

User manipulation with green buttons

Green means go right? Green also means positive, and lastly confirm. So why not manipulate a user’s actions by placing a green button to confirm an action they might have otherwise not taken? That is exactly what I encountered a few days ago at a grocery store.

The Setup

I went to the self checkout, scanned my few items, clicked to end the order and pay by credit card. After swiping my card I was presented with this screen:

What I did

Typically when I see a screen like this: a large title, the total of my order and then a “Yes” and “No” button. I think to myself, “Yes I confirm this charge, lets continue.” So naturally I click Yes because I didn’t want to cancel, and then I was presented with this screen:

Not what I expected

So now I was confused, why is it asking me for cash back? I just wanted to complete my order. So naturally I hit “No” and it went to the “Thank You” screen I expected before.

What happened

After using the machine a few times over the course of a few days I finally realized what was going on. The question on the confirmation screen was not what I expected. It is asking for “Cash Back” and not to confirm the total at all. I then felt silly that I had missed this large print text.

Thinking to myself, “am I the only one who missed this?” I looked around for a few minutes as others were checking out. Four people checked out with credit cards, they were all presented with the same screen, two of them clicked “No” and went on with their day. The other two clicked the “Yes” button and in the same state of confusion paused for a minute before clicking the “No” cash back. Neither of them wanted cash back but yet still clicked the “Yes” button.

Buttons can be dangerous

This reminds me a lot of Microsoft Windows and the issue it has had in the past with users installing spyware simply because they click an “Okay” button on a dialog box. They don’t read the box they just assume that “Yes” is the default and preferred choice. It reminds me of a great TED talk by Barry Schwartz on the paradox of choice. When presented with options users will choose the easiest way out.

The lesson is, as a user be careful about what you click. As a producer be good to your users, design to delight, and not to fool them.

Don’t abandon users, always be testing

A few weeks ago at the CaseV conference I was trying to get wifi in the Chicago Sheraton and unfortunately it was not free, they charge by the day. I fired up my laptop fully prepared to pay the $13.63 for a day’s worth of internet when I was presented with the form above.

A few things struck me as odd.

The first of course was the inability to read the labels for each field. This made it very difficult to use unless you highlight the entire page.

The second was the URL, it was a local address and the page was not protected by an SSL. No way was I going to put my credit card into a form without an SSL. Even a self signed certificate would have worked but CC information going over the air with potentially dozens of people able to intercept it does not sit well with me.

Last but not least the lack of instructions, terms or even description of what I was about to pay for really turned me off. Every customer asks “what is in it for me” before taking any action online. If the benefit doesn’t outweigh the cost the user will not continue. In this case it’s so unclear what the user is getting I would be surprised if anyone has filled out and submitted this form.

Continuous testing

I’m sure they didn’t design the form to be blank like this but whether it was the browser I was using or some change got moved to production that broke the form brings to light a very important lesson. Make sure you test all primary user paths every time a change goes in to production. It might sounds like a daunting task but something like this can easily happen if no one is watching. Just image how many people they are loosing because they didn’t take 10 minutes to test their form.

Enhance user experience by auto-selecting location


A few days ago I did something I’ve never done before, get take out from Applebees Restaurant. (I am in no way endorsing Applebees, just merely writing about an experience I had with them) Upon visiting their site something sparked my attention. Highlighted on the image above is the closest Applebees location to me. I have never been to this site before or set any type of settings previously.

This was great since I came with a purpose, to look at the menu and call the closest location. By them taking that initial step for me I was able to complete my task quicker. Not to mention if I were deciding between two restaurants of equal quality the one that provided me the most information the fastest would probably get my sale.

Location by IP is not anything new, geotargeted ads are everywhere but using it to help users with primary tasks make them feel a greater sense of customer service and increase your sales and ROI. The retail industry is in the best position to take advantage of this since all brick and mortar sales are driven by location. Other industries may have to get a little more creative.

Like I mentioned above location based targeting is not anything new but its use in new ways can really have an impact on your end users. I know I came away happier.