Stop scolding your users

For many years now Iʼve been a strong advocate for a new approach to error handling in user interfaces. I have had little success winning converts. Here and there I win one, but most in the industry either scoff or yawn and turn away. I guess that tells you something.

My suggestion is this: stop scolding users. Help them instead.

I dunno. Seems like an obvious thing to me. But I make this recommendation often. Most of the time it meets with blank looks.

The resistance to change is strong. Even when something makes perfect sense, the immediate urge is to reject it. No one is complaining, right?

Huh. What could go wrong with telling our customers that they are incompetent? Truth is, customers complained all the time. But they made it about the interface, not the error messages.

Difficult, then, to convince the product owners that how we convey the message contributes.

Example: a user fills out a form. She enters her email address, but — oops! — provides an invalid address.

When she tabs out of the email input (or, worse, when she attempts to submit the form), a big red box appears. Something like this:

In short: You bozo! Canʼt you even get your own email address right?

My view is simple. The bozo here is the developer or designer who created the form, not the user. It is the organization that permitted an interface such as this in production.

Users make mistakes. Forms should make it as easy as possible for users to avoid them.

Forms are often difficult to understand. Guessing the intent of the formʼs designer is not always easy. I have filled out dozens — hundreds — of forms that have stymied me. Often, Iʼve given up.

Iʼm pretty stubborn. So if I am giving up, many other users must be doing so as well.

Rarely do I have zero idea what the form expects. Rather, I can think of too many possibilities for what it wants, and I canʼt tell which one is correct. I am left trying to guess what the form expects.

Thatʼs the mark of poor form design. Such forms are myriad.

And it is so easy to avoid this problem! Here is how craft coders approach it:

1. Every form input should know precisely what valid input looks like. Ideally, weʼd have a type system that made very precise runtime static type checking possible. One alternative is the HTML input elementʼs pattern attribute.
2. Every form input must make this information clear to the user both before and as the user enters data. This means both help text and, if possible, an example (but not as a placeholder — leave the input for input).
3. Form fields must make clear whether that field contains valid input. The field must use visual and non-visual elements to do so. The form must explain to the user everything the user must do to make that input valid. Donʼt believe me? See Understanding Guideline 3.3: Input Assistance
4. Instead of a big red X to tell users that theyʼre stupid, provide a big green checkmark to show success. Reward valid input. Never punish invalid input. Rip out the red and go green.
5. Whenever practicable, limit input such that only correct input is possible. If a field expects an integer, then the only non-digit character it should accept is a minus sign. And not even that if it expects a positive integer. If a password cannot contain spaces — and why would you do something dumb like that? — then the password input should not accept spaces either. Why invite your users to shoot themselves in the foot? Itʼs a bit sadistic, no?
6. Update the help as the user enters data. For example: “Remember the @”. Or , for more than one condition, as the user meets each condition, remove it from the help message. Thus, “include at least one number and one punctuation mark” becomes, upon entering a digit, “include at least one punctuation mark”. Easy peasy.
7. Remember: nothing the user does is wrong, rather the form is not yet ready.
8. Test, test, test. Test on real users, too. Donʼt assume that your form is understandable because you understand it. Try it on users cold, and ask them to explain their thinking as they go along. No hints! Then adapt the form until it is as clear and easy as can be.

Finally, this:

• Never require information that you donʼt need.
• In most instances, if you donʼt need a piece of data, donʼt ask for it. You can always give users the opportunity to add more information. This can be by clicking a button on the form to reveal an “optional” section, or by asking them to come back later to add more. You can even allow them to choose to receive a reminder.

The simpler and shorter your form, the more understandable it is. The more understandable the form, the more likely that users will provide all the information.

By rewarding the user for correct input rather than punishing them for incorrect input, you encourage them to finish the form. And you make it less likely that they will avoid or abandon your forms in the future.

And isnʼt that the true aim of your form?

This same practice applies to anything in your app that might throw an error. Remember that errors mark your failure, not the failure of the user. It is not incumbent upon the user to know magically how your app works. It is your job to make it easy for them to grok it.

This should be simple and obvious. Yet it is shocking how infrequent this practice is. Letʼs fix that.