to err is human

One recent after­noon, I got draf­ted into review­ing and edit­ing a bunch of error mes­sages for a product. It was sup­posed to be a quick one hour work. But these assign­ments never really turn out be an hour’s job.

All I had was an Excel file with around 20 mes­sages that had the cur­rent error mes­sage and a descrip­tion when/how the error mes­sage occurs. Feel­ing it would be a good exer­cise to spend the after­noon, I made my way towards the product devel­op­ment team. As we star­ted the exer­cise, I real­ised that the team had no idea about error mes­sages. They just got in touch with me because I was the tech­nical writer. They had obvi­ously thought that I was there just to cor­rect the gram­mar and punc­tu­ation. I sat down and went through each scen­ario where the error mes­sage occurs and did what was required.

One typ­ical user activ­ity is to cre­ate a con­fig­ur­a­tion file into the data­base by cre­at­ing one or by import­ing an exist­ing con­fig­ur­a­tion. The dev team wanted me to look into the errors that occur dur­ing the import pro­cess. Dur­ing that pro­cess, I iden­ti­fied issues with the sequence of error mes­sages appear­ing because the inputs were not val­id­ated atom­ic­ally. Rather, they were val­id­ated as a batch and you got a buck­et­ful of error mes­sages that should have been caught earlier. Being modal in nature, the user had no choice but to click the Ok or Can­cel but­ton to move on, which was too late. And these error mes­sages really weren’t serving any pur­pose other than the developer’s need to say that the user made a error.

I explained that a good error mes­sage con­sists of three parts: what went wrong (a reason), why it was wrong (the prob­lem), and what to do next (a call for action). Mes­sages that fol­low this approach help the user move on with their flow with min­imal inter­rup­tions. I also explained it was bet­ter to anti­cip­ate pos­sible error scen­arios and pre­vent them from hap­pen­ing rather than dis­play an error mes­sage after­wards. As Alan Cooper men­tions as a design prin­ciple in About Face 3, ‘Error mes­sage boxes stop the pro­ceed­ings with idiocy and should be avoided.’ I sug­ges­ted some solu­tions to avoid the error hap­pen­ing in the first place by per­form­ing val­id­a­tions then and there, rather than dis­play them as a bunch of dia­log boxes that force the user to click a but­ton to get the error mes­sage out of the way.

Next up was the lan­guage used in the error mes­sage, which was the ori­ginal reason why I was work­ing with them in the first place. A ques­tion arose if the word ‘please’ had to be included in the error mes­sage like “Please enter an IP address” or should it just read “Enter an IP address”. I felt it was bet­ter to go without the word ‘please’ because it felt too pat­ron­iz­ing and it did not add any value to the sen­tence. Finally I had reworded it to read as “The IP address can­not 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 inter­face guidelines. They were using a Win­dows applic­a­tion, but they were not fol­low­ing the Win­dows User Exper­i­ence Guidelines, but again even Microsoft doesn’t fol­low it at times.

Image via Flickr user:twindx

Chip in with your thoughts on error mes­sages and design­ing for contingencies…