Data validation best practices: how can I better construct user feedback?

Question

Data validation, whether it be domain object, form, or any other type of input validation, could theoretically be part of any development effort, no matter its size or complexity. I sometimes find myself writing informational or error messages that might seem harsh or demanding to unsuspecting users, and frankly I feel like there must be a better way to describe the validation problem to the user.

I know that this topic is subjective and argumentative. I've migrated this question from StackOverflow where I originally asked it with little response.

Basically, I'm looking for good resources on data validation and user feedback that results from it at a theoretical level. Topics and questions I'm interested in are:

1. Content
   • Should I be describing what the user did correctly or incorrectly, or simply what was expected?
   • How much detail can the user read before they get annoyed? (e.g. Is "Username cannot exceed 20 characters." enough, or should it be described more fully, such as "The username cannot be empty, and must be at least 6 characters but cannot exceed 30 characters."?)
2. Grammar
   • How do I decide between phrases like "must not," "may not," or "cannot"?
3. Delivery
   • This can depend on the project, but how should the information be delivered to the user?
   • Should it be obtrusive (e.g. JavaScript alerts) or friendly?
   • Should they be displayed prominently? Immediately (i.e. without confirmation steps, etc.)?
4. Logging
   • Do you bother logging validation errors?
5. Internationalization
   • Some cultures prefer or better understand directness over subtlety and vice-versa (e.g. "Don't do that!" vs. "Please check what you've done."). How do I cater to the majority of users?
6. Accessibility (edit)
   • This is an extension of the delivery topic, but what are the best options for providing feedback to the visually impaired (color blindness or full blindness)?

I may edit this list as I think more about the topic, but I'm genuinely interested in proper user feedback techniques. I'm looking for things like research results, poll results, etc.

I've developed and refined my own techniques over the years that users seem to be okay with, but I work in an environment where the users prefer to adapt to what you give them over speaking up about things they don't like.

I'm interested in hearing your experiences in addition to any resources to which you may be able to point me.

Answer 1

Should I be describing what the user did correctly or incorrectly, or simply what was expected?

If you don't describe the "incorrectly" and "what was expected", the user is lost and cannot make a change. What they did correctly is obvious, since it's not invalid.

What they did incorrectly tells them what to change.

What's expected should tell them what kind of change to make.

How much detail can the user read before they get annoyed?

Varies from user to user. There's no general answer. And there's no easy way to know. Experienced users want short messages. N00bz need long messages. And you can't know the user's level of expertise until after they complain about the messages.

How do I decide between phrases like "must not," "may not," or "cannot"?

You can't decide. It's not your choice. It's your users. In American English (which doesn't even use "shall" except in legal documents) the differences are minor and vary by user. Each user has a personal level of discomfort (or comfort). You can't know the user's level of comfort until after they complain about the messages.

Generally, folks don't like computers telling them way they "must" do. Other than that, it's individual preferences.

This can depend on the project, but how should the information be delivered to the user?

Um... This makes no sense. If the data's invalid, you can't go forward.

Should it be obtrusive (e.g. JavaScript alerts) or friendly?

This makes no sense. "obtrusive" and "friendly" aren't orthogonal.

Should they be displayed prominently? Immediately (i.e. without confirmation steps, etc.)?

This makes no sense. If the data's invalid, then they can't go on, so it has to be prominent.

Do you bother logging validation errors?

Talk to your lawyers about the consequences of users making entry errors. In the medical field, it might matter. In other fields, it rarely matters. If you're fine-tuning your presentation, you'll want to log things so you can figure out what the most common error is and re-engineer things so it cannot possibly be made. If your users are all n00bz (because the app never existed before) you'll need to log things so you can work out the real use cases. If your users are all experts, don't bother logging.

How do I cater to the majority of users?

You can't. Preferences for support and guidance vary by individual person, their level of expertise and their overall comfort with computers and the application. Broad cultural generalizations are less important than individual ones.

Answer 2

The question you should be asking yourself is: How do I make my UI more usable and friendly overall? To do that, read books like "Don't make me think," and the other books listed here.

To answer your specific question about validating user input, I have three suggestions:

1. Use common sense, politeness and courtesy with respect to your verbiage.
2. Give them all of the validation at the same time, on the same page. Don't make them walk through a series of single error messages. Use some sort of visual cue to distinguish the invalid fields.
3. Whenever possible, favor a technique that avoids modal confirmation dialogs. For example, when you delete an email in Gmail, it does not confirm; instead, it moves the message to the trash, and gives you an option to undo.

Answer 3

As you said the issue of validation is subjective. The reason behind this though is that it relates to user experience/usability which is not easily reducible to a finite number of do's or dont's. That said there are some general rules of thumb which can be used to make design/implementation decisions

1. Content: First rule of user experience is it is about user experience, which means it is about making it easy for user to work with software, which means think as a user and not as a developer (or worse hacker)
2. Content: From 1., it follows give information to user on a strictly need to know basis. The user only needs information which is just enough to address the issue, he is not interested (in fact he gets annoyed with) in lots of technical jargon
3. Grammar: Again try to use passive voice as much as possible such as "value should not be null", as opposed to "you must not enter null value" which depending on culture may seem rude/confrontational.
4. Delivery: The feedback should be delivered so that it minimizes any effort/time by user, which is why it should as immediate and as accurate as possible after the error so that user can rectify it. For example it is a text box with incorrect input should be immediately indicated with a different invalidation color.
5. Delivery: An extension of 4. when asking for user to verify all the valid inputs must be retained, with the exception of password.
6. Delivery: They should be delivered as unobtrusively as possible which means the user is notified of the error, but he shouldn't have to spend any extra time, hence modal dialogs are a big no-no you should try as much as possible to stick to disable OK/Next/Apply button and invalidate the input control (example given in 4.)
7. Logging: Make it so that it is possible to toggle logging mode. While logging help in trouble-shooting it is a drag to performance.
8. I18N/L10N: This varies on a case to case specifically implement this only if you need it now or going to need it in near future.

Updated:

Now the situation changes a little in the context of a web application, with thin client and all the validation occurring on server side. To consider this case, there should be one additional rule next in importance only to 1. point (viz. it is all about user exp), that is performance. Whatever we do, the performance should be a priority. Now in our case the performance is severely affected by the number of messages between client and server, which is why it may not be the best idea to send message after every input. Instead one could try a different approach.

To given an example, suppose the input has 5 steps, and user enters incorrect data on step 2 and 4, also step 3 has some password, in this case after user has completed all the steps, client should send message for validation, after the validation on server side, the user should be prompted only to enter only that input which was incorrect (or a password) for steps 2,3 & 4. Also the input to be re-entered should be clearly indicated.

Updated Again: Reg. accessibility for the impaired, I have never worked for the UI however I think the basic principle is same only instead of indicating invalid input by color, it should be indicated with the help of audio. Also in this case it might be a good idea to give immediate feedback instead of waiting till the end of all inputs.

Answer 4

Content

I tend to use multiple validation patterns, each with a short phrase, typically the sentence will describe the violation they made. "XXX cannot be empty."

Grammar

I don't personalize it like saying "you may not have an empty XXX", if you want to make it lighter you could treat the field as though it were it's own entity: "I cannot be empty!" or "I must be at least 30"

Delivery

I prefer a contrasting color (red against white) error string right next to the field, your flow will have to be malleable for this to work.

Logging

I haven't in my projects but you may need to for domain specific (or legal/policy) reasons.

Internationalization

If this is really that important you could break down error strings into parts which could be exchanged:

• "{field} {verb} be empty"
  • XXX cannot be empty
  • XXX must not be empty

Answer 5

What I like to do when practical:

If the input field is categorically invalid I turn the background red. If it's currently invalid but could contain an incomplete version of a valid answer then I turn it yellow. I also display in a nearby location a message describing what's expected and if it's at all complex a message as to why the item is invalid.

(Example: The input range is 100-2000. "1" gets yellow. "3000" gets red.)

Answer 6

Here are my 2 cents:

• content

I think you should describe why the value is not correct, like "username cannot have special characters", so user knows what he did wrong and can fix it. error like "bad username" is making user fight the app(for example I once created 50char password with everything I could think of because I was tired of fighting with the pass-system. however it was very strong password and I had to keep it in text file to remember it.).

• details

I think you should add enough details so user knows whats going on, but not too much(If I get big alert message with a lot of spam there, i wont even read it - its too much work and if I can only click "ok" than why bother? I might read it the second time I see it if Im interested why something doesnt work).

• delivery

I prefer red text near the field or on the top of the page. I use alert only as last resort(clicking ok all the time sounds like something that can annoy people).

• logging

no, If validation is broken user will let you know about it.(if its a work app or he use it a lot/cares)

• internationalization

I think saying "please" to user is annoying, because he should be able to ignore what you are asking and do what he want to do. However if you saying "please" as "you must do that", it would be annoying to me plus its extra useless text(aka spam).

Answer 7

My answer proposes stepping back from the problem and taking a wider view. If that is more than is requested, my apologies and please skip to the next answer :)

Short answer: read Magic Ink.

Long answer...

Why do we find software frustrating to use? Consider some cases:

• Are you sure you want to... ? Gosh, I thought I was sure (after all, I issued the command), but your question has me doubting myself -- there must be some dire consequence. I sure wish I knew what that consequence was...

• Invalid input, please enter a valid date. I'm awfully sorry I offended you by that input! It's just I'm not completely sure how you want me to enter that date. I wish I had a calendar at hand...

Okay, these examples are extreme -- but we've all seen them, right? I'll 'fess up and say I've written a fair share of such questions. The problem is, I sometimes spend hours, days or longer thinking through all the possible workflows. As a programmer, I build up a mental model of the whole rat's nest until I have internalized the whole thing. So now I can see: "Ah yes, step 7b. I need one bit here to tell me whether I should continue or abort. I know: Are you sure (Y/N)? Voilà! That will get me my bit." The problem is, the user has not lived through those hours and days, and certainly has not built-up the mental model. He doesn't even know we're on step 7b! The user will need much more information...

I relate these shaggy dog stories to make a point: I suggest that the messaging associated with data validation is really just a special case of the more general problem of how to present all of the business-related information (content, errors, everything). So, to cut to the chase...

Magic Ink is a paper that tackles head-on "the ubiquity of frustrating, unhelpful software interfaces". It argues that "interactivity is actually a curse for users and a crutch for designers, and users' goals can be better satisfied through other means". The paper also contains pointers to other helpful references.

Answer 8

Content

Following the Delivery approach provides much greater leeway concerning content. Spell it out as necessary. People hate systems that make them feel stupid. Great way to make them feel stupid is putting them in situations where they end up guessing - wrongly.

Grammar: read Elements of Style

Delivery

• make it viewable whilst a user edits the data form - ever hit an alert that tells you what's wrong across several fields only to OK out of it and not remember what needs doing?
• show restrictions on initial data entry - next to each field or tooltip on focus for example
• validate on blur in situations that make sense (e.g. username must be unique).

Logging

Usually no, with a big fat "it depends". There are situations where repeat failures warrant logging. For instance, repeat failed login attempts.

Internationalization

Java Resource Bundles comes to mind. Think this an area without a good answer. Leave to programmers it'll either be too commanding or too verbose :). But maybe I just don't give my fellows enough credit.