HCI and Work Practice
阿大 发表于09:37 2004-04-09UI之旅乃作者的随手笔记，请移步到用户体验研究blog--油茶研究会
HCI and Work Practice
This section makes brief note of challenges facing the community of HCI practitioners. Some of these challenges are of concern to HCI researchers and educators as well.
Many HCI practitioners experience identity conflicts within the first few years of entering an applied position. In general, they must re-orient their views of how they work, what questions they ask, and what about their work is valued. Superb analyses and specifications may miss their objectives if they are not oriented toward the very pragmatic needs of specific developers using specific implementation tools. Optimized productivity may miss its objective if it is in support of the wrong goal, or if it is bought at an unacceptable cost in the quality of work life. Elegant algorithms and architectures may miss their objectives if they do not consider context of use, or -- more frustratingly -- if they are "packaged" within a human interface that makes them inaccessible. Quality of writing or curriculum is often considered secondary to the quality of code or user interface. Designs of any quality are frequently dismissed as being "mere" packaging, and the integrity of a design is often unwittingly undermined by implementation constraints.
At a minimum, relatively new practitioners struggle to determine what subset of their skills and knowledge is actually applicable in an applied setting. Many practitioners maintain a set of somewhat conflicting identities, valuing one set of attributes and achievements in the context of their loyalty to co-workers and organizations, and a rather different set of attributes and achievements in the context of their "home" discipline and their identities within that discipline. This is often experienced as a burden and as a continual challenge to the practitioner's self-esteem.
Some organizations have responded to the challenge of diversity in skill sets by establishing well-defined sequential models for analysis, design, implementation, delivery, and maintenance. Waterfall models provide a well-known class of examples. The contributions of distinct disciplines tend to occur within single steps of such a model. In practice, this separation of functions can fatally limit the bandwidth of communications between successive stages and different disciplines. There is a tendency to push problems off to later stages. One anonymous description of this tendency follows:
"Inadequacies in the analysis are left for implementation to resolve. Implementation creates a set of usability problems. Human factors workers do what they can with these after the design is relatively fixed. What they can't fix is given to technical writers to repair in documentation. Anything that the documentation doesn't fix is left to trainers. If the training curriculum can't fix a problem, then the hot-line takes it on. If we're very lucky, some record of these problems gets into the hands of the next iteration."
Other organizations approach this problem by convening interdisciplinary teams to work on applied projects. These teams provide opportunities for divergent perspectives to be brought together, both for problem resolution and for mutual education. Other intellectual disciplines have begun to explore the concept of "boundary workers" or "border intellectuals" (e.g., Krupat 1992). By virtue of placing themselves at the "frontier" between two different domains of work, knowledge, and practice, the boundary worker is considered to have a better opportunity to combine perspectives. The hope is that the resulting synthesis will have fewer mistakes than a view based on a single perspective. Interdisciplinary teams can make a similar contribution.
However, there remain the related problems of how to combine diverse perspectives, and how to select which perspectives should be brought into a team. These problems encourage HCI practitioners to, within themselves, develop a multidisciplinary approach -- that is, to become the "boundary workers" who are celebrated in other disciplines. It is clear that certain domain areas -- especially work of users -- are likely to remain beyond the reach of most HCI multidisciplinary workers. Nonetheless, multidisciplinary individuals can help provide the bridges that are so clearly needed among the disparate components of HCI knowledge, theory, and practice.
Because of the diverse backgrounds of HCI workers, it is not surprising that there are many practices in HCI. These diverse practices emerge from different theoretical and practice traditions, that in turn have in some cases widely varying philosophical foundations. Engineering, art, business, science, craft, and political advocacy are among the parent disciplines of various HCI practice traditions. Each of these approaches contains one or more paradigms of practice (as well as research), although the disciplines vary in the extent to which they have articulated their paradigms.
Different institutional and work-process sites for HCI work add to the diversity of practices and paradigms for practices. Too much diversity has been fatal for some other fields (see, e.g., Mantei 1989). However, a premature selection of a paradigm for HCI is likely to deny membership to substantial portions of the current HCI community, and there are arguments that diversity of practices is and always will be the optimum approach (Dayton, 1991).
The field of HCI deals in part with the combination of stakeholder perspectives -- that is to say, a system design (including the user interface) serves developers, users, marketers, analysts, technical writers, and so on (Muller, Wildman, and White 1994). Perhaps this model of the HCI external work domain can be applied as a model for HCI's internal conceptual domain as well. A system or product may be based on a set of divergent principles that are known to be in conflict with one another. Perhaps a discipline can be, as well. Several recent papers have attempted to articulate this on-going tension within HCI work (e.g., Carter 1989; Checkland 1984; Floyd 1987; Thoresen 1989). Of particular importance is Floyd's (1987) discussion of the reciprocal needs of "product-oriented" and "process-oriented" paradigms in software engineering.
As applied work, HCI practice fits within a context provided by itself and other workplace activities. One of the most important HCI contexts is the computer product development life cycle -- usually denoted as the software development life cycle. HCI practice can help to inform and improve life cycle activities. Within such a life cycle, HCI emphasizes iteration and concrete communication. HCI research has demonstrated that straightforward activity categories -- such as "analysis," "design," and "evaluation" -- are not separable in practice (e.g., Guindon 1990; Hewett 1986; Olson, Olson, and Carter 1992). These tendencies, and their proven successes, are at variance with current wisdom in traditional management of large software projects, typically termed the waterfall model. HCI practitioners can help show the weaknesses of the waterfall model, but not without risk. The risk is that the somewhat marginalized field of HCI practice may lose some of its credibility and influence if it is perceived within organizations as opposing their received wisdom. There is a need to "scale up" the successes of HCI in analysis/design/assessment in the small, so that these achievements can be applied to computer product work in the large and in the very large.
0 条评论: