Trying a new piece of software can be like playing an adventure game.

Sometimes weird things happen: monsters leap out and eat your file before you've saved it. Sometimes, you wander aimlessly through a convoluted menu structure, searching in vain for one teeny option. Sometimes the option is there, but under an unusual name or behind a funky icon, so you don't recognize it.

And sometimes — sometimes the path is smooth, and you can be sure when you click the mouse or type a command that you will get predictable results.

Both types of product probably perform the function they were designed for... eventually. They might even get the right answers. But one turns its user into a snarling, frustrated demon, while the other just does its job without getting in the way. And guess which one users will recommend to their friends and colleagues?

It comes down to that nebulous thing: usability.

In a usable product, says, Dan Costenaro, Microsoft Outlook Program Manager, "Anyone can walk up to your piece of software, sit down in front of the computer, and accomplish their goal. If it's not goal-driven from the user's perspective, they will never figure it out."

Figuring it out: that's what usability testing measures. Can the target user-to-be of the new or updated product figure it out? If you don't find that out early in the development game, you could be building a black hole for help desk calls.

In productivity software, the user's goal may be to connect with a potential customer and set up a meeting. That may require sending and receiving e-mail, and interacting with the calendar. In a game, the goal may be to blow away the maximum number of aliens while progressing through a virtual world. That means a different set of tasks.

Whatever they are, part of the art of usability testing is in deciding which sets of tasks, or, as Microsoft usability lead Joey Benedek calls them, scenarios, are the right ones to test.