ABSTRACT
The development of schemes to support design, whether behavioral methods or new technologies like groupware, should be based on detailed knowledge about how design occurs. Such data can be used to suggest what kinds of tools people might need as well as to provide a baseline for evaluating the effects of schemes for improvement. We present details of how real groups work in early software design
218meetings. We studied 10 design meetings from four projects in two organizations. The meetings were videotaped, transcribed, and then analyzed using a coding scheme that looked at both the participants' problem solving and those activities they used to coordinate and manage themselves. We also analyzed the structure of their design arguments. We found, to our surprise, that although the meetings differed in how many issues were covered and the breadth of the discussion of these issues, they were strikingly similar in both how people spent their time and the sequential organization of that activity. Overall, only 40% of the time was spent in direct discussions of design, with many swift transitions between alternative ideas and their evaluation. The groups spent another 30% taking stock of their progress through walkthroughs and summaries. Pure coordination activities consumed about 20%, and clarification of ideas—a cross-cutting classification—took a third of the time, indicating how much time was spent in both orchestrating and sharing expertise among group members. The pattern of transitions revealed these activities were clustered into two general classes, design and management. We focused on the design activities, and described their sequential structure both statistically and grammatically. The structuredness of design as a group activity may lend itself to forms of support such as design rationale, although other findings in the literature suggest that doing so on the fly may be disruptive.
