by Diane Wilson, Thyra Rauch, and Joeann Paige

The following article is drawn from a number of sources associated with the ACM CHI '92 conference. It is the last in a series of four articles.

It is easy to design software that does not meet the needs of its users. All we need to do is to leave the end user out of the design process. One might think that more is required--ignoring the requirements, perhaps, or neglecting to do any market research. Although these other activities are useful, studies show that excluding end users from direct participation in design is sufficient to guarantee unusable software.

What is it about users' needs that cannot be summarized in requirements, or that cannot by analyzed through market research? There are several interrelated problems which cause a failure in communications.

• Developers typically don't think like users, even when they use their own software.
• We (that means all of us, from planning through development and on to marketing) don't live in the same world as the people who must deal with the problems that we're trying to solve.
• Finally, our technology is lacking in the "social graces."

Let's take these problems one at a time. Although a solution is beyond the scope of this article, we can learn to recognize and understand the issues; only then can we do something about them.

Why we can't be end users of our own software

Bruce Tognazzini describes interface styles that are appropriate to different types of users. Software developers tend to be introverted intuitives, people who can see and manipulate abstract structures in their minds, structures which become almost as real as anything in the physical world. All too often, such people are relatively poor at communications because they rely on their understanding of these objects in their minds, objects which aren't visible to others. When introverted intuitives drive to work, they follow a map in their minds, and see very little along the way.

When Tognazzini describes how software developers interact with computers, he states, "They are not dependent on a lot of immediate, real-world data. They should do well with human/computer interfaces that are very sketchy, expecting to user to maintain their own 'reality,' their own maps and models of the internal structure of the program." Software developers do well with command line interfaces.

Many end users of applications are more likely to be extroverts, sensories, or both. Extroverts are better communicators, relying on a rich mixture of words and gestures, and make good use of feedback. Sensories perceive and understand the world directly through their perceptions; in extreme cases, the only things that are real to them are the things that they see, hear, touch, smell, and taste--at the moment that their senses perceive these things. Extroverted sensories see everything along the road as they drive to work.

When Tognazzini describes how these people interact with computers, he states, "[They prefer] interfaces that appear 'real,' that do not depend on the memorization of invisible behaviors, that appeal to the real-world sensations of sight, sound, kinesthesia, and so on.... [They] can be expected to do poorly with interfaces that depend on the user to generate their own maps and models of the internal structure of the program." These people do well with visual interfaces that allow direct manipulation.

So what's the point of all this? Introverts and intuitives make up a minority of the population (about 25% each), but they are the dominant types in software development organizations. To put it bluntly, people who communicate based on symbolic manipulation of mental models are designing interfaces for people who want and need a responsive interface that is rich in information, and that accommodates a wide variety of input and working styles.

All of this should put to rest the old lie that user interfaces should be--or can be--intuitively obvious. Nothing is intuitively obvious to a person who doesn't think intuitively. Even intuitive thinkers must form a mental model before intuitive thinking begins. An interface should be articulate; it should ensure that the information a user needs is readily available, including both data and the functions that can be performed on that data. Articulate also implies that the interface readily understands the user's requests, through words and gestures that are most appropriate for the user.

One last observation needs to be made before we move on to the second problem in understanding our users. Don Norman tells us that users interface with their tasks, not with the computer. This places software in the role of a communications medium. Because machines and users do not share a common language, the software must also translate objects and intentions from one medium to another. Those of us who are introverted, intuitive types are perhaps the best suited for understanding and solving the problems in the user's task domain, yet we are the least suited for the job of creating tools that communicate and translate--it simply doesn't come naturally to us, and we understand too many things that can't be seen.

We can overcome this problem, but the first step is awareness, and the second is study: of software engineering, communications, psychology, and graphic design. Given the complexity of modern software, it is not possible for each of us to become experts in all of these areas, but we must understand enough to talk to the experts, and for them to talk to us. This is the real key to the synergy that can come from multidisciplinary teamwork.

Different people, different worlds, different problems

We have just demonstrated that the world is made up of different kinds of people. That's not a stunning revelation. Are these the only differences that we need to be aware of? Of course not.

Nothing in the human world happens in a vacuum. Everything is a part of one or more cultures that surround and shape us, cultures that are derived from our work and our play, cultures that provide a context which gives meaning to everything we do. Our cultures--Americans, southerners, software developers, IBM employees--are all around us, as invisible as the air. We don't live without air; we don't act except in the context of our culture.

This invisibility of culture is a significant barrier to successful communication across cultural boundaries. Scott Kim describes a conversation between a programmer and a graphic artist. To illustrate miscommunication across these cultural boundaries, Kim uses the following example.

As a graduate student, he worked with Donald Knuth on a programming language for typeface design, called Metafont. To a programmer, the design was elegant. It accomplished the type designer's goal, which is the design and specification of type. It allowed a designer to vary overall characteristics, such as stroke width for an entire typeface, with a single parameter. Yet it failed to meet the working priorities of the type designer, because it wasn't visual. It is easy to predict the result that Kim describes:

Both people walk away frustrated. The programmer feels annoyed that the artist doesn't appreciate the work involved; the designer feels outraged that the programmer cannot see the obvious. Yet both people started with good intentions.

In other words, software and user interfaces must mesh with the culture that surrounds their use, or they will not be usable.

Technology as a sociopathic influence

Don Norman classifies technology into two kinds: things that interfere with our lives, and things that enhance our lives. Those things that enhance our lives fit well into the social context where they are used. Those things that interfere step into the middle of human affairs, changing the way we behave and the ways we interact with each other.

As an example, Norman tells us about a sixth grade play. Once upon a time, proud parents came to these plays to watch their children grow up, to see their accomplishments and to support them as they cope with the stress of performance. Nowadays, if you go to one of these plays, you will spend much of your time dodging camcorders, tripping over extension cords, trying to find a seat away from the glare of movie lights. Who is recording the performance? Not the school, but rather the parents--each and every one of them, or so it seems.

It sounds like a nice idea. This is an important moment in each child's life. What could be more wonderful than to be able to relive that moment, again and again? At the time of the idea, the play is still at the center of events, and the camera is at the periphery.

And yet, as the performance begins, the parents are jockeying for camera angles, checking batteries, and squinting through viewfinders that are crowded with focusing and framing aids, exposure meters, and assorted other distractions. Up on the stage, the children looking out at the audience no longer sees parents and friends; instead, they see a mass of impersonal lenses--if they can see anything at all past the blinding lights.

Who's watching the play? Not the parents with the camcorders; they'll watch it later, assuming that nothing goes wrong and that the recording is worth watching. Who's watching the children, taking delight in the moment and supporting them as they learn the ancient human ritual of performing for others? Certainly not the parents with cameras; technology has come in from the periphery and taken over. The parents without cameras aren't seeing much, either; between the lights, the bulk of the cameras in front of them (all at eye level), and the rudeness of people whose whole world has shrunken to a viewfinder, they have no attention left to give to the children.

Computers can be just as impersonal and demanding. How much time do we spend tailoring or working around our software, instead of doing our jobs?

John Seely Brown, director of XEROX PARC, has spent much of his research on these human issues as they relate to computing. He looks at the social periphery, the ways that we use social or environmental knowledge in our approach to work and living. He feels that peripheral cues are at least as important as those at the center of our focus: We do judge a book by its cover, as well as its size, paper quality, weight, and where we find it in the bookstore. We decide whether or not to believe a person based on that person's reputation.

Technology often cuts out peripheral cues and knowledge. Often, the information that gets lost is cultural. For example, personalized (electronic) newspapers may be harder to navigate than real newspapers. Peripheral cues, such as placement (above or below the fold), length (on which page the article continues), and the size of the heading, provide clues to the relative importance of each item. These personalized news services also may no longer function as newspapers, since newspapers are an aspect of shared culture: everyone sees the same thing. Once we begin filtering our news, we will no longer share the news with others. (Just as the parents in Norman's example no longer share a cultural event with their children.)

Brown is concerned that this sort of "demassification," this technological distancing between individuals, could lead to social fragmentation. The "user-friendliness" of an artifact may have much to do with the way it fits into the culture. Brown's antidote to demassification is to use technology to form a distributed community, and to build tools to listen. One example is called "groupware": software and hardware that allow people who are separated in place and time to work together on a common problem, just as if they were in the same room.

In Brown's future, computers have receded back to the periphery--people communicate, while computers record and interpret. One of his fellow researchers describes the XEROX laptop computer: light weight (about a quarter of an ounce), high- resolution display, high-density storage, easily transportable, and can be read from and written to by both human beings and computers. The XEROX laptop is a sheet of paper, a tool that humans have been using for centuries, a tool that fits well into our culture and which all of us know how to use.

Brown tells us that currently, we build tools to amplify the mind. In place of--or in addition to--this, we should build tools to amplify relationships between people.

Becoming advocates of our users

So it is little wonder that we fail to understand our customer's needs, even with the best of information and the best of intentions. We don't live in their world. We don't face their problems. We don't work for their bosses, or share results with their coworkers. We fail to recognize the existence of different cultures; as a result, we interfere with the ways people function in their various cultures.

This is most dangerously true when we think that our users are like ourselves. This is often the case for our customers in IBM's Application Development strategy, because we think that they are programmers, "just like us." They're not! We develop general tools for many people to use. They develop applications to enhance their company's business. We develop in a time-frame of years. They develop in a time-frame of days, weeks, or at most, months. We focus on a single, large problem. They focus on more problems, often smaller problems, problems that come and go unpredictably. We really do not have any reason to think that we understand their world.

How do we solve this problem?

The first step, which this article addresses, is awareness. The second step is to learn to listen to, and to work as a team with those other cultures. The final step is to incorporate this method of working into our development process.

The development process can change to support this new way of thinking. Making that transition will be the subject of a pair of technical reports that expands on this series of articles. For now, it will have to suffice to say that the key is to become advocates for our users--to put our users' needs in place of our own, and to act in their place to ensure that their needs are met.

It is crucial to understand that using our own products is not the same as becoming users of our own products, or becoming users' advocates. The difference is culture, the world of invisible and peripheral cues that shape and constrain our ideas and our behavior. The solution is awareness and the willingness to act on that knowledge. The results are products that let users focus on their tasks, products that do not interfere with that work, products that intensify communications between people who share tasks and priorities. The result is humane software.

References:

1. Brown, John Seely. Closing Plenary address. Monterey, CA: ACM CHI '92 conference, 1992.
2. Buxton, Bill; Card, Stuart; Curtis, Bill; Mantei, Marilyn; and Norman, Donald. Opening Penary address. Monterey, CA: ACM CHI '92 conference, 1992.
3. Kim, Scott. Interdisciplinary Collaboration. In The Art of Human-Computer Interface Design, Brenda Laurel, ed. Reading, MA: Addison-Wesley, 1990.
4. Norman, Donald A. Turn Signals are the Facial Expressions of Automobiles. Reading, MA: Addison-Wesley, 1992.
5. Rheingold, Howard. An Interview with Don Norman. In The Art of Human-Computer Interface Design, Brenda Laurel, ed. Reading, MA: Addison-Wesley, 1990.
6. Tognazzini, Bruce. Tog on Interface. Reading, MA: Addison-Wesley, 1992.

Copyright © 1993 by IBM Corporation. Published with permission.