Making programs more user-friendly

(Page 2 of 2) Return to Page 1

What task is the user trying to perform? How would the user perform that task if s/he didn't have your program?

In this two-fold question, consider what method you're replacing. Nowadays, chances are you're replacing another program. If your user base is migrating from a DOS program, for example, keep the same keystrokes as shortcuts in the new program. If you can't call a task by the same name as in the old program, let the technical writer who's creating your Help know what the old name was, and what it's called now, so s/he can put the old name in the Help index.

With which programs, operating systems, and UI metaphors is the user likely to be familiar?

Use familiar UI elements and functionality

The most likely model for Windows users is Microsoft products. If your program runs in Windows, use Windows standard UI elements and the rules that govern them.

Whatever you're doing has probably been done before

Don't try to reinvent the wheel by creating multi-state check boxes, stand-alone radio buttons, or tiny, cryptic icons with no parallel functionality in the menu. Even if your user is not yet Windows-literate, s/he will be, at least to get into your program. Don't create extra work for users-- if a button with an X in it in the top right hand corner of the dialog box closes the dialog box everywhere else in Windows, why shouldn't it in your program?

When all else fails, read the directions

The Help is usually the last resort for users. While some conscientious folk read the manual cover-to-cover before attempting to use anything more complicated than a pair of nail clippers, most people plunge into a task, and then only look for help when they run into a problem. Creating an intuitive program minimizes the number of snags a user runs into, but does not completely eliminate the need for a good Help system. Give your technical writer as much information as possible about the user base, the tasks performed in a program, and how the program works. Functional design documents are a technical writer's best friend-- don't assume they're too technical or arcane for the technical writer to understand. Most technical writers are also excellent resources for design questions.

Hosted by www.Geocities.ws