When I was working on a project for a large company, an experienced user of that company's software wrote a letter that illustrates a few of the points made in this book. The quoted statements are from the letter.
"The software was represented to me as a more mature product." Interviewing the programmers revealed that schedule was put ahead of quality in the priorities. What had been offered to the customers was the dream of the original project leaders. What was delivered was a schedule-driven "minimal usable subset." Many desirable details had to be omitted because the tools, which had been chosen prior to the completion of the interface design, could not implement the desired interactions.
"The user is required to press Enter or click the mouse button many more times than is necessary to enter information." When entering material into a field, it is not necessary to have the user press Return or Enter or do anything else at all. When the user moves to the next field or screen or uses a menu or a button, the system should just accept the input as it stands.
Using Tab instead of arrow keys to move between fields caused problems. Two of the fields on one screen had free-form text input. In those fields, a user could tab to indent paragraphs or make indented lists. Therefore, Tab would not get the user to the next field. It was painful to watch a user repeatedly tap the Tab key to try to get to the next field.
 A Next Field key would seem to be a useful addition to computer keyboards.
These examples represent two common interface problems. The first is the use of Return to delimit a field, a custom that dates back to the limitations of the teletype machine as used in time-sharing and minicomputer applications many decades ago. The second is the overloading of Return and Tab, using them to mean one thing in free-form text fields and another in shorter fields.
"When a search option is selected, the cursor should appear in the appropriate text box so the user can start entering information without having to click the box with the mouse or press the Tab button." This is a specific case of a general principle: If the user can do only one thing next, have the computer do it.
"Useless dialog boxes are probably the major cause for wasted user input and frustration." The dialog boxes he showed were the kind that inform the user that something has happened and require a mouse click or a press of the Enter key to get rid of them. There is no choice; you must click the box to go on. This is another specific case of the general principle just mentioned: If the user can do only one thing next, do it for him. As the writer said elsewhere in his letter, "It is important that every time a user must interact with a dialog box that there is a productive outcome to the interaction." This can be generalized to: Every time a user must interact with a computer, there must be a productive outcome to the interaction. Moving forward in the work flow in and of itself is not a productive outcome.
The writer went on to complain that another dialog box merely "tells the user that the item is already listed" when the name or number of an existing item was entered on the screen that allowed you to enter a new item. You had to dismiss the dialog box before you could go on. He suggested instead that three buttons should appear, allowing you to leave the item as is, to delete the listed item, or to bring you to a screen where you could edit it. His design is better than what was provided, but we can do better still. Part of this problem is the idea that entering a new item is different from editing or deleting it. Here is a simpler method: The user summons the form and puts in the item descriptor; if it is new, the item is entered, and the user continues as she had expected to continue. If it is an item already on the list, that item's data is brought up so that the user can instantly see that it already exists. She can then edit it directly. Deletion, of course, is just one of the ways you can edit.
The writer pointed out that a screen soon fills up with identical icons differentiated only by the names that appear underneath each of them. He suggested that a greater variety of icons be used because the "environment is a visual one." He's right in that the icons in a screen full of identical icons just wastes space. He suggested that four different icons be used. But with only four, there will still be lots of identical icons lying around. The solution is to realize that the icons are unnecessary. In making graphics-based interfaces, we must remember that text is also a visual cue; it is a very powerful one that is full of specific content and one that we all know very well (see Section 6-3).
"If you have a purchase order open and you want to do an item inquiry, you receive the following dialog box:" The box says: "This application may not be used when 'Create / Update P.O.' is running." The correct user reaction is "Why not?" Here, the designers were not aware of the real work flow of the user's task.
The general principle is that almost any overly structured work flow approach to system design risks impeding a user whose task or inspiration demands a different approach. In this case, the interface moves from aiding the user to being a dictator. A computer should be a servant, not a peer or a boss.
"There is a tendency in the computer industry to conform whether or not it has a productive outcome.... Conforming and having a standard design are very important...because it takes the user less time to get up to speed..., but if by conforming or standardizing, you are creating uselessness, then you have failed in your design." This is exactly one of the points made a few years back by Grudin's well-known article "The Case Against User Interface Consistency" (Grudin 1989). Obviously, Grudin's analysis has not permeated into the industry. Abandon a standard when it is demonstrably harmful to productivity or user satisfaction.
"When the software was designed, it used the standard Windows menuing style." His example showed: "All the menus have uselessness built into them. One menu has the Exit command hidden below the File menu." He was trying to point out that Exit was the only item in that menu. "Exit should sit on the main menu line and the choice File should be removed." As he says, "one item does not make a list." It is wasteful to have to open a menu when there is no further choice.
The writer often made specific suggestions to improve a detail when there was a deeper design flaw that needed correction. For example, in making up a purchase order, the user is first given a screen, called Purchase Order Direct Entry (Add), for a particular product. The user must then choose a quantity. The default quantity is 0, and as the writer points out, "The default value should be 1. I really doubt that anyone will order a quantity of 0." He's right. But the whole screen is a mistake. The user should be presented with a list of items that he can scroll through or access by means of a search. Then he would just change the quantity in the list. In this case, 0 would be an appropriate default. In some applications, the list should retain a particular user-chosen quantity for example, the last quantity ordered as the starting point. Depending on the demands of the task, it might be useful to have a Set All Quantities to 0 button. Clearly labeled and undoable, of course.
There is also a Purchase Order Direct Entry (Remove) screen in the system. This screen is unnecessary: Setting the quantity to 0 in a Purchase Order Direct Entry should remove the item from the purchase order.
The screens have another wasteful convention. There are buttons, marked Save and Exit, at the bottom. Most users are not sure what they do. Does Save both save and exit, in which case it should be labeled Save and Exit, or do you have to click them both in sequence to get out of the screen with the entry saved? If you exit without saving, do you get a warning, such as "Do you want to save your changes before exiting?" or does it just dump your work? In any case, having either button is unnecessary. Once you move the cursor outside the box and start to do anything else, the system should allow you to do it, saving the contents of the old dialog box.
When a customer takes the time to carefully analyze and make constructive suggestions about your product, pay attention! It is not an attack or an embarrassment. This person is not an enemy attacking you; he or she is showing loyalty to and interest in your product.