Being involved in a development process of some Tangible User Interface for conceptual design, I tried for a year now to put some order in my mind about what interface design really is, what User Centered Design (UCD) and some other approaches (Activity Centered Design, Usability Engineering, and so on) have to do with each other. I must confess that I am still confused. There are a lot of models and approaches, like Contextual Design, Participatory Design, Usability Engineering. I had some trouble to understand how they connect to each other and why something new is needed is not all the time easy to get. Anyway, my biggest problem is not a historical one. I am rather preoccupied with some consequences of applying UCD in the developmental process.
Before talking about anything else, let us see what UCD actually is. UCD is defined by one of his creators and big promoters as “a philosophy based on the needs and interests of the user, with an emphasis on making products usable and understandable” (D. A. Norman, 2001, p. 188). The big idea about UCD is quite easy to get: place prospective users are in the focus of the development process. However, I am preoccupied with how this philosophy shapes the developmental process. Therefore I am going to talk about some important assumptions of UCD and their consequences.
The first assumptions I want to talk about is: users know what they need and want, and its consequence: therefore, following their suggestions is the best way to create a well-designed interface. A hard criticism of this assumption comes from the field of interaction design. Cooper (1999) warns about the danger of blindly following users’ suggestions. In this way the design process takes the form of a “customer-driven death spiral” (Cooper, 1999). One of the most important problems of costumer-driven products is the lack of coherence in design. Their development process is reduced to a mutation from one release to an other, instead of “growing in a an orderly manner” (Cooper, 1999, p. 221).
Anyway, let us place the users in the focus in the focus of the design process, assume that they know what they want, and see what happened. The next question arising in my mind is: which users should the interface designer consider as being more important?
There are various classifications, not all the time that different though. For exemplification I propose Eason’s classification. According to him, three different categories of users have to be taken into account in the development process: primary users (frequent hands-on users of the proposed system), secondary users (occasional users or those who use the system trough an intermediary), and tertiary users (those affected by the introduction of the system or who will influence its purchase, but who are unlikely to be hands-on users) (Eason, 1988). Their wishes and needs may not always coincide. So once again, whose wishes should the interface designer take into account. I will propose to care more for the primary user as the ones that eventually will have to adapt to your interface, if the tertiary users are going to purchase it. Happily for us sometimes these category of user coincide.
A second problematic assumption is: users know what they are talking about. Is that true or are users’ reports usually subjective and seldom contain all relevant information. I claim that it is not enough to ask the users what they need and it is difficult to let them analyze their own activity. Users analysis should reveal the users’ mental models (D. A. Norman, 1986) of the task, much of it consisting in users’ tacit knowledge in respect to the way they fulfill their task. This means that the main concern of the analyst will be the users’ procedural knowledge concerning the most familiar and obvious part of the job they are trying to accomplish. Users are asked to explain why and how they do certain things. In order to do this, they have to become aware of their own behavior. Nevertheless, the retrospective description of events is not always very accurate, and users tend to leave out the ordinary activities, concentrating on particularly exciting or boring activities. How true is the wheeze “out of sight, out of mind”? What is the solution? I argue for: Get some objective data!
Let us say that we have eliciting requirements for an interface (mailing program, what ever), we developed a mock up and started a user test session. What can go wrong? We just did what they wanted, and hope that the elicitation process is over. No, it is not always that easy. Users can “change their minds once they see the possibilities more clearly, and discoveries made during later phases may also force retrofitting requirements” (Goguen & Linde, 1993, p. 152). Once again, we remind ourselves that users do not really know all the time what they need, and there are no guarantees that by following their suggestions the product is going to be a success. The development process is an ongoing one, the possibility of deciding different courses of action have to remain possible. User tests have to be performed, so that the elicited requirements can be proofed and … changed. The consequence of this assumption is the development of interfaces that correspond to the users' wishes, but nobody wants to buy them.
The last assumption I would like to talk about is: mental models, skills, and preferences are stable over time. In the UCD approach is already a common fact that considering users in the development process is very important: the product being developed has to be adapted to their experience and mental models, and to take account of their skills and preferences. This way the acceptance of a new product increases in a participatory design process, and deployment problems can be avoided. I am not going to argue that they are not important or do not exist. I just want to ask: Are mental models, skills, and preferences stable over time? and argue that they are not, by asking some more questions. Should one think the same way about operating systems like Windows as he/she did ten years ago? Are the skills from the first day of interacting with an interface equal to those gained after one month of experience? Should we let users change their preferences?
Users may wish for easy-of-learning when they start learning to work with a new interface and for efficiency, defined as speed (with accuracy) in which users can complete the tasks, when they got used to it. Some fans of software upgrades could argue that the new release of the software is going to solve this problem. The question is for whom, for beginner or for experts. I think that most of the time some functions are added, but they are not going to solve the problem. Not all the users start at the same time, learn with the same speed, and even if, they cannot learn with the speed of software upgrades. The solution is to be aware of these changes, to make the software more personalized. Let the user choose when he has reached the next level. Do not give them thousands of functions from the beginning.
The consequence of this assumption is the development of complicated programs, with so many functions and some many ways of doing the same thing, that no user can possibly know them. Those programs that give the beginner no chance of doing his job and transform the experts in proficient clickers. By proficient clickers I mean, those users pressing trying to get rid of pop up windows that try to teach the users all the time how to do what he is doing, or to prevent them to do some “beginners” mistakes.
I think that it is time to get sure that we understand all assumptions of the design philosophy we promote, and their consequences for the developmental process. What do you think?
Some books ....
Cooper, A. (1999). The Inmates are Running the Asylum: SAMS Maymillian Computer Publishing.
Eason, K. (1988). Information Technology and Organisational Change: Taylor & Francis.
Goguen, J. A., & Linde, C. (1993). Technique for requirements elicitation. Paper presented at the Requirements Engineering '93.
Norman, D. A. (1986). Cognitive Engineering. In D. Norman & S. Draper (Eds.), User Centered System Design: New Perspectives on Human-Computer Interaction: Lawrence Erlbaum Associates.
Norman, D. A. (2001). The Design of Everyday Things (Fourth printing ed.): MIT Press.
Needed: Info on Biodiversity Change Over Time
6 years ago
Interesting post, but I think there are some missing parts like for example when the primary, secondary and tertiary users are mentioned.
ReplyDeleteProbably the most useful user for a UCD process is the "extreme" user that push the design to its boundaries. Another type of user is the "special" user, for example, a cognitively disabled user that might not be able to talk or communicate but still is able to use an interface.
Some of the assumptions mentioned before, like users know what they need and want or users know what they are talking about, are irrelevant for this particular case.
Furthermore, with special users it is almost impossible to think about UCD without thinking about the participation of the co-users: caregivers and relatives. They are always with the special user and know him better than anyone else.
In this area I think a normal approach of UCD is not enough and should be used an iterative participatory process where the information should come from pure observation during a testing session and with the advice of the co-users that must participate actively in the design process.
My conclusion to this is that sometimes UCD or Participatory Design are not only a good way of giving more value to a particular Design, but the only way for the designer to get to know what to design.