First of all, Cooper's notion of interaction design is a useful concept worthy of our attention. Cooper distinguishes interaction design from interface design and prefers the former “because 'interface' suggests that you have code over here, people over there, and an interface in between that passes messages between them. It implies that only the interface is answerable to the users' needs” (p. 26). He goes on to argue about interface design that “[l]ike putting an Armani suit on Attila the Hun, interface design only tells how to dress up an existing behavior” (ibid). For an interaction designer, according to Cooper, the design of a product does not only involve interface design, but also behavioral design and conceptual design. He explains that “[b]ehavioral design tells how the elements of the software should act and communicate” (ibid). However, “[i]nteraction designers also work from the outside in, starting from the goals the user is trying to achieve, with an eye toward the broader goals of the business, the capabilities of the technology and the component tasks” (ibid). Thus it is important to include conceptual design, “which considers what is valuable for the users in the first place” (ibid), in the design process (ibid). Cooper argues that the order to the design process should start from conceptual design, then move on to behavioral design, and finally interface design (ibid).
Cooper's view on the interface is very narrow, which is limited to page layout or graphic design, something that “dresses up” the more crucial behaviors of application. Intentionally or unintentionally, Cooper trivializes interface design just as the way he trivializes the “aesthetic” element of design (p. 149).
There are a couple of prejudices and misconceptions involved in his views. First of all, the prejudice against “aesthetic” design that is subject to “subjective” judgment. Judgment of aesthetics is subjective to a certain extent, but that does not mean that such judgment is invalid or groundless. It is also dismissive and a bit pompous for Cooper to assume that design before the digital age only involved aesthetics but had nothing to do with “cognitive friction,” or “the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes” (p. 19). Think of architecture or industrial design, and Cooper's assumption is just a misconception that reinforces the misunderstanding of design as visual design that he himself opposes.
More importantly, to equal interface design as visual design with the only purpose for aesthetics is another misconception of Cooper's argument. The interface is often expressed visually, but it is more than just the “look” of the more heavy lifting code. Norman's (2002) notion of the “system image,” or the “physical structure” of the system (p. 16), can be used to understand the interface. According to Norman, the system image bridges the gap between what the designer designs (the design model) and what the user thinks how the system work (the user's model). Interface, as the physical thing where the interaction between the user and the machine happens is where the system image is materialized to the user. Therefore, interface design does not only involve the page layout, graphic design, or the looks of a system, but how the system is translated and presented to the user. If Cooper's concept of “cognitive friction” is useful at at all, we have to recognize that, contrary to what he claims, the interface is precisely where the cognitive friction occurs for the interface is the site where the human and the machine meet.
Despite these problematic claims, Cooper's insight is valuable in many ways. To be fair, his emphasis on the interaction over visual design (not interface design) seems to fit today's Web development better because of the increasing merging of Web sites and Web-based applications. More importantly, his work points out the problem with software-development processes many companies in the industry employ, and that is programming without interaction design. The product that often results from this process is what he calls a “dancing bear” which does not work well, but because the user does not have any other choices and has to get the job done, she/he has to tolerate the hard-to-use product. In this sense, Cooper is a champion advocate on behalf of the users. The process he advocates compared to the processes that do not work is illustrated as below (pp. 204-205):
From the illustrations, we can tell the Cooper would not agree with usability advocates such as Nielsen that user testing is the only way for good product design. Cooper points out some of the problems with user testing. First of all, he argues that “[t]he main reason why empirical user testing has been widely accepted in the high-tech business is that it fits easily into the existing sequence” (p. 204). That means that user testing actually reinforces the old process of software-development. One of the biggest challenges with user testing is that “[m]ost user testing depends on having a working program to test with, so necessarily it must wait until the program is up and running. This places user testing in the sequence conveniently in parallel to bug testing” (p. 204). This creates a problem, for “[n]o matter who does the designing, regardless of the method she might apply, the effect of design will be negligible if the coding is underway. A fundamental premise of bringing design to the software-development process is that it must occur before the programming begins” (p. 204).
Cooper argues that testing before programming, or what he calls the “pre-facto user testing” is “similar to the pure research that one would expect to find in a university setting” (p. 206). He uses an example of his colleague who tested the effectiveness of the status bar in the interface of a program. He argues that although the test result—users don't pay much attention to the status bar—is valuable, it does not “shed much insight on the underlying problems” (p. 206). Here again, the biggest challenge with pre-fecto user testing and testing or testing during the development of the product is that the product that gets tested is not yet built or completed, and thus any simulacrum (“either a quickly written prototype program or a 'puppet-show' made from paper cutouts or some equivalent, low-tech material” (p. 206)) used in the testing will result in inaccurate testing results.
Although he points out these problems with usability testing, Cooper does not completely dismiss its value. He agrees that “[t]houghtful user testing can uncover a designer's incorrect assumptions. Exposing your design work to users and then redesigning iteratively is always better than not doing so. Some new technologies […] are so untried that the insight provided by basic user testing can be of great value” (p. 207).
That said, usability testing to Cooper perhaps has more rhetorical value than engineering value:
Arguably, the most valuable contribution of usability testing is made when programmers are forced to sit behind the one-way mirrors to view typical users struggling with their programs. The programmers shocked and incredulous, shouting sentiments like, “You are testing mental retards!” Usability testing is a useful whack on the side of the head of recalcitrant software engineers, showing them that there is indeed a problem. It can serve the same purpose for management, too. (p. 207)Considering that Cooper's mean concern in the book is how to persuade companies (and the personnel in the companies from the management to programmers) to embrace the development process that incorporate interaction design before programming, his view on user testing should not be thought as dismissive. However, I'm not sure if he does justice to the user testing method in usability studies.
Perhaps the most important and useful insight Cooper offers in his book is the idea of “goal-directed design” (p. 151). Unlike many others' work on usability (such as Nielsen or Barnum), Cooper distinguishes goals from tasks radically. He emphasizes that “[g]oals are not the same things as tasks. A goals is an end condition, whereas a task is an intermediate process needed to achieve the goal.” (p. 150). He then goes on and notes that “[t]here is an easy way to tell the difference between tasks and goals. Tasks change as technology changes, but goals have the pleasant property of remaining very stable” (p. 150). This means that the consideration of tasks is more closely linked to the product (and especially the features of the product), whereas the consideration of goals must focus on the user. Cooper argues that “[d]esigning from tasks instead of goals is one of the main causes of frustrating and ineffective interaction” and “asking, 'What are the user's goals?' lets us see through the confusion and create more appropriate and satisfactory designs” (p. 151). The goal-directed design requires the designers to analyze the user's goals to solve problems, which often can result in “very different—and much better—solutions” (p. 151).
The goal-directed design shifts the focus from technologies to the user. Especially, the personal goals are considered by Cooper as the most important goals the designer has to consider when designing a product. We can sense this approach in Norman's (2002) work, but Cooper is really pushing this idea forward in his work. The approach of goal-directed design, when applied to user research, will require the researcher to look at the original goals of the user, and then think of the system on the basis of these goals. When applied to research in cultural usability, the approach requires the researcher to shift from asking what color scheme on a Web site is more appealing to users from a certain culture, to understanding what are the important things a user wants to achieve (e.g., to fulfill her/his responsibilities for her/his parents in Confucian cultures), given her/his specific cultural context.
No comments:
Post a Comment