Archive for January, 2007

h1

Usability is a ‘folly’!

January 6, 2007

Warning: long!

I mainly work for software companies. And so far none of those companies have employed a usability expert. As the person who is the ‘user advocate’ when writing the documentation, I’ve worn the ‘she’s the usability person’ hat in the absence of anyone else stepping up to champion for readable labels, helpful screen messages, logical workflows in the interface, etc.

Ideally, usability specialists should be brought in at the initial design stage, then as the coding progresses, right through to release and beyond. Amongst other things, usability testing involves identifying areas where users of the software can get confused, then offering suggestions for fixing these BEFORE the software gets released. Fixes could include redesigning a screen, changing the text on a label, fixing a bug, and so on.

Such fixes cost far less when done before release than after the product has gone out the door. After release, the cost of fixing usability problems is much higher because implementing and testing patches, answering support calls related to things that don’t work as they are expected to, etc. all cost money. Then there’s the unquantifiable cost of user frustration – you know, the “I’d like to throw this bloody computer out the window!” situation I’m sure we’ve all experienced.

So, with that preamble, you can see that I’m very much on the side of making things as clear as possible for the users of the software. I’ve attended international conference sessions on usability, on writing useful error messages, etc. and I’ve worked with enough software in the past 20 years to have a clue about what expectations users have, and what can make their life a little easier. This is not ‘dumbing down’ the software application by any means – it’s about making it usable! Usable software usually garners passionate users (see Kathy Sierra’s great “Creating Passionate Users” blog for some terrific writing on this topic); unusable software tends to suck (to quote Kathy).

Last week when I returned to work, I had an email in my Inbox from the person responsible for testing (one of my clients actually has a dedicated tester – this is a good thing!). But I was completely GOBSMACKED by his response to one of my requests for a useful error message instead of the gobbledegook programmer-speak that was displayed. I won’t quote the request, or his complete response – I think you’ll get the gist of it in these couple of lines: “In my opinion trapping exceptions with … plain english dialogs is folly; a waste of developers’ time, a waste of development budget when there are more important things to do.”

I couldn’t believe it! My first response was jaw drop and eye pop and “what the??”; my second was to just throw it all in and walk out of there saying “Why do I bother?”; my third response was to think unkind thoughts about this person’s intelligence (but he’s an intelligent man); my fourth response – after I’d got over the initial shock – was to ask a respected colleague if he thought I was overreacting (he was equally gobsmacked, so I wasn’t overreacting); my next response was to IM a friend and colleague in the US to get her opinion to see if I was overreacting – she saw my full request and the full response and was equally appalled; my final response – after some hours of restraining myself – was to do a bit of research that showed that it’s not just me bleating about incomprehenisble error messages.

Here was the response I wrote (slightly edited):
====================
I stand by my assertion that ALL error messages in our applications should be useful and readable to the user – and that means plain English telling them what happened and, where possible, how to fix it.

Usable error messages have two main purposes:
* reduce user frustration with the application
* reduce support calls to whatever help desk exists (client’s or ours)

This is not “a folly” and a “waste of developers’ time”. It’s not even just my opinion – for example, see:
* http://www.useit.com/alertbox/20010624.html
* http://www.experoinc.com/resources/papers/2005-06-ErrorMsgs.htm
* “…Where possible, error messages [in Windows 2000] give users specific actions to take, rather than just informing them that something went wrong…” (from Microsoft)
* “… Can the user recover from errors? What do users have to do to recover from errors? Does the product help users recover from errors? For example, does software present comprehensible, informative, non-threatening error messages? …” (from: http://en.wikipedia.org/wiki/Usability)

While I agree that fixing this error message in <current, almost superseded product> is not a good use of developers’ time at the moment, it is essential that error messages in <product to come> are in plain English and meet the basics of letting the user know what happened, why, and how to fix it (where possible). We’ll get much better and more satisfied users that way.
=================
The tester was away all last week, so I’ll see what sort of response I get back on Monday!

Update — other resources:

[Links last checked August 2009]

Posted in User experience | Tagged | 4 Comments »