My reading notes
Digest of Prototyping Approach
Bowers,John & Pycock,James (1994)
Talking through Design: Requirements and Resistance in Cooperative Prototyping
Proceedings of CHI'94.
Researchers interested in design process are concerned to argue that the quality of artifacts may be improved if reasons for design decisions are documented and design alternatives are explored sysyematically. For some researchers the HCI has so far failed to impact upon software engineering to any serious extent (Lim,1992), because HCI has inadequately appreciated the nature of real-world design and not formulated its findings or methods in ways which software engineers can easily use or exploit. It is argued that the user centred orientation of HCI is best developed by the direct and systematic involvement of end-users in the design process (Greenbaum, 1992).
The sociality of design:
Progress in technical design will only be made if we appreciate it nature as a social activity. But this is not enough. what is more challenging is to explicate how-in detail-design is a socia activity, how exactly participants coordinate or what action participants take when coordination breaks down.
User requirements and participatory design:
Trillium project was developed through regular, intensive meetings involving the participation of both users and designers. However, Blomberg and Henderson (1990, CHI,90) note variou ways in which this development effort was, in their view, only superficially participatory design. For example, designers- users meetings did not take place in the user's exact work setting.
The system and the session:
Design a tool called "Designer's Note Pad" DNP in prototype to capture, test, evaluate and generate new requirement for the prototype.
It is rarely possible to simply 'read-off' requirements from the transcript. Requirements are a negotiated product of argument and resistance and not available to be read off. "Work-like use" of versions in cooperative prototyping has developed with an accent on the emergence of new requirements.
Mogensen, P. (1991).
Towards a prototyping approach in systems development.
Scandinavian Journal of information systems Vol.2, pp31-53.
This paper explores the notion of "provocation through concrete experience" towards a prototyping approach. It addresses the question: How do we on the one hand, devise qualitatively new systems, and on the other hand, ensure their usability in a given practice ? The notion of provocation through concrete experience is developed through an investigation of prototyping and activity theory. Exploration of this notion leads to the idea of the systems developer "provoking" concrete, everyday practice, by exposing current problems, calling forth what usually is taken for granted. Problems with current practice and a lack of mutual understanding, usually conceived of as hindrances to successful systems development, are used constructively. These ideas are compared to four related approaches: Future Workshops, Metaphorical Design, cooperative prototyping, and Organizational games. The comparision serves the twofold purpose of contextualizing the new ideas as well as developing techniques for carrying them out.
2. The sources of Inspiration
Prototyping emerged in the late 1970´s.
Activity theory: "It is this very aspect of human performance (Creating new contexts ) -or rather the lack of it - that is becoming the central source of uneasiness and trouble in various fields of societal practice. (Engeström 1987, P.2)." He called expansion. Activity: Level of human agency: Operations, Actions and Activity (example of collective hunt)
Mediatedness: (triangle model)
Contradictions: (emphasize too much)
the cycle of expansive development. (too rough to guid concrete practice)
3. Provocation through concrete experience:
3.1 Why provocation: The taken-for-Grantedness of practice: Activiy theory explain invisibility of more general mediators, such as rules, work organization, language. When we move from individual action to collecyive activity, we have to deal with the "how" (operations), the what "actions) and the why (activity). (the why questions are taken for granted-they are invisible in everyday life)
3.2 What to provoke: Discrepancies(contradictions?) in a practice.
3.3: Who provokes: The system developer as provocateur.
* Designer as an expert: The expert can be said to stand in front of the practioners outling the way to go (a teacher?). in case well-structured, solutions can be defined beforehand. * Designer as a facilitator: stand beside the practioner, supplying them with the means to find out for themselves which way to go. (a Doctor ?). in case one can not defin criteria for usefulness, but one knows the problem and effort is to directed towards possible solutions..
* as a provocateur: Stand behind the practioners supplying the means to find out about the present in order to know what to look for and what to avoid in a future.
Figure 1. The Role Designers in Systems Development (Bai, 1994-04-04)
Figure 2. Design Strategy & Problems Zone (Domain) (Bai, 1994-04-05)
Kautz. K (1993)
Communication support for prototyping project.
Information and software technology, Vol35 No 11/12, pp647-65.
Communication plays a crucial role in the development of software system. In the late of 19602, Schwartz among others, reported that poor communication between programmers was one one reason for the failure of system development projects. More than 20 years later this statement is still true, as Curtis et al. state in a tudy which identifies poor communication teams as one of the major problems in system development.
prototyping is an approach to system development which has evolved from a number of more or less ad hoc techniques to an acceptrd development strategy. It involves producing early operational models, the prototypes, of a future application system. Prototyping techniques are used for experimental purposes and for gaining practical experiences.
A number of well-founded proposals for organizational and methodological support for prototyping exist .
A simulating project in which graduate students represent users and designers respectively in a month, communication was facilitated by communication consultant, wo used project diaries. Benfit of using project diaries:
The diarie documented the course of the project and the reasoning behind the decisions which influenced that course. They were used as an archive for shared knowledge and decisions, and they made visible the changes in the attitudes an dthe expectations of all person involved. Grasping the overall state of the projects was simplifies by the diaries. Project diaries supported the following specific situation: ¤ establishing a project
¤ defining a project goal
¤ structuring project meetings
¤ developing a project language
¤ providing transparency: The problem is that the project members do not understand each other, because they work on the basis of different unarticulated asumptions but fail to recognize this fact. ¤ resolving disagreements
The problem to employ a communication consultants is that project members felt that they were subjected to frequent and unnecessay interruptions and restrictions by the consultants' inquiries; they expressed an unpleasant feeling of being controlled by someone who was not perceived as an ordinary member of the project, but rather as a person whose main function was to oberve and document what was going on in the project.
Collecting and responding to feedback
An absolutely essential ingredient for a successful prototyping effort is a good system for soliciting, collecting, responding to and accounting for, user feedback. Ideally, there should be an automated form as part of the deployed system that allows a user, at any stage in working with the system, to input comments, suggestions,criticisms, trouble reports or anything else the user wants to say. The development activity should collect these daily and let the users know their comments have been received. The users should also get feedback as to the final disposition of their comments and be able to request status of open comments at any time. This mechanism needs to be among the firstcomponents implemented and must be receptive to comments about its own shortcomings, as well as those of othercomponents. As time goes on, feedback statistics will become an important part of the reviews and metrics discussed in the following sections.
Prototype sites need continuous attention and nurturing to keep producing the desired results. A prototype system is a model, an experiment, at best a preliminary version of the real system. As such, it will not be "tuned," and should not be expected to perform well. This should be briefed to the user organization as often as they will listen. However, no amount of dialogue will mitigate the bad effect of a system that is much too slow. At some point, the phrase "It's only a prototype" loses its effectiveness and some attention must be paid to making the system perform at least close to reasonable speed. Otherwise, no matter how good the design is, it will get a reputation that can damage its user acceptance more than involvement in the process enhances acceptance.
A prototype can be used as the final illustration of a system to both users and designers. Prototypes are real, manipulatable, and can be adjusted. As stated in the first Generic Prototyping article, if a picture is worth a thousand words, then a prototype should be worth more.