You are here: Resources --> 2000 --> Sometimes you really can be too helpful
Vous êtes ici : Ressources --> 2000 --> Sometimes you really can be too helpful

Sometimes you really can be too helpful

by Geoff Hart

Previously published, in a different form, as: Hart, G.J. 2000. Being too helpful is bad. Computerworld Canada, June 16:16.

In my 27 August 1999 column, I discussed how on-screen clues called “affordances” help the users of your software understand what’s required of them while they’re filling in forms, changing settings, or using any of the software’s other features. I also observed that since screen real-estate is so cheap, "you can always use a second or third screen if you run out of space" on the first screen.

Marc Goodwin (Systems Coordinator, Bombardier Transport) disagreed, pointing out that “...one of the major complaints that our users have... is that ‘it takes too many screens’ to do things. We need to remember that most users will very quickly get used to their screens. The screen that started out very friendly with lots of instructions and hand holding will quickly become ‘too slow’. Within a week, the user would gladly trade the hand holding for more data on screen and faster input.”

Marc’s observation reflects a main axiom of information design: know your audience’s needs well enough that you understand how to meet those needs. Left unsaid in my original essay was how those needs gradually evolve over time, as today’s neophytes become tomorrow’s power users. This is why it’s so important to establish and maintain relationships with your audience: it gives you a handle on their changing needs so you can continue to meet those needs.

Even when the original users outgrow the training wheels you’ve provided, they still occasionally encounter parts of the software they’ve never before used, and there are always newcomers who can benefit from detailed help that would get in the way of the experts. Fortunately, you can meet both sets of needs by letting the users themselves decide how much help should appear on the screen. You still have to add the basic affordances (e.g.,“type your family name here”), but you can make more detailed help available at the wave of a mouse. For example, let users switch between terse and verbose help directly from the Help menu, or use Apple’s “balloon help” or Microsoft’s “tool tips” to explain icons and other parts of the interface whenever the cursor floats over the object in question. You can even add a button in each dialog box labeled “More help...” What’s wonderful is how you empower users by letting them choose a level of assistance appropriate for their current needs, whatever those needs might be.

Of course, if you’ve got to write the support code for these aids yourself, creating the help system becomes prohibitively time-consuming. Fortunately, modern operating systems such as Windows and the Mac OS do most of this work for you. In particular, they provide built-in access to “context-sensitive help”, which is the jargony way of saying that when users hit the help key, they immediately see the online help for their current “context” (e.g., the specific field in which they’ve placed the cursor or the dialog box that’s currently open). Even where the operating system doesn’t provide built-in support for context-sensitive help, or where you simply lack the time to master yet another API (that of the help system), you can achieve good results simply by adding a “Help” button to each dialog box, and link it directly to text stored within the program or in an external resource file. You’ll lose some of the benefits of a fully modern help system, but you’ve still let users choose their own level of help.

As with well-designed affordances, providing the right help in the right place lets users solve their problems quickly, and that means fewer technical support calls for you to handle. Another example of how working with your audience makes life easier for everyone.

©2004–2024 Geoffrey Hart. All rights reserved.