steve kwan user experience designer

Crappy help text

(December 14th, 2006 - 2:12PM)

We've got an upcoming release, so I decided to go through our help text and improve where possible. What I found was appalling. Here's a tidbit.

"The department of record is the department that is responsible for the records."

I really can't blame anyone but myself for the crappiness of the help text. Actually, that's not entirely true...I can blame the jabronies who wrote the help text, but that won't accomplish anything because they're not with the company anymore. And ultimately, as lead engineer it's up to me to keep an eye out for this sort of problem.

I'm not a big fan of help text in the first place. I think it's an outdated way of helping users. The assumption is that if you cram kilobytes of text in a corner somewhere, the user has no reason to complain if the software's hard to use.

Unfortunately, nobody reads the help. So if you're relying on help text to train your users, you're going to find out that a lot of them are untrained.

If you must have lots of help text, remember that there's a big difference between help text and good help text. It's easy to produce the former, and extremely difficult to produce the latter. Most people opt for the former. Microsoft is a perfect example of this, and anyone who's attempted to use their online help will agree with me.

Writing good help text requires two important skills:

1. Written communication skills (so that your help text is easily accessible)
2. Knowledge of the domain (so that your help text is actually useful)

The big problem is that anyone with these skills would much rather invest their considerable talents in more "prestigious" work. Let's face it: writing help text can be pretty mundane, and it's not something you look forward to doing. So a lot of the time, help text winds up being written by people who really aren't qualified to do so. The result? See the earlier example.

My personal favorite help text faux pas is what I like to call the regurgitated definition: when you re-order the name so that it becomes the explanation. For example:

Object-Oriented Programming: Programming that is object-oriented.

Such definitions are, of course, absolutely useless. And unless you make significant investments in your help text personnel, such definitions are what you'll get.

Again, I don't think help text is the best way of making usable software, and I certainly don't know how to find and retain staff who do a good job of it. But I do know that if you really need help text, make sure it's better than what I'm cleaning up now.