You've developed an application that can pick all the winning lottery tickets, make solar power 99.9% efficient, and spew just the right bon mots to propel your favorite candidates to power. The only hitch is that users find it such a pain that it's not worth the trouble to start it up.

Perhaps it's time to have a tete-a-tete with a usability expert.

Well, DevSource hit the jackpot for you with Theo Mandel, Ph.D., author of The Elements of User Interface Design (Wiley, 1997). Dr. Mandel earned his Ph.D. in cognitive psychology and quantitative psychology, and worked with IBM for 11 years as part of its Common User Access (CUA) group. CUA defined the user interface guidelines for IBM developers, and was used for OS/2 and Windows up to Windows 3.x. As a result, Dr. Mandel did extensive research into GUIs and OOUIs. For the past 10 years, Dr. Mandel has been a consultant in his own company, Interface Design and Development, where he's involved with design prototyping, reviews, and user evaluations.

DevSource: So where do you start?

Mandel: With general principles. There are three rules that help, regardless of the project:

The first Golden Rule is Put The User In Control. Let the user drive the application, instead of the developer defining how users have to use it. If the developer thinks the users have to do things in a certain order, for example, then users are like passengers on a train instead of drivers in cars. Let them get from point "A" to point "B" by different routes. Give users multiple ways to do things.

Let users customize applications and set up preferences. For example, Microsoft applications might not have Save As or Close in the menu bars, but users can add them, and that's really good. I can choose the kind of layout I want if they have multiple toolbars.

DevSource: I take it you would say people should be able to put just the tools they want on a toolbar or create custom toolbars that fit just the space they want, rather than having to crowd up the screen with whole toolbars for each tool they'd like to add?

Mandel: Right — pallets of toolbars. People should have the ability to personalize and customize things.

Be flexible. Let people use both the keyboard and the mouse, but don't assume they always use a mouse. If data input is intensive, allow keyboard use without having to go to a mouse. We assume they have a mouse, but don't assume an application should be optimized for the mouse, especially if the user is working with a text editor or Quicken, where you're typing in data.

If you're watching people do repetitive tasks, you see that they're going back and forth: keyboard, mouse, keyboard, mouse.... Wouldn't it be nice if they could just pick one and not have to go back and forth — if they were in a keyboard kind of mode?

DevSource: That would help a user stay in control.

Mandel: Be forgiving. Let the user do stupid things, then provide immediate reversibility. They can do something destructive, but the program should pop up a warning, such as, "Are you sure?" One warning is nice, but some take it to the extreme. "Are you really sure?" can be intrusive. "Put a check box in there that says, "I don't want to see that again." But you need an Undo.

The idea is to be helpful and give some idea when the user is doing something potentially destructive, but not to be too obtrusive about it. At the same time, let them undo something and let them get it back in a reasonable period of time.

DevSource: Do you see user control issues getting worse as the user gets to a higher level? For example, if the user is designing or editing a Web page, and the software leaves nonstandard source in large blocks of text with no white space or indentations, as if no human would want to manually edit their code after generating the main design? Like they've bought a house without keys to the tool shed?

Mandel: You always should try to give the user the best of both worlds. Try to do the grunt work for them. They don't have to understand HTML, but you have to give them the ability to go in and tweak that. Design for multiple levels of users: Support the novice user and the advanced.

At the same time, you don't want to force the more experienced user to go through the same steps as the novice user. You might supply a wizard, but don't force the more experienced user to go through it.