In a previous 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 at 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 the needs of your audience well enough that you understand how to meet those needs. Left unsaid in my original column was how requirements 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.
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 labelled “More help.” What’s wonderful is how you empower users by letting them choose a level of assistance appropriate for their current needs.
Of course, if you have 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 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 on-line help for their current context (e.g., the specific field in which they’ve placed the cursor or the dialogue 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 dialogue 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. It’s another example of how working with your audience makes life easier for everyone.
Hart (geoff-h@mtl.feric.ca) is a translator, technical writer, editor and a senior member of the Society for Technical Communication. He lives in Pointe-Claire, Que., where he works for a forestry research institute.
