Designing for the other half

Whenever we design something, we confront the problem of accounting for differences in people’s needs, skills and background.

We accept that audiences are diverse, and made up of 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 rank 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 (e.g., Macintosh and Windows).

Unfortunately, this knowledge sometimes leads to 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 assumption 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. So wouldn’t it be logical to assume that two such different sexes have highly different needs? Unfortunately not – and I’m not 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 newcomers who happened to be men. I’m not claiming that you can ignore the differences between the sexes, but don’t let that awareness blind you to more important differences.

Such as the difference between experts and neophytes, for instance? Not necessarily. Take user interfaces, for example. Experts and newcomers both need to accomplish the same tasks with your software, and the similarities in how they’ll do that outweigh the differences: everyone presses the Return key to close dialogue boxes, and everyone uses some combination of mouse and keyboard to control the software. Everyone must be able to find help quickly when they use a feature for the first time.

The truly important differences lie in how often the different types of users consult the help file, 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.

Consider how people control 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. To accommodate these needs, make all the commonly-used commands equally accessible from the menus, the icon bars and the keyboard. Consider the most common keystrokes. If you use the Control (or Command) and Alt (or Option) keys to create shortcuts, choose key combinations that are both easy to remember (e.g., C for Copy) and easy to achieve by people with a range of finger sizes – some shortcuts I’ve used required the dexterity of Houdini.

Consider how people learn to do something new. Most of us want our hands held at least every now and then, but some people require more handholding than others. Create an interface that lets users determine the level of help they need. Provide both detailed and summary help, and make it easy to switch between them. Aren’t these differences more important than someone’s experience level and whether they wear dresses?

So how do you account for the range of variation in an audience? By identifying the differences that are truly significant, not superficial ones that provide little guidance on improving the usability of your product. You do both yourself and your audience a disservice 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.

Hart ( 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.