Now that you know how to optimize your Web forms when things go right, let’s discuss handling errors when things go wrong.
I asked our CTO, John Quarto-vonTivadar, who’s the author of several techie books, to explain things in plain English for us marketers. I asked him to provide insight in such a way you could print this out for developers and tell them this is what you want.
Error handling involves not just the visitor but also the Web site’s response to the visitor’s input. Developers are often tasked with writing code to handle errors. Many times, their instructions are little more than “go write some code” to process such errors. They’re not given guidelines as to precisely what should happen. Without that information, the result is often error-handling done the techie way: concise, accurate, minimal, and thoroughly unintelligible to the average visitor.
You’ve seen this before: You submit a form and get an ugly, unrelated screen that says you’ve made an error. No additional information is provided. Perhaps you actually made two errors. Once you correct the first one, the error message comes back. The Web site wasn’t capable of providing information on all errors at once. It wants to handle them one by one, and gosh darn if it isn’t going to force you to handle them one by one, too.
What Error Handling Is Required?
Error handling falls into two categories: error handling for requirements and error handling for type or format validation.
The first category deals with required information, whatever the company determined must be completed on a form, such as the address field in a pamphlet request form. You can’t send a pamphlet if the customer doesn’t provide a mailing address, right?
The second category deals with ensuring information provided is of the right type. The mailing address field has an address in it, not a phone number.
When designing Web forms, you must determine not only the required information, but also the format of all collected information, required or not. Perhaps a visitor’s phone number is optional. But if she does provide one, your site should be able to determine it is, in fact, a phone number.
Google handles this issue well. Complete only a few required form fields to register to buy AdWords, click “Submit” at the form’s bottom, and watch how the form returns to you. It indicates which fields you must complete and retains already-entered information so you don’t have to type it again.
Developers tend to bring their binary experience with technology to their handling of Web form errors. They fall into two camps: One favors client-side form error handling; the other likes server-side form error handling. In other words, should the Web form itself contain code that checks required fields and data format before it’s submitted or after?
Server-side validation allows great control over the algorithms that operate on the data and bypasses the browser-compatibility issue. But it does require a round trip to the Web server and holds off on error messages until after the user hits “submit.”
Developers often miss the point: What’s right is whatever satisfies the visitor’s needs and creates the tiniest possible speed bump to successful form submission with accurate, intentional data. Developers should use both techniques to better serve business needs, even at the expense of increased complication for themselves when maintaining code.
Presenting Error Messages
Web sites should strive to present error messages to visitors in a way that makes absolutely clear what must be corrected. A good example is Banana Republic. Follow the “Access Your Info” link on the bottom of the page, and submit an improperly formatted email address. The form returns with red text to tell you what the error is and how to fix it.
It’s helpful to have error page copy written to imply the error is in no way the visitor’s fault (even when it is!). Go ahead and blame the Web server: “We’re sorry, our server wasn’t able to understand your Zip Code.” Believe me, you won’t hurt the server’s feelings.
When performing format validation, don’t make users jump through hoops to use a format you prefer but they may not, especially if you can extract the desired format from the provided data. The telephone validation field is one example, such as on Nordstrom.com. The form requires you to enter a phone number with no spaces, dashes, periods, or parentheses.
Why? I am the human. The computer running the site is here to serve my needs. It should accept my phone number is any of the several common formats. A skilled developer can certainly write code to handle such situations and still determine if the data provided is a telephone number or my pet’s name. Other sites manage this with ease, such as AOL. Follow the “try AOL today” link on the right. As you enter a phone number on the signup form, it’s automatically formatted for you.
Finally, bear in mind this strange but true irony: Customers who do experience problems that are handled well by a company often rank their experience with that company higher than customers who don’t encounter any problems at all!
Make the necessary changes. They’ll maximize your return on investment (ROI) and conversion.
Emily Ma, product director of Tencent’s advertising platform products department, was a keynote speaker at ClickZ Live Shanghai where she discussed the ... read more
The terms that customers type into your site search function can help you to gain an understanding of user behaviour and can be used to optimise ... read more
Google Analytics comes with lots of standard reports and settings, but with a little customisation you can extract much more value. One way is ... read more