Communications of the ACM
Affordances, Motivation, and the Design of -User Interfaces
People use tools to achieve desired results. Goal-directed behavior is a human characteristic. While in rare instances someone might speak of being "guided" by tools, we do not generally think of tools as having goals. We would like our tools to be able to suggest what they are for (in the words of Norman [3], to offer affordances), but we do not expect them to control what we do. We hope to provide craftsmen with tools that enable them to engage in conversations with their materials. In an ideal world, the mantra for our tools would be "My purpose is to serve you." Every tool should feel like it was custom designed for you, the user in your context.
How do we design user interfaces with affordances that make these tools "ready to hand" for their users? Current user interfaces do not display the kind of affordances that a hammer or a doorknob does for a user in the physical world. We are not there yet, but there is progress in this direction. One might assume there is progress because we are developing more natural technologiesspeech recognition and output, and advanced visual interfaces. But in our experience working with these and other technologies one thing has become very clear to us. It is not simply the technology employed that makes a system fit its user. We have seen speech recognition systems rejected because they are not natural for interaction. We have seen visually appealing systems that fail because users do not think they provide the function they are seeking.
So what does work? Success in designing affordances into the interface of a tool is based on understanding the user, the user's tasks, and the context in which the user accomplishes tasks and goals. When you understand these aspects of the context of use, it becomes possible to design a system the user understands, appreciates, and uses. The system feels like it was designed specifically (personalized) for them. It is not a simple matter to understand the context of usestatic user-interface guidelines cannot provide answers to dynamic, complex design questions.
New tools introduce change in any context, not just for individuals but for entire organizations and beyond. As agents of change in the workplace, application designers almost always underestimate the impact of placing a new tool in a context. Improving some aspect of a work activity almost always means changing learned behaviors, and people resist such changes unless benefits are clear. Applications that aim to improve workplace productivity might do so in ways that negatively impact individual productivity (for example, when someone has to carry out a task formerly carried out by someone else). Assuming that productivity done is a good measure of design misses a great deal.
Success in designing affordances into the interface of a tool is based on understanding the user, the user's tasks, and the context in which the user accomplishes tasks and goals.
But tool designers can learn much from addressing human activity in the workplace. First of all, everyone wants to feel some level of control over how they work. In this aspect, application developers would do well to assume the audience for their tools will be skeptical when it comes to being marketed as "new and improved." Second, trying to cope with both the technical challenge of building an application system and understanding the work context into which it will be placed need not be approached as a problem requiring a heroic effort on the part of an isolated technical team. Involvement of those who will be affected by the introduction of technology in the design of that technology should not be viewed as an intrusion on the creative activities of the technician any more than the developed application should be viewed as an intrusion on the creative activities of the workplace members for whom it is intended. Multiple perspectives on any system design is more than luxury; it is an essential element in good design (see [1, 4, 5] for some interesting thoughts on teamwork and reflection on action in workplace activities). Closing a gap between advocated theories of teamwork between design teams and user representatives and the actual practices observed in software design projects has become a major focus of activity in supporting design groups [2].
Motivation and Control
There is a paradox in human behavior that is valuable for designers of applications to keep in mind: Everyone wants to be in control, but nobody wants to be controlled. We all want some level of control over our lives both in private and social contexts. None of us wants to admit to being completely controlled by another person or organizationand certainly not by our technology.
Any workplace is made up of individual employees with different roles and responsibilities, including individuals responsible for creating products the organization sells and individuals responsible for supporting various operational aspects of the organization. In order to answer the question of how much control is necessary in a work situation, it is necessary to ask about the nature of the specific activity. When is it necessary to restrict or direct the activity of someone? Is control more appropriate in transaction applications (for example, taking merchandise orders) than in knowledge applications (for example, document creation)? For well-motivated workers who understand their role in the organization, we might require little control. For any worker involved in a task critical to the survival of the organization, we might be more demanding in our need to ensure an activity takes place.
All of this complexity around the nature of control is compounded by the fact that what constitutes control is in the eye of the beholder. While any task may be said to control its performer (in the sense that it directs their activity), people do not generally report feeling controlled by things they want to do. Providing tools that direct our activity, but feel enabling rather than restricting, is an important goal for designers to keep in mind. It is difficult to do, largely because our understanding of the difference between motivation and control (and how to design with an awareness of the distinction) is much less developed than our understanding of technical issues in software design (for example, structuring object-oriented code).
Perhaps the only way to address this design challenge is to take the issue of motivation seriously. Rather than dismissing subtle differences in perception as random noise, we should try to understand how slight differences in the process can result in powerful differences in the product. Consider how different the discussion would be given the following two questions: "How do we control the workplace to produce maximum productivity?" and "How do we motivate workers to be productively creative?"
In our daily lives it is perfectly natural to want to control our environment. We don't want a house full of unruly, unpredictable appliances. But in the workplace, it is easy to confuse issues of predictability with control. In order to coordinate action we need an approach that balances the need for predictable results by individuals (that a certain report is produced at a certain time) with the need for workers to be in control of their own work activity (to decide how to go about preparing the report).
There can be great satisfaction in the ability to mastter one's tools and produce a desired result. When motivated by a goal, people will spend long hours working with an artifact as long as they see it as a means to accomplish that goal. But the same person who has spent 10 years of hard work to learn to play the guitar might complain that a word processor is impossible to use. For those who seek clear guidance on when a tool will be viewed as either enabling or too complex for a task, our scientific tools are woefully not up to making such distinctions.
Does the carpenter control the hammer or does the hammer control the carpenter? The issue is not who or what is really in control, but rather how the workers perceive the role of the tools in their task. What seems important is a feeling they have influence on the way the work is carried out; the tools are not created without input from those who will be asked to use them.
Design as a Conversation
How can we design systems that are perceived as personalized rather than as controlling? There are many approaches to this, which have generally been described under the heading of "user-centered design." While there are many variants on the specifics of the approach, at the core is the difficult and multifaceted task of understanding the users, their work context, and the tasks to be accomplished.
But our tools can also become such an integrated part of the context they are rarely viewed as controlling by their users. For example, we rarely think of the word-processing application as controlling our means of communication though it certainly directs the way we create text. The fact that work context provides considerable support for editing (like spell checking), printing, and distributing (email) documents motivates users to employ the application even when the benefits of using it compared to, say, a handwritten note, might be nonexistent. Personally speaking, there is a time-recording application we use that has always felt like control. Though this system may benefit the organization, we (the users) may not find of tool of personal value.
Does it matter if we view a tool as personalized or controlling? Should the designer care as long as the tool is used? In the long run we think the answer has to be that it does make a strong difference. Tools that users don't feel are tailored to their task, go unused (and unbought). Tools that assist in completing the real tasks users are trying to accomplish become pervasive. If for no other reason, it makes good business sense to develop tools everyone wants to use.
The field of human-computer interaction has come a long way in developing the methodologies and science contributing to the design of better systems. At the same time new technologies are emerging that provide the potential for exciting and valuable new types of multimodal user interfaces combining speech, vision, touch, and beyond. The challenge for the future is bring these technologies together in a way that provides systems that really fulfill our mantra: "Our purpose is to serve you."
References
1. Argyris, C. Reasoning, Learning, and Action. JosseyBass, San Francisco, Calif., 1982.
2. Coble, J., Karat, J., and Kahn, M. Maintaining a focus on user requirements in the development of an electronic patient records system. In Proceedings of the ACM Conference on Human Factors in Computer Systems. ACM, New York, N.Y., 1997.
3. Norman, D. The Design of Everyday Things. Doubleday, New York, N.Y., 1990.
4. Schon, D. Educating the Reflective Practitioner. JosseyBass, San Francisco, Calif., 1987.
5. Whiteside, J. The Phoenix Agenda. Oliver Wight Publications, Essex Junction, U.K., 1993.
©2000 ACM 0002-0782/00/0800 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2000 ACM, Inc.