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]


  1. Oh my! I’ve been in this positions myself on dozens of occasions in the past. I now no longer work in this field.

    I had similar arguments on more than one occasion, and things spiralled out of control when some errors by some developers were written in “Engrish”.

    There was even one occurance where I was testing myself where I followed on screen instructions, to the letter, as coded by the developer only to have my entire database wiped.

    My partner only mentioned today, and he works in Microsoft, that an awful lot of developers really have no concept of how an item may be used in final production.

    Believe me I know how you feel, there were many days where all I wanted to do was take a keyboard and smack some developer upside the head to get my point across.

  2. Just some clarification on the first paragraph – this company did do initial usability testing (I was involved, but not the driver for it). However, the two main drivers either left or went on maternity leave, which left no experienced usability advocates to ‘wave the flag’ for a long time. I became the de facto person raising these sorts of issues… and it can be a lonely road!

  3. Advocating for usability can indeed be a lonely thing to do.

  4. It is beyond doubt that in the case of an error that the user could recover from, they have a better chance of recovering if the error message is easy to understand. Still, there are some valid points in support of the testers statement.

    1. There are many errors messages that are not intended for user consumption. They appear because the system has reached some state that the developers did not think it would reach in normal operation. Showing the error message is an alternative to the system simply crashing. There is no user recovery option, because the conditions was not supposed to occur. The programmer speak may serve to convey to the programmer or support person exactly why the system reached that state so it can be fixed.

    2. Many users don’t read error messages at all, no matter how well or how badly they are written. I can’t count the number of times I have heard people say, “It gave me an error message,” to which I replied, “What does it say,” to which they replied (with great exasperation, as if the question were absurd) “I don’t know.” For many people, machines have only two states: working and broken. It does not occur to them that broken is a condition you can fix or recover from, or that they should be expected to try, or to report anything more than “It’s broken”. Broken is broken. Error messages are for geeks.

    3. While there are certainly quantifiable cost associated with poor error messages, there are also quantifiable costs associated with providing good error messages. The tester may have been asserting that the latter costs would outweigh the former, and they may or may not be right. To make the case, you need to quantify both costs and compare.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: