Form-Field Validation: The Errors-Only Approach

Error pages for form-field validation are dreadful. You’ve just filled out 20 form fields, yet you get the same bloated page thrown back in your face because a single field failed to validate.

I clearly recall the often loud sighs of despair during our last usability study each time a test subject encountered a validation error page.

We also noticed that test subjects who had been exposed to validation errors began to take preventive actions to avoid them in subsequent steps, by writing things such as “N/A” in the “Company name” field if in doubt about whether the field was optional.

When getting the exact same page but with an error message, the user will feel they have made little or no progress, despite having typed 90% of the form fields correctly. (Image: Blue Nile)

Some of the frustration with validation error pages likely stems from the user being returned to the same page they came from. Being returned to the exact same page is problematic for a couple of reasons:

With all form fields still displayed (valid or not), the user might have difficulty identifying the few erroneous fields among the many valid ones.More critically, seeing the same page twice makes it seem like the user has made no progress, despite having just filled in numerous form fields correctly.

At Baymard Institute, we reflected on this problem and got an idea that we call “error fields only” — which is exactly what this article is about. Before exploring this idea, let’s look at three traditional types of validation techniques: “same page reload,” “optimized same page reload” and “live inline validation.”

Here’s a typical validation error page from Staples’ checkout process:

The current error page for Staples’ checkout process. Besides having a subpar indication of errors, Staples also breaks a handful of checkout usability guidelines.

When the user first submits the page, the entire page is reloaded, but with indications of validation errors. A message at the top of the page tells the user they have made an error and describes what the error is; further down the page, the label for the erroneous field is in bold and red.

This is significantly better than the sad practice some websites adopt of only highlighting the erroneous field in red or bold (without any description) and letting the user guess what went wrong. But the implementation could be much more thorough. Let’s look at how Staples’ page could be improved.

To have a fairer baseline for comparison, we’ve made three changes to substantially improve Staples’ error page:

A simple mockup of an optimized version of Staples’ error page. Notice the anchor link at the top and the tailored description near the erroneous fields.

The three changes are:

The error description at the top indicates the number of errors (if there’s more than one) and lists them.These listed errors are links that take the user directly to the corresponding field (especially important in long forms).A tailored message for each erroneous field shows either an example of correctly formatted data (for example, john@example.com) or a tip on what might be wrong with the data (for example, “Looks like the ending in the email address you provided is missing (.com, .org, etc.),” instead of just “Email wrong — please correct.”

Now, in addition to being able to locate the erroneous fields and spot multiple errors more easily, the user actually has guidance on how to correct their data. Some input errors are plain cases of mistyping or obvious details being forgotten, which most users will spot immediately; but if the user lacks clues and can’t instantly see why the data is invalid and has to guess in order to proceed, then they will likely abandon the process.

While better, this second implementation (and the first) still result in a poor experience. The user still gets the whole page with all 31 form fields thrown back at them, despite having inputted 90% of the fields correctly. The signal-to-noise ratio is still high (two errors among all valid fields). The user will likely scroll up and down the form to make sure all errors have been fixed and, finally, scroll down to click that “Continue” button once again. This diminishes the user’s sense of accomplishment and makes their effort to resolve the errors unnecessarily cumbersome.

A very effective technique that resolves some of the issues with the last method is “live inline validation.”

Here, each form field is validated separately as the user types. The error handling is most often instant, with the user being told that their data doesn’t match the expected format (although the user can scroll past and try to submit the form anyway). Luke Wroblewski has done some excellent usability research on the inline validation techniques that work best.

Inline validation alleviates the aforementioned issues by indicating progress and by pointing out the erroneous fields (since the page does not reload). This makes the technique useful for forms in which the fields can be validated independently. In other cases, the data isn’t as simple as a user name, password and email address; sometimes the data needing validation is an array or a set of data. In the realm of e-commerce, one might need an address or credit card to be validated.

To live validate a credit card, you could perform a Luhn check to verify the format of the number, and you could verify the expiration date and security code (or “card verification value”) for the correct number and type of characters. However, the validation could still fail if the data doesn’t all match up when the payment vendor tries to authorize the card or if the card is declined. With live inline validation, the user would be first presented with a green checkmark as they input data in each field, and then they would see an error message after submitting the form if any of the fields didn’t check out. Alternatively, live inline validation could be disabled for just those fields for which the data has to be checked remotely. However, this has the drawback of an inconsistent UI, whereby some fields are validated live while others aren’t.

For address validators, the format of the inputted data could be correct, but the address itself could still fail validation (for example, if the address doesn’t exist). Again, live inline validation would begin here with checkmarks indicating to the user that the inputted data is correct, but then, when the user submits the address form, the website would (confusingly) change its mind and tell the user that it doesn’t recognize the address after all.

Our suggested approach, the fourth and last validation technique, tackles these problems.

As we’ve seen, there are different ways to display error messages, each with its own strengths and weaknesses. Based on these observations, we thought of a validation technique better suited to complex data. What if we removed all validated fields on the error page that reloads? What if we displayed only those fields that failed validation? So, instead of reloading the entire page and showing all 20 fields of the form when only the “Phone” and “Email” fields have errors, you would simply show a page with those two fields and the corresponding messages.

With this approach, the picture is quite different. The user now gets a new page, or an overlay, with just a couple of error fields. A summary of the validated data would also be displayed, along with an “Edit” link in case the user spots something they want to correct. Staples’ error page would then look something like this:

A simple mockup of what Staples’ error page would look like with this fourth approach. Only erroneous fields would be shown, and all validated data would be summarized below with an “Edit” link.

This approach makes the error page much more digestible than the traditional technique, and it makes abundantly clear which fields are the problem, which is particularly helpful in long forms.

Now, the user simply has to fix the fields shown and hit “Continue” — no scrolling, no having to pick out erroneous fields from valid ones, no repetition of the same page, just a simple page explaining exactly what to fix and how to proceed.

Compared to the two traditional reloading techniques (i.e. 1 and 2), the “live inline validation” and “error fields only” techniques both offer the user a sense of progression and a clear distinction between erroneous and valid fields.

The “error fields only” approach is usually best when inline validation wouldn’t quite work. In April 2012, we benchmarked the top 100 e-commerce websites in the world and found that only 8% use live inline validation during checkout (likely due to having to validate both postal addresses and credit cards). In general, the longer the form and the more complex the inputted data and its dependencies, the more likely the error-fields-only approach is the best choice.

Inline validation is effective for simpler forms. When the data is an array or set, such as with postal addresses and credit cards, then the method becomes problematic. In this case, the UI would be illogical (the user would see each field validated individually and then suddenly fail collectively) or inconsistent (only some fields would validate as the user types). Of course, this technique would still require the page to be reloaded as a fallback, in case the user submits the form regardless of inline error messages (or if they have disabled JavaScript); therefore, the page reload techniques (the traditional and newer versions) might be best even for simple forms.

On smartphones, the error-fields-only approach has an advantage over the same-page-reload technique, because users typically lack an overview and context of the form due to the small screen. In such cases, displaying only the erroneous fields would help the user focus on the task at hand.

The error-field-only approach is merely a concept, and it needs both refinement and testing. An even better solution to these user experience problems most likely exists. Maybe having a traditional (although optimized) error page with green checkmarks next to the validated fields on the error page (to indicate the user’s progress) would be a better solution; or perhaps applying a slight fade to validated fields, making the erroneous ones stand out, while maintaining the context of the page.

The error-fields-only approach is more an attempt to inspire and a call to action to rethink how we handle validation errors and thus provide a better user experience.

While we can agree that validation pages aren’t the sexiest part of Web design, we should give them attention because their quality will determine whether the user comes to a screeching halt or feels a small bump on the road.

Got your own examples, mockups and ideas for validation errors? Share them in the comments!

(al)

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

Read more >>

Tweet

Big businesses and the cloud: How to approach three big hurdles

Takeaway: Thoran Rodrigues looks at three major concerns that enterprises have with moving to cloud services or infrastructure from a provider’s standpoint.

The case for cloud computing is pretty compelling: by moving services and infrastructure to the cloud, it becomes possible to optimize not only costs, but also resources such as processing capacity, energy, space, and time of qualified support people. If the advantages over the traditional model are so obvious, however, why aren’t all companies going to the cloud immediately, especially in these times of economic trouble?

If we look at start-ups and small business, we actually see this move happening. Small businesses are quickly adopting all kinds of cloud-based solutions, from infrastructure to software solutions, and any start-up looking for funding should avoid phrases such as “client-server model” or “purchasing servers” in its business plan. The rate of adoption drops sharply with larger companies, however. They are usually very resistant to taking the plunge into the cloud, citing several concerns as reasons to take a “wait-and-see” approach. After a couple of years offering cloud-based services to companies of all sizes, here are a few of the most common concerns that I’ve heard.

Large companies place an enormous emphasis on protecting and restricting the access to information. The several recent high profile cases of data theft have made security the number one concern when discussing cloud computing. It is important as well to understand that the concentration of data that comes with the cloud makes the main providers ever more valuable targets. If everyone stores their data at Amazon, for instance, then hacking into Amazon servers becomes a very profitable opportunity for data thieves.

At the same time, the concern of these providers is greater than that of any individual company. They depend on being trusted to survive, so they must be much more careful with their security than anyone else. Also, most access restriction technologies can be easily deployed on the cloud, and cloud-based software offers the opportunity for a much more detailed monitoring of user activities. Security, therefore, is probably the easiest concern to address.

It is an universal truth that something will, eventually, go wrong. Accountability, as it relates to the cloud, means figuring out who will take the blame when it does. When all systems are internal, managed by the company, the blame will obviously fall with the IT department (regardless of it being at fault). When things are in the cloud, however, it becomes harder to determine who is responsible for what, and who is at fault when a problem occurs.

Perhaps the hardest part of dealing with this concern is that it will rarely be voiced openly; instead, it will show up as a paragraph in a contract, to be enforced “only when something goes wrong”. The best way to address this concern is to be straightforward: clearly state who will be responsible for what from the start, making sure that everyone involved is on the same page.

This is also the “legacy systems” argument. Most large companies have spent millions of dollars developing and maintaining the systems they already have up-and-running, and it’s very hard for them to justify abandoning this investment for a new thing. But then, this is mostly a financial problem, not a technical one. For traditional systems, the cost of initial development must be offset by future usage, while in the cloud there is little or no initial cost, so the expenses remain steady over time. It’s the same thing as buying a server or hiring a virtual machine: it’s harder to get the money to buy the server in the first place, but after it’s been bought, the monthly cost is lower than what would be paid monthly for a cloud server if we disregard upgrades, technical staff, etc.

How would you feel if you had just spent a million dollars developing something and someone shows up with a cloud-based service that does the same thing for just one thousand dollars a month? How hard would it be to explain this to company shareholders? What makes these concerns even harder to deal with is the fact that a lot of the times the discussion about moving to the cloud will involve whoever made the original investment.

The best way to deal with concerns related to previous investments or legacy systems is to talk about total cost of ownership. By moving to a cloud-based model, where most things are purchased as services based on usage metrics, it may be possible for even large companies to reduce their total cost with different solutions, thus justifying any changes from the existing systems to cloud-based ones.

In the end, dealing with any one of these concerns is a matter of communication. What changes from one to the other is only how to communicate. For security, it’s important to show that the cloud can be just as secure, or even more so, than any on-premises solution. For accountability, speaking plainly and taking responsibility is fundamental. Finally, for financial concerns, showing a detailed cost-benefit analysis can make the difference between getting a large contract and ending up empty handed.

Thoran Rodrigues is a cloud enthusiast and entrepreneur.

Read more >>

Tweet

Try the Tag-It Approach For Increased Daily Productivity

Being stressed and overwhelmed with a lot of work is quite common. Whether it's real work or a perception of "I'm so swamped", it is difficult to think straight and fast. To help, we often talk about prioritization, creating SMART goals, etc. Today, let's look at a hybrid model.

The Tag-It Approach is about setting an order of importance and time to your task list. You don’t want to be spending time on the least important tasks while the more important ones are left unattended. Further, you don't want to waste time looking for a task that you can knock out before lunch, this list approach will have weigh priority and time so that you can quickly move from task to task.

You can tag tasks using following parameters:

1. Urgent & Important
2. Huge Benefit to Completion
   
3. Large consequences for delay
   
4. High on Irritation / Nagging
   
5. Estimated Time (to complete the task)

7 Steps to The Tag-It Approach

1. First do the basic task filtering processes. Remove things that you plan to delegate and remove things that are simply 'wish' items.
   
   
2. Create a table with 7 columns. Use the 5 steps above for column headers and then also label another column 'Task Name' and one 'Yes Count'.
   
   
3. Fill the first column with your filtered tasks. Remember - don't add things that you are punting to someone else, this list is for things that you are executing on.
   
   
4. For the next four columns, simply ask yourself following questions and record answers in respective categories –
   
   
   
   
   • Is my task urgent and important?
   • Do I really see a benefit when this task is completed??
   • Will I face negative consequences if this project doesn't get done??
   • Is this task constantly nagging and irritating to me and my peers?
   
   
5. 'Estimated time required' column is self-explanatory.
   
   
6. In the count column, simply add up number of ‘Yes’ your task has. A task with 1 'yes' is not too important compared to a task that accumulates 4 yes answers.
   
   
7. Start picking up tasks in groups of descending order of Count Column and finish them off as fast as possible.

Effectively Using The Estimated Time Column
The 'Estimated Time' column is a great way to create your work schedule for day / week or more than that.

For instance, if a meeting gets cancelled and you suddenly have a free hour, look at your list and choose to knock something out that takes less than an hour. Having this list handy and predetermined, will prevent you from sitting there for 20 minutes wondering what you should work on, or worse, visiting your inbox and simply killing an hour bouncing between Facebook and email.

You can also use ‘Estimated time ’ to set a priority order within your task group. Based on what works for you, you can either work your way through most time consuming to least time consuming (bigger tasks first) or the other way round (quickest tasks first).

Customizing The Tag-It Approach
For the above example we used only five parameters, based on your unique situation, you can add or remove any parameter you want to.

For instance, if you are working on a team and would like to use the tag-it approach, you can consider adding ‘Has dependencies’ as a parameter. This will help you in picking up those tasks first which need to be completed before others can begin their tasks.

Examples of additional parameters you can use: Can become a bottleneck? Customer Impacting? Is this important but not urgent? You get it. Choose things that are important but don't add criteria simply to have a complex plan'. Chose truly pertinent that impact real concerns. Over a period of time as you get comfortable tagging tasks, your tag sheet or file can become a single place where you jot down task specific planning details.

How do you see yourself using the tag-it approach? What customizations can you think of?

Read more >>

Tweet