The importance of error messages

Know More: technical writing 2.0, technical writing

Work with a computer for more than about five minutes and you'll learn that things not only can but do go wrong - often with alarming regularity.

When they do, it's of paramount importance that the error message you receive not only tells you where the problem lies (if possible) but also suggests what you can do to fix it, preferably in a friendly tone that keeps technical jargon to a minimum. In some companies, writing error messages is the work of developers; in others, it falls to tech writers.

One client I'm working with at the moment takes the "friendly" style to a whole new level, replacing messages such as "Are you sure you want to proceed?" with messages such as "There's a risk that this might mess up your data. Is that really what you want?" I can see the thinking behind this - making computers seem less impersonal to less-than-tech-savvy users like the people who work with this company's software - but I suspect such an overly jocular style may start to grate more than a little when you see that message for the 50th time.

I'm reminded of the importance of error messages now because I'm busy installing some new software and have just seen the message "Captrue Device Failure!", which is just wrong in so many ways ... and most of all, doesn't help me one little bit to get the thing working.

It's hard to get the tone right. I agree with you that error messages should not be too friendly.

The biggest problem with error messages, though, is when they are not informative. In an earlier job in technical support, I got to talk to people who became very worried when their computer told them they had committed an "illegal operation".

"Illegal operation" is an example of an error message that means something to the application programmers, but nothing to the application's end users. A user needs to know:

1. What caused the error? Was it me or the computer?
2. What damage has occurred? Is my data lost?
3. What do I do to repair the damage or to avoid causing the same error again?

The user does not need to know what the error is, only what it does.

Posted by: Mark M | June 27, 2006 1:58 AM | Permalink to Comment

Devoted to technical writing and technical writers

related entries

1 Comments/Trackbacks

submit a trackback

post a comment

Comment Preview

Advertise

Related Resources

recent comments

sponsored ads

topics

subscribe

Current News

resources

Support This Blog

archives

blogroll

Know More Media - Writing / Speaking

know more media network

we support unitus

PRWeb

Influencer

ProductivityGoal

CallCenterScript

AdHurl

TheBizofKnowledge

HealthCareVox

BrainBasedBusiness