Designing for the other half

by Geoff Hart

Previously published as: Hart, G. J. 2001. Designing for the other half. http://www.techwr-l.com/techwhirl/magazine/usersadvocate/usersadvocate_designforotherhalf.html

Whenever we design something, we confront the problem of how to account for differences in our audience’s needs, skills, and background. We accept that audiences are diverse, and contain people with widely varying skill levels, physical abilities, background knowledge, and cultural differences. They range from power users who could teach us something about the product to the greenest of neophytes. Some have significant visual or other handicaps. Some can understand the most abstract concepts whereas others wouldn’t recognize a metaphor if it bit them. And some come from very different cultures, and face gaps such as the one that divides Macintosh and Windows users.

Unfortunately, our knowledge of the more obvious differences sometimes leads us to make ridiculous assumptions, such as considering women and men to be different audiences, or believing that it’s impossible to produce something that works equally well for experienced and new users. Let’s examine each of these two assumptions in turn.

Women and men certainly appear to be two solitudes, and John Gray (Men are from Mars, Women are from Venus) has made a great deal of money reminding us of this—and vive la différence! So wouldn’t it logical to assume that two such different sexes have highly different needs? Unfortunately, not in most of the things we document—and I’m not just saying this to be politically correct. I’ve worked with arrogant, overconfident, “alpha male” power users who just happened to be women. I’ve also worked with naive, timid, touchy-feely newbies who just happened to be men. I’m not claiming that you can always ignore the differences between the sexes, but I do claim that you shouldn’t let that awareness blind you to more important differences.

Such as the difference between experts and neophytes, for instance? Not necessarily. Experts and newcomers both need to accomplish many of the same tasks with software, and the similarities in how they do so generally outweigh the differences: every user follows the same steps, in the same order, and uses the same dialog boxes to accomplish specific tasks. They all press the Return key or click OK to command the software to do something with the input in those dialog boxes, and they all use some combination of mouse and keyboard to control the software. Moreover, everyone, whether expert or beginner, must be able to find out these sequences quickly when they use a feature for the first time.

So the truly important differences lie in how often the different types of user consult the help file or printed documentation, try rarely used features of the software, or switch from keyboard to mouse and back again. Once you understand that audiences differ in these crucial factors, you can focus on providing solutions that address both ends of the spectrum of skills for each factor. Even if your audience is 50% male or 50% expert, don’t forget that the other half is still going to have very similar needs that are defined by more than whether they’re male or expert.

For example, consider how people control their software. Some prefer to use the mouse to select menu choices, others insist on using keyboard shortcuts for every function, and still others want icons they can click. What’s important is that your audience differs in these preferences, and that these differences don’t generally depend strongly on their experience level or sex. To accommodate these widely differing needs, it’s important for designers to make all the commonly used commands equally accessible from the menus, the icon bars, and the keyboard; few things are as frustrating as using the keyboard for the vast majority of your work and discovering a command that can only be performed via an icon on an obscure toolbar. (I recently encountered this very problem with trying to remove highlighting from some text in Word; the highlighting option that I needed was only available from the “Reviewing” toolbar, something I’ve never used in all the time I’ve owned Word because I do all my editing exclusively from the keyboard. Worse yet, none of the other techniques for removing formatting worked.)

As technical communicators, we can’t necessarily document how to accomplish each task from the keyboard, the menus, and the mouse, but we can certainly find out which way works best for the majority of our audience and document that to the best of our ability. To meet the needs of those who prefer another approach, we must make a list of alternatives easily accessible by (for example) providing a visual index that shows all the toolbar icons or an alphabetical list that contains all the keyboard shortcuts. And in addition to creating these aids, we must make users aware that they exist. Did you know that Word lets you generate a complete list of its keyboard shortcuts, including ones that aren’t documented in the manual? Few people do—and the last time I checked, explaining how to create that list was not in the documentation. [A look back from 2005: D'oh! The answer is in the Print dialog box. Under the heading "Print what", select "Key assignments".—GH]

Speaking of keystrokes, it’s important to always try what we’re documenting rather than blindly recording the right sequence of steps. Why? Consider the most common keys used in shortcuts: Control (or Command), Shift, and Alt (or Option). Most of us have learned the most common mnemonic key combinations that are consistent between programs (e.g., Command or Control plus C for Copy), yet programmers continue to ignore these standards. It’s our job to point this out, and suggest the appropriate solution. Moreover, we need to pay close attention to how hard it is for us to use the shortcuts, then imagine someone with different physical characteristics tried the same thing. Keystrokes must be easy for people with a range of finger sizes to achieve, yet some shortcuts I’ve used required the dexterity of Houdini and extraordinarily long fingers! We can’t always persuade programmers to choose different shortcuts, but where the keystrokes are likely to be difficult for some to use, we should consider explaining how to accomplish the task from the menus instead.

By assuming that we must write different documentation for both beginners and experts, we forget that even experts are beginners for some functions. Many of us—even the experts—want our hands held at least every now and then, but even the inexpert user sometimes just wants to go ahead and try something. Where possible, we should advocate creating an interface that lets users dynamically adjust the level of help they need. Why not create both detailed and summary help, and make it easy for users to select whichever one they need at a given time?

The kinds of differences I’ve discussed here are obviously more important than someone’s experience level and whether they wear a dress.

So how do you account for the range of variation in an audience? By identifying the differences that are truly significant, not superficial differences that provide little guidance on improving the usability of your product and your documentation. If you rely on obvious but simplistic differences such as the notions that men and women have different needs and that the needs of experts and neophytes are irreconcilable, you do both yourself and your audience a disservice.

For more information:

Hart, G.J. 2001. Audience analysis: looking beyond the superficial. p. 105–107 in: proceedings, STC 48th Annual Conference, 13–16 May 2001, Chicago, IL. Soc. Tech. Comm., Arlington, VA. 608 p.