|Don't Let Your Interface Lie|
|Error Prevention Comes First|
|Simplifying for Usability|
By Gerd Waloszek, SAP AG, SAP User Experience – September 1, 2000
Computers are smart these days. They have huge memories and know everything. Well, there are exceptions to this ... Maybe, you can find such an exception even in your own application.
To help you search your applications for not so smart features, here is an example. In an application that I consulted, the developer wanted me to design a "zero indicator." "What on earth is that and what is it good for?" I asked the developer. He told me that the system could not distinguish between whether the user had entered a zero or nothing at all, because "nothing at all" was converted to zero. This was due to a technical restriction: the field was numeric, and there is no such thing as "nothing at all" for numeric fields.
Users thus have to help the system to overcome its inability to recognize "no input" in numeric fields. This is clearly exposing the inner working of a program to the users and harassing them with it. Of course, using a character field with a check for a zero string and with conversion to numeric values would have solved the problem. But the developer did not consider this option because he it would have been too much work. This story does, hoever, have a "happy end." The developer did not implement the zero indicator and found a better solution.
Here is a second example where applications or web sites need help from users, not the other way around, as it should be. Often users are required to enter data in a certain format, otherwise the system cannot recognize the input as valid data. This is often the case with date and time fields. As a consequence, an error handling procedure is needed, because users do make input errors. Design considerations then focus on the wrong issues, namely on how to formulate the error message and where to display it (see figure 1).
Figure 1: Heading in the wrong direction – an error message, albeit with helpful instructions
Sometimes the system is even "nicer" to the users and also provides instructions right in the application, showing the correct input format (e.g. "DD:MM:YYYY", see figure 2). So the users can read how they should enter the data. Actually, even this does not help much – users still make input errors, and developers complain about their "stupid" users.
Figure 2: Continuing on the wrong track – adding instructions.
But note, this way of thinking is on the wrong track. The problem is not with the users, and they are not too "stupid" to read the instructions and enter the data correctly. The problem is with the system, which forces users to act in a "system-friendly" way. Instead of requiring users to enter data in a certain format, an input field could interpret the data "intelligently." This prevents users from entering invalid data, and there would be no need for onscreen instructions, nor for an error message.
By the way, the dropdown listboxes with 30 or even 31 entries for the days often found on the Web may prevent typing errors, but they are not a good solution for this problem. A solution which satisfies mouse users as well as keyboard users, untrained users as well as proficient user is still to come.
Computers are often not as helpful as one might expect. On the contrary, they often require users to help the system. Though especially the first example may be particularly absurd, you will easily find similar situations in applications or web sites where users have to help the system. Eliminate such situations wherever you find them in your programs; your users will be grateful for this. Only then will your application or web site be truly "user-friendly." Also, tell your colleagues about your solutions so that they can reuse them and do not stumble into the same traps.