All I had was an Excel file with around 20 messages that had the current error message and a description when/how the error message occurs. Feeling it would be a good exercise to spend the afternoon, I made my way towards the product development team. As we started the exercise, I realised that the team had no idea about error messages. They just got in touch with me because I was the technical writer. They had obviously thought that I was there just to correct the grammar and punctuation. I sat down and went through each scenario where the error message occurs and did what was required.

One typical user activity is to create a configuration file into the database by creating one or by importing an existing configuration. The dev team wanted me to look into the errors that occur during the import process. During that process, I identified issues with the sequence of error messages appearing because the inputs were not validated atomically. Rather, they were validated as a batch and you got a bucketful of error messages that should have been caught earlier. Being modal in nature, the user had no choice but to click the Ok or Cancel button to move on, which was too late. And these error messages really weren’t serving any purpose other than the developer’s need to say that the user made a error.

I explained that a good error message consists of three parts: what went wrong (a reason), why it was wrong (the problem), and what to do next (a call for action). Messages that follow this approach help the user move on with their flow with minimal interruptions. I also explained it was better to anticipate possible error scenarios and prevent them from happening rather than display an error message afterwards. As Alan Cooper mentions as a design principle in About Face 3, ‘Error message boxes stop the proceedings with idiocy and should be avoided.’ I suggested some solutions to avoid the error happening in the first place by performing validations then and there, rather than display them as a bunch of dialog boxes that force the user to click a button to get the error message out of the way.

Next up was the language used in the error message, which was the original reason why I was working with them in the first place. A question arose if the word ‘please’ had to be included in the error message like “Please enter an IP address” or should it just read “Enter an IP address”. I felt it was better to go without the word ‘please’ because it felt too patronizing and it did not add any value to the sentence. Finally I had reworded it to read as “The IP address cannot be blank. Enter a valid IP address. The IP address must be of the form of xxx.xxx.xxx.xxx”.

What really irked me was that the developers had no clue to user interface guidelines. They were using a Windows application, but they were not following the Windows User Experience Guidelines, but again even Microsoft doesn’t follow it at times.

Image via Flickr user:twindx

Chip in with your thoughts on error messages and designing for contingencies…

Initially I went about my tasks understanding AS/400 screens and ensuring they were recreated in the web application. Everything was fine on paper and screen. Nothing struck me as untoward. Only when I went back to the AS/400 documentation, I realised that working with the command-line interface was easier than the graphical interface. It was then I recalled a term called “device switching”.

Device Switching happens when a user switches between using two input devices. mostly a mouse and a keyboard. Marlin C. Brown in his book, Human-Computer Interface Design Guidelines, talks about this mouse-keyboard switching.

8.10 Mouse-Keyboard Switching

Avoid frequent mouse-keyboard switches.

Avoid requiring users to make frequent changes form keyboard to mouse. In keyboard-intensive tasks, such as word processing, provide the necessary functions on the keyboard (for example, cursor control keys) to permit the user to perform the task from the keyboard. Frequent changes from keyboard to mouse and back interfere with the flow, and thus the efficiency, of keyboard tasks. The users must reorient their hands to the keyboard after each mouse use.

Mouse & Keyboard, via Flickr user: stopthegears

The AS/400 application has been in use for more than two decades and that users have become proficient in using the keyboard. The AS/400 application, being a data entry intensive application and by virtue of its longevity, had ensured that users have a mental model of screens built into their minds and they have memorised the key sequences to use and navigate through the system.

As a result, I went back to the application and ensured that that tabbing order was in the same sequence as that of the green screen. This took care of the issue of frequent device switching associated with graphical interfaces.

The lesson I learnt from this was to test screens and forms for device switching issues. The lower the number of switches that occur, the better the usability of that screen or form would be.